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 iklam at openjdk.java.net Tue Dec 1 01:14:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 01:14:55 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: <3wo_c-mOOD6m5wBMpO6uDXEi1SPBxAREMp8ai-814pY=.8f0a5223-a9ac-47e7-8c43-e1095e2aa3c6@github.com> On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold LGTM. Thanks for fixing the CDS tests. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Tue Dec 1 01:18:54 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 01:18:54 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold Hi Harold, I don't think we need to add all this new infrastructure for obsolete-aliased flags just so we can continue to print the -Xlog equivalents. I think simply adding these previously aliased flags as obsolete flags in the special flags table would suffice. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Tue Dec 1 01:33:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 01:33:58 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 01:16:11 GMT, David Holmes wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Hi Harold, > I don't think we need to add all this new infrastructure for obsolete-aliased flags just so we can continue to print the -Xlog equivalents. I think simply adding these previously aliased flags as obsolete flags in the special flags table would suffice. > Thanks, > David I should clarify this. I suggested in the bug report that we could continue to print the -Xlog equivalents, but when I wrote that I was thinking that the existing deprecated-aliased code would simply be changed to obsoleted-aliased code. I didn't consider that we might need to keep the deprecated-aliased code for future conversions to UL. But I can see now that we might want to do that. In which case I'd prefer to no longer print the -Xlog equivalents, rather than duplicate the deprecated-aliased code into an obsolete-aliased form. My intent was to get rid of this special aliased flag handling code in the near future. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From cjplummer at openjdk.java.net Tue Dec 1 01:45:56 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Tue, 1 Dec 2020 01:45:56 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> Message-ID: On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: > > * Q3: What has to be done for statically linked agent? > > JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. ------------- PR: https://git.openjdk.java.net/jdk/pull/19 From iklam at openjdk.java.net Tue Dec 1 01:54:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 01:54:57 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v3] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 07:21:13 GMT, Thomas Stuefe wrote: >> To analyze JDK-8256729 further, we need more tracing: >> >> 1) We should print all mappings inside the split area if os::split_reserved_memory() fails >> >> 2) The print-mapping code on windows has some shortcomings: >> - should not probe for mappings outside of what we know are valid address ranges for Windows >> - should handle wrap-arounds - it should be possible to print the whole address space >> - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) >> - should be printed in a more compact manner - base address should be on the same line as the first region >> - maybe adorned with some basic range info, e.g. library mappings > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Fix gtest for MacOS and AIX LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1390 From dholmes at openjdk.java.net Tue Dec 1 02:25:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 02:25:55 GMT Subject: RFR: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" [v2] In-Reply-To: References: <4GRPSMKxwFONrO-YzHXh7z8WxPHJM2tP0Y5X5uWnV10=.03265f2f-a4f7-4ef0-99e3-37701aa6b7fa@github.com> Message-ID: On Mon, 30 Nov 2020 12:57:36 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvmtiTagMap.cpp line 1162: >> >>> 1160: if (_needs_cleaning) { >>> 1161: // Recheck whether to post object free events under the lock. >>> 1162: post_object_free = post_object_free && env()->is_enabled(JVMTI_EVENT_OBJECT_FREE); >> >> Where is `is_enabled` called without the lock being held in a caller of `remove_dead_entries()`? > > void JvmtiTagMap::flush_object_free_events() { > assert_not_at_safepoint(); > if (env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > > Called by JVMTI to disable events and called by the service thread. And here for get_objects_with_tags: > > if (collector.some_dead_found() && env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { > post_dead_objects_on_vm_thread(); > } That isn't quite what I asked. The claim is that `remove_dead_entries_locked` needs to recheck `is_enabled` if `post_object_free` is true in case the enabled state changed from true to false. But I can't see how such a situation can arise. In `flush_object_free_events` we only call `remove_dead_entries(false)` and that is when events were seen to be disabled. ------------- PR: https://git.openjdk.java.net/jdk/pull/1439 From david.holmes at oracle.com Tue Dec 1 02:27:23 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2020 12:27:23 +1000 Subject: RFR: 8257396: AArch64 Zero build is broken after JDK-8252684 In-Reply-To: References: Message-ID: <9386be4d-7254-c400-3a54-60bfc2f0c757@oracle.com> On 30/11/2020 11:29 pm, Andrew Haley wrote: > On 11/30/20 12:37 PM, David Holmes wrote: >> On Mon, 30 Nov 2020 08:49:54 GMT, Aleksey Shipilev wrote: >> >>> Zero does not have AArch64 assembler, so attempt to use it from the test fails to build. The fix is trivial: sense if we are building Zero. >>> >>> Testing: >>> - [x] Linux aarch64 zero build >> >> Lets hope this is the last adjustment needed in relation to this change. > > Aren't the pre-integration tests supposed to pick up this kind of thing? Not for the zero case as Aleksey indicated. And JDK-8252684 was integrated despite the failures in the pre-integration testing. David ----- 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 david.holmes at oracle.com Tue Dec 1 02:44:29 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2020 12:44:29 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> Message-ID: <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> On 1/12/2020 11:45 am, Chris Plummer wrote: > On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: > >>> * Q3: What has to be done for statically linked agent? >> >> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. > > I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. Agreed. Even though you can't physically unload the statically linked library, if it is logically unloaded by some mechanism, then Agent_OnUnload_L is supposed to be called. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/19 > From iklam at openjdk.java.net Tue Dec 1 04:38:15 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 04:38:15 GMT Subject: RFR: 8256254: Convert vmIntrinsics::ID to enum class [v3] In-Reply-To: References: Message-ID: > This PR is follows the same style as https://github.com/openjdk/jdk/pull/276, except this time I am converting `vmIntrinsics::ID` to `vmIntrinsicID`: > > * Convert `vmIntrinsics::SID` to `enum class` to provide better type safety. > * Also, put this enum class in the top level, so it can be forward-declared. I.e., `enum class vmIntrinsicID : int;`. This avoids excessive inclusion of vmIntrinsics.hpp and vmSymbols.hpp (which were included indirectly by almost every hotspot source files). > * vmIntrinsics.hpp: was included 805 times, now included 414 times > * vmSymbols.hpp: was included 805 times, now include 394 times > * Note: more #include reduction will be done in [JDK-8256424](https://bugs.openjdk.java.net/browse/JDK-8256424) > > Many files are changed, but most of them are minor > * Added missing dependencies of vmSymbols.hpp and/or vmIntrinsics.hpp > * safe conversion between vmIntrinsicID and integer types (see comments around `vmIntrinsics::as_int()`) > > Since we have a lot of references like `vmIntrinsics::_invokeGeneric`, I added aliases like > > static const vmIntrinsicID vmIntrinsics::_invokeGeneric = vmIntrinsicID::_invokeGeneric > > so we don't need to change over a thousand `vmIntrinsics::XXX` to `vmIntrinsicID::XXX`. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - fixed merge - Merge branch 'master' into 8256254-vmintrinsics-id-class-enum - @cl4es reviews - 8256254: Convert vmIntrinsics::ID to enum class ------------- Changes: https://git.openjdk.java.net/jdk/pull/1237/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1237&range=02 Stats: 216 lines in 52 files changed: 92 ins; 17 del; 107 mod Patch: https://git.openjdk.java.net/jdk/pull/1237.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1237/head:pull/1237 PR: https://git.openjdk.java.net/jdk/pull/1237 From iklam at openjdk.java.net Tue Dec 1 04:40:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 04:40:55 GMT Subject: RFR: 8254733: HotSpot Style Guide should permit using range-based for loops In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 06:37:57 GMT, Kim Barrett wrote: > Please review and vote on this change to the HotSpot Style Guide to > permit the use of range-based `for` loops in HotSpot code. Range-based > `for` is a feature added in C++11. > > This is a modification of the Style Guide, so rough consensus among > the HotSpot Group members is required to make this change. Only Group > members should vote for approval (via the github PR), though reasoned > objectsions or comments from anyone will be considered. A decision on > this proposal will not be made before Monday 7-Dec-2020 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review > process to approve (click on Review Changes > Approve), rather than > sending a "vote: yes" email reply that would be normal for a CFV. > Other responses can still use email of course. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1488 From suenaga at oss.nttdata.com Tue Dec 1 04:46:14 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 1 Dec 2020 13:46:14 +0900 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> Message-ID: <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> Hi Chris, David, Currently Agent_OnUnload() is not called when Agent_OnLoad() is failed - JVM will abort. Should we re-think this behavior? https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld ``` $ java -agentpath:/path/to/libhelloworld.so=error --version Hello World from Agent_OnLoad() options = error Error occurred during initialization of VM agent library failed to init: /path/to/libhelloworld.so ``` Thanks, Yasumasa On 2020/12/01 11:44, David Holmes wrote: > On 1/12/2020 11:45 am, Chris Plummer wrote: >> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: >> >>>> * Q3: What has to be done for statically linked agent? >>> >>> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. >> >> I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. > > Agreed. Even though you can't physically unload the statically linked library, if it is logically unloaded by some mechanism, then Agent_OnUnload_L is supposed to be called. > > David > ----- > >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/19 >> From kbarrett at openjdk.java.net Tue Dec 1 04:49:14 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 1 Dec 2020 04:49:14 GMT Subject: RFR: 8257466: Improve enum iteration Message-ID: Please review this collection of improvements to the recently added enum iteration facility. These improvements are based on usage in some in-development changes. (1) Added EnumType nested type to EnumRange and EnumIterator. It is an alias for the enum type that is a template parameter for those classes. This is useful when dealing with a range or iterator whose associated enum type is not known because the range/iterator is a template parameter. (2) Added EnumRange::index(T), which converts the argument enumerator to a zero-based index into the range of values. This is useful when mapping from an enumerator to a corresponding array index, for example. (3) Allow enum range bounds to be specified using start and (exclusive) end integral (underlying type) values. This is useful when dealing with enums that are just value ranges and don't have named enumerators. As part of this, changes the enum iteration traits mechanism to use start/end rather than first/last, as that seems to be a little easier to deal with. (4) Added accessors for the first and last enumerator values of a range. (5) Added gtest for enum iteration. Testing: tier1 ------------- Commit messages: - 8257466: Improve enum iteration Changes: https://git.openjdk.java.net/jdk/pull/1530/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1530&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257466 Stats: 187 lines in 2 files changed: 165 ins; 1 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1530/head:pull/1530 PR: https://git.openjdk.java.net/jdk/pull/1530 From kbarrett at openjdk.java.net Tue Dec 1 05:01:55 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 1 Dec 2020 05:01:55 GMT Subject: RFR: 8254733: HotSpot Style Guide should permit using range-based for loops In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 06:37:57 GMT, Kim Barrett wrote: > Please review and vote on this change to the HotSpot Style Guide to > permit the use of range-based `for` loops in HotSpot code. Range-based > `for` is a feature added in C++11. > > This is a modification of the Style Guide, so rough consensus among > the HotSpot Group members is required to make this change. Only Group > members should vote for approval (via the github PR), though reasoned > objectsions or comments from anyone will be considered. A decision on > this proposal will not be made before Monday 7-Dec-2020 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review > process to approve (click on Review Changes > Approve), rather than > sending a "vote: yes" email reply that would be normal for a CFV. > Other responses can still use email of course. > @kimbarrett > > Not related to these changes which are fine. > > I looked again on voting description for Style Guide changes. And it references to `rough consensus` which is not in OpenJDK bylaws : > https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html#L69 > > I think it is bug (separate from these changes) and should be fixed by using our rule http://openjdk.java.net/bylaws#three-vote-consensus > With Project Lead final vote we will need at least 2 other members votes during 2 weeks review period. I think it is similar to `rough consensus`. I'm going to move this discussion to a new thread in hotspot-dev. ------------- PR: https://git.openjdk.java.net/jdk/pull/1488 From david.holmes at oracle.com Tue Dec 1 05:19:04 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2020 15:19:04 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> Message-ID: On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: > Hi Chris, David, > > Currently Agent_OnUnload() is not called when Agent_OnLoad() is failed - > JVM will abort. > Should we re-think this behavior? We should we rethink that? It is probably one of the clearest parts of the spec. If Agent_Onload fails that is considered a fatal error - end of story. The issue is with Agent_onAttach and how its failure should, or should not, impact Agent_OnUnload. David ----- > https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld > > ``` > $ java -agentpath:/path/to/libhelloworld.so=error --version > Hello World from Agent_OnLoad() > ? options = error > Error occurred during initialization of VM > agent library failed to init: /path/to/libhelloworld.so > ``` > > > Thanks, > > Yasumasa > > > On 2020/12/01 11:44, David Holmes wrote: >> On 1/12/2020 11:45 am, Chris Plummer wrote: >>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga >>> wrote: >>> >>>>> * Q3: What has to be done for statically linked agent? >>>> >>>> JVMTI spec says "unless it is statically linked into the >>>> executable", so I think we can ignore about Agent_OnUnload_L() in >>>> this PR. >>> >>> I don't think that makes sense. If you call it for dynamically linked >>> then you need to call it for statically linked also. >> >> Agreed. Even though you can't physically unload the statically linked >> library, if it is logically unloaded by some mechanism, then >> Agent_OnUnload_L is supposed to be called. >> >> David >> ----- >> >>> ------------- >>> >>> PR: https://git.openjdk.java.net/jdk/pull/19 >>> From david.holmes at oracle.com Tue Dec 1 05:21:27 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2020 15:21:27 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> Message-ID: On 1/12/2020 3:19 pm, David Holmes wrote: > On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >> Hi Chris, David, >> >> Currently Agent_OnUnload() is not called when Agent_OnLoad() is failed >> - JVM will abort. >> Should we re-think this behavior? > > We should we rethink that? It is probably one of the clearest parts of > the spec. If Agent_Onload fails that is considered a fatal error - end > of story. I meant, of course, "Why should we rethink that?". David > The issue is with Agent_onAttach and how its failure should, or should > not, impact Agent_OnUnload. > > David > ----- > >> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >> >> ``` >> $ java -agentpath:/path/to/libhelloworld.so=error --version >> Hello World from Agent_OnLoad() >> ?? options = error >> Error occurred during initialization of VM >> agent library failed to init: /path/to/libhelloworld.so >> ``` >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2020/12/01 11:44, David Holmes wrote: >>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga >>>> wrote: >>>> >>>>>> * Q3: What has to be done for statically linked agent? >>>>> >>>>> JVMTI spec says "unless it is statically linked into the >>>>> executable", so I think we can ignore about Agent_OnUnload_L() in >>>>> this PR. >>>> >>>> I don't think that makes sense. If you call it for dynamically >>>> linked then you need to call it for statically linked also. >>> >>> Agreed. Even though you can't physically unload the statically linked >>> library, if it is logically unloaded by some mechanism, then >>> Agent_OnUnload_L is supposed to be called. >>> >>> David >>> ----- >>> >>>> ------------- >>>> >>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>> From iklam at openjdk.java.net Tue Dec 1 05:38:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 05:38:57 GMT Subject: RFR: 8256254: Convert vmIntrinsics::ID to enum class [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 10:22:10 GMT, Claes Redestad wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @cl4es reviews > > Marked as reviewed by redestad (Reviewer). Thanks @cl4es and @vnkozlov for the review. Passed tier1,tier2,builds-tier3,builds-tier4,builds-tier5 ------------- PR: https://git.openjdk.java.net/jdk/pull/1237 From iklam at openjdk.java.net Tue Dec 1 05:38:59 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 05:38:59 GMT Subject: Integrated: 8256254: Convert vmIntrinsics::ID to enum class In-Reply-To: References: Message-ID: On Mon, 16 Nov 2020 20:46:46 GMT, Ioi Lam wrote: > This PR is follows the same style as https://github.com/openjdk/jdk/pull/276, except this time I am converting `vmIntrinsics::ID` to `vmIntrinsicID`: > > * Convert `vmIntrinsics::SID` to `enum class` to provide better type safety. > * Also, put this enum class in the top level, so it can be forward-declared. I.e., `enum class vmIntrinsicID : int;`. This avoids excessive inclusion of vmIntrinsics.hpp and vmSymbols.hpp (which were included indirectly by almost every hotspot source files). > * vmIntrinsics.hpp: was included 805 times, now included 414 times > * vmSymbols.hpp: was included 805 times, now include 394 times > * Note: more #include reduction will be done in [JDK-8256424](https://bugs.openjdk.java.net/browse/JDK-8256424) > > Many files are changed, but most of them are minor > * Added missing dependencies of vmSymbols.hpp and/or vmIntrinsics.hpp > * safe conversion between vmIntrinsicID and integer types (see comments around `vmIntrinsics::as_int()`) > > Since we have a lot of references like `vmIntrinsics::_invokeGeneric`, I added aliases like > > static const vmIntrinsicID vmIntrinsics::_invokeGeneric = vmIntrinsicID::_invokeGeneric > > so we don't need to change over a thousand `vmIntrinsics::XXX` to `vmIntrinsicID::XXX`. This pull request has now been integrated. Changeset: f48737c7 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/f48737c7 Stats: 216 lines in 52 files changed: 92 ins; 17 del; 107 mod 8256254: Convert vmIntrinsics::ID to enum class Reviewed-by: redestad, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1237 From david.holmes at oracle.com Tue Dec 1 05:59:53 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Dec 2020 15:59:53 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> Message-ID: Looking at the original webrev from September: https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html The suggestion to unload the library if Agent_OnAttach fails seems quite reasonable - it is what happens if no Agent_OnAttach function can be found in the agent. But the specification is lacking because it simply states any such error is "ignored" - which is an oversimplification and I think was really intended to contrast with the abort behaviour if Agent_OnLoad fails. In addition the specification indicates that Agent_OnUnload is called any time the agent library is unloaded, except for "uncontrolled shutdown". This unfortunately suggests that before unloading the library after OnAttach fails, we also call OnUnload. That seems wrong and in fact the VM does not do that - and noone seems to have complained. Also note the specification states an agent "must export a start-up function ..." but doesn't say what happens if it doesn't do so. My gut feeling for what the specification should say here is that if the start-up function does not exist, or the call to Agent_OnAttach reports an error, then the agent library is immediately unloaded with no attempt to call the agent shutdown function (Agent_OnUnload). But with my "compatibility glasses" on this may be too strong to retrofit to the specification as other VMs may behave differently. So as I stated in the CSR request we probably want to allow the current hotspot behaviour but not mandate it (unless we check with all the other VM implementations that such a specification is okay with them). I agree that the more general issue of re-loading an agent is a separate issue. David ----- On 1/12/2020 3:21 pm, David Holmes wrote: > On 1/12/2020 3:19 pm, David Holmes wrote: >> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>> Hi Chris, David, >>> >>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is >>> failed - JVM will abort. >>> Should we re-think this behavior? >> >> We should we rethink that? It is probably one of the clearest parts of >> the spec. If Agent_Onload fails that is considered a fatal error - end >> of story. > > I meant, of course, "Why should we rethink that?". > > David > >> The issue is with Agent_onAttach and how its failure should, or should >> not, impact Agent_OnUnload. >> >> David >> ----- >> >>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>> >>> ``` >>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>> Hello World from Agent_OnLoad() >>> ?? options = error >>> Error occurred during initialization of VM >>> agent library failed to init: /path/to/libhelloworld.so >>> ``` >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2020/12/01 11:44, David Holmes wrote: >>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga >>>>> wrote: >>>>> >>>>>>> * Q3: What has to be done for statically linked agent? >>>>>> >>>>>> JVMTI spec says "unless it is statically linked into the >>>>>> executable", so I think we can ignore about Agent_OnUnload_L() in >>>>>> this PR. >>>>> >>>>> I don't think that makes sense. If you call it for dynamically >>>>> linked then you need to call it for statically linked also. >>>> >>>> Agreed. Even though you can't physically unload the statically >>>> linked library, if it is logically unloaded by some mechanism, then >>>> Agent_OnUnload_L is supposed to be called. >>>> >>>> David >>>> ----- >>>> >>>>> ------------- >>>>> >>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>> From suenaga at oss.nttdata.com Tue Dec 1 06:41:43 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Tue, 1 Dec 2020 15:41:43 +0900 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> Message-ID: <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> Hi David, On 2020/12/01 14:59, David Holmes wrote: > Looking at the original webrev from September: > > https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html > > The suggestion to unload the library if Agent_OnAttach fails seems quite reasonable - it is what happens if no Agent_OnAttach function can be found in the agent. > > But the specification is lacking because it simply states any such error is "ignored" - which is an oversimplification and I think was really intended to contrast with the abort behaviour if Agent_OnLoad fails. In addition the specification indicates that Agent_OnUnload is called any time the agent library is unloaded, except for "uncontrolled shutdown". This unfortunately suggests that before unloading the library after OnAttach fails, we also call OnUnload. That seems wrong and in fact the VM does not do that - and noone seems to have complained. > > Also note the specification states an agent "must export a start-up function ..." but doesn't say what happens if it doesn't do so. > > My gut feeling for what the specification should say here is that if the start-up function does not exist, or the call to Agent_OnAttach reports an error, then the agent library is immediately unloaded with no attempt to call the agent shutdown function (Agent_OnUnload). That's what I wanted to suggest! I understand we need to consider following case in this issue, is it right? Agent_OnLoad / Agent_OnLoad_L does not exist: - Agent_OnUnload is not called - DLL is not unloaded (JVM will abort) Agent_OnLoad / Agent_OnLoad_L failed: - Agent_OnUnload is not called - DLL is not unloaded (JVM will abort) Agent_OnAttach does not exist: - Agent_OnUnload is not called - DLL is unloaded Agent_OnAttach_L does not exist: - Agent_OnUnload is not called - DLL is not unloaded (static link) Agent_OnAttach failed: - Agent_OnUnload is not called - DLL is unloaded Agent_OnAttach_L faled: - Agent_OnUnload is not called - DLL is not unloaded (static link) > But with my "compatibility glasses" on this may be too strong to retrofit to the specification as other VMs may behave differently. So as I stated in the CSR request we probably want to allow the current hotspot behaviour but not mandate it (unless we check with all the other VM implementations that such a specification is okay with them). Ok, for example, can we change the spec as following? (Of course, this is not all) ``` diff --git a/src/hotspot/share/prims/jvmti.xml b/src/hotspot/share/prims/jvmti.xml index 44553b8065f..57c87b1a71b 100644 --- a/src/hotspot/share/prims/jvmti.xml +++ b/src/hotspot/share/prims/jvmti.xml @@ -688,7 +688,8 @@ Agent_OnUnload_L(JavaVM *vm) mechanism causes the unload (an unload mechanism is not specified in this document) or the library is (in effect) unloaded by the termination of the VM whether through normal termination or VM failure, including start-up failure. - Uncontrolled shutdown is, of course, an exception to this rule. + Uncontrolled shutdown is, of course, an exception to this rule, and also it might not be called + when start-up function does not exist or fails (returns non-zero value). Note the distinction between this function and the VM Death event: for the VM Death event to be sent, the VM must have run at least to the point of initialization and a valid ``` > I agree that the more general issue of re-loading an agent is a separate issue. Thanks! Yasumasa > David > ----- > > On 1/12/2020 3:21 pm, David Holmes wrote: >> On 1/12/2020 3:19 pm, David Holmes wrote: >>> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>>> Hi Chris, David, >>>> >>>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is failed - JVM will abort. >>>> Should we re-think this behavior? >>> >>> We should we rethink that? It is probably one of the clearest parts of the spec. If Agent_Onload fails that is considered a fatal error - end of story. >> >> I meant, of course, "Why should we rethink that?". >> >> David >> >>> The issue is with Agent_onAttach and how its failure should, or should not, impact Agent_OnUnload. >>> >>> David >>> ----- >>> >>>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>>> >>>> ``` >>>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>>> Hello World from Agent_OnLoad() >>>> ?? options = error >>>> Error occurred during initialization of VM >>>> agent library failed to init: /path/to/libhelloworld.so >>>> ``` >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2020/12/01 11:44, David Holmes wrote: >>>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: >>>>>> >>>>>>>> * Q3: What has to be done for statically linked agent? >>>>>>> >>>>>>> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. >>>>>> >>>>>> I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. >>>>> >>>>> Agreed. Even though you can't physically unload the statically linked library, if it is logically unloaded by some mechanism, then Agent_OnUnload_L is supposed to be called. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> ------------- >>>>>> >>>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>>> From kim.barrett at oracle.com Tue Dec 1 06:43:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Dec 2020 01:43:15 -0500 Subject: HotSpot Style Guide change process Message-ID: <376E1F97-57DE-46CD-B656-BC5340E0BA07@oracle.com> When the Style Guide was updated for C++11/14 usage and other cleanup (JDK-8247976), a change process was added to it. It says Proposed changes should be discussed on the [HotSpot Developers](mailto:hotspot-dev at openjdk.java.net) mailing list, and approved by [rough consensus](https://en.wikipedia.org/wiki/Rough_consensus) of the [HotSpot Group](https://openjdk.java.net/census#hotspot) Members. The Group Lead determines whether consensus has been reached. Changes are likely to be cautious and incremental, since HotSpot coders have been using these guidelines for years. Vladimir Kozlov has questioned this process and suggests another: > I looked again on voting description for Style Guide changes. And it > references to `rough consensus` which is not in OpenJDK bylaws : > https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html#L69 > > I think it is bug (separate from these changes) and should be fixed by > using our rule http://openjdk.java.net/bylaws#three-vote-consensus > With Project Lead final vote we will need at least 2 other members votes > during 2 weeks review period. I think it is similar to `rough consensus`. Use of "rough consensus" with an arbiter has precedent within the OpenJDK, though it's not used in the bylaws. The current text quoted above was based on https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html JEP 2.0, draft 2 - see "Planning", 4th bullet and https://openjdk.java.net/groups/vulnerability/ OpenJDK Vulnerability Group - see "Making decisions" So both the JEP Process and the Vulnerability Group use rough consensus, with the relevant lead as the arbiter. (The V-Team page links to an IETF document describing rough consensus. The HotSpot Style Guide links to the same Wikipedia article as the JEP 2.0 Process; that Wikipedia article references the IETF page.) I called out the new change process specifically in the initial RFR email for JDK-8247976, but that part didn't generate much (any?) discussion. If we don't like it we are certainly free to change. And if Vladimir doesn't like it then we should change, since as HotSpot Lead he's fairly central to that process. But I don't think there's a "lack of precedent" or "not appropriate for OpenJDK" argument for changing. I chose that process because I didn't want it to be too easy to make changes to the Style Guide. In particular, I think it should require more effort than is involved in a typical RFR. Even if we don't change, and especially if we do, some further refinement of the mechanics may be needed. I think the current mechanics may have a problem that the request shows up in one's mailbox looking pretty much like an ordinary RFR. When I was originally thinking about that text we were in a world of pure email change requests, and the document was still a wiki page. With the move of the document to the jdk repository and the move to github and PRs + Skara support for changes, the mechanics are different. It might be better if it could be subject tagged differently, as we do with Call for Vote emails. There are probably things we could do about that, if others agree that's a problem. Or maybe some of you see other problems? From stuefe at openjdk.java.net Tue Dec 1 07:13:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 07:13:57 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 01:51:57 GMT, Ioi Lam wrote: > LGTM Thanks, Ioi! ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From shade at openjdk.java.net Tue Dec 1 07:18:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 07:18:57 GMT Subject: Integrated: 8257396: AArch64 Zero build is broken after JDK-8252684 In-Reply-To: References: Message-ID: <2Bxo62ExXw1tOzDUmiZN4k7Si8a43DlvQu6xyr46ehY=.de7fa9e8-abb9-47e4-93f9-10c24a1b580b@github.com> On Mon, 30 Nov 2020 08:49:54 GMT, Aleksey Shipilev wrote: > Zero does not have AArch64 assembler, so attempt to use it from the test fails to build. The fix is trivial: sense if we are building Zero. > > Testing: > - [x] Linux aarch64 zero build This pull request has now been integrated. Changeset: 13bd2e82 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/13bd2e82 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8257396: AArch64 Zero build is broken after JDK-8252684 Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1511 From shade at openjdk.java.net Tue Dec 1 07:54:14 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 07:54:14 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v9] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. > > C1 code is platform-independent, and it adds the new node which is then lowered to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackholeJava` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Fix _out_arg_limit calculation, fixes the remaining Matcher assert failure ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/8a84621b..672ee3a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From stefank at openjdk.java.net Tue Dec 1 08:39:56 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 1 Dec 2020 08:39:56 GMT Subject: RFR: 8257415: ZGC: Fix barrier_data types In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 12:42:00 GMT, Per Liden wrote: > The `barrier_data` is an `uint8_t`, but we sometimes pass it around as an `int`. With this patch we always treat it as an `uint8_t`. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1514 From shade at openjdk.java.net Tue Dec 1 08:43:14 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 08:43:14 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v10] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. > > C1 code is platform-independent, and it adds the new node which is then lowered to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request incrementally with three additional commits since the last revision: - Revert unnecessary CompilerOracle changes - Use new "no_reg_save_policy" for blackholes, instead of special-casing the kills - Further simplifications ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/672ee3a6..bfd7e9cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=08-09 Stats: 28 lines in 6 files changed: 17 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From eosterlund at openjdk.java.net Tue Dec 1 08:47:53 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 1 Dec 2020 08:47:53 GMT Subject: RFR: 8254733: HotSpot Style Guide should permit using range-based for loops In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 06:37:57 GMT, Kim Barrett wrote: > Please review and vote on this change to the HotSpot Style Guide to > permit the use of range-based `for` loops in HotSpot code. Range-based > `for` is a feature added in C++11. > > This is a modification of the Style Guide, so rough consensus among > the HotSpot Group members is required to make this change. Only Group > members should vote for approval (via the github PR), though reasoned > objectsions or comments from anyone will be considered. A decision on > this proposal will not be made before Monday 7-Dec-2020 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review > process to approve (click on Review Changes > Approve), rather than > sending a "vote: yes" email reply that would be normal for a CFV. > Other responses can still use email of course. Marked as reviewed by eosterlund (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1488 From shade at openjdk.java.net Tue Dec 1 08:57:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 08:57:10 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. > > C1 code is platform-independent, and it adds the new node which is then lowered to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Cleanup BlackholeCallGenerator ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/bfd7e9cf..0c167e2a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=09-10 Stats: 18 lines in 1 file changed: 2 ins; 14 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Tue Dec 1 08:57:10 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 08:57:10 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes In-Reply-To: References: Message-ID: <7sCtDCvcHRqYt-Km9Sc4HOz17L8AjEfaeibO-eO8KFU=.14cf9453-6955-44d8-8bdd-c2bcc82556b1@github.com> On Wed, 25 Nov 2020 12:42:57 GMT, Vladimir Ivanov wrote: >>> Modulo the supports_blackholes switch that logic is essentially the same on all platforms, isn't it? Why can you not just fold the relevant case handling into the generated matcher code? Wouldn't that just require a special case switch to decide whether to use the AD file rule to reduce a `CallJavaNode` vs reducing it to nothing? >> >> Is there a guide rail how to do that? Because I cannot see how we can "reduce to nothing" during matching. We still have to match `CallJavaNode` to something, if not to `MachCallJavaNode`. For that, we need `.ad` match rules, AFAICS. >> >> I am exploring if we I can instead do `CallBlackholeNode` as the subclass of `CallJavaNode`, and match it directly. It would also allow ask Matcher if underlying `.ad` supports blackholes by doing `is_match_rule_supported`. It would still add match rules for blackholes to `.ad`-s, but at least it would not need to inject into current match rules. > > Even if there are no instructions issued, some of the unfortunate effects of a call may be still there (e.g., spills around the place where the node is scheduled, memory state is effectively killed). Fixing that would involve overriding calling conventions, in_RegMask()/out_RegMask(), customize memory effects. > > Can you elaborate on your experiment with introducing custom node you mentioned? > Have you tried introducing new control node and just wire data nodes to it? Okay, I think I massaged the C2 code to make it much less intrusive. @iwanowww, does it spark joy for you? Instead of `CallBlackholeJava` node, it is now `CallBlackhole`, the direct descendant of `Call`. It gives us a few improvements: we control how that node is emitted by using its own `CallGenerator` instead of hacking into existing generator, which also absolves us from doing cleanups in `Ideal`. Plus, we can do a few other additions, like `no_reg_save_policy` to avoid grotesque special-casing for new node around register kills, and rather give the node its own special reg save policy. The only suggestion I failed to follow up on is constructing `MachCallBlackhole` directly in `Matcher`, thus trying to avoid `.ad` changes. I could not find a good place in `Matcher` to do that. I think having a single match rule per `.ad` is still tolerable. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From kbarrett at openjdk.java.net Tue Dec 1 10:04:54 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 1 Dec 2020 10:04:54 GMT Subject: RFR: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" [v2] In-Reply-To: References: <4GRPSMKxwFONrO-YzHXh7z8WxPHJM2tP0Y5X5uWnV10=.03265f2f-a4f7-4ef0-99e3-37701aa6b7fa@github.com> Message-ID: On Tue, 1 Dec 2020 02:22:57 GMT, David Holmes wrote: >> void JvmtiTagMap::flush_object_free_events() { >> assert_not_at_safepoint(); >> if (env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { >> >> Called by JVMTI to disable events and called by the service thread. And here for get_objects_with_tags: >> >> if (collector.some_dead_found() && env()->is_enabled(JVMTI_EVENT_OBJECT_FREE)) { >> post_dead_objects_on_vm_thread(); >> } > > That isn't quite what I asked. The claim is that `remove_dead_entries_locked` needs to recheck `is_enabled` if `post_object_free` is true in case the enabled state changed from true to false. But I can't see how such a situation can arise. In `flush_object_free_events` we only call `remove_dead_entries(false)` and that is when events were seen to be disabled. I think you've missed the indirect remove_dead_entries(true) via post_dead_objects_on_vm_thread() in the enabled case, over on the vmthread. And that's exactly the case that shows up in the hs_err file. The assert happens on the vmthread, in the VMOp used by post_dead_entries_xxx: Stack: [0x00007f07456c6000,0x00007f07457c6000], sp=0x00007f07457c48c0, free space=1018k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x11e92fc] JvmtiExport::post_object_free(JvmtiEnv*, long)+0x8c V [libjvm.so+0x12293b2] JvmtiTagMapTable::remove_dead_entries(JvmtiEnv*, bool)+0x192 V [libjvm.so+0x12212cd] VM_JvmtiPostObjectFree::doit()+0x5d V [libjvm.so+0x198469a] VM_Operation::evaluate()+0x18a V [libjvm.so+0x19a7e7f] VMThread::evaluate_operation(VM_Operation*)+0x17f V [libjvm.so+0x19a88cc] VMThread::inner_execute(VM_Operation*)+0x17c V [libjvm.so+0x19a8b85] VMThread::loop()+0xb5 V [libjvm.so+0x19a8cba] VMThread::run()+0xca V [libjvm.so+0x1893db0] Thread::call_run()+0x100 V [libjvm.so+0x1574796] thread_native_entry(Thread*)+0x116 ------------- PR: https://git.openjdk.java.net/jdk/pull/1439 From pliden at openjdk.java.net Tue Dec 1 10:43:55 2020 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 1 Dec 2020 10:43:55 GMT Subject: Integrated: 8257415: ZGC: Fix barrier_data types In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 12:42:00 GMT, Per Liden wrote: > The `barrier_data` is an `uint8_t`, but we sometimes pass it around as an `int`. With this patch we always treat it as an `uint8_t`. This pull request has now been integrated. Changeset: 021dced2 Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/021dced2 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod 8257415: ZGC: Fix barrier_data types Reviewed-by: smonteith, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/1514 From pliden at openjdk.java.net Tue Dec 1 10:43:54 2020 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 1 Dec 2020 10:43:54 GMT Subject: RFR: 8257415: ZGC: Fix barrier_data types In-Reply-To: References: Message-ID: <2_dBqDO9TzC9UTzAnRq4HBobGpQLMUsoSMXNlK368VA=.27b1fcf1-e8a2-49c0-ad3c-8909a5b82a76@github.com> On Tue, 1 Dec 2020 08:37:38 GMT, Stefan Karlsson wrote: >> The `barrier_data` is an `uint8_t`, but we sometimes pass it around as an `int`. With this patch we always treat it as an `uint8_t`. > > Marked as reviewed by stefank (Reviewer). Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/1514 From stuefe at openjdk.java.net Tue Dec 1 11:16:17 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 11:16:17 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v4] In-Reply-To: References: Message-ID: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings Thomas Stuefe 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: - Print a short snippet for unknown mappings - Merge - Fix gtest for MacOS and AIX - Merge - Initial patch ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1390/files - new: https://git.openjdk.java.net/jdk/pull/1390/files/be7acf6c..e2b71654 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=02-03 Stats: 14114 lines in 328 files changed: 9461 ins; 2685 del; 1968 mod Patch: https://git.openjdk.java.net/jdk/pull/1390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1390/head:pull/1390 PR: https://git.openjdk.java.net/jdk/pull/1390 From coleenp at openjdk.java.net Tue Dec 1 12:13:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 12:13:56 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold I agree with David. We should remove the helpful messages at least for most of the obsolete Print/Trace flags. Not sure about the big 3 though. src/hotspot/share/runtime/arguments.cpp line 617: > 615: #ifndef PRODUCT > 616: // These options are removed in jdk9. Remove this code for jdk10. > 617: static AliasedFlag const removed_develop_logging_flags[] = { I think this removed_develop_logging_flags infrastructure should be removed. src/hotspot/share/runtime/arguments.cpp line 612: > 610: { "TraceRedefineClasses", "-Xlog:redefine+class=", "info", "16.0" }, > 611: { "PrintJNIResolving", "-Xlog:jni+resolve=", "debug", "16.0" }, > 612: { NULL, NULL, NULL, NULL } I think if we wanted to give a message that the flag was obsolete and to suggest changing the command line, we should only do it for -XX:+TraceClassLoading and -XX:+TraceExceptions (I'd originally thought -XX:+TraceClassUnloading was important enough to release note but now I'm not so sure.) The rest of the flags should either go in the table that they're no longer recognized. src/hotspot/share/runtime/arguments.cpp line 1325: > 1323: *arg == '+' ? obs_replacement->tag_name : "off"); > 1324: return true; > 1325: } I see you left this empty in case we change more flags to logging flags. I don't see any Trace flags left that users would care about that merit this amount of helpfulness. I think this should be removed too. ------------- Changes requested by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From coleenp at openjdk.java.net Tue Dec 1 12:22:55 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 12:22:55 GMT Subject: RFR: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" [v2] In-Reply-To: References: <4GRPSMKxwFONrO-YzHXh7z8WxPHJM2tP0Y5X5uWnV10=.03265f2f-a4f7-4ef0-99e3-37701aa6b7fa@github.com> Message-ID: On Tue, 1 Dec 2020 10:02:08 GMT, Kim Barrett wrote: >> That isn't quite what I asked. The claim is that `remove_dead_entries_locked` needs to recheck `is_enabled` if `post_object_free` is true in case the enabled state changed from true to false. But I can't see how such a situation can arise. In `flush_object_free_events` we only call `remove_dead_entries(false)` and that is when events were seen to be disabled. > > I think you've missed the indirect remove_dead_entries(true) via > post_dead_objects_on_vm_thread() in the enabled case, over on the vmthread. > And that's exactly the case that shows up in the hs_err file. The assert > happens on the vmthread, in the VMOp used by post_dead_entries_xxx: > > Stack: [0x00007f07456c6000,0x00007f07457c6000], sp=0x00007f07457c48c0, free space=1018k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x11e92fc] JvmtiExport::post_object_free(JvmtiEnv*, long)+0x8c > V [libjvm.so+0x12293b2] JvmtiTagMapTable::remove_dead_entries(JvmtiEnv*, bool)+0x192 > V [libjvm.so+0x12212cd] VM_JvmtiPostObjectFree::doit()+0x5d > V [libjvm.so+0x198469a] VM_Operation::evaluate()+0x18a > V [libjvm.so+0x19a7e7f] VMThread::evaluate_operation(VM_Operation*)+0x17f > V [libjvm.so+0x19a88cc] VMThread::inner_execute(VM_Operation*)+0x17c > V [libjvm.so+0x19a8b85] VMThread::loop()+0xb5 > V [libjvm.so+0x19a8cba] VMThread::run()+0xca > V [libjvm.so+0x1893db0] Thread::call_run()+0x100 > V [libjvm.so+0x1574796] thread_native_entry(Thread*)+0x116 In flush_object_free_events, we read that the event is enabled outside the lock, then we call remove_dead_entries(true). Then remove_dead_entries() gets the table lock and proceeds to walk the table and post the events. Another thread could be disabling the event while this is happening, leading to the assert. So the fix is to make enabling/disabling the event be under the same table lock, and recheck that the event is enabled under that lock in remove_dead_entries_locked. ------------- PR: https://git.openjdk.java.net/jdk/pull/1439 From coleenp at openjdk.java.net Tue Dec 1 12:50:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 12:50:02 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() Message-ID: The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. ------------- Commit messages: - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. - 8257140: Crash in JvmtiTagMap::flush_object_free_events() Changes: https://git.openjdk.java.net/jdk/pull/1539/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1539&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257140 Stats: 25 lines in 5 files changed: 17 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1539/head:pull/1539 PR: https://git.openjdk.java.net/jdk/pull/1539 From coleenp at openjdk.java.net Tue Dec 1 12:50:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 12:50:02 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:44:24 GMT, Coleen Phillimore wrote: > The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. > > There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. > > The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. Test passed tier1-3 with no failures. ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From vlivanov at openjdk.java.net Tue Dec 1 12:55:01 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Tue, 1 Dec 2020 12:55:01 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 08:57:10 GMT, Aleksey Shipilev wrote: >> JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: >> >> 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. >> 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. >> 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. >> >> Supporting this directly in compilers would improve nanobenchmark fidelity. >> >> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). >> >> Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. >> >> C1 code is platform-independent, and it adds the new node which is then lowered to nothing. >> >> C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. >> >> [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. >> >> [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. >> >> ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup BlackholeCallGenerator Yeah, it shapes really well! ?? Looks much better now. > The only suggestion I failed to follow up on is constructing `MachCallBlackhole` directly in `Matcher`, thus trying to avoid `.ad` changes. I could not find a good place in `Matcher` to do that. I think having a single match rule per `.ad` is still tolerable. `Matcher::match_sfpt()` has call-specific logic for different shapes. Having a special case for Blackhole which turns `CallBlackhole` into `MachCallBlackhole` fits it well. Since every AD instruction has a dedicated class, you can get rid of some additional changes if you customize matching logic for blackhole. Some minor comments follow. src/hotspot/share/c1/c1_GraphBuilder.cpp line 3469: > 3467: Values* args = state()->pop_arguments(callee->arg_size()); > 3468: > 3469: // Blackhole everything except the receiver itself Does it make sense to limit blackhole candidates to static methods only? Otherwise, you end up with a null check in the generated code. src/hotspot/share/c1/c1_InstructionPrinter.cpp line 865: > 863: > 864: void InstructionPrinter::do_Blackhole(Blackhole* x) { > 865: if (x->v() != NULL) { Should be an assert instead? (LIRGenerator::do_Blackhole doesn't expect NULL.) src/hotspot/share/opto/doCall.cpp line 115: > 113: > 114: // Try blackholing a method > 115: if (callee->is_loaded() && The check can be turned into a property on `ciMethod` and the result cached there. src/hotspot/cpu/aarch64/aarch64.ad line 1778: > 1776: } > 1777: > 1778: int MachCallBlackholeNode::ret_addr_offset() { It can be moved into shared code (`machnode.cpp`). src/hotspot/share/c1/c1_GraphBuilder.cpp line 2032: > 2030: if (target->is_loaded() && target->return_type()->basic_type() == T_VOID && > 2031: compilation()->directive()->should_blackhole(target)) { > 2032: if (try_blackhole(target)) { Since `try_blackhole` can't fail, why do the check at all? src/hotspot/share/opto/machnode.cpp line 817: > 815: void MachCallBlackholeNode::dump_spec(outputStream *st) const { > 816: st->print("Blackhole "); > 817: MachCallNode::dump_spec(st); How does the output look like? It would be nice to have the info what are the values being consumed and where they are located. src/hotspot/share/opto/callnode.hpp line 780: > 778: virtual uint size_of() const; // Size is bigger > 779: public: > 780: CallBlackholeNode( const TypeFunc *tf , address addr) : CallNode(tf, addr, TypePtr::BOTTOM) { `addr` can be omitted since it is always `NULL`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From dholmes at openjdk.java.net Tue Dec 1 13:03:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 13:03:55 GMT Subject: RFR: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" [v2] In-Reply-To: References: <4GRPSMKxwFONrO-YzHXh7z8WxPHJM2tP0Y5X5uWnV10=.03265f2f-a4f7-4ef0-99e3-37701aa6b7fa@github.com> Message-ID: On Tue, 1 Dec 2020 10:02:08 GMT, Kim Barrett wrote: >> That isn't quite what I asked. The claim is that `remove_dead_entries_locked` needs to recheck `is_enabled` if `post_object_free` is true in case the enabled state changed from true to false. But I can't see how such a situation can arise. In `flush_object_free_events` we only call `remove_dead_entries(false)` and that is when events were seen to be disabled. > > I think you've missed the indirect remove_dead_entries(true) via > post_dead_objects_on_vm_thread() in the enabled case, over on the vmthread. > And that's exactly the case that shows up in the hs_err file. The assert > happens on the vmthread, in the VMOp used by post_dead_entries_xxx: > > Stack: [0x00007f07456c6000,0x00007f07457c6000], sp=0x00007f07457c48c0, free space=1018k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x11e92fc] JvmtiExport::post_object_free(JvmtiEnv*, long)+0x8c > V [libjvm.so+0x12293b2] JvmtiTagMapTable::remove_dead_entries(JvmtiEnv*, bool)+0x192 > V [libjvm.so+0x12212cd] VM_JvmtiPostObjectFree::doit()+0x5d > V [libjvm.so+0x198469a] VM_Operation::evaluate()+0x18a > V [libjvm.so+0x19a7e7f] VMThread::evaluate_operation(VM_Operation*)+0x17f > V [libjvm.so+0x19a88cc] VMThread::inner_execute(VM_Operation*)+0x17c > V [libjvm.so+0x19a8b85] VMThread::loop()+0xb5 > V [libjvm.so+0x19a8cba] VMThread::run()+0xca > V [libjvm.so+0x1893db0] Thread::call_run()+0x100 > V [libjvm.so+0x1574796] thread_native_entry(Thread*)+0x116 Thanks @kimbarrett and @coleenp I missed the path at the safepoint that leads to the call without the lock. ------------- PR: https://git.openjdk.java.net/jdk/pull/1439 From stuefe at openjdk.java.net Tue Dec 1 13:07:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 13:07:58 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 01:51:57 GMT, Ioi Lam wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix gtest for MacOS and AIX > > LGTM @iklam Could you please take a small look at the last commit? After your Windbg exercises in JDK-8255917 I decided to buff the printout of the mapping. Nothing too complicated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Tue Dec 1 13:07:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 13:07:58 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 13:03:22 GMT, Thomas Stuefe wrote: >> LGTM > > @iklam Could you please take a small look at the last commit? After your Windbg exercises in JDK-8255917 I decided to buff the printout of the mapping. Nothing too complicated. [mapping-printout.txt](https://github.com/openjdk/jdk/files/5622718/mapping-printout.txt) This is an example of the mapping printout for a full process ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From coleenp at openjdk.java.net Tue Dec 1 13:10:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 13:10:58 GMT Subject: RFR: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" [v2] In-Reply-To: References: <5Ed2eVORB8pJ0BmKISasvgLZCT4HIjJt-YA4sjZZW0k=.96a9d20c-f931-493a-83c2-2444e2646896@github.com> Message-ID: <7VprB_RQAWmwT0gQdcU9uWZLdsfcL-GD8_KJZDqn7Ak=.525eb4ba-d00e-4aeb-8ada-403722721b2a@github.com> On Tue, 1 Dec 2020 13:04:56 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Make enable events lock unconditionally if tagmap present. > > Thanks Coleen. > > I think the locking strategy around this code leaves something to be desired but I see the problem more clearly now and how the fix addresses it. > > David Thanks for reviewing this David, Kim and Serguei. ------------- PR: https://git.openjdk.java.net/jdk/pull/1439 From dholmes at openjdk.java.net Tue Dec 1 13:10:57 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 13:10:57 GMT Subject: RFR: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" [v2] In-Reply-To: <5Ed2eVORB8pJ0BmKISasvgLZCT4HIjJt-YA4sjZZW0k=.96a9d20c-f931-493a-83c2-2444e2646896@github.com> References: <5Ed2eVORB8pJ0BmKISasvgLZCT4HIjJt-YA4sjZZW0k=.96a9d20c-f931-493a-83c2-2444e2646896@github.com> Message-ID: On Mon, 30 Nov 2020 13:57:14 GMT, Coleen Phillimore wrote: >> The ServiceThread cleaning used a stale ObjectFree state when calling remove_dead_entries, because another thread had concurrently set is_enabled to false. Add a lock around setting/resetting the lock event state and retest the state under a lock. Ran the test 100s of time without failure, where otherwise it fails very quickly. >> Tested with tier2,3 and running tiers 4,5,6 in progress. >> Thanks to Kim for his previous feedback. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make enable events lock unconditionally if tagmap present. Thanks Coleen. I think the locking strategy around this code leaves something to be desired but I see the problem more clearly now and how the fix addresses it. David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1439 From coleenp at openjdk.java.net Tue Dec 1 13:10:59 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 13:10:59 GMT Subject: Integrated: 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" In-Reply-To: References: Message-ID: <2ALyaFO4a_bzkRjeF24LK0oMzvGNer7zproEkg0sEqU=.a433355a-2a32-43f8-9347-21f992e7328b@github.com> On Wed, 25 Nov 2020 18:40:49 GMT, Coleen Phillimore wrote: > The ServiceThread cleaning used a stale ObjectFree state when calling remove_dead_entries, because another thread had concurrently set is_enabled to false. Add a lock around setting/resetting the lock event state and retest the state under a lock. Ran the test 100s of time without failure, where otherwise it fails very quickly. > Tested with tier2,3 and running tiers 4,5,6 in progress. > Thanks to Kim for his previous feedback. This pull request has now been integrated. Changeset: 3a11009d Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/3a11009d Stats: 20 lines in 3 files changed: 17 ins; 1 del; 2 mod 8256830: misc tests failed with "assert(env->is_enabled(JVMTI_EVENT_OBJECT_FREE)) failed: checking" Reviewed-by: kbarrett, sspitsyn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1439 From shade at openjdk.java.net Tue Dec 1 13:15:55 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 13:15:55 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:23:44 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup BlackholeCallGenerator > > src/hotspot/share/c1/c1_GraphBuilder.cpp line 3469: > >> 3467: Values* args = state()->pop_arguments(callee->arg_size()); >> 3468: >> 3469: // Blackhole everything except the receiver itself > > Does it make sense to limit blackhole candidates to static methods only? > Otherwise, you end up with a null check in the generated code. Unfortunately, not. In JMH, `Blackhole` methods are instance methods (they have state), and that plays nicely with compatibility: when JIT fails to provide blackholing, it would naturally fall back to old behavior. I think null check for receiver is the fair behavior here, as subsequent optimization may expect receiver null-checked after the call. I have not seen null-checks in my `perfasm` runs with C1, though. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Tue Dec 1 14:08:00 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 14:08:00 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:55:05 GMT, Coleen Phillimore wrote: > Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: > > `$ java -XX:+UseNewCode -version > [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). > > There is insufficient memory for the Java Runtime Environment to continue. > Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages > An error report file with more information is saved as: > /16mprotect/hs_err_pid30596.log` > ` You need to merge from master to get GH Actions fixes. They are currently failing with outdated dependencies in your branch, and master has a fix for that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Tue Dec 1 14:08:00 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 14:08:00 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 Message-ID: Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: `$ java -XX:+UseNewCode -version [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). There is insufficient memory for the Java Runtime Environment to continue. Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages An error report file with more information is saved as: /16mprotect/hs_err_pid30596.log` ` ------------- Commit messages: - Made resexhaused001.004 manual tests. You can't reliably run these tests. - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 Changes: https://git.openjdk.java.net/jdk/pull/1540/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1540&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253916 Stats: 15 lines in 6 files changed: 5 ins; 5 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1540.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1540/head:pull/1540 PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Tue Dec 1 14:16:14 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 14:16:14 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: > Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: > > `$ java -XX:+UseNewCode -version > [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). > > There is insufficient memory for the Java Runtime Environment to continue. > Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages > An error report file with more information is saved as: > /16mprotect/hs_err_pid30596.log` > ` Coleen Phillimore 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 mprotect - Made resexhaused001.004 manual tests. You can't reliably run these tests. - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1540/files - new: https://git.openjdk.java.net/jdk/pull/1540/files/5751660c..d34286f9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1540&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1540&range=00-01 Stats: 24816 lines in 603 files changed: 13248 ins; 3971 del; 7597 mod Patch: https://git.openjdk.java.net/jdk/pull/1540.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1540/head:pull/1540 PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Tue Dec 1 14:16:14 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 14:16:14 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 13:53:08 GMT, Aleksey Shipilev wrote: >> Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: >> >> `$ java -XX:+UseNewCode -version >> [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). >> >> There is insufficient memory for the Java Runtime Environment to continue. >> Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages >> An error report file with more information is saved as: >> /16mprotect/hs_err_pid30596.log` >> ` > > You need to merge from master to get GH Actions fixes. They are currently failing with outdated dependencies in your branch, and master has a fix for that. Thanks Aleksey, I've remerged, we'll see if that helps. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Tue Dec 1 14:19:15 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 14:19:15 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: References: Message-ID: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> > The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. > > There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. > > The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. Coleen Phillimore 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 more-jvmti-table - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. - 8257140: Crash in JvmtiTagMap::flush_object_free_events() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1539/files - new: https://git.openjdk.java.net/jdk/pull/1539/files/9aaa0c88..a035ec89 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1539&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1539&range=00-01 Stats: 24816 lines in 603 files changed: 13248 ins; 3971 del; 7597 mod Patch: https://git.openjdk.java.net/jdk/pull/1539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1539/head:pull/1539 PR: https://git.openjdk.java.net/jdk/pull/1539 From shade at openjdk.java.net Tue Dec 1 15:19:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 15:19:57 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:24:54 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup BlackholeCallGenerator > > src/hotspot/share/c1/c1_InstructionPrinter.cpp line 865: > >> 863: >> 864: void InstructionPrinter::do_Blackhole(Blackhole* x) { >> 865: if (x->v() != NULL) { > > Should be an assert instead? (LIRGenerator::do_Blackhole doesn't expect NULL.) Would be sad to `assert` in essentially debugging code. I see that `print_value` does the right thing: prints `NULL`, if any. So I simplified this piece of code to call `print_value` unconditionally. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Tue Dec 1 15:23:55 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 15:23:55 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:43:19 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup BlackholeCallGenerator > > src/hotspot/share/opto/callnode.hpp line 780: > >> 778: virtual uint size_of() const; // Size is bigger >> 779: public: >> 780: CallBlackholeNode( const TypeFunc *tf , address addr) : CallNode(tf, addr, TypePtr::BOTTOM) { > > `addr` can be omitted since it is always `NULL`. Right, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Tue Dec 1 15:29:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 15:29:57 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: <2e6h0fdLLiPMRO_3QGW-IoptUVKt8tKgK8SPZ8KXMYg=.3be75da6-58ff-4728-be7b-1e552dc7e523@github.com> On Tue, 1 Dec 2020 12:30:12 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup BlackholeCallGenerator > > src/hotspot/share/c1/c1_GraphBuilder.cpp line 2032: > >> 2030: if (target->is_loaded() && target->return_type()->basic_type() == T_VOID && >> 2031: compilation()->directive()->should_blackhole(target)) { >> 2032: if (try_blackhole(target)) { > > Since `try_blackhole` can't fail, why do the check at all? Right. This used to be modeled after `try_inline`, which could bail. `try_blackhole` cannot bail, so there is no reason to assert it. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Tue Dec 1 15:43:56 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 15:43:56 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:26:58 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup BlackholeCallGenerator > > src/hotspot/share/opto/doCall.cpp line 115: > >> 113: >> 114: // Try blackholing a method >> 115: if (callee->is_loaded() && > > The check can be turned into a property on `ciMethod` and the result cached there. Yes, but only partially, because C1 and C2 check their own directive sets, and C2 also checks for matching rule. But it does skip unloaded methods more cleanly if we move the first two checks to `ciMethod`. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Tue Dec 1 15:51:00 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 15:51:00 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:28:55 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup BlackholeCallGenerator > > src/hotspot/cpu/aarch64/aarch64.ad line 1778: > >> 1776: } >> 1777: >> 1778: int MachCallBlackholeNode::ret_addr_offset() { > > It can be moved into shared code (`machnode.cpp`). True! Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Tue Dec 1 15:56:01 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 15:56:01 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: <7wHC1VVBP5st7PFgles4qKeLp_A2CmycoFLranbEc2c=.81b6b4df-a260-4a55-8597-ff7facd1181f@github.com> On Tue, 1 Dec 2020 12:37:29 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup BlackholeCallGenerator > > src/hotspot/share/opto/machnode.cpp line 817: > >> 815: void MachCallBlackholeNode::dump_spec(outputStream *st) const { >> 816: st->print("Blackhole "); >> 817: MachCallNode::dump_spec(st); > > How does the output look like? It would be nice to have the info what are the values being consumed and where they are located. I am not sure what takes this path. I modeled this after other `MachCall*Node`-s, by delegating to `MachCallNode`, plus the type message. I thought that would be enough to dump the superclass-call-specific spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From dcubed at openjdk.java.net Tue Dec 1 15:58:54 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 1 Dec 2020 15:58:54 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:47:04 GMT, Coleen Phillimore wrote: > Test passed tier1-3 with no failures. Tier5 and Tier6 have more JPDA testing (JVM/TI, JDWP, JDI, ...) ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From shade at openjdk.java.net Tue Dec 1 16:01:08 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 16:01:08 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v12] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. > > C1 code is platform-independent, and it adds the new node which is then lowered to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - More review cleanups - Merge branch 'master' into JDK-8252505-blackholes - Cleanup BlackholeCallGenerator - Revert unnecessary CompilerOracle changes - Use new "no_reg_save_policy" for blackholes, instead of special-casing the kills - Further simplifications - Fix _out_arg_limit calculation, fixes the remaining Matcher assert failure - Merge branch 'master' into JDK-8252505-blackholes - Remodel CallBlackholeJava -> CallBlackhole - Rehash tests: remove useless, strengthen existing ones - ... and 11 more: https://git.openjdk.java.net/jdk/compare/e3d0f270...c7a594f1 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1203/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=11 Stats: 1071 lines in 50 files changed: 1070 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Tue Dec 1 16:01:09 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 16:01:09 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:52:38 GMT, Vladimir Ivanov wrote: > `Matcher::match_sfpt()` has call-specific logic for different shapes. Having a special case for Blackhole which turns `CallBlackhole` into `MachCallBlackhole` fits it well. > > Since every AD instruction has a dedicated class, you can get rid of some additional changes if you customize matching logic for blackhole. Tried a few approaches, but they seem unsatisfactory. In `Matcher::match_sfpt`, we either need to check for blackhole-ness around `MachNode *m = match_tree(call);` to avoid going for (non-existent) match or recovering in case of expected mismatch of blackhole, or we need to either add the new case before `if( sfpt->is_Call() )` and do the entire thing by ourselves. Seems easier to just accept simple match rules in `.ad`, to be honest. I don't think maintainability is improved by hacking in blackhole handling in `Matcher::match_sfpt`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Tue Dec 1 16:05:12 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 1 Dec 2020 16:05:12 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v13] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. > > C1 code is platform-independent, and it adds the new node which is then lowered to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Make sure the Blackhole match rules match .ad-specific style ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/c7a594f1..3ff8f980 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=11-12 Stats: 11 lines in 6 files changed: 6 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From vladimir.x.ivanov at oracle.com Tue Dec 1 16:28:47 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 1 Dec 2020 19:28:47 +0300 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: <826a3ee1-07d6-3051-ff18-40eae56ddc0d@oracle.com> >> `Matcher::match_sfpt()` has call-specific logic for different shapes. Having a special case for Blackhole which turns `CallBlackhole` into `MachCallBlackhole` fits it well. >> >> Since every AD instruction has a dedicated class, you can get rid of some additional changes if you customize matching logic for blackhole. > > Tried a few approaches, but they seem unsatisfactory. In `Matcher::match_sfpt`, we either need to check for blackhole-ness around `MachNode *m = match_tree(call);` to avoid going for (non-existent) match or recovering in case of expected mismatch of blackhole, or we need to either add the new case before `if( sfpt->is_Call() )` and do the entire thing by ourselves. > > Seems easier to just accept simple match rules in `.ad`, to be honest. I don't think maintainability is improved by hacking in blackhole handling in `Matcher::match_sfpt`. What exactly do you see useful for blackhole inside `if( sfpt->is_Call())` branch? Everything except setting `tf()` looks irrelevant and you can cleanly capture that in MachCallBlackhole factory/ctor. And don't forget about ADLC changes. Those can also go away / migrate to MachCallBlackhole. Best regards, Vladimir Ivanov 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 stuefe at openjdk.java.net Tue Dec 1 16:55:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 16:55:00 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 14:12:58 GMT, Coleen Phillimore wrote: >> You need to merge from master to get GH Actions fixes. They are currently failing with outdated dependencies in your branch, and master has a fix for that. > > Thanks Aleksey, I've remerged, we'll see if that helps. Hi Coleen, I believe this is intermittent and can be temporary (most likely number of process local mappings, see my comment in JBS). Therefore ideally, this should result in an OOM, not a VM exit - at least when it happens during thread creation, which is the most likely scenario. I believe this can happen when the number of mappings exceeds the allowed process limit. One simple maybe stupid approach could be to pre-reserve mappings, and release them in this situation to decrease the process local mapping counter. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From stuefe at openjdk.java.net Tue Dec 1 17:13:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 17:13:57 GMT Subject: RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches In-Reply-To: <66d_EAED3_BRpr9YmIrv1seQFfyUOIPdntMllUyJa-Q=.61c545be-b26d-4d3a-8ac6-e7239656b7a6@github.com> References: <66d_EAED3_BRpr9YmIrv1seQFfyUOIPdntMllUyJa-Q=.61c545be-b26d-4d3a-8ac6-e7239656b7a6@github.com> Message-ID: <9zTPHTKnRl4iFRt4baZc-CmVtVR6yxgaeqnWOu7HSiU=.d213fe75-3fd3-4208-af9b-6f301af78d38@github.com> On Mon, 30 Nov 2020 15:37:34 GMT, Martin Doerr wrote: > The JVM currently runs into Unimplemented() when using -XX:-UseInlineCaches in C2 code (postalloc_expand_java_dynamic_call_sched). > I'd like to enable the existing code in postalloc_expand_java_dynamic_call_sched and fix MachCallDynamicJavaNode::ret_addr_offset() and MacroAssembler::instr_size_for_decode_klass_not_null(). > I suggest to use scratch emit to determine the size, because there are too many cases and emitting it once is fast. Hi Martin, this looks good to my non-compiler-eyes. Cheers, Thomas src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 3166: > 3164: // Determine by scratch emit. > 3165: ResourceMark rm; > 3166: int code_size = 8 * BytesPerInstWord; Is this enough? Can CodeBuffers expand? src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 3168: > 3166: int code_size = 8 * BytesPerInstWord; > 3167: CodeBuffer cb("decode_klass_not_null scratch buffer", code_size, 0); > 3168: MacroAssembler* a = new MacroAssembler(&cb); Idle thought: if this is done frequently, maybe MacroAssembler could have a "dry run" mode with no attached CodeBuffer, just counting instructions. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1521 From mdoerr at openjdk.java.net Tue Dec 1 17:37:54 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 1 Dec 2020 17:37:54 GMT Subject: RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches In-Reply-To: <9zTPHTKnRl4iFRt4baZc-CmVtVR6yxgaeqnWOu7HSiU=.d213fe75-3fd3-4208-af9b-6f301af78d38@github.com> References: <66d_EAED3_BRpr9YmIrv1seQFfyUOIPdntMllUyJa-Q=.61c545be-b26d-4d3a-8ac6-e7239656b7a6@github.com> <9zTPHTKnRl4iFRt4baZc-CmVtVR6yxgaeqnWOu7HSiU=.d213fe75-3fd3-4208-af9b-6f301af78d38@github.com> Message-ID: On Tue, 1 Dec 2020 17:01:28 GMT, Thomas Stuefe wrote: >> The JVM currently runs into Unimplemented() when using -XX:-UseInlineCaches in C2 code (postalloc_expand_java_dynamic_call_sched). >> I'd like to enable the existing code in postalloc_expand_java_dynamic_call_sched and fix MachCallDynamicJavaNode::ret_addr_offset() and MacroAssembler::instr_size_for_decode_klass_not_null(). >> I suggest to use scratch emit to determine the size, because there are too many cases and emitting it once is fast. > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 3166: > >> 3164: // Determine by scratch emit. >> 3165: ResourceMark rm; >> 3166: int code_size = 8 * BytesPerInstWord; > > Is this enough? Can CodeBuffers expand? Maximum size is 7 instructions. ------------- PR: https://git.openjdk.java.net/jdk/pull/1521 From mdoerr at openjdk.java.net Tue Dec 1 17:42:57 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Tue, 1 Dec 2020 17:42:57 GMT Subject: RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches In-Reply-To: <9zTPHTKnRl4iFRt4baZc-CmVtVR6yxgaeqnWOu7HSiU=.d213fe75-3fd3-4208-af9b-6f301af78d38@github.com> References: <66d_EAED3_BRpr9YmIrv1seQFfyUOIPdntMllUyJa-Q=.61c545be-b26d-4d3a-8ac6-e7239656b7a6@github.com> <9zTPHTKnRl4iFRt4baZc-CmVtVR6yxgaeqnWOu7HSiU=.d213fe75-3fd3-4208-af9b-6f301af78d38@github.com> Message-ID: <1A9NfEQw4ZSwCY1yDfGApDSDhBg4egT5aHkH3mH5bA4=.4bece2f9-5a94-4e7d-9225-890769d5cb9f@github.com> On Tue, 1 Dec 2020 17:10:52 GMT, Thomas Stuefe wrote: >> The JVM currently runs into Unimplemented() when using -XX:-UseInlineCaches in C2 code (postalloc_expand_java_dynamic_call_sched). >> I'd like to enable the existing code in postalloc_expand_java_dynamic_call_sched and fix MachCallDynamicJavaNode::ret_addr_offset() and MacroAssembler::instr_size_for_decode_klass_not_null(). >> I suggest to use scratch emit to determine the size, because there are too many cases and emitting it once is fast. > > Hi Martin, > > this looks good to my non-compiler-eyes. > > Cheers, Thomas Thanks for reviewing it! > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 3168: > >> 3166: int code_size = 8 * BytesPerInstWord; >> 3167: CodeBuffer cb("decode_klass_not_null scratch buffer", code_size, 0); >> 3168: MacroAssembler* a = new MacroAssembler(&cb); > > Idle thought: if this is done frequently, maybe MacroAssembler could have a "dry run" mode with no attached CodeBuffer, just counting instructions. The scratch emit is only executed during the first call. Afterwards, the computed_size is just returned and we don't call the CodeBuffer constructor any more. ------------- PR: https://git.openjdk.java.net/jdk/pull/1521 From shade at redhat.com Tue Dec 1 17:57:16 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Dec 2020 18:57:16 +0100 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <826a3ee1-07d6-3051-ff18-40eae56ddc0d@oracle.com> References: <826a3ee1-07d6-3051-ff18-40eae56ddc0d@oracle.com> Message-ID: <662a87e3-3091-ace7-3b10-9d36eaefaac9@redhat.com> On 12/1/20 5:28 PM, Vladimir Ivanov wrote: >> Seems easier to just accept simple match rules in `.ad`, to be honest. I don't think maintainability is improved by hacking in blackhole handling in `Matcher::match_sfpt`. > > What exactly do you see useful for blackhole inside `if( > sfpt->is_Call())` branch? Everything except setting `tf()` looks > irrelevant and you can cleanly capture that in MachCallBlackhole > factory/ctor. It's not that. ADLC actually creates a subclass that defines Name(), rule(), etc. We can fake it, but what I am concerned about is introducing a special case for otherwise generic Matcher code. We also basically sidestep DFA machinery, and I am not at all sure what is the effect at subsequent matches for the incoming edges. Is there a precedent to create Mach nodes like this? Do we actually know if there are pitfalls? I firmly believe that sticking with what Matcher expects of us: *Node -> Mach*Node rules in .ad -- is safer all around. See the example patch: https://cr.openjdk.java.net/~shade/8252505/shared-match.patch It currently fails with: Current CompileTask: C2: 251 16 % compiler.blackhole.BlackholeInstanceSingleArgTest::test_boolean @ 10 (38 bytes) # Internal Error (/home/shade/trunks/jdk/src/hotspot/share/opto/node.hpp:385), pid=614173, tid=614212 # assert(i < _max) failed: oob: i=-1, _max=0 Stack: [0x00007f2cd4406000,0x00007f2cd4507000], sp=0x00007f2cd45021c0, free space=1008k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x1449400] Matcher::xform(Node*, int)+0x5f0 V [libjvm.so+0x144eb96] Matcher::match()+0x4626 V [libjvm.so+0xa37ff4] Compile::Code_Gen()+0xb4 V [libjvm.so+0xa419b9] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x1949 V [libjvm.so+0x87e140] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1e0 V [libjvm.so+0xa53238] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xea8 V [libjvm.so+0xa53df8] CompileBroker::compiler_thread_loop()+0x5b8 V [libjvm.so+0x1a1e0a6] JavaThread::thread_main_inner()+0x266 V [libjvm.so+0x1a247c4] Thread::call_run()+0x104 V [libjvm.so+0x15c33ce] thread_native_entry(Thread*)+0x11e I am not sure I want to trade in a few lines of .ad with fixing new matcher bugs. > And don't forget about ADLC changes. Those can also go away / migrate to > MachCallBlackhole. Yes, they could, but we are drilling another hole in the code that is already quite funky. Let's not. -- Thanks, -Aleksey From smonteith at openjdk.java.net Tue Dec 1 18:27:55 2020 From: smonteith at openjdk.java.net (Stuart Monteith) Date: Tue, 1 Dec 2020 18:27:55 GMT Subject: RFR: 8248736: [aarch64] runtime/signal/TestSigpoll.java failed "fatal error: not an ldr (literal) instruction." In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 15:11:18 GMT, Stuart Monteith wrote: > Change mov to movptr in the nmethod entry barrier. movptr will generate a consistent number of mov/movk instructions that are necessary to consistently calculate the size of the nmethod barrier. You raised the bug @dcubed-ojdk , could you review this please? ------------- PR: https://git.openjdk.java.net/jdk/pull/1481 From dms at samersoff.net Tue Dec 1 18:31:23 2020 From: dms at samersoff.net (Dmitry Samersoff) Date: Tue, 1 Dec 2020 21:31:23 +0300 Subject: GrowableArray - how it works? Message-ID: <0bfd63df-a11e-7a3c-76b1-c3f89612f51e@samersoff.net> Hello Everybody, While experimenting with the use of templates within hotspot in order to reduce VM size, I found a thing that I can't understand. What I'm missing here? arguments.cpp: GrowableArray *options = new (ResourceObj::C_HEAP, mtArguments) Where JavaVMOption is the plain C structure {char*, void*} that comes from jni.h but template class GrowableArray : public GenericGrowableArray { contains couple of functions like one below: int find_from_end(const E& elem) const { for (int i = _len-1; i >= 0; i--) { if (_data[i] == elem) return i; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } return -1; } How it supposed to work? If I instantiate GrowableArray explicitly it can't be compiled at al. Thank you! -Dmitry From github.com+168222+mgkwill at openjdk.java.net Tue Dec 1 20:06:17 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 1 Dec 2020 20:06:17 GMT Subject: RFR: 8256155: 2M large pages for code when LargePageSizeInBytes is set to 1G for heap [v3] In-Reply-To: References: Message-ID: > Add 2M LargePages to _page_sizes > > Use 2m pages for large page requests > less than 1g on linux when 1G are default > pages > > - Add os::Linux::large_page_size_2m() that > returns 2m as size > - Add os::Linux::select_large_page_size() to return > correct large page size for size_t bytes > - Add 2m size to _page_sizes array > - Update reserve_memory_special methods > to set/use large_page_size based on bytes reserved > - Update large page not reserved warnings > to include large_page_size attempted > - Update TestLargePageUseForAuxMemory.java > to expect 2m large pages in some instances > > Signed-off-by: Marcus G K Williams Marcus G K Williams 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 'update_hlp' of github.com:mgkwill/jdk into update_hlp - Add 2M LargePages to _page_sizes Use 2m pages for large page requests less than 1g on linux when 1G are default pages - Add os::Linux::large_page_size_2m() that returns 2m as size - Add os::Linux::select_large_page_size() to return correct large page size for size_t bytes - Add 2m size to _page_sizes array - Update reserve_memory_special methods to set/use large_page_size based on bytes reserved - Update large page not reserved warnings to include large_page_size attempted - Update TestLargePageUseForAuxMemory.java to expect 2m large pages in some instances Signed-off-by: Marcus G K Williams - Merge remote-tracking branch 'upstream/master' into update_hlp - Add 2M LargePages to _page_sizes Use 2m pages for large page requests less than 1g on linux when 1G are default pages - Add os::Linux::large_page_size_2m() that returns 2m as size - Add os::Linux::select_large_page_size() to return correct large page size for size_t bytes - Add 2m size to _page_sizes array - Update reserve_memory_special methods to set/use large_page_size based on bytes reserved - Update large page not reserved warnings to include large_page_size attempted - Update TestLargePageUseForAuxMemory.java to expect 2m large pages in some instances Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1153/files - new: https://git.openjdk.java.net/jdk/pull/1153/files/7092bec8..57e54963 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=01-02 Stats: 204961 lines in 1352 files changed: 133754 ins; 50869 del; 20338 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From iklam at openjdk.java.net Tue Dec 1 20:13:02 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 20:13:02 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v4] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 11:16:17 GMT, Thomas Stuefe wrote: >> To analyze JDK-8256729 further, we need more tracing: >> >> 1) We should print all mappings inside the split area if os::split_reserved_memory() fails >> >> 2) The print-mapping code on windows has some shortcomings: >> - should not probe for mappings outside of what we know are valid address ranges for Windows >> - should handle wrap-arounds - it should be possible to print the whole address space >> - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) >> - should be printed in a more compact manner - base address should be on the same line as the first region >> - maybe adorned with some basic range info, e.g. library mappings > > Thomas Stuefe 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: > > - Print a short snippet for unknown mappings > - Merge > - Fix gtest for MacOS and AIX > - Merge > - Initial patch Marked as reviewed by iklam (Reviewer). src/hotspot/os/windows/os_windows.cpp line 6002: > 6000: for (int i = 0; i < num_words; i++) { > 6001: v[i] = SafeFetch32((int*)p + i, errval); > 6002: if (v[i] == errval) { How about if (SafeFetch32((int*)p + i, 0x1234) == 0x1234 && SafeFetch32((int*)p + i, 0x5678) == 0x5678) { return; } else { v[i] = SafeFetch32((int*)p + i, 0); } ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Tue Dec 1 20:19:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 20:19:00 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 14:16:14 GMT, Coleen Phillimore wrote: >> Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: >> >> `$ java -XX:+UseNewCode -version >> [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). >> >> There is insufficient memory for the Java Runtime Environment to continue. >> Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages >> An error report file with more information is saved as: >> /16mprotect/hs_err_pid30596.log` >> ` > > Coleen Phillimore 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 mprotect > - Made resexhaused001.004 manual tests. You can't reliably run these tests. > - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 After reading through the JBS comments I think this makes sense as an intermediate solution, since - as it was pointed out - running on without stack guards could cause crashes on later. The situation is not ideal but this change does not change much. As far as native memory shortages go, whether or not they result in an OOM is random anyway. pthread_create may fail, which would result in an OOM, or it may cause any number of other APIs to fail, e.g. mmap, which would cause the VM to terminate. The hotspot changes look good. I cannot comment on the changed test attributes. src/hotspot/share/runtime/stackOverflow.cpp line 109: > 107: } > 108: > 109: log_debug(os, thread)("Thread " UINTX_FORMAT " stack guard pages activated: " I always was curious about this uncommit. I wondered whether it was a fallback for platforms where mprotect would not work on thread stacks. But then, why warn unconditionally? ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1540 From stuefe at openjdk.java.net Tue Dec 1 20:20:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 20:20:57 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v4] In-Reply-To: References: Message-ID: <1JQHQOm1UWJhx5ELnVNUUiCncnA33Yuj01sdxyTTvEs=.a1a910cf-bd4d-48a0-8168-293eb5748746@github.com> On Tue, 1 Dec 2020 20:09:38 GMT, Ioi Lam wrote: >> Thomas Stuefe 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: >> >> - Print a short snippet for unknown mappings >> - Merge >> - Fix gtest for MacOS and AIX >> - Merge >> - Initial patch > > src/hotspot/os/windows/os_windows.cpp line 6002: > >> 6000: for (int i = 0; i < num_words; i++) { >> 6001: v[i] = SafeFetch32((int*)p + i, errval); >> 6002: if (v[i] == errval) { > > How about > if (SafeFetch32((int*)p + i, 0x1234) == 0x1234 && > SafeFetch32((int*)p + i, 0x5678) == 0x5678) { > return; > } else { > v[i] = SafeFetch32((int*)p + i, 0); > } Okay, I'll do that (minus the else part). I left it out because come on, its a 1 in 4 billion chance :) but the second SafeFetch only triggers when the first condition is true so this may still be cleaner. ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Tue Dec 1 20:34:09 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 1 Dec 2020 20:34:09 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Ioi ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1390/files - new: https://git.openjdk.java.net/jdk/pull/1390/files/e2b71654..de705074 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1390/head:pull/1390 PR: https://git.openjdk.java.net/jdk/pull/1390 From iklam at openjdk.java.net Tue Dec 1 20:39:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 20:39:56 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 20:34:09 GMT, Thomas Stuefe wrote: >> To analyze JDK-8256729 further, we need more tracing: >> >> 1) We should print all mappings inside the split area if os::split_reserved_memory() fails >> >> 2) The print-mapping code on windows has some shortcomings: >> - should not probe for mappings outside of what we know are valid address ranges for Windows >> - should handle wrap-arounds - it should be possible to print the whole address space >> - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) >> - should be printed in a more compact manner - base address should be on the same line as the first region >> - maybe adorned with some basic range info, e.g. library mappings > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Ioi Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From sjohanss at openjdk.java.net Tue Dec 1 21:29:02 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 1 Dec 2020 21:29:02 GMT Subject: RFR: 8257505: nsk/share/test/StressOptions stressTime is scaled in getter but not when printed Message-ID: Please review this small change to print the correct stress time for tests using `StressOptions`. Quite recently the `getTime()` method on `StressOptions` was changed to scale the stress time using the JTREG timeout factor. See: [JDK-8252522](https://bugs.openjdk.java.net/browse/JDK-8252522) The `printInfo()` method was left using the raw `time` member and will thus output a different time from the one actually used. This change fixes this by using the getter. For consistency the other values are fetched by the getters as well. ------------- Commit messages: - 8257505: nsk/share/test/StressOptions stressTime is scaled in getter but not when printed Changes: https://git.openjdk.java.net/jdk/pull/1545/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1545&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257505 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1545.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1545/head:pull/1545 PR: https://git.openjdk.java.net/jdk/pull/1545 From hseigel at openjdk.java.net Tue Dec 1 21:44:09 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 1 Dec 2020 21:44:09 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8256718: Obsolete the long term deprecated and aliased Trace flags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1525/files - new: https://git.openjdk.java.net/jdk/pull/1525/files/9c373c6b..84e421f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=00-01 Stats: 206 lines in 3 files changed: 13 ins; 192 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1525/head:pull/1525 PR: https://git.openjdk.java.net/jdk/pull/1525 From hseigel at openjdk.java.net Tue Dec 1 21:48:57 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 1 Dec 2020 21:48:57 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:10:59 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > I agree with David. We should remove the helpful messages at least for most of the obsolete Print/Trace flags. Not sure about the big 3 though. Thanks everyone for the reviews. Please review the updated commit which contains the following changes: 1. Moves most of the flags to the normal location for obsolete flags. 2. Keeps the extra -Xlog message for the three most commonly used flags. 3. Removes the removed_develop_logging_flags struct and support functions. 4. Removes the aliased_logging_flags struct and support functions based on Coleen's statement that there are no existing flags that would use it. Thanks! Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From coleenp at openjdk.java.net Tue Dec 1 22:04:00 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 22:04:00 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 20:12:28 GMT, Thomas Stuefe wrote: >> Coleen Phillimore 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 mprotect >> - Made resexhaused001.004 manual tests. You can't reliably run these tests. >> - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 > > src/hotspot/share/runtime/stackOverflow.cpp line 109: > >> 107: } >> 108: >> 109: log_debug(os, thread)("Thread " UINTX_FORMAT " stack guard pages activated: " > > I always was curious about this uncommit. I wondered whether it was a fallback for platforms where mprotect would not work on thread stacks. But then, why warn unconditionally? Maybe the uncommit was an attempt to achieve the same thing as protecting the pages, ie get a SEGV when accessing them. I don't know either. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Tue Dec 1 22:11:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 22:11:01 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 15:55:41 GMT, Daniel D. Daugherty wrote: >> Test passed tier1-3 with no failures. > >> Test passed tier1-3 with no failures. > > Tier5 and Tier6 have more JPDA testing (JVM/TI, JDWP, JDI, ...) tier 4,5,6 pass with no failures. ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From coleenp at openjdk.java.net Tue Dec 1 22:11:05 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 1 Dec 2020 22:11:05 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 20:16:05 GMT, Thomas Stuefe wrote: >> Coleen Phillimore 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 mprotect >> - Made resexhaused001.004 manual tests. You can't reliably run these tests. >> - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 > > After reading through the JBS comments I think this makes sense as an intermediate solution, since - as it was pointed out - running on without stack guards could cause crashes on later. The situation is not ideal but this change does not change much. > > As far as native memory shortages go, whether or not they result in an OOM is random anyway. pthread_create may fail, which would result in an OOM, or it may cause any number of other APIs to fail, e.g. mmap, which would cause the VM to terminate. > > The hotspot changes look good. I cannot comment on the changed test attributes. Thanks for reviewing this Thomas, and for more information about this failure. I answered your comments in the JBS issue. It might be possible to throw OOM instead of vm_exit_out_of_memory but it's not very clean where it'll propagate in the code, and for this low native memory situation, I don't think it's going to help the test make more progress. This has been a longstanding problem with this test so this change makes a cleaner exit for an unlikely application which may also have the same problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From iklam at openjdk.java.net Tue Dec 1 22:28:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 22:28:57 GMT Subject: RFR: 8257466: Improve enum iteration In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 04:41:35 GMT, Kim Barrett wrote: > Please review this collection of improvements to the recently added enum > iteration facility. These improvements are based on usage in some > in-development changes. > > (1) Added EnumType nested type to EnumRange and EnumIterator. It is an alias > for the enum type that is a template parameter for those classes. This is > useful when dealing with a range or iterator whose associated enum type is > not known because the range/iterator is a template parameter. > > (2) Added EnumRange::index(T), which converts the argument enumerator to > a zero-based index into the range of values. This is useful when mapping > from an enumerator to a corresponding array index, for example. > > (3) Allow enum range bounds to be specified using start and (exclusive) end > integral (underlying type) values. This is useful when dealing with enums > that are just value ranges and don't have named enumerators. As part of > this, changes the enum iteration traits mechanism to use start/end rather > than first/last, as that seems to be a little easier to deal with. > > (4) Added accessors for the first and last enumerator values of a range. > > (5) Added gtest for enum iteration. > > Testing: tier1 Marked as reviewed by iklam (Reviewer). src/hotspot/share/utilities/enumIterator.hpp line 115: > 113: static constexpr EnumeratorRangeImpl::Underlying _start = \ > 114: EnumeratorRangeImpl::underlying(Start); \ > 115: static constexpr EnumeratorRangeImpl::Underlying _end = \ Why do we need to call `underlying(Start)` here? Can it be simplified as static constexpr EnumeratorRangeImpl::Underlying _start = Start; or static constexpr EnumeratorRangeImpl::Underlying _start {Start}; ------------- PR: https://git.openjdk.java.net/jdk/pull/1530 From iklam at openjdk.java.net Tue Dec 1 22:31:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 1 Dec 2020 22:31:56 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:44:09 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From kbarrett at openjdk.java.net Tue Dec 1 22:47:59 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 1 Dec 2020 22:47:59 GMT Subject: RFR: 8257505: nsk/share/test/StressOptions stressTime is scaled in getter but not when printed In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:22:18 GMT, Stefan Johansson wrote: > Please review this small change to print the correct stress time for tests using `StressOptions`. > > Quite recently the `getTime()` method on `StressOptions` was changed to scale the stress time using the JTREG timeout factor. See: [JDK-8252522](https://bugs.openjdk.java.net/browse/JDK-8252522) > > The `printInfo()` method was left using the raw `time` member and will thus output a different time from the one actually used. This change fixes this by using the getter. For consistency the other values are fetched by the getters as well. Looks good, and trivial. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1545 From dholmes at openjdk.java.net Tue Dec 1 23:05:01 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 1 Dec 2020 23:05:01 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:04:43 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > src/hotspot/share/runtime/arguments.cpp line 612: > >> 610: { "TraceRedefineClasses", "-Xlog:redefine+class=", "info", "16.0" }, >> 611: { "PrintJNIResolving", "-Xlog:jni+resolve=", "debug", "16.0" }, >> 612: { NULL, NULL, NULL, NULL } > > I think if we wanted to give a message that the flag was obsolete and to suggest changing the command line, we should only do it for -XX:+TraceClassLoading and -XX:+TraceExceptions (I'd originally thought -XX:+TraceClassUnloading was important enough to release note but now I'm not so sure.) The rest of the flags should either go in the table that they're no longer recognized. Keeping the message for any flag requires keeping all the supporting code. I don't see the "big 3" are special. They have been deprecated since 9 and we have clearly told people this when they use them. We're also release-noting this for 16 (again - this was documented when UL was added). I don't think we have to pander to anyone who hasn't updated their launch scripts by now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 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 sspitsyn at openjdk.java.net Wed Dec 2 00:12:58 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Dec 2020 00:12:58 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> References: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> Message-ID: On Tue, 1 Dec 2020 14:19:15 GMT, Coleen Phillimore wrote: >> The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. >> >> There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. >> >> The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. > > Coleen Phillimore 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 more-jvmti-table > - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. > - 8257140: Crash in JvmtiTagMap::flush_object_free_events() Hi Coleen, The JVMTI environment can be disposed with DisposeEnvironment: https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#DisposeEnvironment It seems to me that this operation is better to wait until posting is finished. Otherwise, the information is going to be lost in the report. Of course, we could blame the agent to call the DisposeEnvironment too early but then the agent needs a way to check if posting is finished. Thanks, Serguei ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From sspitsyn at openjdk.java.net Wed Dec 2 00:45:03 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Dec 2020 00:45:03 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: <5r8K8_KQj2e17tkOarKyGAbCQmSgg9BK-jE-jiIQwEs=.d6dc4014-263e-4fee-9c28-86bf47bc554f@github.com> On Tue, 1 Dec 2020 14:16:14 GMT, Coleen Phillimore wrote: >> Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: >> >> `$ java -XX:+UseNewCode -version >> [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). >> >> There is insufficient memory for the Java Runtime Environment to continue. >> Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages >> An error report file with more information is saved as: >> /16mprotect/hs_err_pid30596.log` >> ` > > Coleen Phillimore 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 mprotect > - Made resexhaused001.004 manual tests. You can't reliably run these tests. > - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 Hi Coleen, The fix looks good to me. I'm not sure how adding the jtreg 'manual' key to the tests is helping though. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1540 From kim.barrett at oracle.com Wed Dec 2 01:19:36 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 Dec 2020 20:19:36 -0500 Subject: GrowableArray - how it works? In-Reply-To: <0bfd63df-a11e-7a3c-76b1-c3f89612f51e@samersoff.net> References: <0bfd63df-a11e-7a3c-76b1-c3f89612f51e@samersoff.net> Message-ID: <4320CDEB-CABF-4DDF-8844-B762B15C663C@oracle.com> > On Dec 1, 2020, at 1:31 PM, Dmitry Samersoff wrote: > > Hello Everybody, > > While experimenting with the use of templates within hotspot in order to reduce VM size, I found a thing that I can't understand. > > What I'm missing here? > > arguments.cpp: > > GrowableArray *options = new (ResourceObj::C_HEAP, mtArguments) > > Where JavaVMOption is the plain C structure {char*, void*} that comes from jni.h > > but > > template > class GrowableArray : public GenericGrowableArray { > > contains couple of functions like one below: > > int find_from_end(const E& elem) const { > for (int i = _len-1; i >= 0; i--) { > if (_data[i] == elem) return i; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > } > return -1; > } > > How it supposed to work? > > If I instantiate GrowableArray explicitly it can't be compiled at al. > > Thank you! > -Dmitry Templates have requirements for the template parameters. Attempting to use a type that doesn't meet the requirements is going to fail to compile, sometimes with a really large error dump (the so-called error novel). Concepts should eventually help with that, but we don't have those in C++14. GrowableArray doesn't document its requirements (HotSpot templates rarely have such documentation, which I think is unfortunate), but it's probably similar to the requirements for std::vector; see C++14 23.2.1 and 23.2.3. This is all basic C++ template knowledge. In the specific example given, E must be EqualityComparable. JavaMVOption isn't. From david.holmes at oracle.com Wed Dec 2 01:25:01 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Dec 2020 11:25:01 +1000 Subject: HotSpot Style Guide change process In-Reply-To: <376E1F97-57DE-46CD-B656-BC5340E0BA07@oracle.com> References: <376E1F97-57DE-46CD-B656-BC5340E0BA07@oracle.com> Message-ID: Hi Kim, "rough consensus" has good precedents and is something we should follow here IMO. OpenJDK by-laws are for the formal parts of the OpenJDK processes themselves, not for everything single thing done under the OpenJDK banner. Cheers, David On 1/12/2020 4:43 pm, Kim Barrett wrote: > When the Style Guide was updated for C++11/14 usage and other cleanup > (JDK-8247976), a change process was added to it. It says > > Proposed changes should be discussed on the > [HotSpot Developers](mailto:hotspot-dev at openjdk.java.net) mailing > list, and approved by > [rough consensus](https://en.wikipedia.org/wiki/Rough_consensus) of > the [HotSpot Group](https://openjdk.java.net/census#hotspot) Members. > The Group Lead determines whether consensus has been reached. > Changes are likely to be cautious and incremental, since HotSpot > coders have been using these guidelines for years. > > Vladimir Kozlov has questioned this process and suggests another: > >> I looked again on voting description for Style Guide changes. And it >> references to `rough consensus` which is not in OpenJDK bylaws : >> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html#L69 >> >> I think it is bug (separate from these changes) and should be fixed by >> using our rule http://openjdk.java.net/bylaws#three-vote-consensus >> With Project Lead final vote we will need at least 2 other members votes >> during 2 weeks review period. I think it is similar to `rough consensus`. > > Use of "rough consensus" with an arbiter has precedent within the OpenJDK, > though it's not used in the bylaws. The current text quoted above was based > on > > https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > JEP 2.0, draft 2 - see "Planning", 4th bullet > > and > > https://openjdk.java.net/groups/vulnerability/ > OpenJDK Vulnerability Group - see "Making decisions" > > So both the JEP Process and the Vulnerability Group use rough consensus, > with the relevant lead as the arbiter. (The V-Team page links to an IETF > document describing rough consensus. The HotSpot Style Guide links to > the same Wikipedia article as the JEP 2.0 Process; that Wikipedia article > references the IETF page.) > > I called out the new change process specifically in the initial RFR email > for JDK-8247976, but that part didn't generate much (any?) discussion. > > If we don't like it we are certainly free to change. And if Vladimir > doesn't like it then we should change, since as HotSpot Lead he's fairly > central to that process. But I don't think there's a "lack of precedent" > or "not appropriate for OpenJDK" argument for changing. > > I chose that process because I didn't want it to be too easy to make changes > to the Style Guide. In particular, I think it should require more effort > than is involved in a typical RFR. > > Even if we don't change, and especially if we do, some further refinement of > the mechanics may be needed. I think the current mechanics may have a > problem that the request shows up in one's mailbox looking pretty much like > an ordinary RFR. When I was originally thinking about that text we were in a > world of pure email change requests, and the document was still a wiki page. > With the move of the document to the jdk repository and the move to github > and PRs + Skara support for changes, the mechanics are different. It might > be better if it could be subject tagged differently, as we do with Call for > Vote emails. There are probably things we could do about that, if others > agree that's a problem. Or maybe some of you see other problems? > From david.holmes at oracle.com Wed Dec 2 01:37:29 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 Dec 2020 11:37:29 +1000 Subject: RFR: 8248736: [aarch64] runtime/signal/TestSigpoll.java failed "fatal error: not an ldr (literal) instruction." In-Reply-To: References: Message-ID: <6ff03bc3-da94-4caa-2c27-87b12e57474e@oracle.com> Hi Stuart, On 2/12/2020 4:27 am, Stuart Monteith wrote: > On Fri, 27 Nov 2020 15:11:18 GMT, Stuart Monteith wrote: > >> Change mov to movptr in the nmethod entry barrier. movptr will generate a consistent number of mov/movk instructions that are necessary to consistently calculate the size of the nmethod barrier. > > You raised the bug @dcubed-ojdk , could you review this please? Please note that filing a bug has no bearing on reviewing a PR. We have numerous folk who monitor our testing and will file bugs on failures. You need theRealAph and shipilev to finalize their reviews. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1481 > From coleen.phillimore at oracle.com Wed Dec 2 01:49:06 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 1 Dec 2020 20:49:06 -0500 Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: <5r8K8_KQj2e17tkOarKyGAbCQmSgg9BK-jE-jiIQwEs=.d6dc4014-263e-4fee-9c28-86bf47bc554f@github.com> References: <5r8K8_KQj2e17tkOarKyGAbCQmSgg9BK-jE-jiIQwEs=.d6dc4014-263e-4fee-9c28-86bf47bc554f@github.com> Message-ID: <00bfbef9-e8a8-7bc9-b5cd-a70e1d5814d9@oracle.com> On 12/1/20 7:45 PM, Serguei Spitsyn wrote: > On Tue, 1 Dec 2020 14:16:14 GMT, Coleen Phillimore wrote: > >>> Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: >>> >>> `$ java -XX:+UseNewCode -version >>> [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). >>> >>> There is insufficient memory for the Java Runtime Environment to continue. >>> Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages >>> An error report file with more information is saved as: >>> /16mprotect/hs_err_pid30596.log` >>> ` >> Coleen Phillimore 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 mprotect >> - Made resexhaused001.004 manual tests. You can't reliably run these tests. >> - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 > Hi Coleen, > The fix looks good to me. > I'm not sure how adding the jtreg 'manual' key to the tests is helping though. Thanks Serguei, I added manual to the tests so that they don't run with the normal testing because they're going to continue to be unreliable.? I had to take them out of the ProblemList.txt file though because git checking complained. Thanks for reviewing the change. Coleen > Thanks, > Serguei > > ------------- > > Marked as reviewed by sspitsyn (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1540 From coleen.phillimore at oracle.com Wed Dec 2 02:03:47 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 1 Dec 2020 21:03:47 -0500 Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: References: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> Message-ID: <6e6287be-e9d0-2133-fd5b-f82de032154e@oracle.com> On 12/1/20 7:12 PM, Serguei Spitsyn wrote: > On Tue, 1 Dec 2020 14:19:15 GMT, Coleen Phillimore wrote: > >>> The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. >>> >>> There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. >>> >>> The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. >> Coleen Phillimore 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 more-jvmti-table >> - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. >> - 8257140: Crash in JvmtiTagMap::flush_object_free_events() > Hi Coleen, > > The JVMTI environment can be disposed with DisposeEnvironment: > https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#DisposeEnvironment > It seems to me that this operation is better to wait until posting is finished. Otherwise, the information is going to be lost in the report. Of course, we could blame the agent to call the DisposeEnvironment too early but then the agent needs a way to check if posting is finished. When the event is disposed, it calls set_event_callbacks(), which calls flush_object_free_events, which will flush the remaining object free events for this environment.? So the events aren't lost.? The bug was that after that, the JvmtiEnv is marked as DISPOSED but it's still on the list of JvmtiEnvIterator events that we walk until the next safepoint.? When the JvmtiEnv is disposed, it was deleting the tag_map but leaving it on the list, so later calls to flush_object_free_events was getting a bad tag_map pointer in the JvmtiEnv. Coleen > > Thanks, > Serguei > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1539 From dholmes at openjdk.java.net Wed Dec 2 02:04:05 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 02:04:05 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 14:16:14 GMT, Coleen Phillimore wrote: >> Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: >> >> `$ java -XX:+UseNewCode -version >> [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). >> >> There is insufficient memory for the Java Runtime Environment to continue. >> Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages >> An error report file with more information is saved as: >> /16mprotect/hs_err_pid30596.log` >> ` > > Coleen Phillimore 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 mprotect > - Made resexhaused001.004 manual tests. You can't reliably run these tests. > - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 I'm okay with the functional change here, to do vm_exit_oom when guard page creation fails. I'm not sure about the test change. It was only problem-listed on Linux but now is "manual" on all platforms and so will now be excluded from automated testing on all platforms. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1540 From coleen.phillimore at oracle.com Wed Dec 2 02:08:07 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 1 Dec 2020 21:08:07 -0500 Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: On 12/1/20 9:04 PM, David Holmes wrote: > On Tue, 1 Dec 2020 14:16:14 GMT, Coleen Phillimore wrote: > >>> Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: >>> >>> `$ java -XX:+UseNewCode -version >>> [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). >>> >>> There is insufficient memory for the Java Runtime Environment to continue. >>> Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages >>> An error report file with more information is saved as: >>> /16mprotect/hs_err_pid30596.log` >>> ` >> Coleen Phillimore 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 mprotect >> - Made resexhaused001.004 manual tests. You can't reliably run these tests. >> - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 > I'm okay with the functional change here, to do vm_exit_oom when guard page creation fails. > > I'm not sure about the test change. It was only problem-listed on Linux but now is "manual" on all platforms and so will now be excluded from automated testing on all platforms. I didn't think these tests would be reliable anywhere, but maybe they were on Windows.? What do you suggest? Thanks for reviewing, Coleen > > ------------- > > Marked as reviewed by dholmes (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Wed Dec 2 02:13:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 02:13:56 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 23:01:51 GMT, David Holmes wrote: >> src/hotspot/share/runtime/arguments.cpp line 612: >> >>> 610: { "TraceRedefineClasses", "-Xlog:redefine+class=", "info", "16.0" }, >>> 611: { "PrintJNIResolving", "-Xlog:jni+resolve=", "debug", "16.0" }, >>> 612: { NULL, NULL, NULL, NULL } >> >> I think if we wanted to give a message that the flag was obsolete and to suggest changing the command line, we should only do it for -XX:+TraceClassLoading and -XX:+TraceExceptions (I'd originally thought -XX:+TraceClassUnloading was important enough to release note but now I'm not so sure.) The rest of the flags should either go in the table that they're no longer recognized. > > Keeping the message for any flag requires keeping all the supporting code. I don't see the "big 3" are special. They have been deprecated since 9 and we have clearly told people this when they use them. We're also release-noting this for 16 (again - this was documented when UL was added). I don't think we have to pander to anyone who hasn't updated their launch scripts by now. For these three, I kind of like the pandering. I'm not sure that the release note will reach people using these, especially -XX:+TraceExceptions. I guess they've been getting a deprecation message since 9 so maybe it won't be such a surprise. I never stand in the way of removing code that people won't need, if you think this is the case. ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From kbarrett at openjdk.java.net Wed Dec 2 02:15:05 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 2 Dec 2020 02:15:05 GMT Subject: RFR: 8257466: Improve enum iteration In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 22:23:51 GMT, Ioi Lam wrote: >> Please review this collection of improvements to the recently added enum >> iteration facility. These improvements are based on usage in some >> in-development changes. >> >> (1) Added EnumType nested type to EnumRange and EnumIterator. It is an alias >> for the enum type that is a template parameter for those classes. This is >> useful when dealing with a range or iterator whose associated enum type is >> not known because the range/iterator is a template parameter. >> >> (2) Added EnumRange::index(T), which converts the argument enumerator to >> a zero-based index into the range of values. This is useful when mapping >> from an enumerator to a corresponding array index, for example. >> >> (3) Allow enum range bounds to be specified using start and (exclusive) end >> integral (underlying type) values. This is useful when dealing with enums >> that are just value ranges and don't have named enumerators. As part of >> this, changes the enum iteration traits mechanism to use start/end rather >> than first/last, as that seems to be a little easier to deal with. >> >> (4) Added accessors for the first and last enumerator values of a range. >> >> (5) Added gtest for enum iteration. >> >> Testing: tier1 > > src/hotspot/share/utilities/enumIterator.hpp line 115: > >> 113: static constexpr EnumeratorRangeImpl::Underlying _start = \ >> 114: EnumeratorRangeImpl::underlying(Start); \ >> 115: static constexpr EnumeratorRangeImpl::Underlying _end = \ > > Why do we need to call `underlying(Start)` here? Can it be simplified as > static constexpr EnumeratorRangeImpl::Underlying _start = Start; > or > static constexpr EnumeratorRangeImpl::Underlying _start {Start}; I'd earlier considered requiring the type of Start and End be Underlying rather than convertible to that. The underlying() function is a partial remnant of that. I'll remove it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1530 From coleen.phillimore at oracle.com Wed Dec 2 02:16:46 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 1 Dec 2020 21:16:46 -0500 Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: <88a57523-9cea-36a3-a71c-3930389de982@oracle.com> including serviceability-dev. On 12/1/20 9:08 PM, Coleen Phillimore wrote: > > > On 12/1/20 9:04 PM, David Holmes wrote: >> On Tue, 1 Dec 2020 14:16:14 GMT, Coleen Phillimore >> wrote: >> >>>> Give an error message rather than logging the error and then >>>> crashing later because the JVM can't detect stack overflow.? In a >>>> resource exhausted situation, thread creation is also failing.? >>>> This is the vm_exit_out_of_memory message printed: >>>> >>>> `$ java -XX:+UseNewCode -version >>>> [0.003s][warning][os,thread] Attempt to protect stack guard pages >>>> failed (0x00007f606b249000-0x00007f606b24d000). >>>> >>>> ? There is insufficient memory for the Java Runtime Environment to >>>> continue. >>>> ? Native memory allocation (mprotect) failed to protect 16384 bytes >>>> for memory to guard stack pages >>>> ? An error report file with more information is saved as: >>>> ? /16mprotect/hs_err_pid30596.log` >>>> ` >>> Coleen Phillimore 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 mprotect >>> ? - Made resexhaused001.004 manual tests.? You can't reliably run >>> these tests. >>> ? - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 >> I'm okay with the functional change here, to do vm_exit_oom when >> guard page creation fails. >> >> I'm not sure about the test change. It was only problem-listed on >> Linux but now is "manual" on all platforms and so will now be >> excluded from automated testing on all platforms. > > I didn't think these tests would be reliable anywhere, but maybe they > were on Windows.? What do you suggest? > Thanks for reviewing, > Coleen >> >> ------------- >> >> Marked as reviewed by dholmes (Reviewer). >> >> PR: https://git.openjdk.java.net/jdk/pull/1540 > From coleen.phillimore at oracle.com Wed Dec 2 02:17:07 2020 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 1 Dec 2020 21:17:07 -0500 Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: <6e6287be-e9d0-2133-fd5b-f82de032154e@oracle.com> References: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> <6e6287be-e9d0-2133-fd5b-f82de032154e@oracle.com> Message-ID: <0b694c6b-cba6-1a41-05a8-c4449f63ebec@oracle.com> Including serviceability-dev. On 12/1/20 9:03 PM, Coleen Phillimore wrote: > > > On 12/1/20 7:12 PM, Serguei Spitsyn wrote: >> On Tue, 1 Dec 2020 14:19:15 GMT, Coleen Phillimore >> wrote: >> >>>> The JvmtiTagMap can be deleted while it is posting.? The JvmtiEnv >>>> is still on the list but the env is "disposed" of and the tag_map >>>> is deleted to save memory until the JvmtiEnv can be reclaimed at a >>>> safepoint and taken off the list. >>>> >>>> There's a check JvmtiEnvBase::check_for_periodic_clean_up() that >>>> determines whether the JvmtiEnv can be taken off the list and that >>>> check looks for whether threads are in the middle of >>>> JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count.? So >>>> this part is safe for the JvmtiTagMap changes. >>>> >>>> The fix is to clear the JvmtiTagMapTable of the entries inside the >>>> table lock to save memory but leave JvmtiTagMap intact so that we >>>> can load a valid pointer when iterating through JvmtiEnvIterator.? >>>> We could also not do this at all and let the JvmtiTagMap destructor >>>> delete the table when the JvmtiEnv is also deleted, but we don't >>>> know what customer situation led to this code in the first place. >>> Coleen Phillimore 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 more-jvmti-table >>> ? - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to >>> null out deleted entries. >>> ? - 8257140: Crash in JvmtiTagMap::flush_object_free_events() >> Hi Coleen, >> >> The JVMTI environment can be disposed with DisposeEnvironment: >> https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#DisposeEnvironment >> It seems to me that this operation is better to wait until posting is >> finished. Otherwise, the information is going to be lost in the >> report. Of course, we could blame the agent to call the >> DisposeEnvironment too early but then the agent needs a way to check >> if posting is finished. > > When the event is disposed, it calls set_event_callbacks(), which > calls flush_object_free_events, which will flush the remaining object > free events for this environment.? So the events aren't lost.? The bug > was that after that, the JvmtiEnv is marked as DISPOSED but it's still > on the list of JvmtiEnvIterator events that we walk until the next > safepoint.? When the JvmtiEnv is disposed, it was deleting the tag_map > but leaving it on the list, so later calls to flush_object_free_events > was getting a bad tag_map pointer in the JvmtiEnv. > > Coleen > >> >> Thanks, >> Serguei >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/1539 > From coleenp at openjdk.java.net Wed Dec 2 02:17:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 02:17:01 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:44:09 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags I approve if you remove or leave the big 3 as aliases. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From kbarrett at openjdk.java.net Wed Dec 2 02:30:14 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 2 Dec 2020 02:30:14 GMT Subject: RFR: 8257466: Improve enum iteration [v2] In-Reply-To: References: Message-ID: > Please review this collection of improvements to the recently added enum > iteration facility. These improvements are based on usage in some > in-development changes. > > (1) Added EnumType nested type to EnumRange and EnumIterator. It is an alias > for the enum type that is a template parameter for those classes. This is > useful when dealing with a range or iterator whose associated enum type is > not known because the range/iterator is a template parameter. > > (2) Added EnumRange::index(T), which converts the argument enumerator to > a zero-based index into the range of values. This is useful when mapping > from an enumerator to a corresponding array index, for example. > > (3) Allow enum range bounds to be specified using start and (exclusive) end > integral (underlying type) values. This is useful when dealing with enums > that are just value ranges and don't have named enumerators. As part of > this, changes the enum iteration traits mechanism to use start/end rather > than first/last, as that seems to be a little easier to deal with. > > (4) Added accessors for the first and last enumerator values of a range. > > (5) Added gtest for enum iteration. > > Testing: tier1 Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: iklam review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1530/files - new: https://git.openjdk.java.net/jdk/pull/1530/files/3a4dbd5c..6911c0fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1530&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1530&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 7 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1530/head:pull/1530 PR: https://git.openjdk.java.net/jdk/pull/1530 From kbarrett at openjdk.java.net Wed Dec 2 02:30:15 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 2 Dec 2020 02:30:15 GMT Subject: RFR: 8257466: Improve enum iteration [v2] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 02:12:19 GMT, Kim Barrett wrote: >> src/hotspot/share/utilities/enumIterator.hpp line 115: >> >>> 113: static constexpr EnumeratorRangeImpl::Underlying _start = \ >>> 114: EnumeratorRangeImpl::underlying(Start); \ >>> 115: static constexpr EnumeratorRangeImpl::Underlying _end = \ >> >> Why do we need to call `underlying(Start)` here? Can it be simplified as >> static constexpr EnumeratorRangeImpl::Underlying _start = Start; >> or >> static constexpr EnumeratorRangeImpl::Underlying _start {Start}; > > I'd earlier considered requiring the type of Start and End be Underlying rather than convertible to that. The underlying() function is a partial remnant of that. I'll remove it. Using brace initialization is the way to go, as it prevents narrowing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1530 From dholmes at openjdk.java.net Wed Dec 2 02:44:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 02:44:58 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 02:11:35 GMT, Coleen Phillimore wrote: >> Keeping the message for any flag requires keeping all the supporting code. I don't see the "big 3" are special. They have been deprecated since 9 and we have clearly told people this when they use them. We're also release-noting this for 16 (again - this was documented when UL was added). I don't think we have to pander to anyone who hasn't updated their launch scripts by now. > > For these three, I kind of like the pandering. I'm not sure that the release note will reach people using these, especially -XX:+TraceExceptions. I guess they've been getting a deprecation message since 9 so maybe it won't be such a surprise. I never stand in the way of removing code that people won't need, if you think this is the case. I think we should remove them. There is a risk that the user might not notice the difference between the old and new messages and so not realize they don't actually have active logging any more (until they go to access the logs to diagnose a problem). ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From dholmes at openjdk.java.net Wed Dec 2 02:44:57 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 02:44:57 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:44:09 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags I'm still pushing for treating all flags the same and removing all the aliased-flag code. Coleen seems to be okay either way. :) Thanks, David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From coleenp at openjdk.java.net Wed Dec 2 02:45:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 02:45:03 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: <4FfesCoTJvLcNiOv5zExVnGe7BM3O3NmuoxNwG10NTc=.73f23f82-b9a1-433a-a30b-00d2da70d70f@github.com> On Wed, 2 Dec 2020 02:01:41 GMT, David Holmes wrote: >> Coleen Phillimore 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 mprotect >> - Made resexhaused001.004 manual tests. You can't reliably run these tests. >> - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 > > I'm okay with the functional change here, to do vm_exit_oom when guard page creation fails. > > I'm not sure about the test change. It was only problem-listed on Linux but now is "manual" on all platforms and so will now be excluded from automated testing on all platforms. // Check platform here (instead of @requires) as this test is also called from resexhausted004 if (Platform.isWindows()) { throw new SkippedException("Cannot get JVMTI_RESOURCE_EXHAUSTED_THREADS on Windows"); } The test is programmatically excluded on windows. There's also bug https://bugs.openjdk.java.net/browse/JDK-8244640 which shows that the uncommit_memory() sort of works on windows, but then stack overflow handling is then incorrect. This test, and test resexhausted004 are useful for testing JVMTI_RESOURCE_EXHAUSTED_THREADS, but not as part of our test system since it fails periodically for at least the last 10 years. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From sspitsyn at openjdk.java.net Wed Dec 2 04:03:59 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Dec 2020 04:03:59 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> References: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> Message-ID: <-PmF4wus3tQrE5laLSdXgiMZQWkOjb5-ORcRhuX9KvY=.444b2e07-c521-4c27-8e70-311147fcec84@github.com> On Tue, 1 Dec 2020 14:19:15 GMT, Coleen Phillimore wrote: >> The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. >> >> There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. >> >> The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. > > Coleen Phillimore 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 more-jvmti-table > - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. > - 8257140: Crash in JvmtiTagMap::flush_object_free_events() This is reasonable. Thank you for the explanation! The fix looks good to me. > When the event is disposed, it calls set_event_callbacks()... You, probably meant "environment" is disposed, not "event". This correction is for other readers. :) ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1539 From dholmes at openjdk.java.net Wed Dec 2 04:04:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 04:04:55 GMT Subject: RFR: 8257505: nsk/share/test/StressOptions stressTime is scaled in getter but not when printed In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:22:18 GMT, Stefan Johansson wrote: > Please review this small change to print the correct stress time for tests using `StressOptions`. > > Quite recently the `getTime()` method on `StressOptions` was changed to scale the stress time using the JTREG timeout factor. See: [JDK-8252522](https://bugs.openjdk.java.net/browse/JDK-8252522) > > The `printInfo()` method was left using the raw `time` member and will thus output a different time from the one actually used. This change fixes this by using the getter. For consistency the other values are fetched by the getters as well. Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1545 From ysuenaga at openjdk.java.net Wed Dec 2 04:17:58 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 2 Dec 2020 04:17:58 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> Message-ID: <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> On Tue, 24 Nov 2020 17:43:30 GMT, Erik Gahlin wrote: >> All of failures on GitHub Actions are not caused by this PR. > > Will this fix be able to handla all cases of OOM? @egahlin Is this answer sufficient for you about OOM handling? All comments are welcome. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From vladimir.kozlov at oracle.com Wed Dec 2 04:20:29 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 1 Dec 2020 20:20:29 -0800 Subject: HotSpot Style Guide change process In-Reply-To: References: <376E1F97-57DE-46CD-B656-BC5340E0BA07@oracle.com> Message-ID: Okay. I did not realize that we are already using "rough consensus" in our processes. Thank you, Kim, for pointers. I take back my original suggestion. My next suggestion is to change [rough consensus] link to https://tools.ietf.org/html/rfc7282 which is used by Vulnerability group and also referenced by Wikipedia. It is more formal and will be available for longer time. Regards, Vladimir On 12/1/20 5:25 PM, David Holmes wrote: > Hi Kim, > > "rough consensus" has good precedents and is something we should follow here IMO. OpenJDK by-laws are for the formal > parts of the OpenJDK processes themselves, not for everything single thing done under the OpenJDK banner. > > Cheers, > David > > On 1/12/2020 4:43 pm, Kim Barrett wrote: >> When the Style Guide was updated for C++11/14 usage and other cleanup >> (JDK-8247976), a change process was added to it.? It says >> >> ?? Proposed changes should be discussed on the >> ?? [HotSpot Developers](mailto:hotspot-dev at openjdk.java.net) mailing >> ?? list, and approved by >> ?? [rough consensus](https://en.wikipedia.org/wiki/Rough_consensus) of >> ?? the [HotSpot Group](https://openjdk.java.net/census#hotspot) Members. >> ?? The Group Lead determines whether consensus has been reached. >> ?? Changes are likely to be cautious and incremental, since HotSpot >> ?? coders have been using these guidelines for years. >> >> Vladimir Kozlov has questioned this process and suggests another: >> >>> I looked again on voting description for Style Guide changes. And it >>> references to `rough consensus` which is not in OpenJDK bylaws : >>> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html#L69 >>> >>> I think it is bug (separate from these changes) and should be fixed by >>> using our rule http://openjdk.java.net/bylaws#three-vote-consensus >>> With Project Lead final vote we will need at least 2 other members votes >>> during 2 weeks review period. I think it is similar to `rough consensus`. >> >> Use of "rough consensus" with an arbiter has precedent within the OpenJDK, >> though it's not used in the bylaws. The current text quoted above was based >> on >> >> https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> JEP 2.0, draft 2 - see "Planning", 4th bullet >> >> and >> >> https://openjdk.java.net/groups/vulnerability/ >> OpenJDK Vulnerability Group - see "Making decisions" >> >> So both the JEP Process and the Vulnerability Group use rough consensus, >> with the relevant lead as the arbiter.? (The V-Team page links to an IETF >> document describing rough consensus.? The HotSpot Style Guide links to >> the same Wikipedia article as the JEP 2.0 Process; that Wikipedia article >> references the IETF page.) >> >> I called out the new change process specifically in the initial RFR email >> for JDK-8247976, but that part didn't generate much (any?) discussion. >> >> If we don't like it we are certainly free to change.? And if Vladimir >> doesn't like it then we should change, since as HotSpot Lead he's fairly >> central to that process. But I don't think there's a "lack of precedent" >> or "not appropriate for OpenJDK" argument for changing. >> >> I chose that process because I didn't want it to be too easy to make changes >> to the Style Guide. In particular, I think it should require more effort >> than is involved in a typical RFR. >> >> Even if we don't change, and especially if we do, some further refinement of >> the mechanics may be needed. I think the current mechanics may have a >> problem that the request shows up in one's mailbox looking pretty much like >> an ordinary RFR. When I was originally thinking about that text we were in a >> world of pure email change requests, and the document was still a wiki page. >> With the move of the document to the jdk repository and the move to github >> and PRs + Skara support for changes, the mechanics are different. It might >> be better if it could be subject tagged differently, as we do with Call for >> Vote emails. There are probably things we could do about that, if others >> agree that's a problem. Or maybe some of you see other problems? >> From lmesnik at openjdk.java.net Wed Dec 2 04:21:01 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Dec 2020 04:21:01 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: Message-ID: <___yf1Gd5MQWugSq_RZRaoHMB2ufD0ZYuvXyhn782q0=.20e07ef4-4a4a-4f4f-89ba-bd2a5bdb397c@github.com> On Tue, 1 Dec 2020 14:16:14 GMT, Coleen Phillimore wrote: >> Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: >> >> `$ java -XX:+UseNewCode -version >> [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). >> >> There is insufficient memory for the Java Runtime Environment to continue. >> Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages >> An error report file with more information is saved as: >> /16mprotect/hs_err_pid30596.log` >> ` > > Coleen Phillimore 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 mprotect > - Made resexhaused001.004 manual tests. You can't reliably run these tests. > - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java line 41: > 39: * @library /vmTestbase > 40: * /test/lib > 41: * @run main/othervm/native/manual/timeout=240 What is the reason to make this test manual? ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From lmesnik at openjdk.java.net Wed Dec 2 04:52:01 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Wed, 2 Dec 2020 04:52:01 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: <___yf1Gd5MQWugSq_RZRaoHMB2ufD0ZYuvXyhn782q0=.20e07ef4-4a4a-4f4f-89ba-bd2a5bdb397c@github.com> Message-ID: On Wed, 2 Dec 2020 04:48:08 GMT, Coleen Phillimore wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java line 41: >> >>> 39: * @library /vmTestbase >>> 40: * /test/lib >>> 41: * @run main/othervm/native/manual/timeout=240 >> >> What is the reason to make this test manual? > > These tests are unreliable. Sorry, I've missed the answer to the same question. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Wed Dec 2 04:52:00 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 04:52:00 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: <___yf1Gd5MQWugSq_RZRaoHMB2ufD0ZYuvXyhn782q0=.20e07ef4-4a4a-4f4f-89ba-bd2a5bdb397c@github.com> References: <___yf1Gd5MQWugSq_RZRaoHMB2ufD0ZYuvXyhn782q0=.20e07ef4-4a4a-4f4f-89ba-bd2a5bdb397c@github.com> Message-ID: On Wed, 2 Dec 2020 04:16:11 GMT, Leonid Mesnik wrote: >> Coleen Phillimore 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 mprotect >> - Made resexhaused001.004 manual tests. You can't reliably run these tests. >> - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java line 41: > >> 39: * @library /vmTestbase >> 40: * /test/lib >> 41: * @run main/othervm/native/manual/timeout=240 > > What is the reason to make this test manual? These tests are unreliable. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From iklam at openjdk.java.net Wed Dec 2 05:00:05 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 05:00:05 GMT Subject: RFR: 8257563: Remove excessive include of klass.inline.hpp Message-ID: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> klass.inline.hpp is unnecessarily included by two popular header files: oop.inline.hpp and modRefBarrierSet.inline.hpp These two `#include` lines recursively pull in many header files. Removing them reduce the total number of header inclusion for building HotSpot from 260096 to 254773, or about 2%. Notes to reviewer. The main changes are in the header files: * src/hotspot/share/classfile/systemDictionaryShared.hpp * src/hotspot/share/gc/shared/modRefBarrierSet.inline.hpp * src/hotspot/share/oops/instanceKlass.hpp * src/hotspot/share/oops/instanceKlass.inline.hpp * src/hotspot/share/oops/oop.inline.hpp ------------- Commit messages: - 8257563: Remove excessive include of klass.inline.hpp Changes: https://git.openjdk.java.net/jdk/pull/1552/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1552&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257563 Stats: 276 lines in 83 files changed: 180 ins; 69 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/1552.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1552/head:pull/1552 PR: https://git.openjdk.java.net/jdk/pull/1552 From iklam at openjdk.java.net Wed Dec 2 05:42:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 05:42:57 GMT Subject: RFR: 8257466: Improve enum iteration [v2] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 02:30:14 GMT, Kim Barrett wrote: >> Please review this collection of improvements to the recently added enum >> iteration facility. These improvements are based on usage in some >> in-development changes. >> >> (1) Added EnumType nested type to EnumRange and EnumIterator. It is an alias >> for the enum type that is a template parameter for those classes. This is >> useful when dealing with a range or iterator whose associated enum type is >> not known because the range/iterator is a template parameter. >> >> (2) Added EnumRange::index(T), which converts the argument enumerator to >> a zero-based index into the range of values. This is useful when mapping >> from an enumerator to a corresponding array index, for example. >> >> (3) Allow enum range bounds to be specified using start and (exclusive) end >> integral (underlying type) values. This is useful when dealing with enums >> that are just value ranges and don't have named enumerators. As part of >> this, changes the enum iteration traits mechanism to use start/end rather >> than first/last, as that seems to be a little easier to deal with. >> >> (4) Added accessors for the first and last enumerator values of a range. >> >> (5) Added gtest for enum iteration. >> >> Testing: tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > iklam review Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1530 From dholmes at openjdk.java.net Wed Dec 2 05:50:54 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 05:50:54 GMT Subject: RFR: 8257563: Remove excessive include of klass.inline.hpp In-Reply-To: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> References: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> Message-ID: <88Ld0OwZCdyR2qNBSjqvbgqpoyuSVEXuGmZaPEIXNqE=.950da6e0-c106-4b23-9dd3-74020ff18b5c@github.com> On Wed, 2 Dec 2020 04:44:27 GMT, Ioi Lam wrote: > klass.inline.hpp is unnecessarily included by two popular header files: oop.inline.hpp and modRefBarrierSet.inline.hpp > > These two `#include` lines recursively pull in many header files. Removing them reduce the total number of header inclusion for building HotSpot from 260096 to 254773, or about 2%. > > Notes to reviewer. The main changes are in the header files: > > * src/hotspot/share/classfile/systemDictionaryShared.hpp > * src/hotspot/share/gc/shared/modRefBarrierSet.inline.hpp > * src/hotspot/share/oops/instanceKlass.hpp > * src/hotspot/share/oops/instanceKlass.inline.hpp > * src/hotspot/share/oops/oop.inline.hpp Seems okay. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1552 From egahlin at openjdk.java.net Wed Dec 2 07:21:56 2020 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 2 Dec 2020 07:21:56 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> Message-ID: On Wed, 2 Dec 2020 04:15:38 GMT, Yasumasa Suenaga wrote: >> Will this fix be able to handla all cases of OOM? > > @egahlin Is this answer sufficient for you about OOM handling? All comments are welcome. I think there is a use case for getting an event when an OOM occurs, but the long term plan is to change so that a jdk.JavaErrorThrow is emitted when the exception is thrown, not when the object is allocated. When that is fixed, it will take care of OOME automatically - at all places. I think it is confusing for users to not get an event at every OOME and users/customers will file bugs. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From iklam at openjdk.java.net Wed Dec 2 07:58:07 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 07:58:07 GMT Subject: RFR: 8257565: epsilonBarrierSet.hpp should not include barrierSetAssembler [v3] In-Reply-To: References: Message-ID: > Please review this trivial fix: > > epsilonBarrierSet.hpp is included (recursively via access.hpp) by many CPP files. It unncessarily includes of barrierSetAssembler.hpp, which causes many of the native code assembler header files to be unnecessarily included by many HotSpot CPP files that do not deal with native code assembly. > > Removing this one line reduced the total number of header inclusion for building HotSpot from 260096 to 258193, or about 0.8%. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed aarch64 build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1554/files - new: https://git.openjdk.java.net/jdk/pull/1554/files/82b91085..1df60549 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1554&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1554&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1554.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1554/head:pull/1554 PR: https://git.openjdk.java.net/jdk/pull/1554 From sjohanss at openjdk.java.net Wed Dec 2 08:56:54 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 2 Dec 2020 08:56:54 GMT Subject: RFR: 8257505: nsk/share/test/StressOptions stressTime is scaled in getter but not when printed In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 22:45:38 GMT, Kim Barrett wrote: >> Please review this small change to print the correct stress time for tests using `StressOptions`. >> >> Quite recently the `getTime()` method on `StressOptions` was changed to scale the stress time using the JTREG timeout factor. See: [JDK-8252522](https://bugs.openjdk.java.net/browse/JDK-8252522) >> >> The `printInfo()` method was left using the raw `time` member and will thus output a different time from the one actually used. This change fixes this by using the getter. For consistency the other values are fetched by the getters as well. > > Looks good, and trivial. Thanks @kimbarrett and @dholmes-ora for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/1545 From sjohanss at openjdk.java.net Wed Dec 2 08:56:56 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 2 Dec 2020 08:56:56 GMT Subject: Integrated: 8257505: nsk/share/test/StressOptions stressTime is scaled in getter but not when printed In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 21:22:18 GMT, Stefan Johansson wrote: > Please review this small change to print the correct stress time for tests using `StressOptions`. > > Quite recently the `getTime()` method on `StressOptions` was changed to scale the stress time using the JTREG timeout factor. See: [JDK-8252522](https://bugs.openjdk.java.net/browse/JDK-8252522) > > The `printInfo()` method was left using the raw `time` member and will thus output a different time from the one actually used. This change fixes this by using the getter. For consistency the other values are fetched by the getters as well. This pull request has now been integrated. Changeset: 9de283b8 Author: Stefan Johansson URL: https://git.openjdk.java.net/jdk/commit/9de283b8 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8257505: nsk/share/test/StressOptions stressTime is scaled in getter but not when printed Reviewed-by: kbarrett, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1545 From ysuenaga at openjdk.java.net Wed Dec 2 09:06:57 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 2 Dec 2020 09:06:57 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> Message-ID: On Wed, 2 Dec 2020 07:19:19 GMT, Erik Gahlin wrote: >> @egahlin Is this answer sufficient for you about OOM handling? All comments are welcome. > > I think there is a use case for getting an event when an OOM occurs, but the long term plan is to change so that a jdk.JavaErrorThrow is emitted when the exception is thrown, not when the object is allocated. When that is fixed, it will take care of OOME automatically - at all places. I think it is confusing for users to not get an event at every OOME and users/customers will file bugs. Why OOME is not reported? I guess it is hard corded at `ThrowableTracer::traceError`. If it is correct, because it is implemented in Java? (JFR code in Java might not be work when OOME happens) `ErrorThrownEvent` has description that says OutOfMemoryErrors are ignored, and also OOM in metaspace is reported in other event (`MetaspaceOOM`). So I think we can report OOM other than `jdk.JavaErrorThrow` now until "long term plan" is realized. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From aph at openjdk.java.net Wed Dec 2 09:29:54 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 2 Dec 2020 09:29:54 GMT Subject: RFR: 8248736: [aarch64] runtime/signal/TestSigpoll.java failed "fatal error: not an ldr (literal) instruction." In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 15:11:18 GMT, Stuart Monteith wrote: > Change mov to movptr in the nmethod entry barrier. movptr will generate a consistent number of mov/movk instructions that are necessary to consistently calculate the size of the nmethod barrier. Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1481 From stuefe at openjdk.java.net Wed Dec 2 09:40:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 09:40:56 GMT Subject: RFR: 8257563: Remove excessive include of klass.inline.hpp In-Reply-To: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> References: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> Message-ID: On Wed, 2 Dec 2020 04:44:27 GMT, Ioi Lam wrote: > klass.inline.hpp is unnecessarily included by two popular header files: oop.inline.hpp and modRefBarrierSet.inline.hpp > > These two `#include` lines recursively pull in many header files. Removing them reduce the total number of header inclusion for building HotSpot from 260096 to 254773, or about 2%. > > Notes to reviewer. The main changes are in the header files: > > * src/hotspot/share/classfile/systemDictionaryShared.hpp > * src/hotspot/share/gc/shared/modRefBarrierSet.inline.hpp > * src/hotspot/share/oops/instanceKlass.hpp > * src/hotspot/share/oops/instanceKlass.inline.hpp > * src/hotspot/share/oops/oop.inline.hpp LGTM. Thank you for doing this. My slow notebook thanks you. ..Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1552 From shade at openjdk.java.net Wed Dec 2 10:24:56 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 2 Dec 2020 10:24:56 GMT Subject: RFR: 8248736: [aarch64] runtime/signal/TestSigpoll.java failed "fatal error: not an ldr (literal) instruction." In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 15:11:18 GMT, Stuart Monteith wrote: > Change mov to movptr in the nmethod entry barrier. movptr will generate a consistent number of mov/movk instructions that are necessary to consistently calculate the size of the nmethod barrier. Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1481 From smonteith at openjdk.java.net Wed Dec 2 10:24:57 2020 From: smonteith at openjdk.java.net (Stuart Monteith) Date: Wed, 2 Dec 2020 10:24:57 GMT Subject: Integrated: 8248736: [aarch64] runtime/signal/TestSigpoll.java failed "fatal error: not an ldr (literal) instruction." In-Reply-To: References: Message-ID: On Fri, 27 Nov 2020 15:11:18 GMT, Stuart Monteith wrote: > Change mov to movptr in the nmethod entry barrier. movptr will generate a consistent number of mov/movk instructions that are necessary to consistently calculate the size of the nmethod barrier. This pull request has now been integrated. Changeset: 9a60413b Author: Stuart Monteith Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/9a60413b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8248736: [aarch64] runtime/signal/TestSigpoll.java failed "fatal error: not an ldr (literal) instruction." Reviewed-by: aph, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1481 From stuefe at openjdk.java.net Wed Dec 2 10:54:03 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 10:54:03 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set Message-ID: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Hi, may I please have reviews for the following very small improvement: While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: size_t os::_page_sizes[os::page_sizes_max]; is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). That has the following advantages: - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. ----- The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. Testing: - nightlies at SAP - manual tests with UseLargePages - the new gtests - gh actions (with x86 still failing because of unrelated issues) Thank you, Thomas [1] https://bugs.openjdk.java.net/browse/JDK-8243315 [2] https://bugs.openjdk.java.net/browse/JDK-8256155 ------------- Commit messages: - Add PagesizeSet Changes: https://git.openjdk.java.net/jdk/pull/1522/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257588 Stats: 227 lines in 7 files changed: 174 ins; 30 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/1522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1522/head:pull/1522 PR: https://git.openjdk.java.net/jdk/pull/1522 From kim.barrett at oracle.com Wed Dec 2 11:02:05 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Dec 2020 06:02:05 -0500 Subject: HotSpot Style Guide change process In-Reply-To: References: <376E1F97-57DE-46CD-B656-BC5340E0BA07@oracle.com> Message-ID: > On Dec 1, 2020, at 11:20 PM, Vladimir Kozlov wrote: > > Okay. I did not realize that we are already using "rough consensus" in our processes. > Thank you, Kim, for pointers. I take back my original suggestion. > > My next suggestion is to change [rough consensus] link to https://tools.ietf.org/html/rfc7282 which is used by Vulnerability group and also referenced by Wikipedia. It is more formal and will be available for longer time. That seems reasonable. https://bugs.openjdk.java.net/browse/JDK-8257589 > On 12/1/20 5:25 PM, David Holmes wrote: >> Hi Kim, >> "rough consensus" has good precedents and is something we should follow here IMO. OpenJDK by-laws are for the formal parts of the OpenJDK processes themselves, not for everything single thing done under the OpenJDK banner. >> Cheers, >> David >> On 1/12/2020 4:43 pm, Kim Barrett wrote: >>> Even if we don't change, and especially if we do, some further refinement of >>> the mechanics may be needed. I think the current mechanics may have a >>> problem that the request shows up in one's mailbox looking pretty much like >>> an ordinary RFR. When I was originally thinking about that text we were in a >>> world of pure email change requests, and the document was still a wiki page. >>> With the move of the document to the jdk repository and the move to github >>> and PRs + Skara support for changes, the mechanics are different. It might >>> be better if it could be subject tagged differently, as we do with Call for >>> Vote emails. There are probably things we could do about that, if others >>> agree that's a problem. Or maybe some of you see other problems? I?d still like to get some feedback on the mechanics. Is what I?ve done for a couple of changes working for folks? That is, is using a normal github PR for the change, with ?yes? votes via review approvals, good enough? Are there changes that would make this work better? I?m mostly worried that we seem to be getting more or less the same small group of people. I can?t tell if that?s because others aren?t bothering, or are they not noticing. We want high visibility on changes to the Style Guide. From rrich at openjdk.java.net Wed Dec 2 11:41:02 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 2 Dec 2020 11:41:02 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 20:34:09 GMT, Thomas Stuefe wrote: >> To analyze JDK-8256729 further, we need more tracing: >> >> 1) We should print all mappings inside the split area if os::split_reserved_memory() fails >> >> 2) The print-mapping code on windows has some shortcomings: >> - should not probe for mappings outside of what we know are valid address ranges for Windows >> - should handle wrap-arounds - it should be possible to print the whole address space >> - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) >> - should be printed in a more compact manner - base address should be on the same line as the first region >> - maybe adorned with some basic range info, e.g. library mappings >> >> Tested in our nightlies for a week now, works fine. >> >> Example output see https://github.com/openjdk/jdk/files/5622718/mapping-printout.txt > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Ioi Hi Thomas, I've got a few minor comments for you. Have you got a sample of the trace you could share in this PR? Thanks, Richard. src/hotspot/os/windows/os_windows.cpp line 3220: > 3218: log_warning(os)("os::split_reserved_memory failed for " RANGE_FORMAT, > 3219: RANGE_FORMAT_ARGS(base, size)); > 3220: os::print_memory_mappings((char*)base, size, tty); The type cast for `base` is redundant. src/hotspot/os/windows/os_windows.cpp line 3218: > 3216: (attempt_reserve_memory_at(split_address, size - split) != NULL); > 3217: if (!rc) { > 3218: log_warning(os)("os::split_reserved_memory failed for " RANGE_FORMAT, I'm not very much in favor of the closing ")". It will confuse editors trying to match brackets/parenthesis when reading logs. Also I think it is redundant because an inclusive end does not make much sense without specifying how many bytes are included at the end address. I see there are already uses of that style so I won't veto if you prefer to keep it. src/hotspot/os/windows/os_windows.cpp line 6074: > 6072: char buf[MAX_PATH]; > 6073: int dummy; > 6074: if (os::dll_address_to_library_name(allocation_base, buf, sizeof(buf), &dummy)) { You could pass nullptr instead of &dummy src/hotspot/os/windows/os_windows.cpp line 6001: > 5999: const int errval = 0xDE210244; > 6000: for (int i = 0; i < num_words; i++) { > 6001: v[i] = SafeFetch32((int*)p + i, errval); I think you will get a sign extend of the loaded 4 bytes to 8 bytes intptr_t on 64 bit. This will be confusing. What about using int[] for v and INTX_FORMAT for printing? Alternatively you could leave it like this and use SafeFetchN(). I'd think that would be best. src/hotspot/os/windows/os_windows.cpp line 6141: > 6139: // is large, this may take a long time. Therefore lets stop right away if the address > 6140: // is outside of what we know are valid addresses on Windows. Also, add a loop fuse. > 6141: static const address end_phys = (address)(LP64_ONLY(0x7ffffffffffULL) NOT_LP64(3*G)); This is a virtual address, right? So better name it end_virt? src/hotspot/os/windows/os_windows.cpp line 6108: > 6106: address end = start + bytes; > 6107: address p = start; > 6108: if (p == NULL) { // Lets skip the zero pages. According to hotspot-style.md nullptr should be preferred. src/hotspot/share/runtime/os.cpp line 1742: > 1740: // Prints all mappings > 1741: void os::print_memory_mappings(outputStream* st) { > 1742: os::print_memory_mappings(NULL, (size_t)-1, st); According to hotspot-style.md nullptr should be preferred. test/hotspot/gtest/runtime/test_os.cpp line 504: > 502: buf[0] = '\0'; > 503: stringStream ss(buf, buflen); > 504: if (start != NULL) { According to hotspot-style.md nullptr should be preferred. test/hotspot/gtest/runtime/test_os.cpp line 523: > 521: > 522: TEST_VM(os, show_mappings_full_range) { > 523: test_show_mappings(NULL, 0); According to hotspot-style.md nullptr should be preferred. ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 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 smonteith at openjdk.java.net Wed Dec 2 12:11:55 2020 From: smonteith at openjdk.java.net (Stuart Monteith) Date: Wed, 2 Dec 2020 12:11:55 GMT Subject: RFR: 8248736: [aarch64] runtime/signal/TestSigpoll.java failed "fatal error: not an ldr (literal) instruction." In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 10:21:28 GMT, Aleksey Shipilev wrote: >> Change mov to movptr in the nmethod entry barrier. movptr will generate a consistent number of mov/movk instructions that are necessary to consistently calculate the size of the nmethod barrier. > > Marked as reviewed by shade (Reviewer). Thanks for your reviews @shipilev , @theRealAph! ------------- PR: https://git.openjdk.java.net/jdk/pull/1481 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 vlivanov at openjdk.java.net Wed Dec 2 12:14:56 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 2 Dec 2020 12:14:56 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <7wHC1VVBP5st7PFgles4qKeLp_A2CmycoFLranbEc2c=.81b6b4df-a260-4a55-8597-ff7facd1181f@github.com> References: <7wHC1VVBP5st7PFgles4qKeLp_A2CmycoFLranbEc2c=.81b6b4df-a260-4a55-8597-ff7facd1181f@github.com> Message-ID: <9yTVrPzoPijjtZlmJOku2uCaO0CJ7GRxgQS-5mf0BrU=.7ef38347-aaa5-4f49-b459-e9f36552e8c4@github.com> On Tue, 1 Dec 2020 15:52:59 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/opto/machnode.cpp line 817: >> >>> 815: void MachCallBlackholeNode::dump_spec(outputStream *st) const { >>> 816: st->print("Blackhole "); >>> 817: MachCallNode::dump_spec(st); >> >> How does the output look like? It would be nice to have the info what are the values being consumed and where they are located. > > I am not sure what takes this path. I modeled this after other `MachCall*Node`-s, by delegating to `MachCallNode`, plus the type message. I thought that would be enough to dump the superclass-call-specific spec. `Node::dump()` eventually calls it. Also, IGV collects and shows it (thought it's trimmed right now). There's no flag to dump Mach IR except `-XX:+PrintOptoAssembly`, but it shows different info. Thinking more about it, I don't see much benefit in improving `MachCallBlackholeNode::dump()` since it lacks some important information. Considering blackholes don't obey standard calling conventions, it's hard to say where the arguments are located in generated code. It would be nice to enrich `-XX:+PrintOptoAssembly` with information about consumed values. `MachNode::format` has access to such information through `PhaseRegAlloc* ra` argument. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From vladimir.x.ivanov at oracle.com Wed Dec 2 12:18:48 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 2 Dec 2020 15:18:48 +0300 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: <5b64ff35-ba02-30a6-b883-80682d4a1af5@oracle.com> >> src/hotspot/share/opto/doCall.cpp line 115: >> >>> 113: >>> 114: // Try blackholing a method >>> 115: if (callee->is_loaded() && >> >> The check can be turned into a property on `ciMethod` and the result cached there. > > Yes, but only partially, because C1 and C2 check their own directive sets, and C2 also checks for matching rule. But it does skip unloaded methods more cleanly if we move the first two checks to `ciMethod`. Fixed. I would assume that `-XX:CompileCommand=blackhole,method` marks the method as a blackhole for the whole JVM instance (irrespective of what JIT is used or . Why can't you perform the query from the ciMethod itself? Or do you see controlling it on per-compilation basis valuable? Best regards, Vladimir Ivanov From stefank at openjdk.java.net Wed Dec 2 12:24:57 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 2 Dec 2020 12:24:57 GMT Subject: RFR: 8257563: Remove excessive include of klass.inline.hpp In-Reply-To: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> References: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> Message-ID: On Wed, 2 Dec 2020 04:44:27 GMT, Ioi Lam wrote: > klass.inline.hpp is unnecessarily included by two popular header files: oop.inline.hpp and modRefBarrierSet.inline.hpp > > These two `#include` lines recursively pull in many header files. Removing them reduce the total number of header inclusion for building HotSpot from 260096 to 254773, or about 2%. > > Notes to reviewer. The main changes are in the header files: > > * src/hotspot/share/classfile/systemDictionaryShared.hpp > * src/hotspot/share/gc/shared/modRefBarrierSet.inline.hpp > * src/hotspot/share/oops/instanceKlass.hpp > * src/hotspot/share/oops/instanceKlass.inline.hpp > * src/hotspot/share/oops/oop.inline.hpp Nice! One comment: src/hotspot/cpu/s390/s390.ad line 1329: > 1327: > 1328: #include "oops/klass.inline.hpp" > 1329: I wonder if this should be put in adlc/main.cpp. I'm not sure, but I don't think we usually put includes in the .ad files. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1552 From stuefe at openjdk.java.net Wed Dec 2 12:25:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 12:25:57 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: <2BOQW8WbRGtejblDy_jz1DwhI2hi-Td6ZVdGPb1VwZQ=.bf6b2f75-2ced-494c-9fc5-bff41f21dce2@github.com> On Wed, 2 Dec 2020 11:38:29 GMT, Richard Reingruber wrote: > Hi Thomas, > > I've got a few minor comments for you. > > Have you got a sample of the trace you could share in this PR? > > Thanks, Richard. Yes, see link in the PR description. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Wed Dec 2 12:29:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 12:29:59 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: <3F0jAXa5fJz16qWOMgcI31Yr3A4fmtawA3v7G3-lRZ0=.72c8b39b-7948-431d-abbf-859c1aed066d@github.com> On Wed, 2 Dec 2020 08:50:49 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Ioi > > src/hotspot/os/windows/os_windows.cpp line 3218: > >> 3216: (attempt_reserve_memory_at(split_address, size - split) != NULL); >> 3217: if (!rc) { >> 3218: log_warning(os)("os::split_reserved_memory failed for " RANGE_FORMAT, > > I'm not very much in favor of the closing ")". It will confuse editors trying to match brackets/parenthesis when reading logs. Also I think it is redundant because an inclusive end does not make much sense without specifying how many bytes are included at the end address. > > I see there are already uses of that style so I won't veto if you prefer to keep it. Okay, I agree. Good point with the editors. Exclusive end is the usual default anyway. I'll rework this in a follow up if there is a follow up (there probably will be one). ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stefank at openjdk.java.net Wed Dec 2 12:30:54 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 2 Dec 2020 12:30:54 GMT Subject: Integrated: 8256382: Use try_lock for hs_err EventLog printing In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 12:46:08 GMT, Stefan Karlsson wrote: > The EventLog locks are taken when the hs_err files are generated. Since crashes and asserts can occur when other locks are held, this can cause lock reordering problems if the held locks also are low-rank locks. There's no way to solve this if blocking locks are taken. > > I hit this problem when investigating making the GCLogPrecious lock use the lowest lock rank (same as EventLog). See JDK-8254877. > > Both GCLogPrecious and EventLog are considered "leaf" locks. No other locks should be taken when those locks are taken. However, if we crash in either of these sub-systems, there will be a lock-reordering error message in the hs_err file, and the rest of the logged info is skipped in the currently logged section. > > The proposal is to use try_lock_without_range_check and only log information if the lock could be acquired without blocking. This relies on the new try_lock_without_range_check function from JDK-8255678. > > I've tested this by injecting crashes while not holding locks in both GCLogPrecious, while holding locks during EventLog logging, and when not holding the locks, and verified that we get the expected behavior. > > Example output while crashing during 'Internal exceptions' logging: > Classes redefined (0 events): > No events > > Internal exceptions (5 events): > No events printed - crash while holding lock > > Events (20 events): > Event: 1,437 loading class java/util/HashMap$KeyIterator > Event: 1,438 loading class java/util/HashMap$KeyIterator done > Event: 1,438 loading class java/lang/module/ModuleDescriptor$Exports This pull request has now been integrated. Changeset: 1fd0ea70 Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/1fd0ea70 Stats: 30 lines in 1 file changed: 26 ins; 0 del; 4 mod 8256382: Use try_lock for hs_err EventLog printing Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1408 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 stuefe at openjdk.java.net Wed Dec 2 12:47:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 12:47:58 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 11:25:13 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Ioi > > src/hotspot/os/windows/os_windows.cpp line 6001: > >> 5999: const int errval = 0xDE210244; >> 6000: for (int i = 0; i < num_words; i++) { >> 6001: v[i] = SafeFetch32((int*)p + i, errval); > > I think you will get a sign extend of the loaded 4 bytes to 8 bytes intptr_t on 64 bit. This will be confusing. What about using int[] for v and INTX_FORMAT for printing? > Alternatively you could leave it like this and use SafeFetchN(). I'd think that would be best. Oh this is a stupid mistake. I alternated several times between SafeFetchN and SafeFetch32. I must have committed an inconsistent version. Good catch. ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Wed Dec 2 12:51:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 12:51:57 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 11:38:07 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Ioi > > test/hotspot/gtest/runtime/test_os.cpp line 523: > >> 521: >> 522: TEST_VM(os, show_mappings_full_range) { >> 523: test_show_mappings(NULL, 0); > > According to hotspot-style.md nullptr should be preferred. Sigh. I have an unreasonable dislike against nullptr and the churn that causes (NULL is nullptr anyway post C++11). But I'll be a good boy and change all those :) ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From shade at redhat.com Wed Dec 2 13:10:31 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Dec 2020 14:10:31 +0100 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <5b64ff35-ba02-30a6-b883-80682d4a1af5@oracle.com> References: <5b64ff35-ba02-30a6-b883-80682d4a1af5@oracle.com> Message-ID: <26a8d41e-6292-835c-a1d1-a37b7d942100@redhat.com> On 12/2/20 1:18 PM, Vladimir Ivanov wrote: > I would assume that `-XX:CompileCommand=blackhole,method` marks the > method as a blackhole for the whole JVM instance (irrespective of what > JIT is used or . Why can't you perform the query from the ciMethod > itself? Or do you see controlling it on per-compilation basis valuable? Well, actually I thought it should be like "inline", which consults compiler directive sets. But there is no compiler-specific setting for "blackhole", as DirectiveSet::should_blackhole delegates fully to CompilerOracle. So you're right, and we can indeed just do the global command, and ask CompilerOracle straight in ciMethod. Did so in new commit. -- Thanks, -Aleksey From shade at openjdk.java.net Wed Dec 2 13:14:11 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 2 Dec 2020 13:14:11 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v14] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. > > C1 code is platform-independent, and it adds the new node which is then lowered to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Avoid DirectiveSet changes, go straight to ciMethod ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/3ff8f980..f0e27389 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=12-13 Stats: 22 lines in 6 files changed: 1 ins; 15 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From dnsimon at openjdk.java.net Wed Dec 2 13:32:29 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 2 Dec 2020 13:32:29 GMT Subject: RFR: 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports [v5] In-Reply-To: References: Message-ID: > A number of jtreg tests require a specific GC. These tests should be ignored when EnableJVMCI is true and the JVMCI compiler does not support the required GC. > > This PR adds `JVMCICompiler.isGCSupported` and makes use of it in `WhiteBox.isGCSupported`. > > Prior to this PR, a test requiring a GC not yet supported by a JVMCI compiler fail as follows: > Error occurred during initialization of VM > JVMCI Compiler does not support selected GC: epsilon gc Doug Simon 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: Keep EnableJVMCI off for GCs that don't fully support JVMCI ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1423/files - new: https://git.openjdk.java.net/jdk/pull/1423/files/6e6aef0a..0ac0959e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1423&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1423&range=03-04 Stats: 9746 lines in 264 files changed: 1058 ins; 3297 del; 5391 mod Patch: https://git.openjdk.java.net/jdk/pull/1423.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1423/head:pull/1423 PR: https://git.openjdk.java.net/jdk/pull/1423 From coleenp at openjdk.java.net Wed Dec 2 13:44:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 13:44:56 GMT Subject: RFR: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 [v2] In-Reply-To: References: <___yf1Gd5MQWugSq_RZRaoHMB2ufD0ZYuvXyhn782q0=.20e07ef4-4a4a-4f4f-89ba-bd2a5bdb397c@github.com> Message-ID: On Wed, 2 Dec 2020 04:49:12 GMT, Leonid Mesnik wrote: >> These tests are unreliable and this change will simply give a better error message when they fail. > > Sorry, I've missed the answer to the same question. Thanks Leonid, I didn't really have a better thing to do with these tests because git made me take them off the problem list where they've been on and off for years. ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From coleenp at openjdk.java.net Wed Dec 2 13:44:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 13:44:57 GMT Subject: Integrated: 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:55:05 GMT, Coleen Phillimore wrote: > Give an error message rather than logging the error and then crashing later because the JVM can't detect stack overflow. In a resource exhausted situation, thread creation is also failing. This is the vm_exit_out_of_memory message printed: > > `$ java -XX:+UseNewCode -version > [0.003s][warning][os,thread] Attempt to protect stack guard pages failed (0x00007f606b249000-0x00007f606b24d000). > > There is insufficient memory for the Java Runtime Environment to continue. > Native memory allocation (mprotect) failed to protect 16384 bytes for memory to guard stack pages > An error report file with more information is saved as: > /16mprotect/hs_err_pid30596.log` > ` This pull request has now been integrated. Changeset: cfb50a9c Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/cfb50a9c Stats: 15 lines in 6 files changed: 5 ins; 5 del; 5 mod 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64 Reviewed-by: stuefe, sspitsyn, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1540 From stuefe at openjdk.java.net Wed Dec 2 13:50:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 13:50:11 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v6] In-Reply-To: References: Message-ID: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings > > Tested in our nightlies for a week now, works fine. > > Example output see https://github.com/openjdk/jdk/files/5622718/mapping-printout.txt Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Richard ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1390/files - new: https://git.openjdk.java.net/jdk/pull/1390/files/de705074..89b59069 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=04-05 Stats: 22 lines in 3 files changed: 11 ins; 1 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1390/head:pull/1390 PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Wed Dec 2 13:52:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 13:52:56 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 11:38:29 GMT, Richard Reingruber wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Ioi > > Hi Thomas, > > I've got a few minor comments for you. > > Have you got a sample of the trace you could share in this PR? > > Thanks, Richard. Hi @reinrich thanks a lot for your review. Please take a look at the new version. I modified the test to create a test mapping, just for showing that the snippets are printed out okay. See below, 64- and 32-bit-versions (look for "ABCD" to find the mapping). [printout-32.txt](https://github.com/openjdk/jdk/files/5629650/printout-32.txt) [printout-64.txt](https://github.com/openjdk/jdk/files/5629651/printout-64.txt) Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From dms at samersoff.net Wed Dec 2 14:05:46 2020 From: dms at samersoff.net (Dmitry Samersoff) Date: Wed, 2 Dec 2020 17:05:46 +0300 Subject: GrowableArray - how it works? In-Reply-To: <4320CDEB-CABF-4DDF-8844-B762B15C663C@oracle.com> References: <0bfd63df-a11e-7a3c-76b1-c3f89612f51e@samersoff.net> <4320CDEB-CABF-4DDF-8844-B762B15C663C@oracle.com> Message-ID: <3887b30d-9fea-4a4d-e7a5-c45d07ac4adb@samersoff.net> Hello Kim, Thank you! As soon as we have c++14 enabled for jdk16, are there any plans to cleanup template usage in hs - add static_asserts etc? -Dmitry On 02/12/2020 04:19, Kim Barrett wrote: >> On Dec 1, 2020, at 1:31 PM, Dmitry Samersoff wrote: >> >> Hello Everybody, >> >> While experimenting with the use of templates within hotspot in order to reduce VM size, I found a thing that I can't understand. >> >> What I'm missing here? >> >> arguments.cpp: >> >> GrowableArray *options = new (ResourceObj::C_HEAP, mtArguments) >> >> Where JavaVMOption is the plain C structure {char*, void*} that comes from jni.h >> >> but >> >> template >> class GrowableArray : public GenericGrowableArray { >> >> contains couple of functions like one below: >> >> int find_from_end(const E& elem) const { >> for (int i = _len-1; i >= 0; i--) { >> if (_data[i] == elem) return i; >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> } >> return -1; >> } >> >> How it supposed to work? >> >> If I instantiate GrowableArray explicitly it can't be compiled at al. >> >> Thank you! >> -Dmitry > > Templates have requirements for the template parameters. > > Attempting to use a type that doesn't meet the requirements is going > to fail to compile, sometimes with a really large error dump (the > so-called error novel). Concepts should eventually help with that, but > we don't have those in C++14. > > GrowableArray doesn't document its requirements (HotSpot templates > rarely have such documentation, which I think is unfortunate), but > it's probably similar to the requirements for std::vector; see C++14 > 23.2.1 and 23.2.3. > > This is all basic C++ template knowledge. > > In the specific example given, E must be EqualityComparable. > JavaMVOption isn't. > From rrich at openjdk.java.net Wed Dec 2 14:08:02 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 2 Dec 2020 14:08:02 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v6] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 13:50:11 GMT, Thomas Stuefe wrote: >> To analyze JDK-8256729 further, we need more tracing: >> >> 1) We should print all mappings inside the split area if os::split_reserved_memory() fails >> >> 2) The print-mapping code on windows has some shortcomings: >> - should not probe for mappings outside of what we know are valid address ranges for Windows >> - should handle wrap-arounds - it should be possible to print the whole address space >> - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) >> - should be printed in a more compact manner - base address should be on the same line as the first region >> - maybe adorned with some basic range info, e.g. library mappings >> >> Tested in our nightlies for a week now, works fine. >> >> Example output see https://github.com/openjdk/jdk/files/5622718/mapping-printout.txt > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Richard LGTM, thanks :) src/hotspot/os/windows/os_windows.cpp line 6073: > 6071: if (first_line) { > 6072: char buf[MAX_PATH]; > 6073: if (os::dll_address_to_library_name(allocation_base, buf, sizeof(buf), NULL)) { You forgot one NULL ------------- Marked as reviewed by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/1390 From shade at redhat.com Wed Dec 2 14:09:48 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Dec 2020 15:09:48 +0100 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <9yTVrPzoPijjtZlmJOku2uCaO0CJ7GRxgQS-5mf0BrU=.7ef38347-aaa5-4f49-b459-e9f36552e8c4@github.com> References: <7wHC1VVBP5st7PFgles4qKeLp_A2CmycoFLranbEc2c=.81b6b4df-a260-4a55-8597-ff7facd1181f@github.com> <9yTVrPzoPijjtZlmJOku2uCaO0CJ7GRxgQS-5mf0BrU=.7ef38347-aaa5-4f49-b459-e9f36552e8c4@github.com> Message-ID: <432a7f00-039c-4511-251f-da126ad3801f@redhat.com> On 12/2/20 1:14 PM, Vladimir Ivanov wrote: > Considering blackholes don't obey standard calling conventions, it's hard to say where the > arguments are located in generated code. It would be nice to enrich `-XX:+PrintOptoAssembly` > with information about consumed values. `MachNode::format` has access to such information through > `PhaseRegAlloc* ra` argument. Yes. I cannot see how to get the operands registers from the MachCall (which is MachCallBlackhole is now a subclass of). It seems to be implied by calling convention. The best I can do so far is to poll the types from tf()->domain() of MachCallBlackhole, but that is not very satisfactory. I.e.: case Form::JAVA_BLACKHOLE: fprintf(fp, "for (uint i = 0; i < tf()->domain()->cnt() - TypeFunc::Parms; i++) tf()->domain()->field_at(i + TypeFunc::Parms)->dump_on(st);"); break; I suspect that PhaseRegAlloc* ra does not help here, because it wants Node operands, the same problem... In fact, I don't think other MachCall* nodes get that data too, for example: 1c1 B16: # out( B17 ) <- in( B15 ) Freq: 0.369513 1c1 addq RCX, #-16 # long 1c5 shrq RCX, #3 1c9 movq RDI, R11 # spill 1cc movq RSI, R9 # spill 1cf movq RDX, RCX # spill 1d2 call_leaf_nofp,runtime jlong_disjoint_arraycopy No JVM State Info So where do we go from here? Somehow recording the operands of MachCallBlackhole? -- Thanks, -Aleksey From kbarrett at openjdk.java.net Wed Dec 2 14:12:59 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 2 Dec 2020 14:12:59 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> References: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> Message-ID: On Tue, 1 Dec 2020 14:19:15 GMT, Coleen Phillimore wrote: >> The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. >> >> There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. >> >> The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. > > Coleen Phillimore 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 more-jvmti-table > - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. > - 8257140: Crash in JvmtiTagMap::flush_object_free_events() Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From coleenp at openjdk.java.net Wed Dec 2 14:13:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 14:13:02 GMT Subject: RFR: 8257140: Crash in JvmtiTagMap::flush_object_free_events() [v2] In-Reply-To: References: <3RfBLU2PwZ43TTNBaFh8kJg_xmqcG68yNcekAZ5MMwY=.6d53ad64-ff01-436e-8d5c-edb1e5996ba2@github.com> Message-ID: On Wed, 2 Dec 2020 14:07:31 GMT, Kim Barrett wrote: >> Coleen Phillimore 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 more-jvmti-table >> - Rename JvmtiTagMap::clear() and fix JvmtiTagMapTable::clear() to null out deleted entries. >> - 8257140: Crash in JvmtiTagMap::flush_object_free_events() > > Marked as reviewed by kbarrett (Reviewer). Thanks Serguei and Kim for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From coleenp at openjdk.java.net Wed Dec 2 14:13:03 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 14:13:03 GMT Subject: Integrated: 8257140: Crash in JvmtiTagMap::flush_object_free_events() In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:44:24 GMT, Coleen Phillimore wrote: > The JvmtiTagMap can be deleted while it is posting. The JvmtiEnv is still on the list but the env is "disposed" of and the tag_map is deleted to save memory until the JvmtiEnv can be reclaimed at a safepoint and taken off the list. > > There's a check JvmtiEnvBase::check_for_periodic_clean_up() that determines whether the JvmtiEnv can be taken off the list and that check looks for whether threads are in the middle of JvmtiEnvIterator which sets Thread::jvmti_env_iteration_count. So this part is safe for the JvmtiTagMap changes. > > The fix is to clear the JvmtiTagMapTable of the entries inside the table lock to save memory but leave JvmtiTagMap intact so that we can load a valid pointer when iterating through JvmtiEnvIterator. We could also not do this at all and let the JvmtiTagMap destructor delete the table when the JvmtiEnv is also deleted, but we don't know what customer situation led to this code in the first place. This pull request has now been integrated. Changeset: 2508bc7c Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/2508bc7c Stats: 25 lines in 5 files changed: 17 ins; 0 del; 8 mod 8257140: Crash in JvmtiTagMap::flush_object_free_events() Reviewed-by: sspitsyn, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/1539 From thomas.stuefe at gmail.com Wed Dec 2 14:25:35 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 2 Dec 2020 15:25:35 +0100 Subject: HotSpot Style Guide change process In-Reply-To: References: <376E1F97-57DE-46CD-B656-BC5340E0BA07@oracle.com> Message-ID: On Wed, Dec 2, 2020 at 12:04 PM Kim Barrett wrote: > > On Dec 1, 2020, at 11:20 PM, Vladimir Kozlov > wrote: > > > > Okay. I did not realize that we are already using "rough consensus" in > our processes. > > Thank you, Kim, for pointers. I take back my original suggestion. > > > > My next suggestion is to change [rough consensus] link to > https://tools.ietf.org/html/rfc7282 which is used by Vulnerability group > and also referenced by Wikipedia. It is more formal and will be available > for longer time. > > That seems reasonable. > https://bugs.openjdk.java.net/browse/JDK-8257589 > > > On 12/1/20 5:25 PM, David Holmes wrote: > >> Hi Kim, > >> "rough consensus" has good precedents and is something we should follow > here IMO. OpenJDK by-laws are for the formal parts of the OpenJDK processes > themselves, not for everything single thing done under the OpenJDK banner. > >> Cheers, > >> David > >> On 1/12/2020 4:43 pm, Kim Barrett wrote: > >>> Even if we don't change, and especially if we do, some further > refinement of > >>> the mechanics may be needed. I think the current mechanics may have a > >>> problem that the request shows up in one's mailbox looking pretty much > like > >>> an ordinary RFR. When I was originally thinking about that text we > were in a > >>> world of pure email change requests, and the document was still a wiki > page. > >>> With the move of the document to the jdk repository and the move to > github > >>> and PRs + Skara support for changes, the mechanics are different. It > might > >>> be better if it could be subject tagged differently, as we do with > Call for > >>> Vote emails. There are probably things we could do about that, if > others > >>> agree that's a problem. Or maybe some of you see other problems? > > I?d still like to get some feedback on the mechanics. Is what I?ve done > for a couple > of changes working for folks? That is, is using a normal github PR for > the change, > with ?yes? votes via review approvals, good enough? Are there changes > that would > make this work better? I?m mostly worried that we seem to be getting more > or less > the same small group of people. I can?t tell if that?s because others > aren?t bothering, > or are they not noticing. We want high visibility on changes to the Style > Guide. > > Hi Kim, For me, it is not lack of interest. But changes to the style guide often drift to the bottom of the pile since there is so much to do, and discussing them takes time. hotspot-dev being out of commission for so long in summer did not help either. I sometimes do feel ambivalent about new features, like they don't bring enough to the table to justify the churn. One example, Uniform Initialization increased the number of idioms one has to know, without simplifying anything, since old-style initialization won't go away. But my emotions are never strong enough to publicly block such a proposal with a negative vote, especially in the face of exclusively positive feedback. I have no ready proposals of how to improve the process, just the vague feeling that PRs are maybe a bit low-key. And sometimes move too fast. Especially since the mail flood increased a lot since we switched to skara tooling. Note that this is not to question your work in any way; on the contrary, I really appreciate what you do. But you wondered about the silence, and I tried to answer that with my perspective. Thanks & Cheers, Thomas 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 stuefe at openjdk.java.net Wed Dec 2 14:32:13 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 14:32:13 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v7] In-Reply-To: References: Message-ID: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings > > Tested in our nightlies for a week now, works fine. > > Example output see https://github.com/openjdk/jdk/files/5622718/mapping-printout.txt Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: the last NULL is null ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1390/files - new: https://git.openjdk.java.net/jdk/pull/1390/files/89b59069..bed9505e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1390&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1390/head:pull/1390 PR: https://git.openjdk.java.net/jdk/pull/1390 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 lfoltan at openjdk.java.net Wed Dec 2 14:44:57 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 2 Dec 2020 14:44:57 GMT Subject: RFR: 8257466: Improve enum iteration [v2] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 02:30:14 GMT, Kim Barrett wrote: >> Please review this collection of improvements to the recently added enum >> iteration facility. These improvements are based on usage in some >> in-development changes. >> >> (1) Added EnumType nested type to EnumRange and EnumIterator. It is an alias >> for the enum type that is a template parameter for those classes. This is >> useful when dealing with a range or iterator whose associated enum type is >> not known because the range/iterator is a template parameter. >> >> (2) Added EnumRange::index(T), which converts the argument enumerator to >> a zero-based index into the range of values. This is useful when mapping >> from an enumerator to a corresponding array index, for example. >> >> (3) Allow enum range bounds to be specified using start and (exclusive) end >> integral (underlying type) values. This is useful when dealing with enums >> that are just value ranges and don't have named enumerators. As part of >> this, changes the enum iteration traits mechanism to use start/end rather >> than first/last, as that seems to be a little easier to deal with. >> >> (4) Added accessors for the first and last enumerator values of a range. >> >> (5) Added gtest for enum iteration. >> >> Testing: tier1 > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > iklam review Changes looks good Kim. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1530 From stuefe at openjdk.java.net Wed Dec 2 15:52:01 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 15:52:01 GMT Subject: RFR: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist Message-ID: JNI_ArgumentPusherVaArg copies the given argument list pointer (va_copy) but never releases it. A call to va_end is missing. AFAICS this coding is old. Interestingly, in jdk8 I find this: 0: inline void set_ap(va_list rap) { 0: #ifdef va_copy 0: va_copy(_ap, rap); 0: #elif defined (__va_copy) 0: __va_copy(_ap, rap); 0: #else 0: _ap = rap; 0: #endif 0: } `_ap = rap` seems a strangely relaxed way of doing this. But I do not know the history behind that. I could not find any usage of the original arg pointer, so maybe the `va_copy()` is not even needed. The jdk8 coding seems to indicate that too. But since I was not 100% sure I kept the `va_copy()` and added a `va_end()`. I also made this private (removed the `protected`) since there are no child classes. ------------- Commit messages: - call va_end on copied argp Changes: https://git.openjdk.java.net/jdk/pull/1565/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1565&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257604 Stats: 5 lines in 1 file changed: 4 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1565.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1565/head:pull/1565 PR: https://git.openjdk.java.net/jdk/pull/1565 From mdoerr at openjdk.java.net Wed Dec 2 16:11:07 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 2 Dec 2020 16:11:07 GMT Subject: RFR: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack [v2] In-Reply-To: References: Message-ID: <4YaoI82WXq_zyyJAR3mpULYcz3dbrLa_XPalj7WMqm8=.5b2d4625-bb34-44b4-bf52-cf0a653efb97@github.com> > Method handle logging is broken in fastdebug builds. Problem is that os::current_frame() doesn't return the right frame in fastdebug builds. Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: New solution: Use NOINLINE for os::current_stack_pointer() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1394/files - new: https://git.openjdk.java.net/jdk/pull/1394/files/99f9a85b..a736e3f6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1394&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1394&range=00-01 Stats: 12 lines in 2 files changed: 8 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1394.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1394/head:pull/1394 PR: https://git.openjdk.java.net/jdk/pull/1394 From iklam at openjdk.java.net Wed Dec 2 16:21:58 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 16:21:58 GMT Subject: RFR: 8257563: Remove excessive include of klass.inline.hpp In-Reply-To: References: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> Message-ID: On Wed, 2 Dec 2020 09:37:06 GMT, Stefan Karlsson wrote: >> klass.inline.hpp is unnecessarily included by two popular header files: oop.inline.hpp and modRefBarrierSet.inline.hpp >> >> These two `#include` lines recursively pull in many header files. Removing them reduce the total number of header inclusion for building HotSpot from 260096 to 254773, or about 2%. >> >> Notes to reviewer. The main changes are in the header files: >> >> * src/hotspot/share/classfile/systemDictionaryShared.hpp >> * src/hotspot/share/gc/shared/modRefBarrierSet.inline.hpp >> * src/hotspot/share/oops/instanceKlass.hpp >> * src/hotspot/share/oops/instanceKlass.inline.hpp >> * src/hotspot/share/oops/oop.inline.hpp > > src/hotspot/cpu/s390/s390.ad line 1329: > >> 1327: >> 1328: #include "oops/klass.inline.hpp" >> 1329: > > I wonder if this should be put in adlc/main.cpp. I'm not sure, but I don't think we usually put includes in the .ad files. We have #includes in the .ad files today. I am not sure what the rules are. I am guessing it is "add includes that are specific to the C code inside this .ad file". So I'd like to keep my changes in s390.ad as is. $ find . -name *.ad | xargs grep -l '^#include ' ./cpu/aarch64/aarch64.ad ./cpu/aarch64/gc/z/z_aarch64.ad ./cpu/aarch64/gc/shenandoah/shenandoah_aarch64.ad ./cpu/ppc/ppc.ad ./cpu/x86/gc/z/z_x86_64.ad ./cpu/x86/gc/shenandoah/shenandoah_x86_64.ad ./cpu/x86/gc/shenandoah/shenandoah_x86_32.ad ./cpu/x86/x86.ad ------------- PR: https://git.openjdk.java.net/jdk/pull/1552 From dcubed at openjdk.java.net Wed Dec 2 16:30:02 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 2 Dec 2020 16:30:02 GMT Subject: RFR: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 15:02:30 GMT, Thomas Stuefe wrote: > JNI_ArgumentPusherVaArg copies the given argument list pointer (va_copy) but never releases it. A call to va_end is missing. > > AFAICS this coding is old. Interestingly, in jdk8 I find this: > > 0: inline void set_ap(va_list rap) { > 0: #ifdef va_copy > 0: va_copy(_ap, rap); > 0: #elif defined (__va_copy) > 0: __va_copy(_ap, rap); > 0: #else > 0: _ap = rap; > 0: #endif > 0: } > > `_ap = rap` seems a strangely relaxed way of doing this. But I do not know the history behind that. > > I could not find any usage of the original arg pointer, so maybe the `va_copy()` is not even needed. The jdk8 coding seems to indicate that too. But since I was not 100% sure I kept the `va_copy()` and added a `va_end()`. > > I also made this private (removed the `protected`) since there are no child classes. Looks good. I added more history to the bug report. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1565 From iklam at openjdk.java.net Wed Dec 2 16:32:14 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 16:32:14 GMT Subject: RFR: 8257565: epsilonBarrierSet.hpp should not include barrierSetAssembler [v4] In-Reply-To: References: Message-ID: > Please review this trivial fix: > > epsilonBarrierSet.hpp is included (recursively via access.hpp) by many CPP files. It unncessarily includes of barrierSetAssembler.hpp, which causes many of the native code assembler header files to be unnecessarily included by many HotSpot CPP files that do not deal with native code assembly. > > Removing this one line reduced the total number of header inclusion for building HotSpot from 260096 to 258193, or about 0.8%. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed aarch64 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1554/files - new: https://git.openjdk.java.net/jdk/pull/1554/files/1df60549..ca8c443e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1554&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1554&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1554.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1554/head:pull/1554 PR: https://git.openjdk.java.net/jdk/pull/1554 From coleenp at openjdk.java.net Wed Dec 2 16:39:59 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 2 Dec 2020 16:39:59 GMT Subject: RFR: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist In-Reply-To: References: Message-ID: <3hJ4-tDy-n9s7K5N3r4VC8gv1jRFBaskyrund_0o-Q4=.9041ac65-8676-4724-bb7d-d65f20ca4c1e@github.com> On Wed, 2 Dec 2020 15:02:30 GMT, Thomas Stuefe wrote: > JNI_ArgumentPusherVaArg copies the given argument list pointer (va_copy) but never releases it. A call to va_end is missing. > > AFAICS this coding is old. Interestingly, in jdk8 I find this: > > 0: inline void set_ap(va_list rap) { > 0: #ifdef va_copy > 0: va_copy(_ap, rap); > 0: #elif defined (__va_copy) > 0: __va_copy(_ap, rap); > 0: #else > 0: _ap = rap; > 0: #endif > 0: } > > `_ap = rap` seems a strangely relaxed way of doing this. But I do not know the history behind that. > > I could not find any usage of the original arg pointer, so maybe the `va_copy()` is not even needed. The jdk8 coding seems to indicate that too. But since I was not 100% sure I kept the `va_copy()` and added a `va_end()`. > > I also made this private (removed the `protected`) since there are no child classes. Looks good. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1565 From stuefe at openjdk.java.net Wed Dec 2 16:40:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 2 Dec 2020 16:40:00 GMT Subject: RFR: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 16:26:56 GMT, Daniel D. Daugherty wrote: > Looks good. > > I added more history to the bug report. Thanks, Dan. Unfortunately, the issue is not visible to outsiders. But I guess there were platforms where va_copy was not available (like old versions of VS). ------------- PR: https://git.openjdk.java.net/jdk/pull/1565 From iklam at openjdk.java.net Wed Dec 2 16:49:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 16:49:56 GMT Subject: RFR: 8257565: epsilonBarrierSet.hpp should not include barrierSetAssembler [v2] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 07:24:59 GMT, Aleksey Shipilev wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> removed copyright > > Looks good! Thanks, I'll take care of backports, if any. @shipilev @tstuefe @kimbarrett Thanks for the review. I've tested tier1,builds-tier2,builds-tier3,builds-tier4,builds-tier5 on mach5, plus locally building s390x,ppc64le. ------------- PR: https://git.openjdk.java.net/jdk/pull/1554 From iklam at openjdk.java.net Wed Dec 2 16:59:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 16:59:57 GMT Subject: Integrated: 8257565: epsilonBarrierSet.hpp should not include barrierSetAssembler In-Reply-To: References: Message-ID: <0IhGIlmrQjQq1V0dfsFZUHp6teOZKxgnThIkovryfLM=.b478ca66-dcf1-4e10-9525-5614f493d0ce@github.com> On Wed, 2 Dec 2020 05:22:04 GMT, Ioi Lam wrote: > Please review this trivial fix: > > epsilonBarrierSet.hpp is included (recursively via access.hpp) by many CPP files. It unncessarily includes of barrierSetAssembler.hpp, which causes many of the native code assembler header files to be unnecessarily included by many HotSpot CPP files that do not deal with native code assembly. > > Removing this one line reduced the total number of header inclusion for building HotSpot from 260096 to 258193, or about 0.8%. This pull request has now been integrated. Changeset: 67042664 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/67042664 Stats: 3 lines in 3 files changed: 2 ins; 1 del; 0 mod 8257565: epsilonBarrierSet.hpp should not include barrierSetAssembler Reviewed-by: kbarrett, stuefe, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1554 From stefank at openjdk.java.net Wed Dec 2 17:03:56 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 2 Dec 2020 17:03:56 GMT Subject: RFR: 8257563: Remove excessive include of klass.inline.hpp In-Reply-To: References: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> Message-ID: On Wed, 2 Dec 2020 16:19:05 GMT, Ioi Lam wrote: >> src/hotspot/cpu/s390/s390.ad line 1329: >> >>> 1327: >>> 1328: #include "oops/klass.inline.hpp" >>> 1329: >> >> I wonder if this should be put in adlc/main.cpp. I'm not sure, but I don't think we usually put includes in the .ad files. > > We have #includes in the .ad files today. I am not sure what the rules are. I am guessing it is "add includes that are specific to the C code inside this .ad file". So I'd like to keep my changes in s390.ad as is. > > $ find . -name *.ad | xargs grep -l '^#include ' > ./cpu/aarch64/aarch64.ad > ./cpu/aarch64/gc/z/z_aarch64.ad > ./cpu/aarch64/gc/shenandoah/shenandoah_aarch64.ad > ./cpu/ppc/ppc.ad > ./cpu/x86/gc/z/z_x86_64.ad > ./cpu/x86/gc/shenandoah/shenandoah_x86_64.ad > ./cpu/x86/gc/shenandoah/shenandoah_x86_32.ad > ./cpu/x86/x86.ad OK. So platform-specific files seems to have includes. Got it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1552 From vladimir.x.ivanov at oracle.com Wed Dec 2 17:10:10 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 2 Dec 2020 20:10:10 +0300 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <662a87e3-3091-ace7-3b10-9d36eaefaac9@redhat.com> References: <826a3ee1-07d6-3051-ff18-40eae56ddc0d@oracle.com> <662a87e3-3091-ace7-3b10-9d36eaefaac9@redhat.com> Message-ID: <0c9b1c3c-2110-fbe7-da03-a6ecd1d069a6@oracle.com> >> What exactly do you see useful for blackhole inside `if( >> sfpt->is_Call())` branch? Everything except setting `tf()` looks >> irrelevant and you can cleanly capture that in MachCallBlackhole >> factory/ctor. > > It's not that. ADLC actually creates a subclass that defines Name(), > rule(), etc. > > We can fake it, but what I am concerned about is introducing a special > case for otherwise generic Matcher code. We also basically sidestep DFA > machinery, and I am not at all sure what is the effect at subsequent > matches for the incoming edges. > > Is there a precedent to create Mach nodes like this? Do we actually know > if there are pitfalls? I firmly believe that sticking with what Matcher > expects of us: *Node -> Mach*Node rules in .ad -- is safer all around. > > See the example patch: > ? https://cr.openjdk.java.net/~shade/8252505/shared-match.patch You skipped populating inputs on the MachNode, but I see your point. > I am not sure I want to trade in a few lines of .ad with fixing new > matcher bugs. > >> And don't forget about ADLC changes. Those can also go away / migrate to >> MachCallBlackhole. > > Yes, they could, but we are drilling another hole in the code that is > already quite funky. I have a better example for you: MemBarCPUOrder doesn't participate in matching at all (I'll save you some time: it signals `Matcher` to ignore it through `ideal_reg() == 0` which is taken into account by `Matcher::is_dontcare()`/`Matcher::find_shared_visit()`), but still does its job in Mach IR. The only thing it misses to satisfy blackhole requirements is it doesn't keep anything alive. But it seems just adding the `in_RegMask()` you have should be enough to get you there. And then you can get rid of any ADLC, Matcher, and CallNode-related changes you have right now. It seems, no drilling needed, right? :-) Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed Dec 2 17:16:26 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 2 Dec 2020 20:16:26 +0300 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <26a8d41e-6292-835c-a1d1-a37b7d942100@redhat.com> References: <5b64ff35-ba02-30a6-b883-80682d4a1af5@oracle.com> <26a8d41e-6292-835c-a1d1-a37b7d942100@redhat.com> Message-ID: <1039a82f-b6cd-2a79-a503-dcb4b716f788@oracle.com> On 02.12.2020 16:10, Aleksey Shipilev wrote: > On 12/2/20 1:18 PM, Vladimir Ivanov wrote: >> I would assume that `-XX:CompileCommand=blackhole,method` marks the >> method as a blackhole for the whole JVM instance (irrespective of what >> JIT is used or . Why can't you perform the query from the ciMethod >> itself? Or do you see controlling it on per-compilation basis valuable? > > Well, actually I thought it should be like "inline", which consults > compiler directive sets. > > But there is no compiler-specific setting for "blackhole", as > DirectiveSet::should_blackhole delegates fully to CompilerOracle. So > you're right, and we can indeed just do the global command, and ask > CompilerOracle straight in ciMethod. Did so in new commit. Looks nice! One more idea: what if you populate ciMethod::_intrinsic_id instead when you detect a blackhole method? There's already an example of marker pseudo-intrinsic (vmIntrinsics::_compiledLambdaForm) and you can just introduce a new one for blackhole methods. Then you don't need `BlackholeCallGenerator` anymore and `BlackholeCallGenerator::generate()` can be migrated to `library_call.cpp` as yet another intrinsic. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed Dec 2 17:21:50 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 2 Dec 2020 20:21:50 +0300 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <432a7f00-039c-4511-251f-da126ad3801f@redhat.com> References: <7wHC1VVBP5st7PFgles4qKeLp_A2CmycoFLranbEc2c=.81b6b4df-a260-4a55-8597-ff7facd1181f@github.com> <9yTVrPzoPijjtZlmJOku2uCaO0CJ7GRxgQS-5mf0BrU=.7ef38347-aaa5-4f49-b459-e9f36552e8c4@github.com> <432a7f00-039c-4511-251f-da126ad3801f@redhat.com> Message-ID: > So where do we go from here? Somehow recording the operands of > MachCallBlackhole? Have you tried `PhaseRegAlloc::dump_register(const Node *n, char *buf)` on argument inputs? Best regards, Vladimir Ivanov From kvn at openjdk.java.net Wed Dec 2 17:28:00 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 2 Dec 2020 17:28:00 GMT Subject: RFR: 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports [v5] In-Reply-To: References: Message-ID: <8DCkL0DmY8c2z1X3RkGIpssiMHgjY-HKsbi5vpuH8FM=.da2a6d5c-8c40-4702-ad29-deee3b757229@github.com> On Wed, 2 Dec 2020 13:32:29 GMT, Doug Simon wrote: >> A number of jtreg tests require a specific GC. These tests should be ignored when EnableJVMCI is true and the JVMCI compiler does not support the required GC. >> >> This PR adds `JVMCICompiler.isGCSupported` and makes use of it in `WhiteBox.isGCSupported`. >> >> Prior to this PR, a test requiring a GC not yet supported by a JVMCI compiler fail as follows: >> Error occurred during initialization of VM >> JVMCI Compiler does not support selected GC: epsilon gc > > Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Keep EnableJVMCI off for GCs that don't fully support JVMCI > - implemented isGCSupported in Graal compiler > - removed JVMCI logic from GCConfig and introduced WhiteBox.isGCSupportedByJVMCI instead > - removed broken check_jvmci_supported_gc logic > - removed redundant signature > - move logic to GCConfig > - enable a JVMCICompiler to specify which GCs it supports Latest changes looks like reversal of original. Will GraalVM have additional checks to allow ask Graal before disabling JVMCI? src/hotspot/share/jvmci/jvmci_globals.cpp line 207: > 205: // Check if selected GC is supported by JVMCI and Java compiler > 206: if (!(UseSerialGC || UseParallelGC || UseG1GC)) { > 207: log_warning(gc)("Selected GC does not support JVMCI: %s", GCConfig::hs_err_name()); I would add new UL tag `jvmci` if we don't have it yet and use it here. Also message should say `EnableJVMCI is turned off because ...' ------------- PR: https://git.openjdk.java.net/jdk/pull/1423 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 dnsimon at openjdk.java.net Wed Dec 2 17:44:57 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 2 Dec 2020 17:44:57 GMT Subject: RFR: 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports [v5] In-Reply-To: <8DCkL0DmY8c2z1X3RkGIpssiMHgjY-HKsbi5vpuH8FM=.da2a6d5c-8c40-4702-ad29-deee3b757229@github.com> References: <8DCkL0DmY8c2z1X3RkGIpssiMHgjY-HKsbi5vpuH8FM=.da2a6d5c-8c40-4702-ad29-deee3b757229@github.com> Message-ID: On Wed, 2 Dec 2020 17:25:09 GMT, Vladimir Kozlov wrote: > Latest changes looks like reversal of original. Will GraalVM have additional checks to allow ask Graal before disabling JVMCI? No, the changes in this PR are sufficient. When JVMCI support is added for Graal to be able to implement support for ZGC/Shenandoah/Epsilon, the `check_jvmci_supported_gc` implementation will be updated. > src/hotspot/share/jvmci/jvmci_globals.cpp line 207: > >> 205: // Check if selected GC is supported by JVMCI and Java compiler >> 206: if (!(UseSerialGC || UseParallelGC || UseG1GC)) { >> 207: log_warning(gc)("Selected GC does not support JVMCI: %s", GCConfig::hs_err_name()); > > I would add new UL tag `jvmci` if we don't have it yet and use it here. Also message should say `EnableJVMCI is turned off because ...' Is the `gc` tag not applicable here? Or are you saying a `jvmci` tag should be added as well? I will update the message as you suggest. ------------- PR: https://git.openjdk.java.net/jdk/pull/1423 From kvn at openjdk.java.net Wed Dec 2 17:44:57 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 2 Dec 2020 17:44:57 GMT Subject: RFR: 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports [v5] In-Reply-To: References: <8DCkL0DmY8c2z1X3RkGIpssiMHgjY-HKsbi5vpuH8FM=.da2a6d5c-8c40-4702-ad29-deee3b757229@github.com> Message-ID: On Wed, 2 Dec 2020 17:37:57 GMT, Doug Simon wrote: > > Latest changes looks like reversal of original. Will GraalVM have additional checks to allow ask Graal before disabling JVMCI? > > No, the changes in this PR are sufficient. When JVMCI support is added for Graal to be able to implement support for ZGC/Shenandoah/Epsilon, the `check_jvmci_supported_gc` implementation will be updated. Okay. If you are fine with that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1423 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 dnsimon at openjdk.java.net Wed Dec 2 17:50:56 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 2 Dec 2020 17:50:56 GMT Subject: RFR: 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports [v5] In-Reply-To: References: <8DCkL0DmY8c2z1X3RkGIpssiMHgjY-HKsbi5vpuH8FM=.da2a6d5c-8c40-4702-ad29-deee3b757229@github.com> Message-ID: On Wed, 2 Dec 2020 17:41:49 GMT, Vladimir Kozlov wrote: >>> Latest changes looks like reversal of original. Will GraalVM have additional checks to allow ask Graal before disabling JVMCI? >> >> No, the changes in this PR are sufficient. When JVMCI support is added for Graal to be able to implement support for ZGC/Shenandoah/Epsilon, the `check_jvmci_supported_gc` implementation will be updated. > >> > Latest changes looks like reversal of original. Will GraalVM have additional checks to allow ask Graal before disabling JVMCI? >> >> No, the changes in this PR are sufficient. When JVMCI support is added for Graal to be able to implement support for ZGC/Shenandoah/Epsilon, the `check_jvmci_supported_gc` implementation will be updated. > > Okay. If you are fine with that. There is the interesting question of whether explicit JVMCI API extensions are needed for Epsilon. @shipilev what's your intuition on that? ------------- PR: https://git.openjdk.java.net/jdk/pull/1423 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 dnsimon at openjdk.java.net Wed Dec 2 18:02:14 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 2 Dec 2020 18:02:14 GMT Subject: RFR: 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports [v6] In-Reply-To: References: Message-ID: > A number of jtreg tests require a specific GC. These tests should be ignored when EnableJVMCI is true and the JVMCI compiler does not support the required GC. > > This PR adds `JVMCICompiler.isGCSupported` and makes use of it in `WhiteBox.isGCSupported`. > > Prior to this PR, a test requiring a GC not yet supported by a JVMCI compiler fail as follows: > Error occurred during initialization of VM > JVMCI Compiler does not support selected GC: epsilon gc Doug Simon has updated the pull request incrementally with one additional commit since the last revision: added jvmci tag to new warning and improved its message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1423/files - new: https://git.openjdk.java.net/jdk/pull/1423/files/0ac0959e..2aa5be51 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1423&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1423&range=04-05 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1423.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1423/head:pull/1423 PR: https://git.openjdk.java.net/jdk/pull/1423 From vladimir.x.ivanov at oracle.com Wed Dec 2 18:26:15 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 2 Dec 2020 21:26:15 +0300 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: Message-ID: <202ecd3f-b17e-494b-7130-0c1d62e9761c@oracle.com> > Unfortunately, not. In JMH, `Blackhole` methods are instance methods (they have state), and that plays nicely with compatibility: when JIT fails to provide blackholing, it would naturally fall back to old behavior. I think null check for receiver is the fair behavior here, as subsequent optimization may expect receiver null-checked after the call. I have not seen null-checks in my `perfasm` runs with C1, though. It will "consume" and keep it alive the receiver, but have you considered passing receiver explicitly as an argument? If you want to keep instance method support, please, double-check that null check stays there for correctness. Best regards, Vladimir Ivanov From shade at redhat.com Wed Dec 2 18:35:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Dec 2020 19:35:37 +0100 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <202ecd3f-b17e-494b-7130-0c1d62e9761c@oracle.com> References: <202ecd3f-b17e-494b-7130-0c1d62e9761c@oracle.com> Message-ID: On 12/2/20 7:26 PM, Vladimir Ivanov wrote: > >> Unfortunately, not. In JMH, `Blackhole` methods are instance methods (they have state), and that plays nicely with compatibility: when JIT fails to provide blackholing, it would naturally fall back to old behavior. I think null check for receiver is the fair behavior here, as subsequent optimization may expect receiver null-checked after the call. I have not seen null-checks in my `perfasm` runs with C1, though. > > It will "consume" and keep it alive the receiver, but have you > considered passing receiver explicitly as an argument? I cannot parse what you are saying here. Please elaborate? > If you want to keep instance method support, please, double-check that > null check stays there for correctness. OK, that looks empirically verifiable (i.e. with the jtreg test), will od. -- Thanks, -Aleksey From kvn at openjdk.java.net Wed Dec 2 18:37:57 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 2 Dec 2020 18:37:57 GMT Subject: RFR: 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports [v6] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:02:14 GMT, Doug Simon wrote: >> A number of jtreg tests require a specific GC. These tests should be ignored when EnableJVMCI is true and the JVMCI compiler does not support the required GC. >> >> This PR adds `JVMCICompiler.isGCSupported` and makes use of it in `WhiteBox.isGCSupported`. >> >> Prior to this PR, a test requiring a GC not yet supported by a JVMCI compiler fail as follows: >> Error occurred during initialization of VM >> JVMCI Compiler does not support selected GC: epsilon gc > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > added jvmci tag to new warning and improved its message Marked as reviewed by kvn (Reviewer). src/hotspot/share/jvmci/jvmci_globals.cpp line 207: > 205: // Check if selected GC is supported by JVMCI and Java compiler > 206: if (!(UseSerialGC || UseParallelGC || UseG1GC)) { > 207: log_warning(gc, jvmci)("Setting EnableJVMCI to false as selected GC does not support JVMCI: %s", GCConfig::hs_err_name()); Now message is: [0.001s][warning][gc,jvmci] Setting EnableJVMCI to false as selected GC does not support JVMCI: z gc Okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/1423 From vladimir.x.ivanov at oracle.com Wed Dec 2 18:42:59 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 2 Dec 2020 21:42:59 +0300 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: <202ecd3f-b17e-494b-7130-0c1d62e9761c@oracle.com> Message-ID: <6f45ed07-01f6-4731-748d-c780c99cb365@oracle.com> On 02.12.2020 21:35, Aleksey Shipilev wrote: > On 12/2/20 7:26 PM, Vladimir Ivanov wrote: >> >>> Unfortunately, not. In JMH, `Blackhole` methods are instance methods >>> (they have state), and that plays nicely with compatibility: when JIT >>> fails to provide blackholing, it would naturally fall back to old >>> behavior. I think null check for receiver is the fair behavior here, >>> as subsequent optimization may expect receiver null-checked after the >>> call. I have not seen null-checks in my `perfasm` runs with C1, though. >> >> It will "consume" and keep it alive the receiver, but have you >> considered passing receiver explicitly as an argument? > > I cannot parse what you are saying here. Please elaborate? T urn instance method into a static one and explicity pass receiver into it as an argument. You can still use it to extract state inside the method if intrinsification fails. The only difference I see is receiver becomes treated as an ordinary argument which is consumed by a blackhole while in the current implementation you ignore receiver. Best regards, Vladimir Ivanov >> If you want to keep instance method support, please, double-check that >> null check stays there for correctness. > > OK, that looks empirically verifiable (i.e. with the jtreg test), will od. > From hseigel at openjdk.java.net Wed Dec 2 18:44:08 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 2 Dec 2020 18:44:08 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8256718: Obsolete the long term deprecated and aliased Trace flags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1525/files - new: https://git.openjdk.java.net/jdk/pull/1525/files/84e421f7..2c5bec9a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1525&range=01-02 Stats: 40 lines in 2 files changed: 3 ins; 36 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1525.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1525/head:pull/1525 PR: https://git.openjdk.java.net/jdk/pull/1525 From hseigel at openjdk.java.net Wed Dec 2 18:54:03 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 2 Dec 2020 18:54:03 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 12:02:57 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > src/hotspot/share/runtime/arguments.cpp line 617: > >> 615: #ifndef PRODUCT >> 616: // These options are removed in jdk9. Remove this code for jdk10. >> 617: static AliasedFlag const removed_develop_logging_flags[] = { > > I think this removed_develop_logging_flags infrastructure should be removed. done. ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From hseigel at openjdk.java.net Wed Dec 2 18:53:59 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 2 Dec 2020 18:53:59 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v2] In-Reply-To: References: Message-ID: <4H1k-dufXhXpZM-wIl6YTa4b8_6SGcOWOC6QG4LXXf0=.f54a8f80-b42a-4392-8c8e-88bd2b2c308e@github.com> On Wed, 2 Dec 2020 02:42:18 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > I'm still pushing for treating all flags the same and removing all the aliased-flag code. > > Coleen seems to be okay either way. :) > > Thanks, > David Please review this latest webrev. It removes all the aliasing code for the obsolete tracing flags and does not suggest logging alternatives in their obsolete flag messages. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From shade at redhat.com Wed Dec 2 19:24:01 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Dec 2020 20:24:01 +0100 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <0c9b1c3c-2110-fbe7-da03-a6ecd1d069a6@oracle.com> References: <826a3ee1-07d6-3051-ff18-40eae56ddc0d@oracle.com> <662a87e3-3091-ace7-3b10-9d36eaefaac9@redhat.com> <0c9b1c3c-2110-fbe7-da03-a6ecd1d069a6@oracle.com> Message-ID: On 12/2/20 6:10 PM, Vladimir Ivanov wrote: > I have a better example for you: MemBarCPUOrder doesn't participate in > matching at all (I'll save you some time: it signals `Matcher` to ignore > it through `ideal_reg() == 0` which is taken into account by > `Matcher::is_dontcare()`/`Matcher::find_shared_visit()`), but still does > its job in Mach IR. The only thing it misses to satisfy blackhole > requirements is it doesn't keep anything alive. But it seems just adding > the `in_RegMask()` you have should be enough to get you there. And then > you can get rid of any ADLC, Matcher, and CallNode-related changes you > have right now. It seems, no drilling needed, right? :-) I think being explicit about Blackhole having a call-like effects, having its own call generators, and matching as any regular node is the explicitness that is good explicitness. Yes, it adds a handful of LOCs on regular paths, but it does not try to do many special things at once. This is why CallBlackholeJava -> CallBlackhole remodel happened: making it less special and more congruent with existing nodes, even though it would have been "easier" to hack the Call*Java. We need to draw the line in the sand somewhere. I can try to do what MemBarCPUOrder does, but honestly it feels like a conceptual step back. The next thing you would ask is to print consumed values in OptoAssembly, like I am prototyping now for MachCallBlackhole. It is possible now because Matcher knows about it and its form. If Matcher ignores MemBarCPUOrder, does it mean OptoAssembly omits any format for it as well? -- Thanks, -Aleksey From sspitsyn at openjdk.java.net Wed Dec 2 19:30:57 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 2 Dec 2020 19:30:57 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:44:08 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags The update looks good to me. It is a nice simplification. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 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:24:11 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 2 Dec 2020 20:24:11 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: Message-ID: > Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html > > On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, PROT_NONE), the function was made aware of exec permissions. > > For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference compared with old code. > > For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not shrink (if I haven't missed anything, by the implementation and in principle). > > Tested: > * local tier1 > * jdk-submit > * codesign[2] with hardened runtime and allow-jit but without > allow-unsigned-executable-memory entitlements[3] produce a working bundle. > > (adding GC group as suggested by @dholmes-ora) > > > [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 > [2] > > codesign \ > --sign - \ > --options runtime \ > --entitlements ents.plist \ > --timestamp \ > $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib > [3] > > > > > com.apple.security.cs.allow-jit > > com.apple.security.cs.disable-library-validation > > com.apple.security.cs.allow-dyld-environment-variables > > > Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Separate executable_memory interface - Merge remote-tracking branch 'upstream/master' into 8234930 - Revert everything - Fix test builds (nothing except macOS still buildable) - os::reserve to take exec parameter - Bookkeeping without interface changes - Minimal working example, no uncommit - Merge remote-tracking branch 'upstream/master' into 8234930 - Revert "Use MAP_JIT for CodeCache pages" This reverts commit 114d9cffd62cab42790b65091648fe75345c4533. - Use MAP_JIT for CodeCache pages ------------- Changes: https://git.openjdk.java.net/jdk/pull/294/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=05 Stats: 372 lines in 28 files changed: 193 ins; 41 del; 138 mod Patch: https://git.openjdk.java.net/jdk/pull/294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/294/head:pull/294 PR: https://git.openjdk.java.net/jdk/pull/294 From iklam at openjdk.java.net Wed Dec 2 21:13:58 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 21:13:58 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:44:08 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From akozlov at openjdk.java.net Wed Dec 2 21:14:57 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Wed, 2 Dec 2020 21:14:57 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com> <_XaA5cQEInPMn5Q5gj2y7AFCRprFQiYfI6BeUN49FhA=.9f17ae05-b37e-4f40-a83f-fd34aa812575@github.com> Message-ID: On Wed, 14 Oct 2020 10:56:25 GMT, Anton Kozlov wrote: >>> > GrowableArray maybe not the best choice here since e.g. it requires you to search twice on add. A better solution may be a specialized BST. >>> >>> I assume amount of executable mappings to be small. Depends on if exec parameter available at reserve, it is either only a single one for the CodeCache (see below) or plus several more for mappings with unknown mode (that were not committed yet) >>> >>> > IMHO too heavvy weight for a platform only change. >>> > If there are other uses for such a solution (managing memory regions, melting them together, splitting them maybe on remove) >>> > we should not support setting and clearing exec on commit but only on a per-mapping base. >>> >>> It is more simple when the whole mapping is executable or not. We don't need to split/merge on commit/uncommit then. But we need do to something when os::release_memory is called on a submapping of a mapping with unknown status. Like on AIX, uncommit is made https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp#L2096. But here for macOS, I'm trying to avoid any change of behavior for non-exec mappings. >>> >>> If the exec parameter is provided for reserve (as it eventually would be), then we don't need splitting/merging at all. This is what the latest patch is about. I haven't tested that thoroughly yet, but eventually it would be possible to deduce correct exec values for os::reserve based on subsequent os::commit. If we make a step back, we have exec parameter known for reserve and commit, I also pretty sure that it is possible to deduce that for any uncommit (which was one of the initial concerns) >>> >>> Let's agree on some plan how to attack the problem? I would like to distinguish the work toward MAP_JIT and improving interface. Not sure what should come first. Are you still opposing to have exec parameter in os::reserve/commit/uncommit and obligating callers to provide consistent exec values for each, at least at this phase? >>> >>> I mean, eventually we will have a platform-dependent `handle_t` for mapping or equivalent. Like if we provide size of the whole mapping (the context) for each commit_memory on AIX, we won't need to do the bookkeeping. What if os::commit to take ReservedSpace and do something conservative when that is not provided? >> >> >> >>> > GrowableArray maybe not the best choice here since e.g. it requires you to search twice on add. A better solution may be a specialized BST. >>> >>> I assume amount of executable mappings to be small. Depends on if exec parameter available at reserve, it is either only a single one for the CodeCache (see below) or plus several more for mappings with unknown mode (that were not committed yet) >>> >>> > IMHO too heavvy weight for a platform only change. >>> > If there are other uses for such a solution (managing memory regions, melting them together, splitting them maybe on remove) >>> > we should not support setting and clearing exec on commit but only on a per-mapping base. >>> >>> It is more simple when the whole mapping is executable or not. We don't need to split/merge on commit/uncommit then. But we need do to something when os::release_memory is called on a submapping of a mapping with unknown status. Like on AIX, uncommit is made https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp#L2096. But here for macOS, I'm trying to avoid any change of behavior for non-exec mappings. >>> >>> If the exec parameter is provided for reserve (as it eventually would be), then we don't need splitting/merging at all. This is what the latest patch is about. I haven't tested that thoroughly yet, but eventually it would be possible to deduce correct exec values for os::reserve based on subsequent os::commit. If we make a step back, we have exec parameter known for reserve and commit, I also pretty sure that it is possible to deduce that for any uncommit (which was one of the initial concerns) >>> >>> Let's agree on some plan how to attack the problem? I would like to distinguish the work toward MAP_JIT and improving interface. Not sure what should come first. Are you still opposing to have exec parameter in os::reserve/commit/uncommit and obligating callers to provide consistent exec values for each, at least at this phase? >>> >>> I mean, eventually we will have a platform-dependent `handle_t` for mapping or equivalent. Like if we provide size of the whole mapping (the context) for each commit_memory on AIX, we won't need to do the bookkeeping. What if os::commit to take ReservedSpace and do something conservative when that is not provided? >> >> Are there any users of executable memory which cannot live with anonymous mapping on whatever address with small pages? Does anyone need large pages or a specific wish address? >> >> If not, maybe we really should introduce a (reserve|commit|uncommit|release)_executable_memory() at least temporarily, as you suggested. At least that would be clear, and could provide a clear starting point for a new interface. > >> Are there any users of executable memory which cannot live with anonymous mapping on whatever address with small pages? Does anyone need large pages or a specific wish address? > > Nothing jumps out immediately. > Recently we've come across CDS problems, which also requires executable permissions, but it uses file-based mapping and os::map_memory. > >> If not, maybe we really should introduce a (reserve|commit|uncommit|release)_executable_memory() at least temporarily, as you suggested. At least that would be clear, and could provide a clear starting point for a new interface. > > Then I'll start doing this. I'll create another JBS issue for the interface closer to the point when it is ready. > > Thanks! Hi, I've just pushed an update with the new executable_memory interface. Still WIP, few notes and one major problem description follow. The new interface does not allow reserve executable memory with a specific address (restriction of MAP_JIT). Before the change, such executable memory was required by * workaround on 32bit linux-x86 https://github.com/openjdk/jdk/pull/294/files#diff-ec5e71a69afd99d4cfec5f5c657242bae9434656025694e67cae03a5e3722e84 * reading of CDS archive on windows https://github.com/openjdk/jdk/pull/294/files#diff-c93e710cbc38c989c0ab250cd4ac04d2ab157f44ee535bb035f473c42d0557c7 In both cases, it was changed to reserve non-executable memory and mprotect, which produce same result as before. Generally speaking, only platform-specific workarounds were requiring a specific address for executable mapping. MAP_JIT implementation on top of the new interface is really tiny, so it does not need a separate commit, I think. The major problem here is that executable memory now cannot be reserved at a certain alignment, although it may be required. I think the alignment should be an extra parameter to executable_memory_reserve and not e.g. reserve_executable_memory_aligned. So I'll work in this direction. Two functions like reserve_memory and reserve_memory_aligned look excessive. ReservedSpace for some reason tries to use the unaligned version first and when it fails (how should it know the result should be aligned?), fallbacks to reserve_memory_alignment. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/virtualspace.cpp#L227. It will be more straightforward to ask for alignment from the start when it's required. I'm going to make alignment a parameter for reserve_memory as well, with the default value to be "no specific alignment", and to remove reserve_memory_aligned. It will simplify the implementation of reserve_executable_memory with alignment argument, and I hope to propose the suggested refactoring separately from this PR. Please let me know if I missed something, or going to miss :) ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From iklam at openjdk.java.net Wed Dec 2 22:58:01 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 22:58:01 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 20:24:11 GMT, Anton Kozlov wrote: >> Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html >> >> On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, PROT_NONE), the function was made aware of exec permissions. >> >> For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference compared with old code. >> >> For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not shrink (if I haven't missed anything, by the implementation and in principle). >> >> Tested: >> * local tier1 >> * jdk-submit >> * codesign[2] with hardened runtime and allow-jit but without >> allow-unsigned-executable-memory entitlements[3] produce a working bundle. >> >> (adding GC group as suggested by @dholmes-ora) >> >> >> [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 >> [2] >> >> codesign \ >> --sign - \ >> --options runtime \ >> --entitlements ents.plist \ >> --timestamp \ >> $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib >> [3] >> >> >> >> >> com.apple.security.cs.allow-jit >> >> com.apple.security.cs.disable-library-validation >> >> com.apple.security.cs.allow-dyld-environment-variables >> >> >> > > Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Separate executable_memory interface > - Merge remote-tracking branch 'upstream/master' into 8234930 > - Revert everything > - Fix test builds (nothing except macOS still buildable) > - os::reserve to take exec parameter > - Bookkeeping without interface changes > - Minimal working example, no uncommit > - Merge remote-tracking branch 'upstream/master' into 8234930 > - Revert "Use MAP_JIT for CodeCache pages" > > This reverts commit 114d9cffd62cab42790b65091648fe75345c4533. > - Use MAP_JIT for CodeCache pages The CDS changes in filemap.cpp look reasonable to me. Today this code is used on Windows only, but we are thinking of using it for all platforms (sometime in JDK 17). Do you think `os::protect_memory(base, size, os::MEM_PROT_RWX)` will work on all platforms? ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/294 From dholmes at openjdk.java.net Wed Dec 2 23:02:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 23:02:56 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 18:44:08 GMT, Harold Seigel wrote: >> Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. >> >> With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. >> >> VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. >> >> The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8256718: Obsolete the long term deprecated and aliased Trace flags Looks good! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1525 From iklam at openjdk.java.net Wed Dec 2 23:27:17 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 2 Dec 2020 23:27:17 GMT Subject: RFR: 8257563: Remove excessive include of klass.inline.hpp [v2] In-Reply-To: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> References: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> Message-ID: > klass.inline.hpp is unnecessarily included by two popular header files: oop.inline.hpp and modRefBarrierSet.inline.hpp > > These two `#include` lines recursively pull in many header files. Removing them reduce the total number of header inclusion for building HotSpot from 260096 to 254773, or about 2%. > > Notes to reviewer. The main changes are in the header files: > > * src/hotspot/share/classfile/systemDictionaryShared.hpp > * src/hotspot/share/gc/shared/modRefBarrierSet.inline.hpp > * src/hotspot/share/oops/instanceKlass.hpp > * src/hotspot/share/oops/instanceKlass.inline.hpp > * src/hotspot/share/oops/oop.inline.hpp Ioi Lam 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 8257563-remove-excessive-include-klass.inline.hpp - fixed ppc and x390 builds - Merge branch 'master' into 8257563-remove-excessive-include-klass.inline.hpp - 8257563: Remove excessive include of klass.inline.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1552/files - new: https://git.openjdk.java.net/jdk/pull/1552/files/96ce2128..1bd69389 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1552&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1552&range=00-01 Stats: 1750 lines in 62 files changed: 1031 ins; 502 del; 217 mod Patch: https://git.openjdk.java.net/jdk/pull/1552.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1552/head:pull/1552 PR: https://git.openjdk.java.net/jdk/pull/1552 From dholmes at openjdk.java.net Wed Dec 2 23:43:54 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 2 Dec 2020 23:43:54 GMT Subject: RFR: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist In-Reply-To: <3hJ4-tDy-n9s7K5N3r4VC8gv1jRFBaskyrund_0o-Q4=.9041ac65-8676-4724-bb7d-d65f20ca4c1e@github.com> References: <3hJ4-tDy-n9s7K5N3r4VC8gv1jRFBaskyrund_0o-Q4=.9041ac65-8676-4724-bb7d-d65f20ca4c1e@github.com> Message-ID: On Wed, 2 Dec 2020 16:36:55 GMT, Coleen Phillimore wrote: >> JNI_ArgumentPusherVaArg copies the given argument list pointer (va_copy) but never releases it. A call to va_end is missing. >> >> AFAICS this coding is old. Interestingly, in jdk8 I find this: >> >> 0: inline void set_ap(va_list rap) { >> 0: #ifdef va_copy >> 0: va_copy(_ap, rap); >> 0: #elif defined (__va_copy) >> 0: __va_copy(_ap, rap); >> 0: #else >> 0: _ap = rap; >> 0: #endif >> 0: } >> >> `_ap = rap` seems a strangely relaxed way of doing this. But I do not know the history behind that. >> >> I could not find any usage of the original arg pointer, so maybe the `va_copy()` is not even needed. The jdk8 coding seems to indicate that too. But since I was not 100% sure I kept the `va_copy()` and added a `va_end()`. >> >> I also made this private (removed the `protected`) since there are no child classes. > > Looks good. You can read this for historical copying of va_list args: https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_34.html#SEC674 But I'm not at all sure that our use of these macros in a RAII helper object is actually valid. From what I've read these macros have to be used in the same function in which the va_list was received. I'm also not clear why we call va_copy in the first place, as we only need that if the caller also needs to access the va list of arguments. Or perhaps if we need to ensure we actually have something we can pass to another function ... but in that case the va_copy should be in the same function where the va_start is (and the corresponding va_end). (Imagine if args were passed in registers, you'd need to call va_copy to copy them to the stack in the function in which the register still holds the arg.) ------------- PR: https://git.openjdk.java.net/jdk/pull/1565 From vladimir.x.ivanov at oracle.com Wed Dec 2 23:50:10 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 3 Dec 2020 02:50:10 +0300 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: <826a3ee1-07d6-3051-ff18-40eae56ddc0d@oracle.com> <662a87e3-3091-ace7-3b10-9d36eaefaac9@redhat.com> <0c9b1c3c-2110-fbe7-da03-a6ecd1d069a6@oracle.com> Message-ID: <7e4ad69b-d9ce-cad4-503e-8b79561729d3@oracle.com> >> I have a better example for you: MemBarCPUOrder doesn't participate in >> matching at all (I'll save you some time: it signals `Matcher` to ignore >> it through `ideal_reg() == 0` which is taken into account by >> `Matcher::is_dontcare()`/`Matcher::find_shared_visit()`), but still does >> its job in Mach IR. The only thing it misses to satisfy blackhole >> requirements is it doesn't keep anything alive. But it seems just adding >> the `in_RegMask()` you have should be enough to get you there. And then >> you can get rid of any ADLC, Matcher, and CallNode-related changes you >> have right now. It seems, no drilling needed, right? :-) > > I think being explicit about Blackhole having a call-like effects, > having its own call generators, and matching as any regular node is the > explicitness that is good explicitness. Yes, it adds a handful of LOCs > on regular paths, but it does not try to do many special things at once. > This is why CallBlackholeJava -> CallBlackhole remodel happened: making > it less special and more congruent with existing nodes, even though it > would have been "easier" to hack the Call*Java. > > We need to draw the line in the sand somewhere. I can try to do what > MemBarCPUOrder does, but honestly it feels like a conceptual step back. That's the point we disagree on from the very beginning. For me, modeling a Blackhole-like entity with a call node is far from a perfect match from conceptual perspective. From engineering perspective it may be convenient and simplify some implementation aspects, but it brings a lot of baggage which is completely unrelated to the final goal. As I pointed out earlier in our discussion, there are other concepts (like SafePoint and MemBar) in C2 which aren't a perfect fit as well, but in many respects a closer match to model Blackhole. I think we have much better understanding now what is essential for Blackhole and it can be implemented with something simple yet sufficient to do the job. In that respect, lowering to Mach IR is completely irrelevant: Blackhole doesn't require anything platform-specific. Blackhole doesn't need anything more than control and memory ordering effects from a Call (plus, some rudimentary argument support), so either the rest of the functionality has to be explicitly undone/disabled or in the best case left intact unused. Also, I consider Blackhole a very niche tool and it feels much closer to yet another intrinsic (which routinely inject custom nodes and IR shapes into the graph) than a CallGenerator which IMO is more appropriate to represent call strategies than just a factory to construct call nodes. (FTR it's perfectly fine to produce calls in intrinsics. And the the peculiarities of constructing Blackhole node can be encapsulated inside GraphKit/LibraryCallKit.) Initially, the major obstacle to adopt intrinsics was the requirement on them to be placed only in trusted code inside JDK, but I think we have the answer now how to relax the limitation. That's my take on the problem you are trying to solve. > The next thing you would ask is to print consumed values in > OptoAssembly, like I am prototyping now for MachCallBlackhole. It is > possible now because Matcher knows about it and its form. If Matcher > ignores MemBarCPUOrder, does it mean OptoAssembly omits any format for > it as well? It's not Matcher job. It's ADLC which pre-generates the implementation from a pattern described in format section. The nodes ignored during matching aren't removed, but stays intact in the graph surrounded by newly created mach nodes. (Otherwise, MemBarCPUOrder wouldn't have been able to succeed at its job of ordering the memory graph.) PrintOptoAssembly just iterates over scheduled Mach IR at the end of PhaseOutput and calls `Node::format()` on each node (with some exceptions). So, if a node is part of Mach IR, then it is visited. You can easily customize the output by overriding `Node::format(PhaseRegAlloc*)` and some ideal nodes already do that (e.g., BoxLock). Best regards, Vladimir Ivanov From dholmes at openjdk.java.net Thu Dec 3 00:00:55 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 3 Dec 2020 00:00:55 GMT Subject: RFR: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist In-Reply-To: References: <3hJ4-tDy-n9s7K5N3r4VC8gv1jRFBaskyrund_0o-Q4=.9041ac65-8676-4724-bb7d-d65f20ca4c1e@github.com> Message-ID: On Wed, 2 Dec 2020 23:40:50 GMT, David Holmes wrote: >> Looks good. > > You can read this for historical copying of va_list args: > https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_34.html#SEC674 > > But I'm not at all sure that our use of these macros in a RAII helper object is actually valid. From what I've read these macros have to be used in the same function in which the va_list was received. > > I'm also not clear why we call va_copy in the first place, as we only need that if the caller also needs to access the va list of arguments. Or perhaps if we need to ensure we actually have something we can pass to another function ... but in that case the va_copy should be in the same function where the va_start is (and the corresponding va_end). (Imagine if args were passed in registers, you'd need to call va_copy to copy them to the stack in the function in which the register still holds the arg.) E.g. I think this macro: va_list args; \ va_start(args, methodID); \ JavaValue jvalue(Tag); \ JNI_ArgumentPusherVaArg ap(methodID, args); \ jni_invoke_nonstatic(env, &jvalue, obj, JNI_VIRTUAL, methodID, &ap, CHECK_0); \ va_end(args); \ should be: va_list args; \ +va_list args_copy; \ va_start(args, methodID); \ +va_copy(args, args_copy); \ JavaValue jvalue(Tag); \ ! JNI_ArgumentPusherVaArg ap(methodID, args_copy); \ jni_invoke_nonstatic(env, &jvalue, obj, JNI_VIRTUAL, methodID, &ap, CHECK_0); \ + va_end(args_copy); \ va_end(args); \ ------------- PR: https://git.openjdk.java.net/jdk/pull/1565 From dholmes at openjdk.java.net Thu Dec 3 01:24:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 3 Dec 2020 01:24:56 GMT Subject: RFR: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist In-Reply-To: References: <3hJ4-tDy-n9s7K5N3r4VC8gv1jRFBaskyrund_0o-Q4=.9041ac65-8676-4724-bb7d-d65f20ca4c1e@github.com> Message-ID: On Wed, 2 Dec 2020 23:58:00 GMT, David Holmes wrote: >> You can read this for historical copying of va_list args: >> https://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_34.html#SEC674 >> >> But I'm not at all sure that our use of these macros in a RAII helper object is actually valid. From what I've read these macros have to be used in the same function in which the va_list was received. >> >> I'm also not clear why we call va_copy in the first place, as we only need that if the caller also needs to access the va list of arguments. Or perhaps if we need to ensure we actually have something we can pass to another function ... but in that case the va_copy should be in the same function where the va_start is (and the corresponding va_end). (Imagine if args were passed in registers, you'd need to call va_copy to copy them to the stack in the function in which the register still holds the arg.) > > E.g. I think this macro: > > va_list args; \ > va_start(args, methodID); \ > JavaValue jvalue(Tag); \ > JNI_ArgumentPusherVaArg ap(methodID, args); \ > jni_invoke_nonstatic(env, &jvalue, obj, JNI_VIRTUAL, methodID, &ap, CHECK_0); \ > va_end(args); \ > should be: > va_list args; \ > +va_list args_copy; \ > va_start(args, methodID); \ > +va_copy(args, args_copy); \ > JavaValue jvalue(Tag); \ > ! JNI_ArgumentPusherVaArg ap(methodID, args_copy); \ > jni_invoke_nonstatic(env, &jvalue, obj, JNI_VIRTUAL, methodID, &ap, CHECK_0); \ > + va_end(args_copy); \ > va_end(args); \ Though technically we still need the current code and proposed fix as we can't just do a direct assignment in the helper. ------------- PR: https://git.openjdk.java.net/jdk/pull/1565 From iklam at openjdk.java.net Thu Dec 3 01:36:59 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 3 Dec 2020 01:36:59 GMT Subject: RFR: 8257563: Remove excessive include of klass.inline.hpp [v2] In-Reply-To: References: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> Message-ID: On Wed, 2 Dec 2020 09:38:32 GMT, Thomas Stuefe wrote: >> Ioi Lam 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 8257563-remove-excessive-include-klass.inline.hpp >> - fixed ppc and x390 builds >> - Merge branch 'master' into 8257563-remove-excessive-include-klass.inline.hpp >> - 8257563: Remove excessive include of klass.inline.hpp > > LGTM. Thank you for doing this. My slow notebook thanks you. > > ..Thomas Thanks @tstuefe @stefank @dholmes-ora for the review. I've tested tier1,builds-tier2,builds-tier3,builds-tier4,builds-tier5 on mach5, plus locally building s390x,ppc64le. ------------- PR: https://git.openjdk.java.net/jdk/pull/1552 From iklam at openjdk.java.net Thu Dec 3 01:37:00 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 3 Dec 2020 01:37:00 GMT Subject: Integrated: 8257563: Remove excessive include of klass.inline.hpp In-Reply-To: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> References: <62TxBC_zmuLfQrGq4aZcFf2fhxrCRJq6TNMltgXKFJ0=.d8315e0c-1813-4388-a716-cb8e1fdb6623@github.com> Message-ID: On Wed, 2 Dec 2020 04:44:27 GMT, Ioi Lam wrote: > klass.inline.hpp is unnecessarily included by two popular header files: oop.inline.hpp and modRefBarrierSet.inline.hpp > > These two `#include` lines recursively pull in many header files. Removing them reduce the total number of header inclusion for building HotSpot from 260096 to 254773, or about 2%. > > Notes to reviewer. The main changes are in the header files: > > * src/hotspot/share/classfile/systemDictionaryShared.hpp > * src/hotspot/share/gc/shared/modRefBarrierSet.inline.hpp > * src/hotspot/share/oops/instanceKlass.hpp > * src/hotspot/share/oops/instanceKlass.inline.hpp > * src/hotspot/share/oops/oop.inline.hpp This pull request has now been integrated. Changeset: 02a0a027 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/02a0a027 Stats: 278 lines in 85 files changed: 182 ins; 69 del; 27 mod 8257563: Remove excessive include of klass.inline.hpp Reviewed-by: dholmes, stuefe, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/1552 From kim.barrett at oracle.com Thu Dec 3 01:49:43 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 2 Dec 2020 20:49:43 -0500 Subject: GrowableArray - how it works? In-Reply-To: <3887b30d-9fea-4a4d-e7a5-c45d07ac4adb@samersoff.net> References: <0bfd63df-a11e-7a3c-76b1-c3f89612f51e@samersoff.net> <4320CDEB-CABF-4DDF-8844-B762B15C663C@oracle.com> <3887b30d-9fea-4a4d-e7a5-c45d07ac4adb@samersoff.net> Message-ID: <515E2485-6F5B-47A9-9704-05E0096E0C61@oracle.com> > On Dec 2, 2020, at 9:05 AM, Dmitry Samersoff wrote: > > Hello Kim, > > Thank you! > > As soon as we have c++14 enabled for jdk16, Um, we have already enabled C++14 for JDK16. > are there any plans to cleanup template usage in hs - add static_asserts etc? static_asserts are not really sufficient, and may even make things worse; in some situations they'll do little beyond adding to the error novel. Additional infrastructure (like Concepts (C++20), or something like Boost.ConceptCheck) and idioms are what's needed for mechanical checking and reporting. Requirements documentation is useful even with those, since such things can only do syntactic checks, not semantics or performance. From kbarrett at openjdk.java.net Thu Dec 3 04:14:00 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 3 Dec 2020 04:14:00 GMT Subject: RFR: 8257466: Improve enum iteration [v2] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 05:39:50 GMT, Ioi Lam wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> iklam review > > Marked as reviewed by iklam (Reviewer). Thanks for reviewing @iklam and @lfoltan ------------- PR: https://git.openjdk.java.net/jdk/pull/1530 From kbarrett at openjdk.java.net Thu Dec 3 04:32:16 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 3 Dec 2020 04:32:16 GMT Subject: RFR: 8257466: Improve enum iteration [v3] In-Reply-To: References: Message-ID: > Please review this collection of improvements to the recently added enum > iteration facility. These improvements are based on usage in some > in-development changes. > > (1) Added EnumType nested type to EnumRange and EnumIterator. It is an alias > for the enum type that is a template parameter for those classes. This is > useful when dealing with a range or iterator whose associated enum type is > not known because the range/iterator is a template parameter. > > (2) Added EnumRange::index(T), which converts the argument enumerator to > a zero-based index into the range of values. This is useful when mapping > from an enumerator to a corresponding array index, for example. > > (3) Allow enum range bounds to be specified using start and (exclusive) end > integral (underlying type) values. This is useful when dealing with enums > that are just value ranges and don't have named enumerators. As part of > this, changes the enum iteration traits mechanism to use start/end rather > than first/last, as that seems to be a little easier to deal with. > > (4) Added accessors for the first and last enumerator values of a range. > > (5) Added gtest for enum iteration. > > Testing: tier1 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 three additional commits since the last revision: - Merge branch 'master' into improve_enum_iter - iklam review - 8257466: Improve enum iteration ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1530/files - new: https://git.openjdk.java.net/jdk/pull/1530/files/6911c0fa..ef12da9d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1530&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1530&range=01-02 Stats: 8229 lines in 320 files changed: 6262 ins; 1006 del; 961 mod Patch: https://git.openjdk.java.net/jdk/pull/1530.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1530/head:pull/1530 PR: https://git.openjdk.java.net/jdk/pull/1530 From kbarrett at openjdk.java.net Thu Dec 3 04:32:18 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 3 Dec 2020 04:32:18 GMT Subject: Integrated: 8257466: Improve enum iteration In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 04:41:35 GMT, Kim Barrett wrote: > Please review this collection of improvements to the recently added enum > iteration facility. These improvements are based on usage in some > in-development changes. > > (1) Added EnumType nested type to EnumRange and EnumIterator. It is an alias > for the enum type that is a template parameter for those classes. This is > useful when dealing with a range or iterator whose associated enum type is > not known because the range/iterator is a template parameter. > > (2) Added EnumRange::index(T), which converts the argument enumerator to > a zero-based index into the range of values. This is useful when mapping > from an enumerator to a corresponding array index, for example. > > (3) Allow enum range bounds to be specified using start and (exclusive) end > integral (underlying type) values. This is useful when dealing with enums > that are just value ranges and don't have named enumerators. As part of > this, changes the enum iteration traits mechanism to use start/end rather > than first/last, as that seems to be a little easier to deal with. > > (4) Added accessors for the first and last enumerator values of a range. > > (5) Added gtest for enum iteration. > > Testing: tier1 This pull request has now been integrated. Changeset: 39325272 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/39325272 Stats: 180 lines in 2 files changed: 158 ins; 1 del; 21 mod 8257466: Improve enum iteration Improve support for iteration on enums that are just range of values, without named enumerators. Reviewed-by: iklam, lfoltan ------------- PR: https://git.openjdk.java.net/jdk/pull/1530 From stuefe at openjdk.java.net Thu Dec 3 04:55:54 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 04:55:54 GMT Subject: RFR: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist In-Reply-To: References: <3hJ4-tDy-n9s7K5N3r4VC8gv1jRFBaskyrund_0o-Q4=.9041ac65-8676-4724-bb7d-d65f20ca4c1e@github.com> Message-ID: On Thu, 3 Dec 2020 01:22:29 GMT, David Holmes wrote: >> E.g. I think this macro: >> >> va_list args; \ >> va_start(args, methodID); \ >> JavaValue jvalue(Tag); \ >> JNI_ArgumentPusherVaArg ap(methodID, args); \ >> jni_invoke_nonstatic(env, &jvalue, obj, JNI_VIRTUAL, methodID, &ap, CHECK_0); \ >> va_end(args); \ >> should be: >> va_list args; \ >> +va_list args_copy; \ >> va_start(args, methodID); \ >> +va_copy(args, args_copy); \ >> JavaValue jvalue(Tag); \ >> ! JNI_ArgumentPusherVaArg ap(methodID, args_copy); \ >> jni_invoke_nonstatic(env, &jvalue, obj, JNI_VIRTUAL, methodID, &ap, CHECK_0); \ >> + va_end(args_copy); \ >> va_end(args); \ > > Though technically we still need the current code and proposed fix as we can't just do a direct assignment in the helper. > > Correction: technically va_copy and va_end are supposed to occur in the same function, so we're assuming our RAII object gets inlined if we think we're adhering to that. > > Perhaps I'm overthinking all this. It may not be "by the book" but it certainly seems to "work" okay so perhaps best not to rock the boat here. :) Hi David, I think the thoughts are valid, I thought it odd too. The usage of va_args is tightly defined. https://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdarg.h.html Posix specifies: `Each invocation of the va_start() and va_copy() macros shall be matched by a corresponding invocation of the va_end() macro in the same function.` I also wondered why we copy in the first place, but as I wrote, I was not sure I missed some caller or some way the original ap got used. "not rocking the boat" - should I just withdraw this patch? Its a small theoretical leak. But I did a quick test on my Ubuntu box, leaking an va_list, and could not see any memory loss. Of course it may still be leaking on other platforms. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1565 From dholmes at openjdk.java.net Thu Dec 3 05:00:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 3 Dec 2020 05:00:56 GMT Subject: RFR: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist In-Reply-To: References: <3hJ4-tDy-n9s7K5N3r4VC8gv1jRFBaskyrund_0o-Q4=.9041ac65-8676-4724-bb7d-d65f20ca4c1e@github.com> Message-ID: On Thu, 3 Dec 2020 04:52:48 GMT, Thomas Stuefe wrote: >> Though technically we still need the current code and proposed fix as we can't just do a direct assignment in the helper. >> >> Correction: technically va_copy and va_end are supposed to occur in the same function, so we're assuming our RAII object gets inlined if we think we're adhering to that. >> >> Perhaps I'm overthinking all this. It may not be "by the book" but it certainly seems to "work" okay so perhaps best not to rock the boat here. :) > > Hi David, > > I think the thoughts are valid, I thought it odd too. The usage of va_args is tightly defined. > > https://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdarg.h.html > Posix specifies: > `Each invocation of the va_start() and va_copy() macros shall be matched by a corresponding invocation of the va_end() macro in the same function.` > > I also wondered why we copy in the first place, but as I wrote, I was not sure I missed some caller or some way the original ap got used. > > "not rocking the boat" - should I just withdraw this patch? Its a small theoretical leak. But I did a quick test on my Ubuntu box, leaking an va_list, and could not see any memory loss. Of course it may still be leaking on other platforms. > > Cheers, Thomas Hi Thomas, IIUC (and at best that is a partial understanding) the allocation of memory by va_start only happens under specific conditions, and I don't know exactly what they are. I tried going to the source: https://github.com/gcc-mirror/gcc/blob/master/gcc/builtins.c but that wasn't exactly illuminating without understanding all the other gcc-isms in use. (You may understand better than I.) I think your fix is harmless, and technically improves the existing code, even if there are potentially other flaws with how we do this. So if you and the other reviewers want to go ahead that seems fine to me. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1565 From stuefe at openjdk.java.net Thu Dec 3 07:53:54 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 07:53:54 GMT Subject: RFR: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist In-Reply-To: References: <3hJ4-tDy-n9s7K5N3r4VC8gv1jRFBaskyrund_0o-Q4=.9041ac65-8676-4724-bb7d-d65f20ca4c1e@github.com> Message-ID: <3H9kFfu8B5HYLlOMCPb78os6gsjraVRZXtp7kEbalyE=.40265f97-a661-4a3d-9741-80c8e7c31590@github.com> On Thu, 3 Dec 2020 04:57:42 GMT, David Holmes wrote: >> Hi David, >> >> I think the thoughts are valid, I thought it odd too. The usage of va_args is tightly defined. >> >> https://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdarg.h.html >> Posix specifies: >> `Each invocation of the va_start() and va_copy() macros shall be matched by a corresponding invocation of the va_end() macro in the same function.` >> >> I also wondered why we copy in the first place, but as I wrote, I was not sure I missed some caller or some way the original ap got used. >> >> "not rocking the boat" - should I just withdraw this patch? Its a small theoretical leak. But I did a quick test on my Ubuntu box, leaking an va_list, and could not see any memory loss. Of course it may still be leaking on other platforms. >> >> Cheers, Thomas > > Hi Thomas, > > IIUC (and at best that is a partial understanding) the allocation of memory by va_start only happens under specific conditions, and I don't know exactly what they are. I tried going to the source: > > https://github.com/gcc-mirror/gcc/blob/master/gcc/builtins.c > > but that wasn't exactly illuminating without understanding all the other gcc-isms in use. (You may understand better than I.) > > I think your fix is harmless, and technically improves the existing code, even if there are potentially other flaws with how we do this. So if you and the other reviewers want to go ahead that seems fine to me. > > Thanks, > David Thank you Coleen, David and Dan. ------------- PR: https://git.openjdk.java.net/jdk/pull/1565 From stuefe at openjdk.java.net Thu Dec 3 07:53:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 07:53:55 GMT Subject: Integrated: JDK-8257604: JNI_ArgumentPusherVaArg leaks valist In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 15:02:30 GMT, Thomas Stuefe wrote: > JNI_ArgumentPusherVaArg copies the given argument list pointer (va_copy) but never releases it. A call to va_end is missing. > > AFAICS this coding is old. Interestingly, in jdk8 I find this: > > 0: inline void set_ap(va_list rap) { > 0: #ifdef va_copy > 0: va_copy(_ap, rap); > 0: #elif defined (__va_copy) > 0: __va_copy(_ap, rap); > 0: #else > 0: _ap = rap; > 0: #endif > 0: } > > `_ap = rap` seems a strangely relaxed way of doing this. But I do not know the history behind that. > > I could not find any usage of the original arg pointer, so maybe the `va_copy()` is not even needed. The jdk8 coding seems to indicate that too. But since I was not 100% sure I kept the `va_copy()` and added a `va_end()`. > > I also made this private (removed the `protected`) since there are no child classes. This pull request has now been integrated. Changeset: ae1eb286 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/ae1eb286 Stats: 5 lines in 1 file changed: 4 ins; 1 del; 0 mod 8257604: JNI_ArgumentPusherVaArg leaks valist Reviewed-by: dcubed, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1565 From stuefe at openjdk.java.net Thu Dec 3 08:40:17 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 08:40:17 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set [v2] In-Reply-To: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: > Hi, > > may I please have reviews for the following very small improvement: > > While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: > > size_t os::_page_sizes[os::page_sizes_max]; > > is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. > > Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). > > That has the following advantages: > - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. > - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. > > ----- > > The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. > > > Testing: > - nightlies at SAP > - manual tests with UseLargePages > - the new gtests > - gh actions (with x86 still failing because of unrelated issues) > > Thank you, > > Thomas > > [1] https://bugs.openjdk.java.net/browse/JDK-8243315 > [2] https://bugs.openjdk.java.net/browse/JDK-8256155 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Fix 32bit issues ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1522/files - new: https://git.openjdk.java.net/jdk/pull/1522/files/7014f81e..9e936bcf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=00-01 Stats: 95 lines in 2 files changed: 39 ins; 29 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/1522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1522/head:pull/1522 PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Thu Dec 3 08:44:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 08:44:57 GMT Subject: Integrated: JDK-8256864: [windows] Improve tracing for mapping errors In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 15:26:45 GMT, Thomas Stuefe wrote: > To analyze JDK-8256729 further, we need more tracing: > > 1) We should print all mappings inside the split area if os::split_reserved_memory() fails > > 2) The print-mapping code on windows has some shortcomings: > - should not probe for mappings outside of what we know are valid address ranges for Windows > - should handle wrap-arounds - it should be possible to print the whole address space > - Protection information is printed wrong (MEMORY_BASIC_INFORMATION.Protect would be the correct member) > - should be printed in a more compact manner - base address should be on the same line as the first region > - maybe adorned with some basic range info, e.g. library mappings > > Tested in our nightlies for a week now, works fine. > > Example output see https://github.com/openjdk/jdk/files/5622718/mapping-printout.txt This pull request has now been integrated. Changeset: b44a329f Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/b44a329f Stats: 143 lines in 4 files changed: 123 ins; 2 del; 18 mod 8256864: [windows] Improve tracing for mapping errors Reviewed-by: iklam, rrich ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From stuefe at openjdk.java.net Thu Dec 3 08:44:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 08:44:56 GMT Subject: RFR: JDK-8256864: [windows] Improve tracing for mapping errors [v5] In-Reply-To: References: Message-ID: On Tue, 1 Dec 2020 20:37:18 GMT, Ioi Lam wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Ioi > > Marked as reviewed by iklam (Reviewer). Thanks @iklam and @reinrich . All tests went through sucessfully tonight. ------------- PR: https://git.openjdk.java.net/jdk/pull/1390 From akozlov at openjdk.java.net Thu Dec 3 08:51:01 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 3 Dec 2020 08:51:01 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 22:55:32 GMT, Ioi Lam wrote: > Do you think os::protect_memory(base, size, os::MEM_PROT_RWX) will work on all platforms? It looks so. Not sure about AIX, it ends up with ::mprotect, at least theoretically should be fine. On Linux and macOS without hardening it should be also OK. Without this patch, we don't support macOS hardened mode at all. But I have some private hacks for CDS with hardening, they reuse some of windows code for reading the archive content instead of mapping, so the future looks even more convenient. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From tschatzl at openjdk.java.net Thu Dec 3 10:23:02 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 3 Dec 2020 10:23:02 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 08:40:17 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Fix 32bit issues Changes requested by tschatzl (Reviewer). To be really nitpicky: the subject of the PR should be made more specific to mention that the new set is a bitset not just a set. I.e. os::page_sizes has already previously been a set (of integers), so where's the change? :P src/hotspot/share/runtime/os.cpp line 79: > 77: int os::_processor_count = 0; > 78: int os::_initial_active_processor_count = 0; > 79: os::PagesizeSet os::_page_sizes; While I'm typically not a fan of aligning variable identifiers, it's already there. Please align this new one too with the others. src/hotspot/share/runtime/os.cpp line 1851: > 1849: > 1850: ////// Implementation of pagesizeset_t > 1851: There is no pagesizeset_t ;) src/hotspot/share/runtime/os.cpp line 1854: > 1852: // A pagesizeset_t is a set containing a set of page sizes. > 1853: > 1854: // sets the given page size Not sure if this is the correct place for a description what the method does, it seems to me that the definition in the hpp file is a better place. Also all other methods are described there already, and this description does not add anything new. src/hotspot/share/runtime/os.cpp line 1863: > 1861: bool os::PagesizeSet::is_set(size_t pagesize) const { > 1862: assert(is_power_of_2(pagesize), "pagesize must be a power of 2: " INTPTR_FORMAT, pagesize); > 1863: return _v & pagesize; Please do not rely on implicit comparison against unequal 0. src/hotspot/share/runtime/os.cpp line 1870: > 1868: assert(is_power_of_2(pagesize), "pagesize must be a power of 2: " INTPTR_FORMAT, pagesize); > 1869: // mask out all pages sizes >= pagesize: > 1870: uintx v2 = _v & pagesize - 1; I would prefer to add the brackets instead of relying on operator strengths. They would make the intent more clear or at least require less thinking. src/hotspot/share/runtime/os.cpp line 1904: > 1902: size_t os::PagesizeSet::smallest() const { > 1903: assert(min_page_size() > 0, "Sanity"); > 1904: return next_larger(min_page_size() / 2); Why not just return `min_page_size()` here? An assert may be added to check that they are the same though. src/hotspot/share/runtime/os.hpp line 103: > 101: > 102: public: > 103: The class PagesizeSet does not need to be public. src/hotspot/share/runtime/os.cpp line 1860: > 1858: } > 1859: > 1860: // returns true if given page size is part of the set Same as for `add()`. src/hotspot/share/runtime/os.hpp line 112: > 110: bool is_set(size_t pagesize) const; > 111: // given a page size, return the next smaller page size in this set, or 0. > 112: size_t next_smaller(size_t pagesize) const; Please let all documentation sentences start with upper case. src/hotspot/share/runtime/os.cpp line 1919: > 1917: } else if (sz < G) { > 1918: st->print(SIZE_FORMAT "m", sz / M); > 1919: } else { The prefixes for mega/gigabyte are "M" and "G" instead of "m" and "g" respectively src/hotspot/share/runtime/os.cpp line 1887: > 1885: return 0; > 1886: } > 1887: while ((v2 & 1) == 0) { Maybe the `count_trailing_zeros()` method could be used here instead of doing the same manually. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522Changes requested by tschatzl (Reviewer). From shade at openjdk.java.net Thu Dec 3 10:44:29 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 10:44:29 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v15] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. > > C1 code is platform-independent, and it adds the new node which is then lowered to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request incrementally with five additional commits since the last revision: - Make sure null-checks are handled correctly after blackholed methods - Parallelize and ID the tests properly - Multiple arguments tests - Remodel blackhole hook as fake intrinsic - Remodel CallBlackhole as Blackhole membar ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/f0e27389..6b7d762f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=13-14 Stats: 1563 lines in 59 files changed: 939 ins; 608 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From github.com+71302734+amitdpawar at openjdk.java.net Thu Dec 3 10:54:09 2020 From: github.com+71302734+amitdpawar at openjdk.java.net (Amit Pawar) Date: Thu, 3 Dec 2020 10:54:09 GMT Subject: RFR: 8254699: Suboptimal PreTouchParallelChunkSize defaults and limits [v3] In-Reply-To: References: Message-ID: > This PR fixes lower and default value of JVM flag PreTouchParallelChunkSize. Its default value is 1GB and is used by both G1GC and ParallelGC to pretouch the pages. Following test showed that reducing the chunk size improves JVM startup time and GC pause time. > > Tests are: (Test machine 2P 64C/128T with 1TB memory) > 1. JVM startup time test with AdaptiveSizePolicy disabled: Pretouch 1TB of memory with/without transparent large page support and used time command to measure the time taken. > Command: time ./jdk/bin/java -XX:+AlwaysPreTouch -XX:+-Xmx900g -Xms900g -Xmn800g -XX:SurvivorRatio=400 -Xlog:gc*=debug:file=gc.log -XX:ParallelGCThreads=128 -XX:PreTouchParallelChunkSize= -version > 2. JVM startup and GC pause time test with AdaptiveSizePolicy enabled: SPECjbb composite run with 1TB heap and transparent large page support was enabled. > > Test results are recorded in XL file. [PreTouchParallelChunkSize_TestResults.xlsx](https://github.com/openjdk/jdk/files/5612448/PreTouchParallelChunkSize_TestResults.xlsx) > > Test results shows: > 1. With AdaptiveSizePolicy disabled. > 1. G1GC improved upto ~14% on large page disabled and ~5% on enabled. > 2. ParallelGC improved upto ~15% on large page disabled and ~5% on enabled. > 3. Tests showed improvement from 64KB for default page size and 2MB for lage page size. > 4. Please check "JVM_Startup_Summary" sheet in XL file for more detail. > > 2. SPECjbb composite test with UseAdaptiveSizePolicy + UseLargePages enabled. > 1. Pretouch takes up-to 30-90% less time for memory range 32MB-4GB. This happens because memory less than 1GB also pretouched with multiple threads. > 2. Same also helps to bring down GC pause time and this is dependent on memory size. Effect is larger when expansion size is smaller. > 3. Please check SPECjbb_Summary sheet in XL file for more detail. > > Default value of PreTouchParallelChunkSize is changed to 4MB and based your suggestion it can be changed to right value. Please check and review this PR. Amit Pawar has updated the pull request incrementally with one additional commit since the last revision: PreTouchParallelChunkSize is changed to platform-dependent and default value set to 4M from 1G for Linux only. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1503/files - new: https://git.openjdk.java.net/jdk/pull/1503/files/ef6fa419..4397e430 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1503&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1503&range=01-02 Stats: 5 lines in 5 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1503.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1503/head:pull/1503 PR: https://git.openjdk.java.net/jdk/pull/1503 From shade at redhat.com Thu Dec 3 10:59:52 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 3 Dec 2020 11:59:52 +0100 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <1039a82f-b6cd-2a79-a503-dcb4b716f788@oracle.com> References: <5b64ff35-ba02-30a6-b883-80682d4a1af5@oracle.com> <26a8d41e-6292-835c-a1d1-a37b7d942100@redhat.com> <1039a82f-b6cd-2a79-a503-dcb4b716f788@oracle.com> Message-ID: <172d0d0a-6c02-000b-97de-082c8f5c03f0@redhat.com> On 12/2/20 6:16 PM, Vladimir Ivanov wrote: > One more idea: what if you populate ciMethod::_intrinsic_id instead when > you detect a blackhole method? There's already an example of marker > pseudo-intrinsic (vmIntrinsics::_compiledLambdaForm) and you can just > introduce a new one for blackhole methods. > > Then you don't need `BlackholeCallGenerator` anymore and > `BlackholeCallGenerator::generate()` can be migrated to > `library_call.cpp` as yet another intrinsic. Yes, done in new commits. It requires a few collateral changes: - CheckIntrinsic paths disable _blackhole, unless we special-case that there is no @IntrinsicCandidate enabled. - JMH cannot request both "blackhole" and "dontinline" on Blackhole methods, as "dontinline" would take precedence. This is to say that _blackhole is essentially inline intrinsic now. - C1 can (and should) use the same thing, which removes the need for new nodes there, AFAICS. -- Thanks, -Aleksey From shade at redhat.com Thu Dec 3 11:01:29 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 3 Dec 2020 12:01:29 +0100 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <6f45ed07-01f6-4731-748d-c780c99cb365@oracle.com> References: <202ecd3f-b17e-494b-7130-0c1d62e9761c@oracle.com> <6f45ed07-01f6-4731-748d-c780c99cb365@oracle.com> Message-ID: <83c408ae-7a88-d09a-6a88-3dab39a7f4fe@redhat.com> On 12/2/20 7:42 PM, Vladimir Ivanov wrote: > The only difference I see is receiver becomes treated as an ordinary > argument which is consumed by a blackhole while in the current > implementation you ignore receiver. Actually, I don't think we need to ignore receiver in current code. It is a left-over from my experiments that were only taking care of primitive arguments. Since current code is much more simple, we can just blackhole everything. Done in new commits. >>> If you want to keep instance method support, please, double-check that >>> null check stays there for correctness. >> >> OK, that looks empirically verifiable (i.e. with the jtreg test), will od. Added a new test, seems to pass fine. -- Thanks, -Aleksey From shade at openjdk.java.net Thu Dec 3 11:05:11 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 11:05:11 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v16] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. > > C1 code is platform-independent, and it adds the new node which is then lowered to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. > > Another exploration in making this less intrusive makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Formatting touchups ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/6b7d762f..a261682b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=14-15 Stats: 6 lines in 2 files changed: 5 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From dnsimon at openjdk.java.net Thu Dec 3 11:35:08 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Thu, 3 Dec 2020 11:35:08 GMT Subject: RFR: 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports [v7] In-Reply-To: References: Message-ID: <8f6cmBnWpoVE29EhxmrpTkXbDidpM19pjEk7xta-tIQ=.a1cd722d-8f46-4370-a721-4d0168e0b48f@github.com> > A number of jtreg tests require a specific GC. These tests should be ignored when EnableJVMCI is true and the JVMCI compiler does not support the required GC. > > This PR adds `JVMCICompiler.isGCSupported` and makes use of it in `WhiteBox.isGCSupported`. > > Prior to this PR, a test requiring a GC not yet supported by a JVMCI compiler fail as follows: > Error occurred during initialization of VM > JVMCI Compiler does not support selected GC: epsilon gc Doug Simon has updated the pull request incrementally with one additional commit since the last revision: Fix @requires vm.jvmci ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1423/files - new: https://git.openjdk.java.net/jdk/pull/1423/files/2aa5be51..3848e438 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1423&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1423&range=05-06 Stats: 52 lines in 7 files changed: 40 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1423.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1423/head:pull/1423 PR: https://git.openjdk.java.net/jdk/pull/1423 From github.com+71302734+amitdpawar at openjdk.java.net Thu Dec 3 11:39:54 2020 From: github.com+71302734+amitdpawar at openjdk.java.net (Amit Pawar) Date: Thu, 3 Dec 2020 11:39:54 GMT Subject: RFR: 8254699: Suboptimal PreTouchParallelChunkSize defaults and limits [v2] In-Reply-To: References: <-IgaNSYmBVVimEHic6I4rf6eAYnjJHhygRgvVhS1OgU=.f9c3b001-aba9-4c21-8a55-262860241ff5@github.com> <9Ajth2BhjNfDOxM_0EmQ_MU3ymGzd7t0VToXi7afkPc=.b285e9f5-10ba-43cf-9156-c913444087bc@github.com> Message-ID: <73MqPgRylK6xISzmG0ZfhPxtRDYaXt1kRrGgRf1ktFo=.97a4c2b6-2946-4c20-8b05-15ec2abec16d@github.com> On Wed, 2 Dec 2020 14:52:04 GMT, Amit Pawar wrote: >> I have not done extensive measurements, I basically ran some startup benchmarks with: >> -XX:+AlwaysPreTouch -Xms8g -Xmx8g >> -XX:+AlwaysPreTouch -Xms8g -Xmx8g -XX:PreTouchParallelChunkSize=4m >> -XX:+AlwaysPreTouch -Xms8g -Xmx8g -XX:PreTouchParallelChunkSize=128m >> >> And on Windows going with the current default is the clear winner, while on Linux using 4M gives best results. Given that and your tests I think it is fairly safe to use 4M for Linux, but for the other OSes we need to do more measurements before changing to a different value. > > OK and I will make it platform specific as suggested. > > Thanks, > Amit PreTouchParallelChunkSize is changed to platform-dependent as suggested. Please check now. To make testing easier created two scripts and attached as zip file [run_pretouch_test.zip](https://github.com/openjdk/jdk/files/5635703/run_pretouch_test.zip). 1. Script "run_pretouch_test.sh" will run pretouch test by configuring **"from space"** to 1MB to 8GB for chunk sizes 64KB to 1GB. Tested only on Linux for both default and large pages. 2. Script "print_timetaken.sh" will collect and print time taken from all the generated GC log files. Time taken will be extracted for only **"from space"** and it will print table similar to shown in Excel file. [PreTouchWithDifferentMemorySize.xlsx](https://github.com/openjdk/jdk/files/5635750/PreTouchWithDifferentMemorySize.xlsx) 3. Should have build using git id "8ef5ed7c64808c6b039baa0751afa7ff017b318d" else it wont work. This particular revision dumps time for PretouchTask. Thanks, Amit ------------- PR: https://git.openjdk.java.net/jdk/pull/1503 From shade at redhat.com Thu Dec 3 11:45:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 3 Dec 2020 12:45:06 +0100 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: <7wHC1VVBP5st7PFgles4qKeLp_A2CmycoFLranbEc2c=.81b6b4df-a260-4a55-8597-ff7facd1181f@github.com> <9yTVrPzoPijjtZlmJOku2uCaO0CJ7GRxgQS-5mf0BrU=.7ef38347-aaa5-4f49-b459-e9f36552e8c4@github.com> <432a7f00-039c-4511-251f-da126ad3801f@redhat.com> Message-ID: <86e1fa5c-00a3-d966-08bd-be36c2107990@redhat.com> On 12/2/20 6:21 PM, Vladimir Ivanov wrote: > >> So where do we go from here? Somehow recording the operands of >> MachCallBlackhole? > > Have you tried `PhaseRegAlloc::dump_register(const Node *n, char *buf)` > on argument inputs? Yes, new commit has it. For the sample method like: public void test_08(Blackhole bh) { bh.consume(x + y); bh.consume(x + y); ... -XX:+PrintOptoAssembly finally looks like this: 02c movl R11, [RSI + #16 (8-bit)] # int ! Field: org/openjdk/jmh/samples/XplusY.y 030 addl R11, [RSI + #12 (8-bit)] # int 034 blackhole RDX, R11 034 movl R11, [RSI + #16 (8-bit)] # int ! Field: org/openjdk/jmh/samples/XplusY.y 038 addl R11, [RSI + #12 (8-bit)] # int 03c blackhole RDX, R11 RDX is receiver ("bh"), and R11 is "x + y". -- Thanks, -Aleksey From vladimir.x.ivanov at oracle.com Thu Dec 3 11:46:06 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 3 Dec 2020 14:46:06 +0300 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <83c408ae-7a88-d09a-6a88-3dab39a7f4fe@redhat.com> References: <202ecd3f-b17e-494b-7130-0c1d62e9761c@oracle.com> <6f45ed07-01f6-4731-748d-c780c99cb365@oracle.com> <83c408ae-7a88-d09a-6a88-3dab39a7f4fe@redhat.com> Message-ID: <524960ad-9ee4-a47b-deee-187903ec2f84@oracle.com> >> The only difference I see is receiver becomes treated as an ordinary >> argument which is consumed by a blackhole while in the current >> implementation you ignore receiver. > > Actually, I don't think we need to ignore receiver in current code. It > is a left-over from my experiments that were only taking care of > primitive arguments. Since current code is much more simple, we can just > blackhole everything. Done in new commits. Does it make more sense now to further limit the intrinsic to static methods only? It won't simplify the implementation any futher, but will help reduce perceived complexity (need to reason about both virtual and static cases). Best regards, Vladimir Ivanov >>>> If you want to keep instance method support, please, double-check that >>>> null check stays there for correctness. >>> >>> OK, that looks empirically verifiable (i.e. with the jtreg test), >>> will od. > > Added a new test, seems to pass fine. > From shade at redhat.com Thu Dec 3 11:48:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 3 Dec 2020 12:48:03 +0100 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <7e4ad69b-d9ce-cad4-503e-8b79561729d3@oracle.com> References: <826a3ee1-07d6-3051-ff18-40eae56ddc0d@oracle.com> <662a87e3-3091-ace7-3b10-9d36eaefaac9@redhat.com> <0c9b1c3c-2110-fbe7-da03-a6ecd1d069a6@oracle.com> <7e4ad69b-d9ce-cad4-503e-8b79561729d3@oracle.com> Message-ID: <338bd243-d25c-ca63-4f8d-d56744457d35@redhat.com> On 12/3/20 12:50 AM, Vladimir Ivanov wrote: >> We need to draw the line in the sand somewhere. I can try to do what >> MemBarCPUOrder does, but honestly it feels like a conceptual step back. > > That's the point we disagree on from the very beginning. Here is where I was confused. The discussion never mentioned the word "disagree" up until now. You asked for clarifications why call-based approach was used, thanked me for explanations, and then went on suggesting other directions for experimentation. It did not read as "I disagree with current approach, here is the approach I would like to see tried", but rather as "Looks okay, and here is something we could also try". There is a world of difference between these two statements. > I think we have much better understanding now what is essential for > Blackhole and it can be implemented with something simple yet sufficient > to do the job. Right! New iteration hopefully does what you suggest. And it is indeed much simpler than call-based approach, thank you. > The nodes ignored during matching aren't removed, but stays intact in > the graph surrounded by newly created mach nodes. (Otherwise, > MemBarCPUOrder wouldn't have been able to succeed at its job of ordering > the memory graph.) OK, that is good to know. I thought only Mach nodes are left after the matching. New commits have the Blackhole formatter. -- Thanks, -Aleksey From shade at openjdk.java.net Thu Dec 3 11:49:13 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 11:49:13 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v17] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. > > C1 code is platform-independent, and it adds the new node which is then lowered to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. > > Another exploration in making this less intrusive makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Print Blackhole format ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/a261682b..f20abdaa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=15-16 Stats: 23 lines in 2 files changed: 23 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From vlivanov at openjdk.java.net Thu Dec 3 11:49:14 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 3 Dec 2020 11:49:14 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v16] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 11:05:11 GMT, Aleksey Shipilev wrote: >> JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: >> >> 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. >> 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. >> 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. >> >> Supporting this directly in compilers would improve nanobenchmark fidelity. >> >> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). >> >> Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. >> >> C1 code is platform-independent, and it adds the new node which is then lowered to nothing. >> >> C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. >> >> [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. >> >> [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. >> >> ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. >> >> Another exploration in making this less intrusive makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Formatting touchups Very nice! A couple of minor comments follow. src/hotspot/share/ci/ciMethod.cpp line 161: > 159: if (CompilerOracle::should_blackhole(h_m) && > 160: _signature->return_type()->basic_type() == T_VOID && > 161: h_m->intrinsic_id() == vmIntrinsics::_none) { Why not switch to blackhole unconditionally and override existing intrinsic if any? src/hotspot/share/opto/library_call.cpp line 6860: > 6858: // This matches methods that were requested to be blackholed through compile commands. > 6859: // > 6860: bool LibraryCallKit::inline_blackhole() { I can't see where receiver null check comes from. Don't you have to explicitly insert it in the intrinsic? ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From vladimir.x.ivanov at oracle.com Thu Dec 3 11:54:20 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 3 Dec 2020 14:54:20 +0300 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <86e1fa5c-00a3-d966-08bd-be36c2107990@redhat.com> References: <7wHC1VVBP5st7PFgles4qKeLp_A2CmycoFLranbEc2c=.81b6b4df-a260-4a55-8597-ff7facd1181f@github.com> <9yTVrPzoPijjtZlmJOku2uCaO0CJ7GRxgQS-5mf0BrU=.7ef38347-aaa5-4f49-b459-e9f36552e8c4@github.com> <432a7f00-039c-4511-251f-da126ad3801f@redhat.com> <86e1fa5c-00a3-d966-08bd-be36c2107990@redhat.com> Message-ID: I like it! Very informative. Best regards, Vladimir Ivanov On 03.12.2020 14:45, Aleksey Shipilev wrote: > On 12/2/20 6:21 PM, Vladimir Ivanov wrote: >> >>> So where do we go from here? Somehow recording the operands of >>> MachCallBlackhole? >> >> Have you tried `PhaseRegAlloc::dump_register(const Node *n, char *buf)` >> on argument inputs? > > Yes, new commit has it. For the sample method like: > > ??? public void test_08(Blackhole bh) { > ??????? bh.consume(x + y); > ??????? bh.consume(x + y); > ??????? ... > > -XX:+PrintOptoAssembly finally looks like this: > > 02c???? movl??? R11, [RSI + #16 (8-bit)]??????? # int ! Field: > org/openjdk/jmh/samples/XplusY.y > 030???? addl??? R11, [RSI + #12 (8-bit)]??????? # int > 034???? blackhole RDX, R11 > > 034???? movl??? R11, [RSI + #16 (8-bit)]??????? # int ! Field: > org/openjdk/jmh/samples/XplusY.y > 038???? addl??? R11, [RSI + #12 (8-bit)]??????? # int > 03c???? blackhole RDX, R11 > > RDX is receiver ("bh"), and R11 is "x + y". > From shade at openjdk.java.net Thu Dec 3 11:56:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 11:56:59 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v16] In-Reply-To: References: Message-ID: <93Lq6Xn0I-XtK2FvdweD6ByLxFThHQnp3H-ivLBaI-4=.f5563865-8246-4c58-9558-91634cef2b64@github.com> On Thu, 3 Dec 2020 11:28:07 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Formatting touchups > > src/hotspot/share/ci/ciMethod.cpp line 161: > >> 159: if (CompilerOracle::should_blackhole(h_m) && >> 160: _signature->return_type()->basic_type() == T_VOID && >> 161: h_m->intrinsic_id() == vmIntrinsics::_none) { > > Why not switch to blackhole unconditionally and override existing intrinsic if any? I thought existing intrinsic should take precedence over blackhole. But maybe blackhole should really take a precedence here, as it comes from an explicit compile command. I'll drop `== none` check. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From stefank at openjdk.java.net Thu Dec 3 12:08:59 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 3 Dec 2020 12:08:59 GMT Subject: RFR: 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports [v7] In-Reply-To: <8f6cmBnWpoVE29EhxmrpTkXbDidpM19pjEk7xta-tIQ=.a1cd722d-8f46-4370-a721-4d0168e0b48f@github.com> References: <8f6cmBnWpoVE29EhxmrpTkXbDidpM19pjEk7xta-tIQ=.a1cd722d-8f46-4370-a721-4d0168e0b48f@github.com> Message-ID: On Thu, 3 Dec 2020 11:35:08 GMT, Doug Simon wrote: >> A number of jtreg tests require a specific GC. These tests should be ignored when EnableJVMCI is true and the JVMCI compiler does not support the required GC. >> >> This PR adds `JVMCICompiler.isGCSupported` and makes use of it in `WhiteBox.isGCSupported`. >> >> Prior to this PR, a test requiring a GC not yet supported by a JVMCI compiler fail as follows: >> Error occurred during initialization of VM >> JVMCI Compiler does not support selected GC: epsilon gc > > Doug Simon has updated the pull request incrementally with one additional commit since the last revision: > > Fix @requires vm.jvmci I've been talking to Doug the last few days and we've settled on this approach that both solves their testing needs, and at the same time satisfy my wish to *not* turn on EnableJVMCI for GCs that don't have fully support for it. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1423 From vlivanov at openjdk.java.net Thu Dec 3 12:13:00 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 3 Dec 2020 12:13:00 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v17] In-Reply-To: References: Message-ID: <2w_9Xdlhxsrr3nfcjcwpuguy0fbNbqpEqjX9jm5wntc=.8f28862f-2ef9-494e-9e96-e6d1d7d846df@github.com> On Thu, 3 Dec 2020 11:49:13 GMT, Aleksey Shipilev wrote: >> JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: >> >> 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. >> 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. >> 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. >> >> Supporting this directly in compilers would improve nanobenchmark fidelity. >> >> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). >> >> Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. >> >> C1 code is platform-independent, and it adds the new node which is then lowered to nothing. >> >> C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. >> >> [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. >> >> [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. >> >> ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. >> >> Another exploration in making this less intrusive makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Print Blackhole format src/hotspot/share/opto/memnode.cpp line 3471: > 3469: st->print(", "); > 3470: } > 3471: char buf[128]; I'd introduce `PhaseRegAlloc::dump_register(Node*,outputStream*)` overload and put these 3 lines there. Then ADLC-generated code can be migrated to it later. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From stuefe at openjdk.java.net Thu Dec 3 12:16:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 12:16:57 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 09:49:14 GMT, Thomas Schatzl wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix 32bit issues > > src/hotspot/share/runtime/os.cpp line 1904: > >> 1902: size_t os::PagesizeSet::smallest() const { >> 1903: assert(min_page_size() > 0, "Sanity"); >> 1904: return next_larger(min_page_size() / 2); > > Why not just return `min_page_size()` here? > > An assert may be added to check that they are the same though. Not sure what you mean. PagesizeSet::smallest() returns the smallest page in the page size set, which may be any size, or 0 if empty. os::_page_sizes should always contain os::vm_page_size(), but that too is not the same as os::min_page_size(). os::min_page_size() is just a constant, equal or smaller than the smallest page size across all platforms. The naming is confusing, and probably it could be just a static const instead of a function. But I don't want to touch that with this change. But there are probably a number of misuses of os::min_page_size() where the author actually meant os::vm_page_size(). ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From vladimir.x.ivanov at oracle.com Thu Dec 3 12:28:54 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 3 Dec 2020 15:28:54 +0300 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <338bd243-d25c-ca63-4f8d-d56744457d35@redhat.com> References: <826a3ee1-07d6-3051-ff18-40eae56ddc0d@oracle.com> <662a87e3-3091-ace7-3b10-9d36eaefaac9@redhat.com> <0c9b1c3c-2110-fbe7-da03-a6ecd1d069a6@oracle.com> <7e4ad69b-d9ce-cad4-503e-8b79561729d3@oracle.com> <338bd243-d25c-ca63-4f8d-d56744457d35@redhat.com> Message-ID: <9bfb6fb0-efb9-5895-d2f9-a2c6bed14713@oracle.com> >>> We need to draw the line in the sand somewhere. I can try to do what >>> MemBarCPUOrder does, but honestly it feels like a conceptual step back. >> >> That's the point we disagree on from the very beginning. > > Here is where I was confused. The discussion never mentioned the word > "disagree" up until now. And I don't remember you used the word "conceptual" in the discussion before ;-) > You asked for clarifications why call-based approach was used, thanked > me for explanations, and then went on suggesting other directions for > experimentation. It did not read as "I disagree with current approach, > here is the approach I would like to see tried", but rather as "Looks > okay, and here is something we could also try". There is a world of > difference between these two statements. Point taken. I'll try to be more explicit next time. Sorry for the confusion. >> I think we have much better understanding now what is essential for >> Blackhole and it can be implemented with something simple yet sufficient >> to do the job. > > Right! New iteration hopefully does what you suggest. And it is indeed > much simpler than call-based approach, thank you. It looks very good. Thanks for taking my suggestions into account. Best regards, Vladimir Ivanov >> The nodes ignored during matching aren't removed, but stays intact in >> the graph surrounded by newly created mach nodes. (Otherwise, >> MemBarCPUOrder wouldn't have been able to succeed at its job of ordering >> the memory graph.) > > OK, that is good to know. I thought only Mach nodes are left after the > matching. New commits have the Blackhole formatter. > From tschatzl at openjdk.java.net Thu Dec 3 12:28:55 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 3 Dec 2020 12:28:55 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 12:13:53 GMT, Thomas Stuefe wrote: >> src/hotspot/share/runtime/os.cpp line 1904: >> >>> 1902: size_t os::PagesizeSet::smallest() const { >>> 1903: assert(min_page_size() > 0, "Sanity"); >>> 1904: return next_larger(min_page_size() / 2); >> >> Why not just return `min_page_size()` here? >> >> An assert may be added to check that they are the same though. > > Not sure what you mean. > > PagesizeSet::smallest() returns the smallest page in the page size set, which may be any size, or 0 if empty. > > os::_page_sizes should always contain os::vm_page_size(), but that too is not the same as os::min_page_size(). os::min_page_size() is just a constant, equal or smaller than the smallest page size across all platforms. > > The naming is confusing, and probably it could be just a static const instead of a function. But I don't want to touch that with this change. But there are probably a number of misuses of os::min_page_size() where the author actually meant os::vm_page_size(). Okay, apologies for falling into the mentioned trap. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From shade at openjdk.java.net Thu Dec 3 12:32:15 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 12:32:15 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v18] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. > > C1 code is platform-independent, and it adds the new node which is then lowered to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. > > Another exploration in making this less intrusive makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: - Handle null-checks in intrinsics to maintain the semantics - Blackhole takes precedence over all other intrinsics ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/f20abdaa..88712d15 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=16-17 Stats: 39 lines in 5 files changed: 26 ins; 5 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Thu Dec 3 12:32:17 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 12:32:17 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v16] In-Reply-To: References: Message-ID: <7uAu4MtW58aGxEuWGEBvLwY7-Oj7Lf0XH1KRBldJYmw=.931dc888-3aea-461a-96f9-3f7e8b5e62a3@github.com> On Thu, 3 Dec 2020 11:41:28 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Formatting touchups > > src/hotspot/share/opto/library_call.cpp line 6860: > >> 6858: // This matches methods that were requested to be blackholed through compile commands. >> 6859: // >> 6860: bool LibraryCallKit::inline_blackhole() { > > I can't see where receiver null check comes from. Don't you have to explicitly insert it in the intrinsic? Dang. We should do receiver null-checks in intrinsics. Added. It looks like C2 is able to elide null-checks in JMH hot loops, while C1 leaves the first null-check in subsequent `Blackhole` calls. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Thu Dec 3 12:35:01 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 12:35:01 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v17] In-Reply-To: <2w_9Xdlhxsrr3nfcjcwpuguy0fbNbqpEqjX9jm5wntc=.8f28862f-2ef9-494e-9e96-e6d1d7d846df@github.com> References: <2w_9Xdlhxsrr3nfcjcwpuguy0fbNbqpEqjX9jm5wntc=.8f28862f-2ef9-494e-9e96-e6d1d7d846df@github.com> Message-ID: On Thu, 3 Dec 2020 12:07:48 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Print Blackhole format > > src/hotspot/share/opto/memnode.cpp line 3471: > >> 3469: st->print(", "); >> 3470: } >> 3471: char buf[128]; > > I'd introduce `PhaseRegAlloc::dump_register(Node*,outputStream*)` overload and put these 3 lines there. > > Then ADLC-generated code can be migrated to it later. That refactoring would make sense, but maybe as separate PR that does everything at once? So that we don't introduce changeset dependencies. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at redhat.com Thu Dec 3 12:36:31 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 3 Dec 2020 13:36:31 +0100 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: <524960ad-9ee4-a47b-deee-187903ec2f84@oracle.com> References: <202ecd3f-b17e-494b-7130-0c1d62e9761c@oracle.com> <6f45ed07-01f6-4731-748d-c780c99cb365@oracle.com> <83c408ae-7a88-d09a-6a88-3dab39a7f4fe@redhat.com> <524960ad-9ee4-a47b-deee-187903ec2f84@oracle.com> Message-ID: On 12/3/20 12:46 PM, Vladimir Ivanov wrote: >> Actually, I don't think we need to ignore receiver in current code. It >> is a left-over from my experiments that were only taking care of >> primitive arguments. Since current code is much more simple, we can just >> blackhole everything. Done in new commits. > > Does it make more sense now to further limit the intrinsic to static > methods only? AFAIU, current intrinsics look back at the original Java method shape. So if we limit intrinsics to static methods, it would require API-breaking changes in JMH (i.e. users who do explicit Blackhole.consume calls), which I hope to avoid. Let's handle instance methods. ...or I misunderstand the suggestion (again). -- Thanks, -Aleksey From tschatzl at openjdk.java.net Thu Dec 3 12:39:55 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 3 Dec 2020 12:39:55 GMT Subject: RFR: 8254733: HotSpot Style Guide should permit using range-based for loops In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 06:37:57 GMT, Kim Barrett wrote: > Please review and vote on this change to the HotSpot Style Guide to > permit the use of range-based `for` loops in HotSpot code. Range-based > `for` is a feature added in C++11. > > This is a modification of the Style Guide, so rough consensus among > the HotSpot Group members is required to make this change. Only Group > members should vote for approval (via the github PR), though reasoned > objectsions or comments from anyone will be considered. A decision on > this proposal will not be made before Monday 7-Dec-2020 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review > process to approve (click on Review Changes > Approve), rather than > sending a "vote: yes" email reply that would be normal for a CFV. > Other responses can still use email of course. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1488 From shade at openjdk.java.net Thu Dec 3 12:43:13 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 12:43:13 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v19] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. > > C1 code is platform-independent, and it adds the new node which is then lowered to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. > > Another exploration in making this less intrusive makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: - Merge branch 'master' into JDK-8252505-blackholes - Handle null-checks in intrinsics to maintain the semantics - Blackhole takes precedence over all other intrinsics - Print Blackhole format - Formatting touchups - Make sure null-checks are handled correctly after blackholed methods - Parallelize and ID the tests properly - Multiple arguments tests - Remodel blackhole hook as fake intrinsic - Remodel CallBlackhole as Blackhole membar - ... and 23 more: https://git.openjdk.java.net/jdk/compare/56b15fbb...1c4b1706 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1203/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=18 Stats: 1443 lines in 31 files changed: 1441 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From vlivanov at openjdk.java.net Thu Dec 3 12:43:13 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 3 Dec 2020 12:43:13 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v17] In-Reply-To: References: <2w_9Xdlhxsrr3nfcjcwpuguy0fbNbqpEqjX9jm5wntc=.8f28862f-2ef9-494e-9e96-e6d1d7d846df@github.com> Message-ID: On Thu, 3 Dec 2020 12:32:26 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/opto/memnode.cpp line 3471: >> >>> 3469: st->print(", "); >>> 3470: } >>> 3471: char buf[128]; >> >> I'd introduce `PhaseRegAlloc::dump_register(Node*,outputStream*)` overload and put these 3 lines there. >> >> Then ADLC-generated code can be migrated to it later. > > That refactoring would make sense, but maybe as separate PR that does everything at once? So that we don't introduce changeset dependencies. I'm fine with it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From vladimir.x.ivanov at oracle.com Thu Dec 3 12:44:40 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 3 Dec 2020 15:44:40 +0300 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v11] In-Reply-To: References: <202ecd3f-b17e-494b-7130-0c1d62e9761c@oracle.com> <6f45ed07-01f6-4731-748d-c780c99cb365@oracle.com> <83c408ae-7a88-d09a-6a88-3dab39a7f4fe@redhat.com> <524960ad-9ee4-a47b-deee-187903ec2f84@oracle.com> Message-ID: <1632e795-16d6-2c0f-e80a-ded2e64f08fc@oracle.com> On 03.12.2020 15:36, Aleksey Shipilev wrote: > On 12/3/20 12:46 PM, Vladimir Ivanov wrote: >>> Actually, I don't think we need to ignore receiver in current code. It >>> is a left-over from my experiments that were only taking care of >>> primitive arguments. Since current code is much more simple, we can just >>> blackhole everything. Done in new commits. >> >> Does it make more sense now to further limit the intrinsic to static >> methods only? > > AFAIU, current intrinsics look back at the original Java method shape. > So if we limit intrinsics to static methods, it would require > API-breaking changes in JMH (i.e. users who do explicit > Blackhole.consume calls), which I hope to avoid. Let's handle instance > methods. You could introduce helper static methods and call them from Blackhole.consume(). That way you will avoid any API-level changes. (That's how intrinsics are usually shaped: there's a Java wrapper exposed to users which does input validation and then calls into intrinsified method which is shaped in such a way to simplify JVM life as much as possible). Best regards, Vladimir Ivanov From vlivanov at openjdk.java.net Thu Dec 3 12:51:00 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 3 Dec 2020 12:51:00 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v19] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 12:43:13 GMT, Aleksey Shipilev wrote: >> JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: >> >> 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. >> 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. >> 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. >> >> Supporting this directly in compilers would improve nanobenchmark fidelity. >> >> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). >> >> Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. >> >> C1 code is platform-independent, and it adds the new node which is then lowered to nothing. >> >> C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. >> >> [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. >> >> [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. >> >> ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. >> >> Another exploration in making this less intrusive makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: > > - Merge branch 'master' into JDK-8252505-blackholes > - Handle null-checks in intrinsics to maintain the semantics > - Blackhole takes precedence over all other intrinsics > - Print Blackhole format > - Formatting touchups > - Make sure null-checks are handled correctly after blackholed methods > - Parallelize and ID the tests properly > - Multiple arguments tests > - Remodel blackhole hook as fake intrinsic > - Remodel CallBlackhole as Blackhole membar > - ... and 23 more: https://git.openjdk.java.net/jdk/compare/56b15fbb...1c4b1706 Looks good! src/hotspot/share/ci/ciMethod.cpp line 160: > 158: > 159: if (CompilerOracle::should_blackhole(h_m) && > 160: _signature->return_type()->basic_type() == T_VOID) { Does it make sense to print a diagnostic message (possibly turned off by `-XX:CompileCommand=quiet`) if a method matches, but has non-void return type? ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1203 From stuefe at openjdk.java.net Thu Dec 3 13:01:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 13:01:55 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 12:26:04 GMT, Thomas Schatzl wrote: >> Not sure what you mean. >> >> PagesizeSet::smallest() returns the smallest page in the page size set, which may be any size, or 0 if empty. >> >> os::_page_sizes should always contain os::vm_page_size(), but that too is not the same as os::min_page_size(). os::min_page_size() is just a constant, equal or smaller than the smallest page size across all platforms. >> >> The naming is confusing, and probably it could be just a static const instead of a function. But I don't want to touch that with this change. But there are probably a number of misuses of os::min_page_size() where the author actually meant os::vm_page_size(). > > Okay, apologies for falling into the mentioned trap. No problem. We should probably improve this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From dnsimon at openjdk.java.net Thu Dec 3 13:15:58 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Thu, 3 Dec 2020 13:15:58 GMT Subject: RFR: 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports [v7] In-Reply-To: References: <8f6cmBnWpoVE29EhxmrpTkXbDidpM19pjEk7xta-tIQ=.a1cd722d-8f46-4370-a721-4d0168e0b48f@github.com> Message-ID: On Thu, 3 Dec 2020 12:05:57 GMT, Stefan Karlsson wrote: >> Doug Simon has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix @requires vm.jvmci > > I've been talking to Doug the last few days and we've settled on this approach that both solves their testing needs, and at the same time satisfy my wish to *not* turn on EnableJVMCI for GCs that don't have fully support for it. Thanks a lot for the diligent review and helpful contributions @stefank ! ------------- PR: https://git.openjdk.java.net/jdk/pull/1423 From stuefe at openjdk.java.net Thu Dec 3 13:17:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 13:17:59 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a set [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 09:50:54 GMT, Thomas Schatzl wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix 32bit issues > > src/hotspot/share/runtime/os.hpp line 103: > >> 101: >> 102: public: >> 103: > > The class PagesizeSet does not need to be public. Would it be okay to leave this public anyway? It is used from the gtests. I could make a fixture class and make it friend of os but that would be similarly ugly. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From hseigel at openjdk.java.net Thu Dec 3 13:17:59 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 3 Dec 2020 13:17:59 GMT Subject: RFR: 8256718: Obsolete the long term deprecated and aliased Trace flags [v3] In-Reply-To: References: Message-ID: On Wed, 2 Dec 2020 23:00:03 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8256718: Obsolete the long term deprecated and aliased Trace flags > > Looks good! > > Thanks, > David Thanks Coleen, Ioi, Serguei, and David for all the reviews. Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From hseigel at openjdk.java.net Thu Dec 3 13:18:01 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 3 Dec 2020 13:18:01 GMT Subject: Integrated: 8256718: Obsolete the long term deprecated and aliased Trace flags In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 21:13:05 GMT, Harold Seigel wrote: > Please review this change to obsolete the deprecated and aliased Trace flags. The now empty aliased_logging_flags support was left in arguments.cpp for use by trace flags that get deprecated and aliased in the future. > > With this change, users will get the following example messages when using these obsolete flags, depending on whether -XX:+... or -XX:-... was specified: > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=info instead. > > VM warning: Ignoring option TraceClassPaths; support was removed in 16.0. Please use -Xlog:class+path=off instead. > > The change was tested with tiers1and 2 on Linux, Windows, and MacOS, and tiers 3-5 on Linux x64 and with JCK lang and vm tests. > > Thanks, Harold This pull request has now been integrated. Changeset: e4497c9e Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/e4497c9e Stats: 326 lines in 23 files changed: 16 ins; 289 del; 21 mod 8256718: Obsolete the long term deprecated and aliased Trace flags Reviewed-by: sspitsyn, iklam, dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1525 From stuefe at openjdk.java.net Thu Dec 3 13:26:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 13:26:55 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 09:59:16 GMT, Thomas Schatzl wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix 32bit issues > > src/hotspot/share/runtime/os.cpp line 1860: > >> 1858: } >> 1859: >> 1860: // returns true if given page size is part of the set > > Same as for `add()`. Not possible, since its used from within os::Linux, os::Aix etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From tschatzl at openjdk.java.net Thu Dec 3 13:42:58 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 3 Dec 2020 13:42:58 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 13:23:41 GMT, Thomas Stuefe wrote: >> src/hotspot/share/runtime/os.cpp line 1860: >> >>> 1858: } >>> 1859: >>> 1860: // returns true if given page size is part of the set >> >> Same as for `add()`. > > Not possible, since its used from within os::Linux, os::Aix etc. Your comment is probably related to the comment of making the `PageSizeSet` class private. Hmm, I did try that out though and compiled locally on Linux.... maybe I messed up somewhere. Leave it public then. Otherwise I am a bit confused how this statement relates to the request to move the code comment to the .hpp file. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From dnsimon at openjdk.java.net Thu Dec 3 13:46:59 2020 From: dnsimon at openjdk.java.net (Doug Simon) Date: Thu, 3 Dec 2020 13:46:59 GMT Subject: Integrated: 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports In-Reply-To: References: Message-ID: On Tue, 24 Nov 2020 23:46:17 GMT, Doug Simon wrote: > A number of jtreg tests require a specific GC. These tests should be ignored when EnableJVMCI is true and the JVMCI compiler does not support the required GC. > > This PR adds `JVMCICompiler.isGCSupported` and makes use of it in `WhiteBox.isGCSupported`. > > Prior to this PR, a test requiring a GC not yet supported by a JVMCI compiler fail as follows: > Error occurred during initialization of VM > JVMCI Compiler does not support selected GC: epsilon gc This pull request has now been integrated. Changeset: fa58671f Author: Doug Simon URL: https://git.openjdk.java.net/jdk/commit/fa58671f Stats: 218 lines in 21 files changed: 177 ins; 21 del; 20 mod 8257020: [JVMCI] enable a JVMCICompiler to specify which GCs it supports Reviewed-by: stefank, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1423 From stuefe at openjdk.java.net Thu Dec 3 13:53:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 13:53:56 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 13:39:47 GMT, Thomas Schatzl wrote: >> Not possible, since its used from within os::Linux, os::Aix etc. > > Your comment is probably related to the comment of making the `PageSizeSet` class private. Hmm, I did try that out though and compiled locally on Linux.... maybe I messed up somewhere. Leave it public then. > > Otherwise I am a bit confused how this statement relates to the request to move the code comment to the .hpp file. You know, communication was a bit easier when we wrote mails :) I thought you meant "make add() private". Sorry for my confusion. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Thu Dec 3 13:59:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 13:59:11 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> > Hi, > > may I please have reviews for the following very small improvement: > > While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: > > size_t os::_page_sizes[os::page_sizes_max]; > > is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. > > Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). > > That has the following advantages: > - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. > - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. > > ----- > > The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. > > > Testing: > - nightlies at SAP > - manual tests with UseLargePages > - the new gtests > - gh actions (with x86 still failing because of unrelated issues) > > Thank you, > > Thomas > > [1] https://bugs.openjdk.java.net/browse/JDK-8243315 > [2] https://bugs.openjdk.java.net/browse/JDK-8256155 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Thomas ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1522/files - new: https://git.openjdk.java.net/jdk/pull/1522/files/9e936bcf..fdae7642 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=01-02 Stats: 24 lines in 3 files changed: 2 ins; 9 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/1522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1522/head:pull/1522 PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Thu Dec 3 13:59:12 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 13:59:12 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 10:20:01 GMT, Thomas Schatzl wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix 32bit issues > > To be really nitpicky: the subject of the PR should be made more specific to mention that the new set is a bitset not just a set. I.e. os::page_sizes has already previously been a set (of integers), so where's the change? :P Hi Thomas, thanks again for the review. I hope I addressed all points. I completely removed the comments from the cpp file and corrected them in the hpp file, which removes the need to keep them in sync. And I rather have them in the hpp file, that makes my IDE happy. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 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 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 sjohanss at openjdk.java.net Thu Dec 3 15:13:57 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 3 Dec 2020 15:13:57 GMT Subject: RFR: 8254699: Suboptimal PreTouchParallelChunkSize defaults and limits [v3] In-Reply-To: References: Message-ID: <5ctYj9iDgI1K4Xy3t6y8jE-K7w4t8K6wJ3XPGGUjkZs=.c32d7f19-13c9-4061-8973-626bffe65590@github.com> On Thu, 3 Dec 2020 10:54:09 GMT, Amit Pawar wrote: >> This PR fixes lower and default value of JVM flag PreTouchParallelChunkSize. Its default value is 1GB and is used by both G1GC and ParallelGC to pretouch the pages. Following test showed that reducing the chunk size improves JVM startup time and GC pause time. >> >> Tests are: (Test machine 2P 64C/128T with 1TB memory) >> 1. JVM startup time test with AdaptiveSizePolicy disabled: Pretouch 1TB of memory with/without transparent large page support and used time command to measure the time taken. >> Command: time ./jdk/bin/java -XX:+AlwaysPreTouch -XX:+-Xmx900g -Xms900g -Xmn800g -XX:SurvivorRatio=400 -Xlog:gc*=debug:file=gc.log -XX:ParallelGCThreads=128 -XX:PreTouchParallelChunkSize= -version >> 2. JVM startup and GC pause time test with AdaptiveSizePolicy enabled: SPECjbb composite run with 1TB heap and transparent large page support was enabled. >> >> Test results are recorded in XL file. [PreTouchParallelChunkSize_TestResults.xlsx](https://github.com/openjdk/jdk/files/5612448/PreTouchParallelChunkSize_TestResults.xlsx) >> >> Test results shows: >> 1. With AdaptiveSizePolicy disabled. >> 1. G1GC improved upto ~14% on large page disabled and ~5% on enabled. >> 2. ParallelGC improved upto ~15% on large page disabled and ~5% on enabled. >> 3. Tests showed improvement from 64KB for default page size and 2MB for lage page size. >> 4. Please check "JVM_Startup_Summary" sheet in XL file for more detail. >> >> 2. SPECjbb composite test with UseAdaptiveSizePolicy + UseLargePages enabled. >> 1. Pretouch takes up-to 30-90% less time for memory range 32MB-4GB. This happens because memory less than 1GB also pretouched with multiple threads. >> 2. Same also helps to bring down GC pause time and this is dependent on memory size. Effect is larger when expansion size is smaller. >> 3. Please check SPECjbb_Summary sheet in XL file for more detail. >> >> Default value of PreTouchParallelChunkSize is changed to 4MB and based your suggestion it can be changed to right value. Please check and review this PR. > > Amit Pawar has updated the pull request incrementally with one additional commit since the last revision: > > PreTouchParallelChunkSize is changed to platform-dependent and default value set to 4M from 1G for Linux only. Looks good. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1503 From stuefe at openjdk.java.net Thu Dec 3 15:22:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 15:22:57 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 08:48:13 GMT, Anton Kozlov wrote: >> The CDS changes in filemap.cpp look reasonable to me. Today this code is used on Windows only, but we are thinking of using it for all platforms (sometime in JDK 17). Do you think `os::protect_memory(base, size, os::MEM_PROT_RWX)` will work on all platforms? > >> Do you think os::protect_memory(base, size, os::MEM_PROT_RWX) will work on all platforms? > > It looks so. Not sure about AIX, it ends up with ::mprotect, at least theoretically should be fine. On Linux and macOS without hardening it should be also OK. Without this patch, we don't support macOS hardened mode at all. But I have some private hacks for CDS with hardening, they reuse some of windows code for reading the archive content instead of mapping, so the future looks even more convenient. Hi Anton, Unfortunately I am not sure anymore that a separate API for reserving code is practical. See https://github.com/openjdk/jdk/pull/1153 (https://bugs.openjdk.java.net/browse/JDK-8256155). People want to be able to use large paged memory for code. Large paged memory gets allocated via os::reserve_memory_special(). Today we already split the API space into two groups: os::reserve_memory() and friends, and os::(reserve|release)_memory_special(). Adding an "executable" API group to that would multiply the number of APIs by two. I am afraid we are stuck with the exec flag on reserve and commit. If you are interested, there was a lively discussion under https://github.com/openjdk/jdk/pull/1161 (https://bugs.openjdk.java.net/browse/JDK-8243315). Among other things it was discussed whether we should get rid of multi-page regions (mixing various page sizes). See Linux::reserve_memory_special_hugetlb_mixed. This would simplify coding. Since I feel bad now for causing you work, I give up any opposition to extending the APIs with the exec parameter. So I had a closer look at your original change again: https://github.com/openjdk/jdk/pull/294/commits/114d9cffd62cab42790b65091648fe75345c4533 I wonder whether we could simplify things, if we let go of the notion that the code heap gets only committed on demand. I do not know how MacOS memory overcommit works in detail. But on Linux, committing memory increases process footprint toward the commit charge limit, and may need swap space, but it does not increase RSS as long as the memory is not touched. I do not know how important on MacOS delaying memory commit really is. If its not important, then we could just do this: reserve_memory : - not executable: mmap MAP_NORESERVE, PROT_NONE - executable: mmap MAP_JIT *without* MAP_NORESERVE, PROT_READ|PROT_WRITE|PROT_EXEC (so its committed and accessible right away) commit_memory - not executable: mmap without MAP_NORESERVE, PROT_READ|PROT_WRITE - executable: (return, nothing to do) uncommit_memory - not executable: mmap MAP_NORESERVE, PROT_NONE - executable: (return, nothing to do, since you indicate that this is that memory does not get returned to the OS immediately) Furthermore, about uncommit: I wonder whether madvice(MADV_FREE) would alone be already sufficient to release the memory. I have no Mac and cannot test this. The range would still be accessible though, but combining that with mprotect(PROT_NONE) should take care of this. Then we could just in general avoid the mmap(MAP_NORESERVE|MAP_FIXED) call. Then we do not need the exec parameter for uncommit at all. > Two functions like reserve_memory and reserve_memory_aligned look excessive. ReservedSpace for some reason tries to use the unaligned version first and when it fails (how should it know the result should be aligned?), fallbacks to reserve_memory_alignment. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/virtualspace.cpp#L227. It will be more straightforward to ask for alignment from the start when it's required. I'm going to make alignment a parameter for reserve_memory as well, with the default value to be "no specific alignment", and to remove reserve_memory_aligned. It will simplify the implementation of reserve_executable_memory with alignment argument, and I hope to propose the suggested refactoring separately from this PR. > This makes sense, but is outside the scope of this RFE. In general, I think in the API we need a separation between page size and alignment (both have been confused in the past, see discussion under https://github.com/openjdk/jdk/pull/1161). But page size is irrelevant for reserve_memory - which reserves per default just with os::vm_page_size() - but for reserve_memory_special we should specify both. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From github.com+71302734+amitdpawar at openjdk.java.net Thu Dec 3 15:27:01 2020 From: github.com+71302734+amitdpawar at openjdk.java.net (Amit Pawar) Date: Thu, 3 Dec 2020 15:27:01 GMT Subject: RFR: 8254699: Suboptimal PreTouchParallelChunkSize defaults and limits [v3] In-Reply-To: <5ctYj9iDgI1K4Xy3t6y8jE-K7w4t8K6wJ3XPGGUjkZs=.c32d7f19-13c9-4061-8973-626bffe65590@github.com> References: <5ctYj9iDgI1K4Xy3t6y8jE-K7w4t8K6wJ3XPGGUjkZs=.c32d7f19-13c9-4061-8973-626bffe65590@github.com> Message-ID: On Thu, 3 Dec 2020 15:11:29 GMT, Stefan Johansson wrote: >> Amit Pawar has updated the pull request incrementally with one additional commit since the last revision: >> >> PreTouchParallelChunkSize is changed to platform-dependent and default value set to 4M from 1G for Linux only. > > Looks good. Thanks for approving and will issue Integrate command now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1503 From shade at openjdk.java.net Thu Dec 3 15:55:18 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 15:55:18 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v20] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > Current prototype is for initial approach review and early testing. I am open for suggestions how to make it simpler; not that I haven't tried, but it is likely there is something I am overlooking here. > > C1 code is platform-independent, and it adds the new node which is then lowered to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the fourth attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. This seems to require the least fiddling with C2 internals. > > Another exploration in making this less intrusive makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision: - Print warning on non-void blackhole methods - Fix release build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/1c4b1706..7f146f11 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=18-19 Stats: 91 lines in 4 files changed: 88 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Thu Dec 3 15:55:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 15:55:20 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v19] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 12:48:06 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: >> >> - Merge branch 'master' into JDK-8252505-blackholes >> - Handle null-checks in intrinsics to maintain the semantics >> - Blackhole takes precedence over all other intrinsics >> - Print Blackhole format >> - Formatting touchups >> - Make sure null-checks are handled correctly after blackholed methods >> - Parallelize and ID the tests properly >> - Multiple arguments tests >> - Remodel blackhole hook as fake intrinsic >> - Remodel CallBlackhole as Blackhole membar >> - ... and 23 more: https://git.openjdk.java.net/jdk/compare/56b15fbb...1c4b1706 > > src/hotspot/share/ci/ciMethod.cpp line 160: > >> 158: >> 159: if (CompilerOracle::should_blackhole(h_m) && >> 160: _signature->return_type()->basic_type() == T_VOID) { > > Does it make sense to print a diagnostic message (possibly turned off by `-XX:CompileCommand=quiet`) if a method matches, but has non-void return type? Yes, it does make sense. The check should be moved to `CompilerOracle` to make it cleaner, moved. Added the test a well. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 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 akozlov at openjdk.java.net Thu Dec 3 17:23:55 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 3 Dec 2020 17:23:55 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 15:19:51 GMT, Thomas Stuefe wrote: >>> Do you think os::protect_memory(base, size, os::MEM_PROT_RWX) will work on all platforms? >> >> It looks so. Not sure about AIX, it ends up with ::mprotect, at least theoretically should be fine. On Linux and macOS without hardening it should be also OK. Without this patch, we don't support macOS hardened mode at all. But I have some private hacks for CDS with hardening, they reuse some of windows code for reading the archive content instead of mapping, so the future looks even more convenient. > > Hi Anton, > > Unfortunately I am not sure anymore that a separate API for reserving code is practical. See https://github.com/openjdk/jdk/pull/1153 (https://bugs.openjdk.java.net/browse/JDK-8256155). People want to be able to use large paged memory for code. Large paged memory gets allocated via os::reserve_memory_special(). > > Today we already split the API space into two groups: os::reserve_memory() and friends, and os::(reserve|release)_memory_special(). Adding an "executable" API group to that would multiply the number of APIs by two. I am afraid we are stuck with the exec flag on reserve and commit. > > If you are interested, there was a lively discussion under https://github.com/openjdk/jdk/pull/1161 (https://bugs.openjdk.java.net/browse/JDK-8243315). Among other things it was discussed whether we should get rid of multi-page regions (mixing various page sizes). See Linux::reserve_memory_special_hugetlb_mixed. This would simplify coding. > > Since I feel bad now for causing you work, I give up any opposition to extending the APIs with the exec parameter. So I had a closer look at your original change again: > > https://github.com/openjdk/jdk/pull/294/commits/114d9cffd62cab42790b65091648fe75345c4533 > > I wonder whether we could simplify things, if we let go of the notion that the code heap gets only committed on demand. I do not know how MacOS memory overcommit works in detail. But on Linux, committing memory increases process footprint toward the commit charge limit, and may need swap space, but it does not increase RSS as long as the memory is not touched. I do not know how important on MacOS delaying memory commit really is. If its not important, then we could just do this: > > reserve_memory : > - not executable: mmap MAP_NORESERVE, PROT_NONE > - executable: mmap MAP_JIT *without* MAP_NORESERVE, PROT_READ|PROT_WRITE|PROT_EXEC (so its committed and accessible right away) > > commit_memory > - not executable: mmap without MAP_NORESERVE, PROT_READ|PROT_WRITE > - executable: (return, nothing to do) > > uncommit_memory > - not executable: mmap MAP_NORESERVE, PROT_NONE > - executable: (return, nothing to do, since you indicate that this is that memory does not get returned to the OS immediately) > > Furthermore, about uncommit: I wonder whether madvice(MADV_FREE) would alone be already sufficient to release the memory. I have no Mac and cannot test this. The range would still be accessible though, but combining that with mprotect(PROT_NONE) should take care of this. Then we could just in general avoid the mmap(MAP_NORESERVE|MAP_FIXED) call. Then we do not need the exec parameter for uncommit at all. > >> Two functions like reserve_memory and reserve_memory_aligned look excessive. ReservedSpace for some reason tries to use the unaligned version first and when it fails (how should it know the result should be aligned?), fallbacks to reserve_memory_alignment. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/virtualspace.cpp#L227. It will be more straightforward to ask for alignment from the start when it's required. I'm going to make alignment a parameter for reserve_memory as well, with the default value to be "no specific alignment", and to remove reserve_memory_aligned. It will simplify the implementation of reserve_executable_memory with alignment argument, and I hope to propose the suggested refactoring separately from this PR. >> > > This makes sense, but is outside the scope of this RFE. > > In general, I think in the API we need a separation between page size and alignment (both have been confused in the past, see discussion under https://github.com/openjdk/jdk/pull/1161). But page size is irrelevant for reserve_memory - which reserves per default just with os::vm_page_size() - but for reserve_memory_special we should specify both. > > Cheers, Thomas > Unfortunately I am not sure anymore that a separate API for reserving code is practical. See #1153 (https://bugs.openjdk.java.net/browse/JDK-8256155). People want to be able to use large paged memory for code. Large paged memory gets allocated via os::reserve_memory_special(). I think os::reserve_memory_special is substantially different, it does not allow commit/uncommit. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/virtualspace.cpp#L170 basically defines it this way. I'm mostly concerned with interface for executable memory with commit. > Today we already split the API space into two groups: os::reserve_memory() and friends, and os::(reserve|release)_memory_special(). Adding an "executable" API group to that would multiply the number of APIs by two. I am afraid we are stuck with the exec flag on reserve and commit. It adds another API. And it's interesting that the only user of executable_memory are ReservedSpace and VirtualSpace. Removing executable argument from the rest of cases seems beneficial. I find it in somewhat more strict comparing with a boolean flag. But it's not really required for MAP_JIT. >From interface implementation point of view, it's convenient to have a single interface with as many parameters as possible, even excessive and unused. It will enable tricky cases handling inside the implementation. executable_memory API is artificial separation in this case. It will be necessary if some combination of parameters are impossible to implement, but it's not our case, so we can live without it. > I wonder whether we could simplify things, if we let go of the notion that the code heap gets only committed on demand. I'm not sure, what is the aim of the simplification below? Now access to uncommitted memory will cause a trap, just like on other platforms. > I do not know how MacOS memory overcommit works in detail. But on Linux, committing memory increases process footprint toward the commit charge limit, and may need swap space, but it does not increase RSS as long as the memory is not touched. I do not know how important on MacOS delaying memory commit really is. If its not important, then we could just do this: > > reserve_memory : > - not executable: mmap MAP_NORESERVE, PROT_NONE > - executable: mmap MAP_JIT _without_ MAP_NORESERVE, PROT_READ|PROT_WRITE|PROT_EXEC (so its committed and accessible right away) > > commit_memory > - not executable: mmap without MAP_NORESERVE, PROT_READ|PROT_WRITE > - executable: (return, nothing to do) > > uncommit_memory > - not executable: mmap MAP_NORESERVE, PROT_NONE > - executable: (return, nothing to do, since you indicate that this is that memory does not get returned to the OS immediately) > > Furthermore, about uncommit: I wonder whether madvice(MADV_FREE) would alone be already sufficient to release the memory. I have no Mac and cannot test this. The range would still be accessible though, but combining that with mprotect(PROT_NONE) should take care of this. Then we could just in general avoid the mmap(MAP_NORESERVE|MAP_FIXED) call. Then we do not need the exec parameter for uncommit at all. madvise(FREE) is not sufficient unfortunately. For executable memory, it's best we can do. But we should not use it for regular memory. > In general, I think in the API we need a separation between page size and alignment (both have been confused in the past, see discussion under #1161). But page size is irrelevant for reserve_memory - which reserves per default just with os::vm_page_size() - but for reserve_memory_special we should specify both. If we talk about reveting to 114d9cf, there is no change beyond extra boolean argument, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/294 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 github.com+168222+mgkwill at openjdk.java.net Thu Dec 3 17:57:56 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 3 Dec 2020 17:57:56 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v2] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Thu, 3 Dec 2020 13:56:03 GMT, Thomas Stuefe wrote: >> To be really nitpicky: the subject of the PR should be made more specific to mention that the new set is a bitset not just a set. I.e. os::page_sizes has already previously been a set (of integers), so where's the change? :P > > Hi Thomas, > > thanks again for the review. I hope I addressed all points. I completely removed the comments from the cpp file and corrected them in the hpp file, which removes the need to keep them in sync. And I rather have them in the hpp file, that makes my IDE happy. > > Cheers, Thomas +1 on the general thrust of this change. I'd be happy to incorporate into https://github.com/openjdk/jdk/pull/1153 & JDK-8256155 [1] if they are approved. [1] https://bugs.openjdk.java.net/browse/JDK-8256155 ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From github.com+168222+mgkwill at openjdk.java.net Thu Dec 3 18:05:59 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 3 Dec 2020 18:05:59 GMT Subject: RFR: 8256155: 2M large pages for code when LargePageSizeInBytes is set to 1G for heap [v3] In-Reply-To: References: <-xtX9qSJHuD-qfp52XPToKhkl1HypRmNFHCJaupaync=.99285cd9-69a6-42cd-84b4-3c87fefc2cc5@github.com> <8f-BJdFip5yf0Rv4uw-qcXVk2uM3Lb6Hrq9VPR6UzF4=.04966477-8834-4fb9-aa77-8da86f104176@github.com> Message-ID: On Sun, 29 Nov 2020 08:17:09 GMT, Thomas Stuefe wrote: >> I honestly don't even know why we have UseSHM. Seems redundant, and since it uses SystemV shared memory which has a different semantics from mmap, it is subtly broken in a number of places (eg https://bugs.openjdk.java.net/browse/JDK-8257040 or https://bugs.openjdk.java.net/browse/JDK-8257041). > > One thing I stumbled upon while looking at this code is why the CodeHeap always wants to have at least 8 pages covering its range: > > // If large page support is enabled, align code heaps according to large > // page size to make sure that code cache is covered by large pages. > const size_t alignment = MAX2(page_size(false, 8), (size_t) os::vm_allocation_granularity()); > > which means that for a wish pagesize of 1G, the code cache would have to cover at least 8G. I am not even sure this is possible, isn't it limited to 4G? > > Anyway, they don't uncommit. And the comment in codecache.cpp indicates this is to be able to step-wise commit, but with huge pages the space is committed right from the start anyway. So I do not see what good these 8 pages do. If we allowed the CodeCache to use just one page, it could be 1G in size and use a single 1G page. > > Note that there are similar min_page_size requests in GC, but I did not look closer into them. > > Also, this does not take away the usefulness of this proposal. Working on addressing comments in the code on this PR. Should have a tested change pushed later today and replies to comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From stuefe at openjdk.java.net Thu Dec 3 18:13:01 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 18:13:01 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 17:21:38 GMT, Anton Kozlov wrote: > > Unfortunately I am not sure anymore that a separate API for reserving code is practical. See #1153 (https://bugs.openjdk.java.net/browse/JDK-8256155). People want to be able to use large paged memory for code. Large paged memory gets allocated via os::reserve_memory_special(). > > I think os::reserve_memory_special is substantially different, it does not allow commit/uncommit. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/virtualspace.cpp#L170 basically defines it this way. I'm mostly concerned with interface for executable memory with commit. That was not my point. So you introduce os::reserve_executable_memory() - a new API which allocates small paged executable memory. If you want large paged executable memory you still need to call os::reserve_memory_special, which still needs to retain its executable parameter. So this new API does not cover all use cases for executable. Unless you also add a new os::reserve_executable_memory_special(). This is what I meant with doubling the API numbers. > And it's interesting that the only user of executable_memory are ReservedSpace and VirtualSpace. Removing executable argument from the rest of cases seems beneficial. I find it in somewhat more strict comparing with a boolean flag. But it's not really required for MAP_JIT. I'd like to keep the os::xxx APIs indepent from their use cases in ReservedSpace. In other words, they should stay consistent in themselves. > > From interface implementation point of view, it's convenient to have a single interface with as many parameters as possible, even excessive and unused. It will enable tricky cases handling inside the implementation. executable_memory API is artificial separation in this case. It will be necessary if some combination of parameters are impossible to implement, but it's not our case, so we can live without it. > > > I wonder whether we could simplify things, if we let go of the notion that the code heap gets only committed on demand. > > I'm not sure, what is the aim of the simplification below? To remove the coding depending on executable-ness from commit and uncommit. > Now access to uncommitted memory will cause a trap, just like on other platforms. Sorry, you lost me there. Where would I get a trap? My point was, for executable=true: - on reserve, commit executable memory right away instead of on-demand committing later - on commit and uncommit, just do nothing On commit, the OS makes sure the memory is underlayed with swap space. The memory also counts toward the commit charge of the process. What effects this has in practice highly depends on the OS. Hence my question. For the code heap, it may not matter that much. And ignoring uncommit for executable memory was based on your observation that it did not show observable effects anyway for you, and that code heap does not shrink. > > > I do not know how MacOS memory overcommit works in detail. But on Linux, committing memory increases process footprint toward the commit charge limit, and may need swap space, but it does not increase RSS as long as the memory is not touched. I do not know how important on MacOS delaying memory commit really is. If its not important, then we could just do this: > > reserve_memory : > > > > * not executable: mmap MAP_NORESERVE, PROT_NONE > > * executable: mmap MAP_JIT _without_ MAP_NORESERVE, PROT_READ|PROT_WRITE|PROT_EXEC (so its committed and accessible right away) > > > > commit_memory > > > > * not executable: mmap without MAP_NORESERVE, PROT_READ|PROT_WRITE > > * executable: (return, nothing to do) > > > > uncommit_memory > > > > * not executable: mmap MAP_NORESERVE, PROT_NONE > > * executable: (return, nothing to do, since you indicate that this is that memory does not get returned to the OS immediately) > > > Furthermore, about uncommit: I wonder whether madvice(MADV_FREE) would alone be already sufficient to release the memory. I have no Mac and cannot test this. The range would still be accessible though, but combining that with mprotect(PROT_NONE) should take care of this. Then we could just in general avoid the mmap(MAP_NORESERVE|MAP_FIXED) call. Then we do not need the exec parameter for uncommit at all. > > madvise(FREE) is not sufficient unfortunately. For executable memory, it's best we can do. But we should not use it for regular memory. How so? What is the difference? > > > In general, I think in the API we need a separation between page size and alignment (both have been confused in the past, see discussion under #1161). But page size is irrelevant for reserve_memory - which reserves per default just with os::vm_page_size() - but for reserve_memory_special we should specify both. > > If we talk about reveting to [114d9cf](https://github.com/openjdk/jdk/commit/114d9cffd62cab42790b65091648fe75345c4533), there is no change beyond extra boolean argument, right? Yes, I think so. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 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 thomas.stuefe at gmail.com Thu Dec 3 18:48:35 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 3 Dec 2020 19:48:35 +0100 Subject: Linux large pages: why do we have UseSHM? Message-ID: Hi, I wonder why we support two different ways (discounting THPs) to allocate huge pages on Linux. We support allocating huge pages both via System V shm APIs (UseSHM) and via the "newer" mmap Posix APIs (UseHugeTLBFS). The latter is default for +UseLargePages. I do not see a practical difference beside the fact that: - System V shm API is slightly fussier to use (eg no partial unmap possible) - it requires kernel.shmmax to be correctly set, in addition to the vm.nr_xxx_hugepages - it requires more user permissions But in the end, we end up with kernel huge pages, one way or the other. Both give access to 2M and 1G pages. I looked through mailing list archives and bug descriptions, but beyond vague mentionings of "one way could fail, then try the other" I did not find anything. I must be missing something. Does anyone have any closer knowledge about this? Thank you! Thomas From shade at openjdk.java.net Thu Dec 3 18:49:11 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 3 Dec 2020 18:49:11 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v21] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the final attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. > > The fourth, and hopefully final attempt is in this PR. It makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Fix C2 _blackhole: polls arguments count from caller, not callee ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/7f146f11..3387ad8c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=20 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=19-20 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From github.com+71302734+amitdpawar at openjdk.java.net Thu Dec 3 19:07:55 2020 From: github.com+71302734+amitdpawar at openjdk.java.net (Amit Pawar) Date: Thu, 3 Dec 2020 19:07:55 GMT Subject: Integrated: 8254699: Suboptimal PreTouchParallelChunkSize defaults and limits In-Reply-To: References: Message-ID: On Sun, 29 Nov 2020 16:47:58 GMT, Amit Pawar wrote: > This PR fixes lower and default value of JVM flag PreTouchParallelChunkSize. Its default value is 1GB and is used by both G1GC and ParallelGC to pretouch the pages. Following test showed that reducing the chunk size improves JVM startup time and GC pause time. > > Tests are: (Test machine 2P 64C/128T with 1TB memory) > 1. JVM startup time test with AdaptiveSizePolicy disabled: Pretouch 1TB of memory with/without transparent large page support and used time command to measure the time taken. > Command: time ./jdk/bin/java -XX:+AlwaysPreTouch -XX:+-Xmx900g -Xms900g -Xmn800g -XX:SurvivorRatio=400 -Xlog:gc*=debug:file=gc.log -XX:ParallelGCThreads=128 -XX:PreTouchParallelChunkSize= -version > 2. JVM startup and GC pause time test with AdaptiveSizePolicy enabled: SPECjbb composite run with 1TB heap and transparent large page support was enabled. > > Test results are recorded in XL file. [PreTouchParallelChunkSize_TestResults.xlsx](https://github.com/openjdk/jdk/files/5612448/PreTouchParallelChunkSize_TestResults.xlsx) > > Test results shows: > 1. With AdaptiveSizePolicy disabled. > 1. G1GC improved upto ~14% on large page disabled and ~5% on enabled. > 2. ParallelGC improved upto ~15% on large page disabled and ~5% on enabled. > 3. Tests showed improvement from 64KB for default page size and 2MB for lage page size. > 4. Please check "JVM_Startup_Summary" sheet in XL file for more detail. > > 2. SPECjbb composite test with UseAdaptiveSizePolicy + UseLargePages enabled. > 1. Pretouch takes up-to 30-90% less time for memory range 32MB-4GB. This happens because memory less than 1GB also pretouched with multiple threads. > 2. Same also helps to bring down GC pause time and this is dependent on memory size. Effect is larger when expansion size is smaller. > 3. Please check SPECjbb_Summary sheet in XL file for more detail. > > Default value of PreTouchParallelChunkSize is changed to 4MB and based your suggestion it can be changed to right value. Please check and review this PR. This pull request has now been integrated. Changeset: 805d0581 Author: Amit Pawar Committer: Thomas Schatzl URL: https://git.openjdk.java.net/jdk/commit/805d0581 Stats: 6 lines in 5 files changed: 4 ins; 0 del; 2 mod 8254699: Suboptimal PreTouchParallelChunkSize defaults and limits Reviewed-by: tschatzl, sjohanss ------------- PR: https://git.openjdk.java.net/jdk/pull/1503 From stuefe at openjdk.java.net Thu Dec 3 20:26:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 3 Dec 2020 20:26:59 GMT Subject: RFR: 8243315: ParallelScavengeHeap::initialize() passes GenAlignment as page size to os::trace_page_sizes instead of actual page size In-Reply-To: References: <0t69lhO_zHj_sg0_doBgHyv5Fpu6Y2OuZsza1NsyE6A=.2a972bf7-5e12-4ce3-9ca2-b2add68d07c5@github.com> <3ZpyM1gAZ0HeDdWd4_Ps98de3IKXvCowyDeFCaso97U=.9694feb3-82d5-4da6-bda6-5431e3dd94d1@github.com> <_imjzmFgjMEABYlW2LnfuyJNqyil1kBrX_A Fmq_LBlc=.7b70d4bd-6257-4436-81ee-19b40953ed10@github.com> Message-ID: <_qRBxRvNC_w-dIJBHQuQ1g6u0FglanBbNaryxqtCiF8=.ce17ac67-08ba-4b2a-a360-704fca1f9c94@github.com> On Thu, 26 Nov 2020 08:48:43 GMT, Stefan Johansson wrote: >> Hi Thomas, >> >> first off, the last thing I want is for matters to become more complicated. God no. >> >> Today the virtual memory layer is inconsistent and undocumented and has subtle bugs. Among other things this means that PRs can take forever to discuss, which I guess is frustrating for newcomers. Or if they are pushed they can cause a lot of cleanup work afterwards. >> >> Just attempting to write a consistent API description of the virtual memory layer, parameters expected behavior etc, is very difficult. I know since I tried. And that is a bad sign. Tests are missing too, since what you cannot describe you cannot test. For an interesting example, see JDK-8255978. That bug had been in there since at least JDK8. >> >> One problem I see reoccurring with these APIs is that meta information about a reservation are needed later, but are lost. Many examples: >> - the exact flags with which a mapping was established (exec or not, MAP_JIT, etc) >> - which API has been used (AIX) >> - what the page sizes were at reservation time >> - whether the area had been stitched together with multiple mappings or a single one >> .. etc. >> >> The code then often tries to guess these information from "circumstantial evidence", which introduces lots of strange dependencies and makes the coding fragile. ReservedSpace::actual_page_size() in this patch is one example. >> >> A better way would be to have these information kept somewhere. Ideally, the OS would do this and I could ask it for properties of a memory mapping. In reality, the OS is not so forthcoming. So we should keep these information ourselves. >> >> One of these information is the page sizes of a region. In that light you can see my proposal. I did not propose to change a single atom about how os::reserve_memory_special() works. I just proposed for it to just be honest and return information about what it did. So that this information could be kept inside ReservedSpace and reused instead of guessed. And since the reality today is that os::reserve_memory_special() can reserve multiple page sizes, a correct implementation would have to reflect that or be wrong. >> >> You are right, reporting multiple page sizes is more difficult than just one. But even more complex is what we have today, where a mapping can have multiple page sizes but this is not acknowledged by upper layers. In this case, we have ReservedSpace::actual_page_size() which plain cannot be implemented correctly. >> >> I am fine with the idea of restricting RS to just one page size. But then lets do that and get rid of mixed TLBFS reservation (and whatever Windows does, they may be doing something similar). We also should specify the page size as an explicit parameter and not confuse this with the alignment. >> >>> That code may be an artifact of 32 bit machines from 10+ years ago where address space fragmentation has been a real concern (typically Windows). Or RAM sizes were measured in hundreds of MB instead of GBs where (on Linux) pre-reserving hundreds of MB for huge pages is/has been an issue. >> >> I am not sure what coding you refer to. >> >>> and that Intel wants to further complicate it and add 2M pages, means we have a need here. >> >>> The JDK-8256155 (Intel) CR does not state that requirement. Imho it only says that the author wants to use (any and all) configured pages for different reserved spaces. E.g. the machine has (on x64, to simplify the case) configured: 10 1G pages 1000 2M pages so the heap should use the 1G pages (assuming it's less than 10G), other reservations like code heap should first use the 50 2M pages before falling back to other page sizes to better use available TLB cache entries. I would prefer if we do not overcomplicate the requirements :) >> >> Flexible stitching would have one advantage though, in that a huge page pool could be better used. In your example, if someone starts with a 12G heap, it would fail since no pool indicidually is large enough, but combining different page sizes would work. >> >> I wont insist on this. As I wrote, I am fine with one-pagesize-per-mapping if we can arrive there. >> >>> Also probably this should be asked and followed up in the correct review thread. >> >> Since it was relevant to this PR, I did mention it here. >> >>> I'd like a simpler, maybe less flexible but understandable by mere mortals OS layer :) lower layer that does not make upper layers too complicated. >> >> I do too. >> >>>> >>> This is a kind of one-sided argument, taking only commit into account. Since actually giving back memory is expected nowadays, taking care of different random page sizes is complicated. E.g. when implementing G1's region memory management (in 8u40) the decision to only support a single page size for every one of its GC data structures has been a conscious one - because the complexity overhead did not justify the gains. Nobody complained yet. >> >> I may be missing something here, but is hupe paged space not pinned? How can this be uncommitted? Okay yes, if it can be uncommitted, multiple page sizes should be avoided. >> >>>> For example, were I to re-introduce large pages for Metaspace, I would like to have the luxury of just calling os::reserve_memory_special() without having to think about specific geometry - if the space is large enough for large pages, it should stitch the area together as best as it can. >> >>> That's true, but that Metaspace layer then needs to be aware of multiple page sizes when uncommitting, and (presumably) tracking liveness on the lowest granularity anyway. Which does not make the code easier. >> >> See above. I was under the assumption that uncommit goes out of the window the moment you choose explicit large pages. >> >>> Thanks, Thomas >> >> Thanks, Thomas > > You are correct that explicit huge pages are pinned and of course there might be situations where it would be beneficial to do the stitching, but I think the maintenance cost will be significantly higher. It sound like you would prefer a simpler model as well and int would certainly be interesting to see if there are any problems connected to getting rid of the mixed mappings we have today. > > I also agree that we should do better book keeping since it is so hard to get the information later on. Hi guys, gentle ping. I know we are all busy with the impending code freeze :) I am fine with removing the ability to reserve space with multiple page sizes. But that is something I cannot drive - probably someone at Oracle should, since it has repercussions for GC and for backward compatibility. Might also take a bit longer. Meanwhile, we still have the new ReservedSpace::actual_page_size(), which is subtly broken and will be more so once JDK-8234930 is implemented. IIUC you did not like the proposal of making reserve_space_special() return information about the reserved page sizes. That's totally fine for me, but have we decided on how to deal with this instead? Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1161 From akozlov at openjdk.java.net Thu Dec 3 20:28:55 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 3 Dec 2020 20:28:55 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 18:10:18 GMT, Thomas Stuefe wrote: >>> Unfortunately I am not sure anymore that a separate API for reserving code is practical. See #1153 (https://bugs.openjdk.java.net/browse/JDK-8256155). People want to be able to use large paged memory for code. Large paged memory gets allocated via os::reserve_memory_special(). >> >> I think os::reserve_memory_special is substantially different, it does not allow commit/uncommit. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/virtualspace.cpp#L170 basically defines it this way. I'm mostly concerned with interface for executable memory with commit. >> >>> Today we already split the API space into two groups: os::reserve_memory() and friends, and os::(reserve|release)_memory_special(). Adding an "executable" API group to that would multiply the number of APIs by two. I am afraid we are stuck with the exec flag on reserve and commit. >> >> It adds another API. And it's interesting that the only user of executable_memory are ReservedSpace and VirtualSpace. Removing executable argument from the rest of cases seems beneficial. I find it in somewhat more strict comparing with a boolean flag. But it's not really required for MAP_JIT. >> >> From interface implementation point of view, it's convenient to have a single interface with as many parameters as possible, even excessive and unused. It will enable tricky cases handling inside the implementation. executable_memory API is artificial separation in this case. It will be necessary if some combination of parameters are impossible to implement, but it's not our case, so we can live without it. >> >>> I wonder whether we could simplify things, if we let go of the notion that the code heap gets only committed on demand. >> >> I'm not sure, what is the aim of the simplification below? Now access to uncommitted memory will cause a trap, just like on other platforms. >> >>> I do not know how MacOS memory overcommit works in detail. But on Linux, committing memory increases process footprint toward the commit charge limit, and may need swap space, but it does not increase RSS as long as the memory is not touched. I do not know how important on MacOS delaying memory commit really is. If its not important, then we could just do this: >>> >>> reserve_memory : >>> - not executable: mmap MAP_NORESERVE, PROT_NONE >>> - executable: mmap MAP_JIT _without_ MAP_NORESERVE, PROT_READ|PROT_WRITE|PROT_EXEC (so its committed and accessible right away) >>> >>> commit_memory >>> - not executable: mmap without MAP_NORESERVE, PROT_READ|PROT_WRITE >>> - executable: (return, nothing to do) >>> >>> uncommit_memory >>> - not executable: mmap MAP_NORESERVE, PROT_NONE >>> - executable: (return, nothing to do, since you indicate that this is that memory does not get returned to the OS immediately) >>> >> >>> Furthermore, about uncommit: I wonder whether madvice(MADV_FREE) would alone be already sufficient to release the memory. I have no Mac and cannot test this. The range would still be accessible though, but combining that with mprotect(PROT_NONE) should take care of this. Then we could just in general avoid the mmap(MAP_NORESERVE|MAP_FIXED) call. Then we do not need the exec parameter for uncommit at all. >> >> madvise(FREE) is not sufficient unfortunately. For executable memory, it's best we can do. But we should not use it for regular memory. >> >>> In general, I think in the API we need a separation between page size and alignment (both have been confused in the past, see discussion under #1161). But page size is irrelevant for reserve_memory - which reserves per default just with os::vm_page_size() - but for reserve_memory_special we should specify both. >> >> If we talk about reveting to 114d9cf, there is no change beyond extra boolean argument, right? > >> > Unfortunately I am not sure anymore that a separate API for reserving code is practical. See #1153 (https://bugs.openjdk.java.net/browse/JDK-8256155). People want to be able to use large paged memory for code. Large paged memory gets allocated via os::reserve_memory_special(). >> >> I think os::reserve_memory_special is substantially different, it does not allow commit/uncommit. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/memory/virtualspace.cpp#L170 basically defines it this way. I'm mostly concerned with interface for executable memory with commit. > > That was not my point. > > So you introduce os::reserve_executable_memory() - a new API which allocates small paged executable memory. If you want large paged executable memory you still need to call os::reserve_memory_special, which still needs to retain its executable parameter. So this new API does not cover all use cases for executable. Unless you also add a new os::reserve_executable_memory_special(). This is what I meant with doubling the API numbers. > >> And it's interesting that the only user of executable_memory are ReservedSpace and VirtualSpace. Removing executable argument from the rest of cases seems beneficial. I find it in somewhat more strict comparing with a boolean flag. But it's not really required for MAP_JIT. > > I'd like to keep the os::xxx APIs indepent from their use cases in ReservedSpace. In other words, they should stay consistent in themselves. > >> >> From interface implementation point of view, it's convenient to have a single interface with as many parameters as possible, even excessive and unused. It will enable tricky cases handling inside the implementation. executable_memory API is artificial separation in this case. It will be necessary if some combination of parameters are impossible to implement, but it's not our case, so we can live without it. >> >> > I wonder whether we could simplify things, if we let go of the notion that the code heap gets only committed on demand. >> >> I'm not sure, what is the aim of the simplification below? > > To remove the coding depending on executable-ness from commit and uncommit. > >> Now access to uncommitted memory will cause a trap, just like on other platforms. > > Sorry, you lost me there. Where would I get a trap? > > My point was, for executable=true: > - on reserve, commit executable memory right away instead of on-demand committing later > - on commit and uncommit, just do nothing > > On commit, the OS makes sure the memory is underlayed with swap space. The memory also counts toward the commit charge of the process. What effects this has in practice highly depends on the OS. Hence my question. For the code heap, it may not matter that much. > > And ignoring uncommit for executable memory was based on your observation that it did not show observable effects anyway for you, and that code heap does not shrink. > >> >> > I do not know how MacOS memory overcommit works in detail. But on Linux, committing memory increases process footprint toward the commit charge limit, and may need swap space, but it does not increase RSS as long as the memory is not touched. I do not know how important on MacOS delaying memory commit really is. If its not important, then we could just do this: >> > reserve_memory : >> > >> > * not executable: mmap MAP_NORESERVE, PROT_NONE >> > * executable: mmap MAP_JIT _without_ MAP_NORESERVE, PROT_READ|PROT_WRITE|PROT_EXEC (so its committed and accessible right away) >> > >> > commit_memory >> > >> > * not executable: mmap without MAP_NORESERVE, PROT_READ|PROT_WRITE >> > * executable: (return, nothing to do) >> > >> > uncommit_memory >> > >> > * not executable: mmap MAP_NORESERVE, PROT_NONE >> > * executable: (return, nothing to do, since you indicate that this is that memory does not get returned to the OS immediately) >> >> > Furthermore, about uncommit: I wonder whether madvice(MADV_FREE) would alone be already sufficient to release the memory. I have no Mac and cannot test this. The range would still be accessible though, but combining that with mprotect(PROT_NONE) should take care of this. Then we could just in general avoid the mmap(MAP_NORESERVE|MAP_FIXED) call. Then we do not need the exec parameter for uncommit at all. >> >> madvise(FREE) is not sufficient unfortunately. For executable memory, it's best we can do. But we should not use it for regular memory. > > How so? What is the difference? > >> >> > In general, I think in the API we need a separation between page size and alignment (both have been confused in the past, see discussion under #1161). But page size is irrelevant for reserve_memory - which reserves per default just with os::vm_page_size() - but for reserve_memory_special we should specify both. >> >> If we talk about reveting to [114d9cf](https://github.com/openjdk/jdk/commit/114d9cffd62cab42790b65091648fe75345c4533), there is no change beyond extra boolean argument, right? > > Yes, I think so. > > > reserve_memory : > > > > > > * not executable: mmap MAP_NORESERVE, PROT_NONE > > > * executable: mmap MAP_JIT _without_ MAP_NORESERVE, PROT_READ|PROT_WRITE|PROT_EXEC (so its committed and accessible right away) > > > > > > commit_memory > > > > > > * not executable: mmap without MAP_NORESERVE, PROT_READ|PROT_WRITE > > > * executable: (return, nothing to do) > > > > > > uncommit_memory > > > > > > * not executable: mmap MAP_NORESERVE, PROT_NONE > > > * executable: (return, nothing to do, since you indicate that this is that memory does not get returned to the OS immediately) > > > > > I'm not sure, what is the aim of the simplification [above]? > > To remove the coding depending on executable-ness from commit and uncommit. Sorry, how can e.g uncommit choose executable or not-executable case, if executable parameter is not provided? --- > > Now access to uncommitted memory will cause a trap, just like on other platforms. > > Sorry, you lost me there. Where would I get a trap? I mean, after a call to pd_uncommit_memory on linux the memory mprotected with PROT_NONE. Any access to that region will generate a signal. --- > > My point was, for executable=true: > > * on reserve, commit executable memory right away instead of on-demand committing later > * on commit and uncommit, just do nothing As far as I understand you propose to remove lines 2010 - 2014 https://github.com/openjdk/jdk/blob/114d9cffd62cab42790b65091648fe75345c4533/src/hotspot/os/bsd/os_bsd.cpp#L2010 but later you suggest (in different context, but the statement is correct) > The range would still be accessible though, but combining that with mprotect(PROT_NONE) should take care of this The current implementation does mprotect(NONE). madvice(FREE) is not accounted immediately, but this hint is better than nothing. --- > > > Furthermore, about uncommit: I wonder whether madvice(MADV_FREE) would alone be already sufficient to release the memory. I have no Mac and cannot test this. The range would still be accessible though, but combining that with mprotect(PROT_NONE) should take care of this. Then we could just in general avoid the mmap(MAP_NORESERVE|MAP_FIXED) call. Then we do not need the exec parameter for uncommit at all. > > > > > > madvise(FREE) is not sufficient unfortunately. For executable memory, it's best we can do. But we should not use it for regular memory. > > How so? What is the difference? madvise is really a hint and doesn't have exact effect as a real uncommit. A real, immediately accountable uncommit is a https://github.com/openjdk/jdk/blob/114d9cffd62cab42790b65091648fe75345c4533/src/hotspot/os/bsd/os_bsd.cpp#L2015. As I cannot do this for executable memory, I use madvise as an alternative to nothing. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From stefank at openjdk.java.net Thu Dec 3 21:17:59 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 3 Dec 2020 21:17:59 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 13:59:11 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Thomas Just a few drive-by comment: Could PagesizeSet be named PageSizeSet. The rest of the code separates the word, so I think that name would be better. The same for some of the parameters that are named pagesize. Also, I think you could have called the class PageSizes. I don't think the fact that this is a 'set' matters for the usages of the class. It also makes the variable name match the type name, which I guess is an indication that it wouldn't be such a bad name: ``` static PageSizes _page_sizes;` vs static PagesizeSet _page_sizes; ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stefank at openjdk.java.net Thu Dec 3 21:28:59 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 3 Dec 2020 21:28:59 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 13:59:11 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Thomas src/hotspot/share/runtime/os.cpp line 1859: > 1857: bool os::PagesizeSet::is_set(size_t pagesize) const { > 1858: assert(is_power_of_2(pagesize), "pagesize must be a power of 2: " INTPTR_FORMAT, pagesize); > 1859: return (_v & pagesize) > 0; Why is this `> 0` and not simply `!= 0` src/hotspot/share/runtime/os.cpp line 1869: > 1867: return round_down_power_of_2(v2); > 1868: } > 1869: return 0; In next_larger you use the for: if (v2 == 0) { return 0; } return ... I think it would be nice to be consistent between the two functions. src/hotspot/share/runtime/os.cpp line 1863: > 1861: > 1862: size_t os::PagesizeSet::next_smaller(size_t pagesize) const { > 1863: assert(is_power_of_2(pagesize), "pagesize must be a power of 2: " INTPTR_FORMAT, pagesize); You're using INTPR_FORMAT to print a size_t. I guess this is done to print hex values. We have a SIZE_FORMAT_HEX for that use case. src/hotspot/share/runtime/os.hpp line 110: > 108: PagesizeSet() : _v(0) {} > 109: void add(size_t pagesize); > 110: bool is_set(size_t pagesize) const; Could this be private. It's an implementation detail that you use a bit set and have "set" bits. If not, maybe consider a more high-level name. is_added, is_registered, contains? src/hotspot/share/runtime/os.hpp line 106: > 104: // A simple value class holding a set of page sizes (similar to sigset_t) > 105: class PagesizeSet { > 106: uintx _v; All in-parameters are size_t. It seems like this could be size_t as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From iklam at openjdk.java.net Thu Dec 3 22:01:16 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 3 Dec 2020 22:01:16 GMT Subject: RFR: 8243205: Modularize JVM flags declaration Message-ID: This is the first step for modularizing the xxx_globals.hpp. The goals are - Improve modularization of HotSpot source - Reduce JVM build time To prove that this works, I have moved compiler_globals.hpp outside of the monolithic globals.hpp. Before this fix, compiler_globals.hpp was included by 922 HotSpot .o files. After this fix, it's included by 283 .o files. I plan to do more refactoring later, such as: - move gc_globals.hpp out of globals.hpp - move the flags related to tiered compilation (about 40 flags) out of globals.hpp - move the platform-specific flags outside of globals.hpp - these flags should be used only by platform-specific files. They shouldn't be used by shared files. ------------- Commit messages: - 8243205: Modularize global variable declaration for JVM flag macros Changes: https://git.openjdk.java.net/jdk/pull/1608/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1608&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8243205 Stats: 494 lines in 27 files changed: 303 ins; 158 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/1608.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1608/head:pull/1608 PR: https://git.openjdk.java.net/jdk/pull/1608 From github.com+168222+mgkwill at openjdk.java.net Thu Dec 3 22:59:06 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 3 Dec 2020 22:59:06 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 21:23:46 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Thomas > > src/hotspot/share/runtime/os.hpp line 110: > >> 108: PagesizeSet() : _v(0) {} >> 109: void add(size_t pagesize); >> 110: bool is_set(size_t pagesize) const; > > Could this be private. It's an implementation detail that you use a bit set and have "set" bits. If not, maybe consider a more high-level name. is_added, is_registered, contains? I'd prefer if this stays public, I've already found it useful, but I agree that the name could be more informative. Perhaps contains(size_t pagesize)? ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From coleenp at openjdk.java.net Thu Dec 3 23:17:54 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 3 Dec 2020 23:17:54 GMT Subject: RFR: 8243205: Modularize JVM flags declaration In-Reply-To: References: Message-ID: <21WfKMjegdMRZADQ4TksPpHOEYQgpe6UFJotYY_3zwM=.f1260c17-073b-4963-a9e2-2f778d8a0f6a@github.com> On Thu, 3 Dec 2020 21:51:42 GMT, Ioi Lam wrote: > This is the first step for modularizing the xxx_globals.hpp. The goals are > > - Improve modularization of HotSpot source > - Reduce JVM build time > > To prove that this works, I have moved compiler_globals.hpp outside of the monolithic globals.hpp. Before this fix, compiler_globals.hpp was included by 922 HotSpot .o files. After this fix, it's included by 283 .o files. > > I plan to do more refactoring later, such as: > > - move gc_globals.hpp out of globals.hpp > - move the flags related to tiered compilation (about 40 flags) out of globals.hpp > - move the platform-specific flags outside of globals.hpp > - these flags should be used only by platform-specific files. They shouldn't be used by shared files. > > Note: this is target for JDK 17. What is the include architecture of this? compiler_globals.hpp includes c1_globals.hpp includes c1_globals_pd.hpp ? ------------- PR: https://git.openjdk.java.net/jdk/pull/1608 From github.com+168222+mgkwill at openjdk.java.net Thu Dec 3 23:18:57 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 3 Dec 2020 23:18:57 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v3] In-Reply-To: <8f-BJdFip5yf0Rv4uw-qcXVk2uM3Lb6Hrq9VPR6UzF4=.04966477-8834-4fb9-aa77-8da86f104176@github.com> References: <-xtX9qSJHuD-qfp52XPToKhkl1HypRmNFHCJaupaync=.99285cd9-69a6-42cd-84b4-3c87fefc2cc5@github.com> <8f-BJdFip5yf0Rv4uw-qcXVk2uM3Lb6Hrq9VPR6UzF4=.04966477-8834-4fb9-aa77-8da86f104176@github.com> Message-ID: <-34e3icSZgu8A4-oTQcGCdLuQYWFFWNKe_btQifE7IY=.fa92e2f8-f2a7-4438-959c-ce544b644c05@github.com> On Thu, 19 Nov 2020 08:19:59 GMT, Stefan Johansson wrote: > > Hi Stefan, > > Thanks so much for your review. > > > Hi and welcome :) > > > I haven't started reviewing the code in detail but a first quick glance raised a couple of questions/comments: > > > > > > * Why do we have a special case for `exec` when selecting a large page size? > > > > > > To my knowledge 2M is the smallest large pages size supported by Linux at the moment. Hardcoding 2M pages was an attempt to simplify the reservation of code memory using LargePages. In most cases currently code memory is reserved in default page size of the system when using 1G LargePages because it does not require 1G or larger reservations. In modern Linux variants default page size seems to be 4k on x86_64. In other architectures it could be up to 64k. The purpose of the patch is to enable the use of smaller LargePages for reservations less than 1G when LargePages are enabled and 1G is set as LargePageSizeInBytes, so as not to fall back to 4k-64k pages for these reservations. > > Perhaps I should just select the page size <= bytes requested and remove 'exec' special case. > > Yes, I see no reason to keep that special case and we want to keep this code as general as possible. Looking at the code in `os::Linux::find_default_large_page_size()` it looks like S390 supports 1M large pages, so we cannot assume 2M. I suggest using a technique similar to the one used in `os::Linux::find_large_page_size` to find supported page sizes. If you scan `/sys/kernel/mm/hugepages` and populate `_page_sizes` using the information found we know we only get supported sizes. > > > > * If we need the special case, `exec_large_page_size()` should not be hard code to return 2m but rather use `os::default_large_page_size()`. > > > > > > os::default_large_page_size() will not necessarily be small enough for code memory reservations if the os::default_large_page_size() = 1G, in those cases we would get 4k on most linux x86_64 variants. My attempt is to ensure the smallest large_page_size availabe is used for code memory reservations. Perhaps my 2M hardcoding was a mistake and I should discover this size and select it based on the bytes being reserved. > > You are correct that the default size might indeed be 1G, so using something like I suggest above to figure out the available page sizes and then using an appropriate one given the size of the mapping sounds good. > Agreed. > Please also avoid force pushing changes to open PRs since it makes it harder to follow what changes between updates. It is fine for a PR to contain multiple commits and if you need to update with things from the main branch you should merge rather than rebase. > Thanks for letting me know. I'll work in that workflow from now on. In other open source communities I've worked in we used a gerrit (example: [gerrit.onap.org](https://gerrit.onap.org/)) workflow where each patch-set was tracked by gerrit using a change-id `Change-Id: I51625afb91451ee95c051c4edc8e7c30589f3831`. Using this workflow we would avoid merges and would use rebasing for simplicity and to avoid other workflow/CI issues and gerrit maintains change history and comments etc. As you say, it looks like merging and flattening into one commit is the way these pull requests get into openjdk/jdk master. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From serb at openjdk.java.net Thu Dec 3 23:22:59 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 3 Dec 2020 23:22:59 GMT Subject: RFR: JDK-8255544: Create a checked cast [v2] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 17:29:57 GMT, Coleen Phillimore wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8255544: Create a checked cast > > Looks good to me. I guess this PR should be closed? ------------- PR: https://git.openjdk.java.net/jdk/pull/904 From github.com+168222+mgkwill at openjdk.java.net Thu Dec 3 23:24:56 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 3 Dec 2020 23:24:56 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v3] In-Reply-To: References: <-xtX9qSJHuD-qfp52XPToKhkl1HypRmNFHCJaupaync=.99285cd9-69a6-42cd-84b4-3c87fefc2cc5@github.com> <8f-BJdFip5yf0Rv4uw-qcXVk2uM3Lb6Hrq9VPR6UzF4=.04966477-8834-4fb9-aa77-8da86f104176@github.com> Message-ID: On Sun, 29 Nov 2020 08:17:09 GMT, Thomas Stuefe wrote: > One thing I stumbled upon while looking at this code is why the CodeHeap always wants to have at least 8 pages covering its range: > > ``` > // If large page support is enabled, align code heaps according to large > // page size to make sure that code cache is covered by large pages. > const size_t alignment = MAX2(page_size(false, 8), (size_t) os::vm_allocation_granularity()); > ``` > > which means that for a wish pagesize of 1G, the code cache would have to cover at least 8G. I am not even sure this is possible, isn't it limited to 4G? > > Anyway, they don't uncommit. And the comment in codecache.cpp indicates this is to be able to step-wise commit, but with huge pages the space is committed right from the start anyway. So I do not see what good these 8 pages do. If we allowed the CodeCache to use just one page, it could be 1G in size and use a single 1G page. > > Note that there are similar min_page_size requests in GC, but I did not look closer into them. > > Also, this does not take away the usefulness of this proposal. Interesting. I'll look at min_page_size requests in GC and codecache in relation to large pages and see what kind of optimization can be done in another JDK-Issue/PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From iklam at openjdk.java.net Thu Dec 3 23:32:10 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 3 Dec 2020 23:32:10 GMT Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp Message-ID: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> stubRoutines.hpp is unnecessarily included by thread.hpp and copy.hpp. This causes a large number of header files related to native code generation to be included by almost all HotSpot .o files. - Before the fix, stubRoutines.hpp is included by 803 .o files. - After the fix, stubRoutines.hpp is included by 117 .o files. The total number of included header files decreased from 252893 to 247631, or about 2%. Note: the main change is the removal of stubRoutines.hpp in thread.hpp and copy.hpp. Unfortunately I have to fix quite a few missing dependencies in other source files that are revealed by the removal. ------------- Commit messages: - 8257731: Remove excessive include of stubRoutines.hpp Changes: https://git.openjdk.java.net/jdk/pull/1610/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1610&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257731 Stats: 99 lines in 59 files changed: 73 ins; 10 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1610/head:pull/1610 PR: https://git.openjdk.java.net/jdk/pull/1610 From github.com+168222+mgkwill at openjdk.java.net Thu Dec 3 23:48:15 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 3 Dec 2020 23:48:15 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v4] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams 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: - Adress Comments, Rework changes for PagesizeSet Signed-off-by: Marcus G K Williams - JDK-8257588: Make os::_page_sizes a bitmask #1522 - Merge branch 'master' into update_hlp - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp - Add 2M LargePages to _page_sizes Use 2m pages for large page requests less than 1g on linux when 1G are default pages - Add os::Linux::large_page_size_2m() that returns 2m as size - Add os::Linux::select_large_page_size() to return correct large page size for size_t bytes - Add 2m size to _page_sizes array - Update reserve_memory_special methods to set/use large_page_size based on bytes reserved - Update large page not reserved warnings to include large_page_size attempted - Update TestLargePageUseForAuxMemory.java to expect 2m large pages in some instances Signed-off-by: Marcus G K Williams - Merge remote-tracking branch 'upstream/master' into update_hlp - Add 2M LargePages to _page_sizes Use 2m pages for large page requests less than 1g on linux when 1G are default pages - Add os::Linux::large_page_size_2m() that returns 2m as size - Add os::Linux::select_large_page_size() to return correct large page size for size_t bytes - Add 2m size to _page_sizes array - Update reserve_memory_special methods to set/use large_page_size based on bytes reserved - Update large page not reserved warnings to include large_page_size attempted - Update TestLargePageUseForAuxMemory.java to expect 2m large pages in some instances Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1153/files - new: https://git.openjdk.java.net/jdk/pull/1153/files/57e54963..0901e70e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=02-03 Stats: 2740 lines in 107 files changed: 1814 ins; 632 del; 294 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Thu Dec 3 23:53:56 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 3 Dec 2020 23:53:56 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v4] In-Reply-To: References: <-xtX9qSJHuD-qfp52XPToKhkl1HypRmNFHCJaupaync=.99285cd9-69a6-42cd-84b4-3c87fefc2cc5@github.com> <8f-BJdFip5yf0Rv4uw-qcXVk2uM3Lb6Hrq9VPR6UzF4=.04966477-8834-4fb9-aa77-8da86f104176@github.com> Message-ID: On Thu, 3 Dec 2020 23:22:17 GMT, Marcus G K Williams wrote: >> One thing I stumbled upon while looking at this code is why the CodeHeap always wants to have at least 8 pages covering its range: >> >> // If large page support is enabled, align code heaps according to large >> // page size to make sure that code cache is covered by large pages. >> const size_t alignment = MAX2(page_size(false, 8), (size_t) os::vm_allocation_granularity()); >> >> which means that for a wish pagesize of 1G, the code cache would have to cover at least 8G. I am not even sure this is possible, isn't it limited to 4G? >> >> Anyway, they don't uncommit. And the comment in codecache.cpp indicates this is to be able to step-wise commit, but with huge pages the space is committed right from the start anyway. So I do not see what good these 8 pages do. If we allowed the CodeCache to use just one page, it could be 1G in size and use a single 1G page. >> >> Note that there are similar min_page_size requests in GC, but I did not look closer into them. >> >> Also, this does not take away the usefulness of this proposal. > >> One thing I stumbled upon while looking at this code is why the CodeHeap always wants to have at least 8 pages covering its range: >> >> ``` >> // If large page support is enabled, align code heaps according to large >> // page size to make sure that code cache is covered by large pages. >> const size_t alignment = MAX2(page_size(false, 8), (size_t) os::vm_allocation_granularity()); >> ``` >> >> which means that for a wish pagesize of 1G, the code cache would have to cover at least 8G. I am not even sure this is possible, isn't it limited to 4G? >> >> Anyway, they don't uncommit. And the comment in codecache.cpp indicates this is to be able to step-wise commit, but with huge pages the space is committed right from the start anyway. So I do not see what good these 8 pages do. If we allowed the CodeCache to use just one page, it could be 1G in size and use a single 1G page. >> >> Note that there are similar min_page_size requests in GC, but I did not look closer into them. >> >> Also, this does not take away the usefulness of this proposal. > > Interesting. I'll look at min_page_size requests in GC and codecache in relation to large pages and see what kind of optimization can be done in another JDK-Issue/PR. Recent push is dependent on and includes #1522 - when it is updated, I will update here. Removed 2M/exec specific code. Re-wrote to take advantage of #1522. Attempted to address other comments. Please let me know if I've missed something. My apologies this took so long to update, we had a long holiday weekend. Thanks again for all of the review @kstefanj and @tstuefe! ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Fri Dec 4 00:01:02 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Fri, 4 Dec 2020 00:01:02 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v4] In-Reply-To: References: Message-ID: <4RB8I8eA6hYo_ORAUdzd9EtIMAhIi_3G1689-5DKndE=.811d784a-a81d-4ca2-8c87-5540cca5d585@github.com> On Thu, 3 Dec 2020 23:48:15 GMT, Marcus G K Williams wrote: >> When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using >> Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). >> >> This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). >> >> In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. > > Marcus G K Williams 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: > > - Adress Comments, Rework changes for PagesizeSet > > Signed-off-by: Marcus G K Williams > - JDK-8257588: Make os::_page_sizes a bitmask #1522 > - Merge branch 'master' into update_hlp > - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp > - Add 2M LargePages to _page_sizes > > Use 2m pages for large page requests > less than 1g on linux when 1G are default > pages > > - Add os::Linux::large_page_size_2m() that > returns 2m as size > - Add os::Linux::select_large_page_size() to return > correct large page size for size_t bytes > - Add 2m size to _page_sizes array > - Update reserve_memory_special methods > to set/use large_page_size based on bytes reserved > - Update large page not reserved warnings > to include large_page_size attempted > - Update TestLargePageUseForAuxMemory.java > to expect 2m large pages in some instances > > Signed-off-by: Marcus G K Williams > - Merge remote-tracking branch 'upstream/master' into update_hlp > - Add 2M LargePages to _page_sizes > > Use 2m pages for large page requests > less than 1g on linux when 1G are default > pages > > - Add os::Linux::large_page_size_2m() that > returns 2m as size > - Add os::Linux::select_large_page_size() to return > correct large page size for size_t bytes > - Add 2m size to _page_sizes array > - Update reserve_memory_special methods > to set/use large_page_size based on bytes reserved > - Update large page not reserved warnings > to include large_page_size attempted > - Update TestLargePageUseForAuxMemory.java > to expect 2m large pages in some instances > > Signed-off-by: Marcus G K Williams src/hotspot/os/linux/os_linux.cpp line 3900: > 3898: err); \ > 3899: } while (0) > 3900: Remove this remnant of UseSHM changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From iklam at openjdk.java.net Fri Dec 4 00:01:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 4 Dec 2020 00:01:55 GMT Subject: RFR: 8243205: Modularize JVM flags declaration In-Reply-To: <21WfKMjegdMRZADQ4TksPpHOEYQgpe6UFJotYY_3zwM=.f1260c17-073b-4963-a9e2-2f778d8a0f6a@github.com> References: <21WfKMjegdMRZADQ4TksPpHOEYQgpe6UFJotYY_3zwM=.f1260c17-073b-4963-a9e2-2f778d8a0f6a@github.com> Message-ID: On Thu, 3 Dec 2020 23:15:17 GMT, Coleen Phillimore wrote: > What is the include architecture of this? compiler_globals.hpp includes c1_globals.hpp includes c1_globals_pd.hpp ? c1_globals.hpp declares the flags, and c1_globals_pd.hpp defines the (platform-specific) default values of the flags. For example, c1_globals.hpp includes c1_globals_x86.hpp, which has define_pd_global(bool, CICompileOSR, true ); which gets preprocessed to: const bool pd_CICompileOSR = true;; ------------- PR: https://git.openjdk.java.net/jdk/pull/1608 From github.com+168222+mgkwill at openjdk.java.net Fri Dec 4 00:07:12 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Fri, 4 Dec 2020 00:07:12 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v5] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Remove remnant UseSHM change Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1153/files - new: https://git.openjdk.java.net/jdk/pull/1153/files/0901e70e..b5bd144d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=03-04 Stats: 13 lines in 1 file changed: 0 ins; 10 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From iklam at openjdk.java.net Fri Dec 4 00:12:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 4 Dec 2020 00:12:57 GMT Subject: RFR: 8243205: Modularize JVM flags declaration In-Reply-To: <21WfKMjegdMRZADQ4TksPpHOEYQgpe6UFJotYY_3zwM=.f1260c17-073b-4963-a9e2-2f778d8a0f6a@github.com> References: <21WfKMjegdMRZADQ4TksPpHOEYQgpe6UFJotYY_3zwM=.f1260c17-073b-4963-a9e2-2f778d8a0f6a@github.com> Message-ID: On Thu, 3 Dec 2020 23:15:17 GMT, Coleen Phillimore wrote: >> This is the first step for modularizing the xxx_globals.hpp. The goals are >> >> - Improve modularization of HotSpot source >> - Reduce JVM build time >> >> To prove that this works, I have moved compiler_globals.hpp outside of the monolithic globals.hpp. Before this fix, compiler_globals.hpp was included by 922 HotSpot .o files. After this fix, it's included by 283 .o files. >> >> I plan to do more refactoring later, such as: >> >> - move gc_globals.hpp out of globals.hpp >> - move the flags related to tiered compilation (about 40 flags) out of globals.hpp >> - move the platform-specific flags outside of globals.hpp >> - these flags should be used only by platform-specific files. They shouldn't be used by shared files. >> >> Note: this is target for JDK 17. > > What is the include architecture of this? compiler_globals.hpp includes c1_globals.hpp includes c1_globals_pd.hpp ? (Sorry my previous comment was sent prematurely when I clicked the wrong button in GitHub). > What is the include architecture of this? compiler_globals.hpp includes c1_globals.hpp includes c1_globals_pd.hpp ? c1_globals.hpp declares the flags for C1, and c1_globals_pd.hpp defines the (platform-specific) default values of the flags. For example, c1_globals.hpp includes c1_globals_x86.hpp, which has define_pd_global(bool, CSEArrayLength, false); which gets preprocessed to: const bool pd_CSEArrayLength = false; in c1_globals.hpp, we have develop_pd(bool, CSEArrayLength, \ "Create separate nodes for length in array accesses") \ which, in product build, gets preprocessed to: const bool CSEArrayLength = pd_CSEArrayLength; So this is the reason that c1_globals.hpp needs to include c1_globals_pd.hpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/1608 From coleenp at openjdk.java.net Fri Dec 4 00:12:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 4 Dec 2020 00:12:58 GMT Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> Message-ID: <70ayMWpx2ofsYivCjHlYe2K0Hl0uzjQFIyL1a4NFugI=.758dfa01-b052-46d4-a4b0-63c82ee11477@github.com> On Thu, 3 Dec 2020 23:20:33 GMT, Ioi Lam wrote: > stubRoutines.hpp is unnecessarily included by thread.hpp and copy.hpp. This causes a large number of header files related to native code generation to be included by almost all HotSpot .o files. > > - Before the fix, stubRoutines.hpp is included by 803 .o files. > - After the fix, stubRoutines.hpp is included by 117 .o files. > > The total number of included header files decreased from 252893 to 247631, or about 2%. > > Note: the main change is the removal of stubRoutines.hpp in thread.hpp and copy.hpp. Unfortunately I have to fix quite a few missing dependencies in other source files that are revealed by the removal. Looks good to me, if you did a test build of zero and maybe ppc at least. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1610 From kvn at openjdk.java.net Fri Dec 4 00:18:57 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 4 Dec 2020 00:18:57 GMT Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> Message-ID: On Thu, 3 Dec 2020 23:20:33 GMT, Ioi Lam wrote: > stubRoutines.hpp is unnecessarily included by thread.hpp and copy.hpp. This causes a large number of header files related to native code generation to be included by almost all HotSpot .o files. > > - Before the fix, stubRoutines.hpp is included by 803 .o files. > - After the fix, stubRoutines.hpp is included by 117 .o files. > > The total number of included header files decreased from 252893 to 247631, or about 2%. > > Note: the main change is the removal of stubRoutines.hpp in thread.hpp and copy.hpp. Unfortunately I have to fix quite a few missing dependencies in other source files that are revealed by the removal. Make sure all builds are passed. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1610 From iklam at openjdk.java.net Fri Dec 4 00:28:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 4 Dec 2020 00:28:57 GMT Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> Message-ID: On Fri, 4 Dec 2020 00:16:39 GMT, Vladimir Kozlov wrote: > Make sure all builds are passed. @vnkozlov @coleenp I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. ------------- PR: https://git.openjdk.java.net/jdk/pull/1610 From kvn at openjdk.java.net Fri Dec 4 00:35:59 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 4 Dec 2020 00:35:59 GMT Subject: RFR: 8243205: Modularize JVM flags declaration In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 21:51:42 GMT, Ioi Lam wrote: > This is the first step for modularizing the xxx_globals.hpp. The goals are > > - Improve modularization of HotSpot source > - Reduce JVM build time > > To prove that this works, I have moved compiler_globals.hpp outside of the monolithic globals.hpp. Before this fix, compiler_globals.hpp was included by 922 HotSpot .o files. After this fix, it's included by 283 .o files. > > I plan to do more refactoring later, such as: > > - move gc_globals.hpp out of globals.hpp > - move the flags related to tiered compilation (about 40 flags) out of globals.hpp > - move the platform-specific flags outside of globals.hpp > - these flags should be used only by platform-specific files. They shouldn't be used by shared files. > > Note: this is target for JDK 17. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1608 From kvn at openjdk.java.net Fri Dec 4 00:37:53 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 4 Dec 2020 00:37:53 GMT Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> Message-ID: On Fri, 4 Dec 2020 00:26:13 GMT, Ioi Lam wrote: > > Make sure all builds are passed. > > @vnkozlov @coleenp I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. Good. Please, list testing in your PR descriptions so that we know what you did. ------------- PR: https://git.openjdk.java.net/jdk/pull/1610 From iklam at openjdk.java.net Fri Dec 4 00:50:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 4 Dec 2020 00:50:56 GMT Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> Message-ID: On Fri, 4 Dec 2020 00:35:03 GMT, Vladimir Kozlov wrote: > > > Make sure all builds are passed. > > > > > > @vnkozlov @coleenp I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. > > Good. Please, list testing in your PR descriptions so that we know what you did. Done. I updated the PR descriptions. ------------- PR: https://git.openjdk.java.net/jdk/pull/1610 From stuefe at openjdk.java.net Fri Dec 4 05:35:03 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 05:35:03 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 22:56:04 GMT, Marcus G K Williams wrote: >> src/hotspot/share/runtime/os.hpp line 110: >> >>> 108: PagesizeSet() : _v(0) {} >>> 109: void add(size_t pagesize); >>> 110: bool is_set(size_t pagesize) const; >> >> Could this be private. It's an implementation detail that you use a bit set and have "set" bits. If not, maybe consider a more high-level name. is_added, is_registered, contains? > > I'd prefer if this stays public, I've already found it useful, but I agree that the name could be more informative. Perhaps contains(size_t pagesize)? Cannot be private since its used from other nested classes (os::Linux etc). But I can rename it to contains() ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 05:39:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 05:39:59 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 21:25:28 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Thomas > > src/hotspot/share/runtime/os.hpp line 106: > >> 104: // A simple value class holding a set of page sizes (similar to sigset_t) >> 105: class PagesizeSet { >> 106: uintx _v; > > All in-parameters are size_t. It seems like this could be size_t as well. This is my personal taste; I dislike keeping anything a size_t which is not a memory range size (e.g. I dislike its use as an array index). But it does not matter much to me here since size_t is guaranteed to be unsigned. > src/hotspot/share/runtime/os.cpp line 1863: > >> 1861: >> 1862: size_t os::PagesizeSet::next_smaller(size_t pagesize) const { >> 1863: assert(is_power_of_2(pagesize), "pagesize must be a power of 2: " INTPTR_FORMAT, pagesize); > > You're using INTPR_FORMAT to print a size_t. I guess this is done to print hex values. We have a SIZE_FORMAT_HEX for that use case. Sure ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 06:05:10 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 06:05:10 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> > Hi, > > may I please have reviews for the following very small improvement: > > While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: > > size_t os::_page_sizes[os::page_sizes_max]; > > is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. > > Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). > > That has the following advantages: > - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. > - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. > > ----- > > The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. > > > Testing: > - nightlies at SAP > - manual tests with UseLargePages > - the new gtests > - gh actions (with x86 still failing because of unrelated issues) > > Thank you, > > Thomas > > [1] https://bugs.openjdk.java.net/browse/JDK-8243315 > [2] https://bugs.openjdk.java.net/browse/JDK-8256155 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Stefan K ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1522/files - new: https://git.openjdk.java.net/jdk/pull/1522/files/fdae7642..23569726 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=02-03 Stats: 35 lines in 3 files changed: 0 ins; 1 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/1522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1522/head:pull/1522 PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 06:05:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 06:05:11 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 21:18:16 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Thomas > > src/hotspot/share/runtime/os.cpp line 1869: > >> 1867: return round_down_power_of_2(v2); >> 1868: } >> 1869: return 0; > > In next_larger you use the for: > if (v2 == 0) { > return 0; > } > return ... > I think it would be nice to be consistent between the two functions. > Just a few drive-by comment: Could PagesizeSet be named PageSizeSet. The rest of the code separates the word, so I think that name would be better. The same for some of the parameters that are named pagesize. > > Also, I think you could have called the class PageSizes. I don't think the fact that this is a 'set' matters for the usages of the class. It also makes the variable name match the type name, which I guess is an indication that it wouldn't be such a bad name: > > ``` > static PageSizes _page_sizes;` > ``` > > vs > > ``` > static PagesizeSet _page_sizes; > ``` Hi Stefan, thanks for your review! I adapted most of your suggestions. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From shade at openjdk.java.net Fri Dec 4 07:55:09 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 07:55:09 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v22] In-Reply-To: References: Message-ID: <4muP623qHxEuMXiAF2QFaIVo2lztcNtwlyN33pARca4=.44f589fd-8055-4205-bba8-9eaf20c56d75@github.com> > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the final attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. > > The fourth, and hopefully final attempt is in this PR. It makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits: - Cleanup LibraryCallKit::inline_blackhole - Simplify tests - Merge branch 'master' into JDK-8252505-blackholes - Fix C2 _blackhole: polls arguments count from caller, not callee - Print warning on non-void blackhole methods - Fix release build - Merge branch 'master' into JDK-8252505-blackholes - Handle null-checks in intrinsics to maintain the semantics - Blackhole takes precedence over all other intrinsics - Print Blackhole format - ... and 29 more: https://git.openjdk.java.net/jdk/compare/d08c612b...64962bc3 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1203/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=21 Stats: 1503 lines in 30 files changed: 1501 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From github.com+16932759+shqking at openjdk.java.net Fri Dec 4 08:24:11 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Fri, 4 Dec 2020 08:24:11 GMT Subject: RFR: 8257743: Minimal build on AArch64 failed with --disable-precompiled-headers Message-ID: <3ILq8C9JmaxO83_JsjsMcSy8Oe4r6KlRSVekJ61cKS8=.cdad953a-b4cd-4377-b146-f03927fe4287@github.com> The build failed due to undeclared 'java_lang_ref_Reference'. Making the corresponding header (classfile/javaClasses.hpp) included would fix it. ------------- Commit messages: - 8257743: Minimal build on AArch64 failed with --disable-precompiled-headers Changes: https://git.openjdk.java.net/jdk/pull/1619/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1619&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257743 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1619.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1619/head:pull/1619 PR: https://git.openjdk.java.net/jdk/pull/1619 From shade at openjdk.java.net Fri Dec 4 08:37:11 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 08:37:11 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v23] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the final attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. > > The fourth, and hopefully final attempt is in this PR. It makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Whitespace fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/64962bc3..f0d5f739 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=22 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=21-22 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Fri Dec 4 08:38:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 08:38:59 GMT Subject: RFR: 8257743: Minimal build on AArch64 failed with --disable-precompiled-headers In-Reply-To: <3ILq8C9JmaxO83_JsjsMcSy8Oe4r6KlRSVekJ61cKS8=.cdad953a-b4cd-4377-b146-f03927fe4287@github.com> References: <3ILq8C9JmaxO83_JsjsMcSy8Oe4r6KlRSVekJ61cKS8=.cdad953a-b4cd-4377-b146-f03927fe4287@github.com> Message-ID: On Fri, 4 Dec 2020 08:19:43 GMT, Hao Sun wrote: > The build failed due to undeclared 'java_lang_ref_Reference'. > Making the corresponding header (classfile/javaClasses.hpp) included would fix it. Looks good and trivial. Is this a new build failure? Can you pinpoint the commit after which it started to fail? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1619 From shade at openjdk.java.net Fri Dec 4 08:52:56 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 08:52:56 GMT Subject: RFR: 8257743: Minimal build on AArch64 failed with --disable-precompiled-headers In-Reply-To: References: <3ILq8C9JmaxO83_JsjsMcSy8Oe4r6KlRSVekJ61cKS8=.cdad953a-b4cd-4377-b146-f03927fe4287@github.com> Message-ID: On Fri, 4 Dec 2020 08:35:48 GMT, Aleksey Shipilev wrote: >> The build failed due to undeclared 'java_lang_ref_Reference'. >> Making the corresponding header (classfile/javaClasses.hpp) included would fix it. > > Looks good and trivial. > > Is this a new build failure? Can you pinpoint the commit after which it started to fail? Nevermind, I bisected myself, it is caused by JDK-8257563, added the link to JIRA. ------------- PR: https://git.openjdk.java.net/jdk/pull/1619 From github.com+16932759+shqking at openjdk.java.net Fri Dec 4 09:15:58 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Fri, 4 Dec 2020 09:15:58 GMT Subject: Integrated: 8257743: Minimal build on AArch64 failed with --disable-precompiled-headers In-Reply-To: <3ILq8C9JmaxO83_JsjsMcSy8Oe4r6KlRSVekJ61cKS8=.cdad953a-b4cd-4377-b146-f03927fe4287@github.com> References: <3ILq8C9JmaxO83_JsjsMcSy8Oe4r6KlRSVekJ61cKS8=.cdad953a-b4cd-4377-b146-f03927fe4287@github.com> Message-ID: On Fri, 4 Dec 2020 08:19:43 GMT, Hao Sun wrote: > The build failed due to undeclared 'java_lang_ref_Reference'. > Making the corresponding header (classfile/javaClasses.hpp) included would fix it. This pull request has now been integrated. Changeset: af6b7f9c Author: Hao Sun Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/af6b7f9c Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8257743: Minimal build on AArch64 failed with --disable-precompiled-headers Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1619 From vlivanov at openjdk.java.net Fri Dec 4 09:22:00 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 4 Dec 2020 09:22:00 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v23] In-Reply-To: References: Message-ID: <52nKoNwt6GzvZ1_PmJuXOdXITUJmOFWChYL8jKjgUM0=.7a6708be-87ae-4ab1-8a57-59c6aac5060e@github.com> On Fri, 4 Dec 2020 08:37:11 GMT, Aleksey Shipilev wrote: >> JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: >> >> 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. >> 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. >> 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. >> >> Supporting this directly in compilers would improve nanobenchmark fidelity. >> >> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). >> >> C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. >> >> C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the final attempt. >> >> [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. >> >> [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. >> >> ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. >> >> The fourth, and hopefully final attempt is in this PR. It makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Whitespace fixes src/hotspot/share/compiler/compilerOracle.cpp line 418: > 416: } else { > 417: ttyLocker ttyl; > 418: tty->print_cr("Warning: blackhole compile command only works for methods with void type: %s", It is printed unconditionally. What about guarding it with `!CompilerOracle::be_quiet()`? test/hotspot/jtreg/compiler/blackhole/BlackholeNonVoidWarning.java line 60: > 58: OutputAnalyzer output = new OutputAnalyzer(pb.start()); > 59: output.shouldHaveExitValue(0); > 60: output.shouldContain("blackhole compile command only works for methods with void type: compiler.blackhole.BlackholeTarget.bh_sr_int(I)I"); The test passes `-XX:CompileCommand=quiet`, but then checks the warning is printed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From github.com+16932759+shqking at openjdk.java.net Fri Dec 4 09:22:57 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Fri, 4 Dec 2020 09:22:57 GMT Subject: RFR: 8257743: Minimal build on AArch64 failed with --disable-precompiled-headers In-Reply-To: References: <3ILq8C9JmaxO83_JsjsMcSy8Oe4r6KlRSVekJ61cKS8=.cdad953a-b4cd-4377-b146-f03927fe4287@github.com> Message-ID: On Fri, 4 Dec 2020 08:50:27 GMT, Aleksey Shipilev wrote: >> Looks good and trivial. >> >> Is this a new build failure? Can you pinpoint the commit after which it started to fail? > > Nevermind, I bisected myself, it is caused by JDK-8257563, added the link to JIRA. Yes. It is indeed JDK-8257563. @shipilev Thanks a lot. ------------- PR: https://git.openjdk.java.net/jdk/pull/1619 From shade at openjdk.java.net Fri Dec 4 09:26:59 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 09:26:59 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v23] In-Reply-To: <52nKoNwt6GzvZ1_PmJuXOdXITUJmOFWChYL8jKjgUM0=.7a6708be-87ae-4ab1-8a57-59c6aac5060e@github.com> References: <52nKoNwt6GzvZ1_PmJuXOdXITUJmOFWChYL8jKjgUM0=.7a6708be-87ae-4ab1-8a57-59c6aac5060e@github.com> Message-ID: On Fri, 4 Dec 2020 09:17:47 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Whitespace fixes > > src/hotspot/share/compiler/compilerOracle.cpp line 418: > >> 416: } else { >> 417: ttyLocker ttyl; >> 418: tty->print_cr("Warning: blackhole compile command only works for methods with void type: %s", > > It is printed unconditionally. What about guarding it with `!CompilerOracle::be_quiet()`? As far as I can see, `CompilerOracle` prints warnings even with `quiet`. `quiet` seems to really only shun the successful messages. So this behavior is consistent. And frankly, it is a better UX: errors in compiler commands should be visible. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From vlivanov at openjdk.java.net Fri Dec 4 09:37:57 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 4 Dec 2020 09:37:57 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v23] In-Reply-To: References: <52nKoNwt6GzvZ1_PmJuXOdXITUJmOFWChYL8jKjgUM0=.7a6708be-87ae-4ab1-8a57-59c6aac5060e@github.com> Message-ID: On Fri, 4 Dec 2020 09:23:58 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/compiler/compilerOracle.cpp line 418: >> >>> 416: } else { >>> 417: ttyLocker ttyl; >>> 418: tty->print_cr("Warning: blackhole compile command only works for methods with void type: %s", >> >> It is printed unconditionally. What about guarding it with `!CompilerOracle::be_quiet()`? > > As far as I can see, `CompilerOracle` prints warnings even with `quiet`. `quiet` seems to really only shun the successful messages. So this behavior is consistent. And frankly, it is a better UX: errors in compiler commands should be visible. IMO `CompileCommand=quiet` is fine here, but another option is to check `PrintWarnings`. I believe the output can be quite noisy and there's no way to turn it off. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Fri Dec 4 09:41:57 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 09:41:57 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v23] In-Reply-To: References: <52nKoNwt6GzvZ1_PmJuXOdXITUJmOFWChYL8jKjgUM0=.7a6708be-87ae-4ab1-8a57-59c6aac5060e@github.com> Message-ID: On Fri, 4 Dec 2020 09:35:31 GMT, Vladimir Ivanov wrote: >> As far as I can see, `CompilerOracle` prints warnings even with `quiet`. `quiet` seems to really only shun the successful messages. So this behavior is consistent. And frankly, it is a better UX: errors in compiler commands should be visible. > > IMO `CompileCommand=quiet` is fine here, but another option is to check `PrintWarnings`. I believe the output can be quite noisy and there's no way to turn it off. Well, if users want to shun the warning, then they should not put incorrect compiler commands to JVM. For example, JMH does run with `quiet` to silence the "successful" command output, and I still want JVM to show warning messages when people put a `@CompilerControl(BLACKHOLE)` on a wrong method. It is better UX. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Fri Dec 4 09:46:53 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 09:46:53 GMT Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> Message-ID: <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> On Fri, 4 Dec 2020 00:48:16 GMT, Ioi Lam wrote: >>> > Make sure all builds are passed. >>> >>> @vnkozlov @coleenp I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. >> >> Good. Please, list testing in your PR descriptions so that we know what you did. > >> > > Make sure all builds are passed. >> > >> > >> > @vnkozlov @coleenp I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. >> >> Good. Please, list testing in your PR descriptions so that we know what you did. > > Done. I updated the PR descriptions. I have a suggestion: let's wait until JDK 16 forks for stabilization before we do any `#include` reshuffling? There are build breakages from these changes, so it would be nice to have these breakages away from the stabilizing repository. ------------- PR: https://git.openjdk.java.net/jdk/pull/1610 From vlivanov at openjdk.java.net Fri Dec 4 09:51:55 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 4 Dec 2020 09:51:55 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v23] In-Reply-To: References: <52nKoNwt6GzvZ1_PmJuXOdXITUJmOFWChYL8jKjgUM0=.7a6708be-87ae-4ab1-8a57-59c6aac5060e@github.com> Message-ID: On Fri, 4 Dec 2020 09:39:19 GMT, Aleksey Shipilev wrote: >> IMO `CompileCommand=quiet` is fine here, but another option is to check `PrintWarnings`. I believe the output can be quite noisy and there's no way to turn it off. > > Well, if users want to shun the warning, then they should not put incorrect compiler commands to JVM. For example, JMH does run with `quiet` to silence the "successful" command output, and I still want JVM to show warning messages when people put a `@CompilerControl(BLACKHOLE)` on a wrong method. It is better UX. Then check `PrintWarnings`? It's an explicit user request to silent JVM warnings on output stream. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From vlivanov at openjdk.java.net Fri Dec 4 10:04:33 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 4 Dec 2020 10:04:33 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v23] In-Reply-To: References: <52nKoNwt6GzvZ1_PmJuXOdXITUJmOFWChYL8jKjgUM0=.7a6708be-87ae-4ab1-8a57-59c6aac5060e@github.com> Message-ID: On Fri, 4 Dec 2020 09:49:16 GMT, Vladimir Ivanov wrote: >> Well, if users want to shun the warning, then they should not put incorrect compiler commands to JVM. For example, JMH does run with `quiet` to silence the "successful" command output, and I still want JVM to show warning messages when people put a `@CompilerControl(BLACKHOLE)` on a wrong method. It is better UX. > > Then check `PrintWarnings`? It's an explicit user request to silent JVM warnings on output stream. I agree now that `CompileCommand=quiet` is not appropriate here. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Fri Dec 4 10:04:44 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 10:04:44 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v23] In-Reply-To: References: <52nKoNwt6GzvZ1_PmJuXOdXITUJmOFWChYL8jKjgUM0=.7a6708be-87ae-4ab1-8a57-59c6aac5060e@github.com> Message-ID: On Fri, 4 Dec 2020 09:50:58 GMT, Vladimir Ivanov wrote: >> Then check `PrintWarnings`? It's an explicit user request to silent JVM warnings on output stream. > > I agree now that `CompileCommand=quiet` is not appropriate here. All right. I see `CompilerOracle` sometimes calls into `warning` from `debug.cpp` that handles `PrintWarnings`. Updated new hunk to use it, and a test case that proves it works. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Fri Dec 4 10:07:45 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 10:07:45 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: Message-ID: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the final attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. > > The fourth, and hopefully final attempt is in this PR. It makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Do not print void warning with -XX:-PrintWarnings ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1203/files - new: https://git.openjdk.java.net/jdk/pull/1203/files/f0d5f739..306cd963 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=23 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1203&range=22-23 Stats: 31 lines in 2 files changed: 18 ins; 1 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/1203.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1203/head:pull/1203 PR: https://git.openjdk.java.net/jdk/pull/1203 From rrich at openjdk.java.net Fri Dec 4 10:48:10 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 4 Dec 2020 10:48:10 GMT Subject: RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches In-Reply-To: <66d_EAED3_BRpr9YmIrv1seQFfyUOIPdntMllUyJa-Q=.61c545be-b26d-4d3a-8ac6-e7239656b7a6@github.com> References: <66d_EAED3_BRpr9YmIrv1seQFfyUOIPdntMllUyJa-Q=.61c545be-b26d-4d3a-8ac6-e7239656b7a6@github.com> Message-ID: On Mon, 30 Nov 2020 15:37:34 GMT, Martin Doerr wrote: > The JVM currently runs into Unimplemented() when using -XX:-UseInlineCaches in C2 code (postalloc_expand_java_dynamic_call_sched). > I'd like to enable the existing code in postalloc_expand_java_dynamic_call_sched and fix MachCallDynamicJavaNode::ret_addr_offset() and MacroAssembler::instr_size_for_decode_klass_not_null(). > I suggest to use scratch emit to determine the size, because there are too many cases and emitting it once is fast. Looks good to me. Thanks, Richard. ------------- Marked as reviewed by rrich (Committer). PR: https://git.openjdk.java.net/jdk/pull/1521 From rrich at openjdk.java.net Fri Dec 4 10:48:11 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 4 Dec 2020 10:48:11 GMT Subject: RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches In-Reply-To: <1A9NfEQw4ZSwCY1yDfGApDSDhBg4egT5aHkH3mH5bA4=.4bece2f9-5a94-4e7d-9225-890769d5cb9f@github.com> References: <66d_EAED3_BRpr9YmIrv1seQFfyUOIPdntMllUyJa-Q=.61c545be-b26d-4d3a-8ac6-e7239656b7a6@github.com> <9zTPHTKnRl4iFRt4baZc-CmVtVR6yxgaeqnWOu7HSiU=.d213fe75-3fd3-4208-af9b-6f301af78d38@github.com> <1A9NfEQw4ZSwCY1yDfGApDSDhBg4egT5aHkH3mH5bA4=.4bece2f9-5a94-4e7d-9225-890769d5cb9f@github.com> Message-ID: On Tue, 1 Dec 2020 17:38:17 GMT, Martin Doerr wrote: >> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 3168: >> >>> 3166: int code_size = 8 * BytesPerInstWord; >>> 3167: CodeBuffer cb("decode_klass_not_null scratch buffer", code_size, 0); >>> 3168: MacroAssembler* a = new MacroAssembler(&cb); >> >> Idle thought: if this is done frequently, maybe MacroAssembler could have a "dry run" mode with no attached CodeBuffer, just counting instructions. > > The scratch emit is only executed during the first call. Afterwards, the computed_size is just returned and we don't call the CodeBuffer constructor any more. I just asked myself how this is thread safe then. Well it is not. The scratch emit ist executed at most once /per thread/ ;) ------------- PR: https://git.openjdk.java.net/jdk/pull/1521 From mdoerr at openjdk.java.net Fri Dec 4 11:29:14 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 4 Dec 2020 11:29:14 GMT Subject: RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches In-Reply-To: References: <66d_EAED3_BRpr9YmIrv1seQFfyUOIPdntMllUyJa-Q=.61c545be-b26d-4d3a-8ac6-e7239656b7a6@github.com> Message-ID: On Fri, 4 Dec 2020 10:45:33 GMT, Richard Reingruber wrote: >> The JVM currently runs into Unimplemented() when using -XX:-UseInlineCaches in C2 code (postalloc_expand_java_dynamic_call_sched). >> I'd like to enable the existing code in postalloc_expand_java_dynamic_call_sched and fix MachCallDynamicJavaNode::ret_addr_offset() and MacroAssembler::instr_size_for_decode_klass_not_null(). >> I suggest to use scratch emit to determine the size, because there are too many cases and emitting it once is fast. > > Looks good to me. > > Thanks, Richard. Thanks a lot for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/1521 From mdoerr at openjdk.java.net Fri Dec 4 11:29:15 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 4 Dec 2020 11:29:15 GMT Subject: RFR: 8257423: [PPC64] Support -XX:-UseInlineCaches In-Reply-To: References: <66d_EAED3_BRpr9YmIrv1seQFfyUOIPdntMllUyJa-Q=.61c545be-b26d-4d3a-8ac6-e7239656b7a6@github.com> <9zTPHTKnRl4iFRt4baZc-CmVtVR6yxgaeqnWOu7HSiU=.d213fe75-3fd3-4208-af9b-6f301af78d38@github.com> <1A9NfEQw4ZSwCY1yDfGApDSDhBg4egT5aHkH3mH5bA4=.4bece2f9-5a94-4e7d-9225-890769d5cb9f@github.com> Message-ID: On Fri, 4 Dec 2020 10:45:22 GMT, Richard Reingruber wrote: >> The scratch emit is only executed during the first call. Afterwards, the computed_size is just returned and we don't call the CodeBuffer constructor any more. > > I just asked myself how this is thread safe then. Well it is not. The scratch emit ist executed at most once /per thread/ ;) Interesting point. Right, it doesn't have to be thread safe. All threads which compute it concurrently will compute the same result. ------------- PR: https://git.openjdk.java.net/jdk/pull/1521 From mdoerr at openjdk.java.net Fri Dec 4 11:29:16 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 4 Dec 2020 11:29:16 GMT Subject: Integrated: 8257423: [PPC64] Support -XX:-UseInlineCaches In-Reply-To: <66d_EAED3_BRpr9YmIrv1seQFfyUOIPdntMllUyJa-Q=.61c545be-b26d-4d3a-8ac6-e7239656b7a6@github.com> References: <66d_EAED3_BRpr9YmIrv1seQFfyUOIPdntMllUyJa-Q=.61c545be-b26d-4d3a-8ac6-e7239656b7a6@github.com> Message-ID: On Mon, 30 Nov 2020 15:37:34 GMT, Martin Doerr wrote: > The JVM currently runs into Unimplemented() when using -XX:-UseInlineCaches in C2 code (postalloc_expand_java_dynamic_call_sched). > I'd like to enable the existing code in postalloc_expand_java_dynamic_call_sched and fix MachCallDynamicJavaNode::ret_addr_offset() and MacroAssembler::instr_size_for_decode_klass_not_null(). > I suggest to use scratch emit to determine the size, because there are too many cases and emitting it once is fast. This pull request has now been integrated. Changeset: 1d2d9815 Author: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/1d2d9815 Stats: 31 lines in 2 files changed: 15 ins; 7 del; 9 mod 8257423: [PPC64] Support -XX:-UseInlineCaches Reviewed-by: stuefe, rrich ------------- PR: https://git.openjdk.java.net/jdk/pull/1521 From stuefe at openjdk.java.net Fri Dec 4 12:18:15 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 12:18:15 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 20:26:23 GMT, Anton Kozlov wrote: > > > > > > madvise(FREE) is not sufficient unfortunately. For executable memory, it's best we can do. But we should not use it for regular memory. > > > > > > How so? What is the difference? > > madvise is really a hint and doesn't have exact effect as a real uncommit. A real, immediately accountable uncommit is a > > https://github.com/openjdk/jdk/blob/114d9cffd62cab42790b65091648fe75345c4533/src/hotspot/os/bsd/os_bsd.cpp#L2015 > > . As I cannot do this for executable memory, I use madvise as an alternative to nothing. I may have not been clear, sorry. My point was: For uncommit, we seem to have the option of either: 1) mmap(MAP_FIXED|MAP_NORESERVE, PROT_NONE) 2) madvise(MADV_FREE) + mprotect(PROT_NONE) You do (1) for !exec, (2) for exec. Why? Either (2) works - reclaims memory for the OS. Then it can be used in all cases, exec or !exec. The commit would be a simple mprotect(PROT_RW). For uncommit, we would need no exec parameter. Or (2) does not work, as you claim. Then why bother at all? Interestingly, your initial proposal would have resulted in the following sequence of calls when committing executable memory: anon_mmap() -> mmap(MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS | MAP_JIT, PROT_NONE) commit_memory() -> mprotect(PROT_READ|PROT_WRITE|PROT_EXEC) Note how on commit_memory() we never clear the MAP_NORESERVE flag. And still commit works? And does not trap on access? Because if that works this is an indication that MAP_NORESERVE has no meaning on MacOS. I found nothing about MAP_NORESERVE in the kernel source you posted [1], in the MacOS manpage for mmap [2] nor the OpenBSD mmap manpage [3]. MAP_NORESERVE is a non-Posix extension, so I wonder if it gets even honored on MacOS or if they just provided the flag to avoid build errors. If MAP_NORESERVE has no meaning, we do not need to call mmap() for committing and uncommitting; mprotect, maybe combined with madvise(MADV_FREE), should suffice. Thanks, Thomas [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 [2] https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/mmap.2.html [3] https://man.openbsd.org/mmap.2 ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From sjohanss at openjdk.java.net Fri Dec 4 12:30:15 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 4 Dec 2020 12:30:15 GMT Subject: RFR: 8243315: ParallelScavengeHeap::initialize() passes GenAlignment as page size to os::trace_page_sizes instead of actual page size In-Reply-To: <_qRBxRvNC_w-dIJBHQuQ1g6u0FglanBbNaryxqtCiF8=.ce17ac67-08ba-4b2a-a360-704fca1f9c94@github.com> References: <0t69lhO_zHj_sg0_doBgHyv5Fpu6Y2OuZsza1NsyE6A=.2a972bf7-5e12-4ce3-9ca2-b2add68d07c5@github.com> <3ZpyM1gAZ0HeDdWd4_Ps98de3IKXvCowyDeFCaso97U=.9694feb3-82d5-4da6-bda6-5431e3dd94d1@github.com> <_imjzmFgjMEABYlW2LnfuyJNqyil1kBrX_A Fmq_LBlc=.7b70d4bd-6257-4436-81ee-19b40953ed10@github.com> <_qRBxRvNC_w-dIJBHQuQ1g6u0FglanBbNaryxqtCiF8=.ce17ac67-08ba-4b2a-a360-704fca1f9c94@github.com> Message-ID: On Thu, 3 Dec 2020 20:24:23 GMT, Thomas Stuefe wrote: >> You are correct that explicit huge pages are pinned and of course there might be situations where it would be beneficial to do the stitching, but I think the maintenance cost will be significantly higher. It sound like you would prefer a simpler model as well and int would certainly be interesting to see if there are any problems connected to getting rid of the mixed mappings we have today. >> >> I also agree that we should do better book keeping since it is so hard to get the information later on. > > Hi guys, > > gentle ping. I know we are all busy with the impending code freeze :) > > I am fine with removing the ability to reserve space with multiple page sizes. But that is something I cannot drive - probably someone at Oracle should, since it has repercussions for GC and for backward compatibility. Might also take a bit longer. > > Meanwhile, we still have the new ReservedSpace::actual_page_size(), which is subtly broken and will be more so once JDK-8234930 is implemented. IIUC you did not like the proposal of making reserve_space_special() return information about the reserved page sizes. That's totally fine for me, but have we decided on how to deal with this instead? > > Cheers, Thomas Hi Thomas, I just filed [JDK-8257757](https://bugs.openjdk.java.net/browse/JDK-8257757) to keep track of this, feel free to add information to it. Let's work together to try to improve this. Cheers, Stefan ------------- PR: https://git.openjdk.java.net/jdk/pull/1161 From shade at openjdk.java.net Fri Dec 4 12:45:15 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 4 Dec 2020 12:45:15 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v19] In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 12:48:30 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: >> >> - Merge branch 'master' into JDK-8252505-blackholes >> - Handle null-checks in intrinsics to maintain the semantics >> - Blackhole takes precedence over all other intrinsics >> - Print Blackhole format >> - Formatting touchups >> - Make sure null-checks are handled correctly after blackholed methods >> - Parallelize and ID the tests properly >> - Multiple arguments tests >> - Remodel blackhole hook as fake intrinsic >> - Remodel CallBlackhole as Blackhole membar >> - ... and 23 more: https://git.openjdk.java.net/jdk/compare/56b15fbb...1c4b1706 > > Looks good! I think testing is all-green in GH Actions. I also passed tier{1,2} locally. Also passes JMH validation tests. I think we are ready to integrate this. @theRealAph, @adinn, @cl4es, want to ack the current patch? ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 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 stefank at openjdk.java.net Fri Dec 4 14:26:24 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 4 Dec 2020 14:26:24 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: On Fri, 4 Dec 2020 06:05:10 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Stefan K I think this mostly looks good, but there are a number of cleanups that I'd like you to consider. src/hotspot/share/runtime/os.cpp line 1852: > 1850: ////// Implementation of PageSizes > 1851: > 1852: void os::PageSizes::add(size_t pagesize) { pagesize => page_size and the same for other places as well. src/hotspot/share/runtime/os.cpp line 1876: > 1874: return 0; > 1875: } > 1876: int l = exact_log2(pagesize) + 1; l is not a good variable name. It's too easy to mistake for 1, depending on font. src/hotspot/share/runtime/os.cpp line 1894: > 1892: size_t os::PageSizes::smallest() const { > 1893: assert(min_page_size() > 0, "Sanity"); > 1894: return next_larger(min_page_size() / 2); I'm not sure why you use min_page_size() / 2 instead of another small enough power_of_2, say the smallest one: return next_larger(1); and thereby get rid of the dependency on the odd min_page_size(). src/hotspot/share/runtime/os.hpp line 126: > 124: static OSThread* _starting_thread; > 125: static address _polling_page; > 126: static PageSizes _page_sizes; Indentation is off by two spaces test/hotspot/gtest/runtime/test_os.cpp line 612: > 610: static const int max_page_size_log2 = (int)(sizeof(size_t) * 8); > 611: > 612: TEST_VM(os, pagesizeset_test_range) { pagesizeset name needs to be updated. test/hotspot/gtest/runtime/test_os.cpp line 613: > 611: > 612: TEST_VM(os, pagesizeset_test_range) { > 613: for (int bit = min_page_size_log2; bit < max_page_size_log2; bit ++) { bit ++ => bit++ : the same in the rest of the file. test/hotspot/gtest/runtime/test_os.cpp line 610: > 608: > 609: static const int min_page_size_log2 = exact_log2(os::min_page_size()); > 610: static const int max_page_size_log2 = (int)(sizeof(size_t) * 8); Could this be simply BitsPerWord? test/hotspot/gtest/runtime/test_os.cpp line 617: > 615: const size_t s = (size_t)1 << bit; > 616: const size_t s2 = (size_t)1 << bit2; > 617: //tty->print_cr(SIZE_FORMAT " - " SIZE_FORMAT, s, s2); Remove? test/hotspot/gtest/runtime/test_os.cpp line 625: > 623: } > 624: ASSERT_EQ((size_t)0, pss.smallest()); > 625: ASSERT_EQ((size_t)0, pss.largest()); This doesn't have to be inside a double nested for loop. This could be single check done once. test/hotspot/gtest/runtime/test_os.cpp line 669: > 667: stringStream ss(buffer, sizeof(buffer)); > 668: pss.print_on(&ss); > 669: // tty->print_cr("%s", buffer); Remove? ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stefank at openjdk.java.net Fri Dec 4 14:26:25 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 4 Dec 2020 14:26:25 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v3] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <_SIKvcTtkVXbdaH-YPzKXZazSvRPBU8i0kBj145q5A4=.e5784a8f-a750-438f-a0f5-82ccb1f9293c@github.com> Message-ID: On Thu, 3 Dec 2020 21:16:07 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Thomas > > src/hotspot/share/runtime/os.cpp line 1859: > >> 1857: bool os::PagesizeSet::is_set(size_t pagesize) const { >> 1858: assert(is_power_of_2(pagesize), "pagesize must be a power of 2: " INTPTR_FORMAT, pagesize); >> 1859: return (_v & pagesize) > 0; > > Why is this `> 0` and not simply `!= 0` I'm not sure if you saw this comment, but is there a reason why > 0 is used here? ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stefank at openjdk.java.net Fri Dec 4 14:26:26 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Fri, 4 Dec 2020 14:26:26 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: On Fri, 4 Dec 2020 13:50:47 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Stefan K > > src/hotspot/share/runtime/os.cpp line 1876: > >> 1874: return 0; >> 1875: } >> 1876: int l = exact_log2(pagesize) + 1; > > l is not a good variable name. It's too easy to mistake for 1, depending on font. FWIW, this calculation was non-obvious when reading this. Maybe something like this would be easier? Feel free to ignore if you don't like it. // Remove current and smaller page sizes size_t v2 = _v & ~(pagesize + (pagesize - 1)) if (v2 == 0) { return 0; } return (size_t)1 << count_trailing_zeros(v2); ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 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 akozlov at openjdk.java.net Fri Dec 4 15:33:14 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 4 Dec 2020 15:33:14 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 12:15:33 GMT, Thomas Stuefe wrote: >>> > > reserve_memory : >>> > > >>> > > * not executable: mmap MAP_NORESERVE, PROT_NONE >>> > > * executable: mmap MAP_JIT _without_ MAP_NORESERVE, PROT_READ|PROT_WRITE|PROT_EXEC (so its committed and accessible right away) >>> > > >>> > > commit_memory >>> > > >>> > > * not executable: mmap without MAP_NORESERVE, PROT_READ|PROT_WRITE >>> > > * executable: (return, nothing to do) >>> > > >>> > > uncommit_memory >>> > > >>> > > * not executable: mmap MAP_NORESERVE, PROT_NONE >>> > > * executable: (return, nothing to do, since you indicate that this is that memory does not get returned to the OS immediately) >>> > > >>> > I'm not sure, what is the aim of the simplification [above]? >>> >>> To remove the coding depending on executable-ness from commit and uncommit. >> >> Sorry, how can e.g uncommit choose executable or not-executable case, if executable parameter is not provided? >> >> --- >> >>> > Now access to uncommitted memory will cause a trap, just like on other platforms. >>> >>> Sorry, you lost me there. Where would I get a trap? >> >> I mean, after a call to pd_uncommit_memory on linux the memory mprotected with PROT_NONE. Any access to that region will generate a signal. >> >> --- >> >>> >>> My point was, for executable=true: >>> >>> * on reserve, commit executable memory right away instead of on-demand committing later >>> * on commit and uncommit, just do nothing >> >> As far as I understand you propose to remove lines 2010 - 2014 https://github.com/openjdk/jdk/blob/114d9cffd62cab42790b65091648fe75345c4533/src/hotspot/os/bsd/os_bsd.cpp#L2010 >> >> but later you suggest (in different context, but the statement is correct) >> >>> The range would still be accessible though, but combining that with mprotect(PROT_NONE) should take care of this >> >> The current implementation does mprotect(NONE). madvice(FREE) is not accounted immediately, but this hint is better than nothing. >> >> --- >> >>> > > Furthermore, about uncommit: I wonder whether madvice(MADV_FREE) would alone be already sufficient to release the memory. I have no Mac and cannot test this. The range would still be accessible though, but combining that with mprotect(PROT_NONE) should take care of this. Then we could just in general avoid the mmap(MAP_NORESERVE|MAP_FIXED) call. Then we do not need the exec parameter for uncommit at all. >>> > >>> > >>> > madvise(FREE) is not sufficient unfortunately. For executable memory, it's best we can do. But we should not use it for regular memory. >>> >>> How so? What is the difference? >> >> madvise is really a hint and doesn't have exact effect as a real uncommit. A real, immediately accountable uncommit is a https://github.com/openjdk/jdk/blob/114d9cffd62cab42790b65091648fe75345c4533/src/hotspot/os/bsd/os_bsd.cpp#L2015. As I cannot do this for executable memory, I use madvise as an alternative to nothing. > >> > > >> > > madvise(FREE) is not sufficient unfortunately. For executable memory, it's best we can do. But we should not use it for regular memory. >> > >> > >> > How so? What is the difference? >> >> madvise is really a hint and doesn't have exact effect as a real uncommit. A real, immediately accountable uncommit is a >> >> https://github.com/openjdk/jdk/blob/114d9cffd62cab42790b65091648fe75345c4533/src/hotspot/os/bsd/os_bsd.cpp#L2015 >> >> . As I cannot do this for executable memory, I use madvise as an alternative to nothing. > > I may have not been clear, sorry. My point was: > > For uncommit, we seem to have the option of either: > > 1) mmap(MAP_FIXED|MAP_NORESERVE, PROT_NONE) > 2) madvise(MADV_FREE) + mprotect(PROT_NONE) > > You do (1) for !exec, (2) for exec. Why? > > Either (2) works - reclaims memory for the OS. Then it can be used in all cases, exec or !exec. The commit would be a simple mprotect(PROT_RW). For uncommit, we would need no exec parameter. > > Or (2) does not work, as you claim. Then why bother at all? > > Interestingly, your initial proposal would have resulted in the following sequence of calls when committing executable memory: > anon_mmap() -> mmap(MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS | MAP_JIT, PROT_NONE) > commit_memory() -> mprotect(PROT_READ|PROT_WRITE|PROT_EXEC) > Note how on commit_memory() we never clear the MAP_NORESERVE flag. And still commit works? And does not trap on access? Because if that works this is an indication that MAP_NORESERVE has no meaning on MacOS. > > I found nothing about MAP_NORESERVE in the kernel source you posted [1], in the MacOS manpage for mmap [2] nor the OpenBSD mmap manpage [3]. MAP_NORESERVE is a non-Posix extension, so I wonder if it gets even honored on MacOS or if they just provided the flag to avoid build errors. > > If MAP_NORESERVE has no meaning, we do not need to call mmap() for committing and uncommitting; mprotect, maybe combined with madvise(MADV_FREE), should suffice. > > Thanks, Thomas > > [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 > [2] https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man2/mmap.2.html > [3] https://man.openbsd.org/mmap.2 > 1. mmap(MAP_FIXED|MAP_NORESERVE, PROT_NONE) > 2. madvise(MADV_FREE) + mprotect(PROT_NONE) > > Or (2) does not work, as you claim. Then why bother at all? Right, (2) is an actual state. It does not work like we'd want to (at least not immediately accounted in RSS). But the OS provides this interface and claims to react in some way. > MADV_FREE Indicates that the application will not need the information contained in this address range, so the pages may be reused right away. The address range will remain valid. This is used with madvise() system call. It enables the OS release the memory sometime later, for example. In contrast, doing nothing will keep the memory that is garbage. > I wonder if [MAP_NORESERVE] gets even honored on MacOS Right, it's defined and not used, the only occurrence is https://github.com/apple/darwin-xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/bsd/sys/mman.h#L116 The use of MAP_NORESRVE slipped in from the original BSD pd_commit_memory code. I can delete it, if it bothers. > If MAP_NORESERVE has no meaning, we do not need to call mmap() for committing and uncommitting; mprotect, maybe combined with madvise(MADV_FREE), should suffice. I could not follow, sorry. Why it's so? Thanks, Anton ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From aph at openjdk.java.net Fri Dec 4 16:02:18 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 4 Dec 2020 16:02:18 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v19] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 12:42:32 GMT, Aleksey Shipilev wrote: > I think testing is all-green in GH Actions. I also passed tier{1,2} locally. Also passes JMH validation tests. I think we are ready to integrate this. @theRealAph, @adinn, @cl4es, want to ack the current patch? I'm testing on AArch64 now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From stuefe at openjdk.java.net Fri Dec 4 16:15:14 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 16:15:14 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 15:30:09 GMT, Anton Kozlov wrote: > > 1. mmap(MAP_FIXED|MAP_NORESERVE, PROT_NONE) > > 2. madvise(MADV_FREE) + mprotect(PROT_NONE) > > > > Or (2) does not work, as you claim. Then why bother at all? > > Right, (2) is an actual state. It does not work like we'd want to (at least not immediately accounted in RSS). But the OS provides this interface and claims to react in some way. > > > ``` > > MADV_FREE Indicates that the application will not need the information contained in this address range, so the pages may be reused right away. The address range will remain valid. This is used with madvise() system call. > > ``` > > It enables the OS release the memory sometime later, for example. In contrast, doing nothing will keep the memory that is garbage. > > > I wonder if [MAP_NORESERVE] gets even honored on MacOS > > Right, it's defined and not used, the only occurrence is https://github.com/apple/darwin-xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/bsd/sys/mman.h#L116 > > The use of MAP_NORESRVE slipped in from the original BSD pd_commit_memory code. I can delete it, if it bothers. > > > If MAP_NORESERVE has no meaning, we do not need to call mmap() for committing and uncommitting; mprotect, maybe combined with madvise(MADV_FREE), should suffice. > > I could not follow, sorry. Why it's so? > Your original chain of thought, if I understand you correctly, was like this: - We want to provide MAP_JIT on a mapping. Apple tells us to. - On reserve, we add it to the initial mmap call. Easy. - But hotspot later - commit/uncommit - replaces that mapping again. With subsequent mmap calls. On those, MAP_FIXED is specified since the original mapping gets replaced. - But on those secondary mmap calls we cannot add MAP_JIT. Because it cannot be combined with MAP_FIXED. - Therefore we switch to: on commit, do mprotect(RW). On uncommit, madvise(MADV_FREE) + mprotect(NONE). Am I right so far? My thought is this: In existing code, the technique used to commit and uncommit memory is to switch the MAP_NORESERVE flag on the mapping, combined with a change in protection. E.g. mmap(MAP_NORESERVE, PROT_NONE) to uncommit. No documentation says this releases memory. But from experience we see it work on Linux - the kernel takes the hint that the pages are not needed anymore. Changing the MAP_NORESERVE flag is the only reason we have those subsequent mmap calls. Those that need MAP_FIXED. And conflict with MAP_JIT. If MAP_NORESERVE is a noop on Mac, the only other effect those mmap calls have is the protection change: in uncommit, the mmap(MAP_NORESERVE|MAP_FIXED, PROT_NONE) would be equivalent to a mprotect(PROT_NONE). Since todays os::uncommit_memory() works on MacOS (at least I assume it does??), then that PROT_NONE protection change must be the reason for it working, since the MAP_NORESERVE is a noop. So, if MAP_NORESERVE is a noop, there is no reason to have secondary calls to mmap(MAP_FIXED), which conflict with MAP_JIT. Then, the code you proposed for the exec=true path should work equally well for the standard path. That would make the coding a lot easier. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/294 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 aph at openjdk.java.net Fri Dec 4 16:30:17 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 4 Dec 2020 16:30:17 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: Message-ID: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> On Fri, 4 Dec 2020 10:07:45 GMT, Aleksey Shipilev wrote: >> JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: >> >> 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. >> 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. >> 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. >> >> Supporting this directly in compilers would improve nanobenchmark fidelity. >> >> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). >> >> C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. >> >> C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the final attempt. >> >> [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. >> >> [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. >> >> ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. >> >> The fourth, and hopefully final attempt is in this PR. It makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Do not print void warning with -XX:-PrintWarnings AArch64 looks good. This is a substantial improvement. There's still a pesky volatile load of isDone inside the inner loop, but that's for another day. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1203 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 stuefe at openjdk.java.net Fri Dec 4 16:46:15 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 16:46:15 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: On Fri, 4 Dec 2020 13:48:25 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Stefan K > > src/hotspot/share/runtime/os.cpp line 1852: > >> 1850: ////// Implementation of PageSizes >> 1851: >> 1852: void os::PageSizes::add(size_t pagesize) { > > pagesize => page_size and the same for other places as well. Oh missed that in your first review, sorry. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 16:51:19 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 16:51:19 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: <1Zy7P5mUhopVWb396qbBSI-csdhSf-BH8YH16XH00pg=.bc247f1a-0817-4839-9d5b-1762b53152c2@github.com> On Fri, 4 Dec 2020 14:08:09 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Stefan K > > src/hotspot/share/runtime/os.cpp line 1894: > >> 1892: size_t os::PageSizes::smallest() const { >> 1893: assert(min_page_size() > 0, "Sanity"); >> 1894: return next_larger(min_page_size() / 2); > > I'm not sure why you use min_page_size() / 2 instead of another small enough power_of_2, say the smallest one: > return next_larger(1); > and thereby get rid of the dependency on the odd min_page_size(). True. Earlier implementation had a lop in next_larger. But now it does not matter. 1 is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 16:51:16 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 16:51:16 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: On Fri, 4 Dec 2020 13:59:51 GMT, Stefan Karlsson wrote: >> src/hotspot/share/runtime/os.cpp line 1876: >> >>> 1874: return 0; >>> 1875: } >>> 1876: int l = exact_log2(pagesize) + 1; >> >> l is not a good variable name. It's too easy to mistake for 1, depending on font. > > FWIW, this calculation was non-obvious when reading this. Maybe something like this would be easier? Feel free to ignore if you don't like it. > // Remove current and smaller page sizes > size_t v2 = _v & ~(pagesize + (pagesize - 1)) > if (v2 == 0) { > return 0; > } > return (size_t)1 << count_trailing_zeros(v2); I like yours more. Its clearer. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 16:51:20 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 16:51:20 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: <1Zy7P5mUhopVWb396qbBSI-csdhSf-BH8YH16XH00pg=.bc247f1a-0817-4839-9d5b-1762b53152c2@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> <1Zy7P5mUhopVWb396qbBSI-csdhSf-BH8YH16XH00pg=.bc247f1a-0817-4839-9d5b-1762b53152c2@github.com> Message-ID: On Fri, 4 Dec 2020 16:47:30 GMT, Thomas Stuefe wrote: >> src/hotspot/share/runtime/os.cpp line 1894: >> >>> 1892: size_t os::PageSizes::smallest() const { >>> 1893: assert(min_page_size() > 0, "Sanity"); >>> 1894: return next_larger(min_page_size() / 2); >> >> I'm not sure why you use min_page_size() / 2 instead of another small enough power_of_2, say the smallest one: >> return next_larger(1); >> and thereby get rid of the dependency on the odd min_page_size(). > > True. Earlier implementation had a lop in next_larger. But now it does not matter. 1 is fine. (Note that min_page_size should be really a constant, and named differently. I have this mentally marked as another small cleanup) ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 17:03:16 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 17:03:16 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: On Fri, 4 Dec 2020 14:20:17 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Stefan K > > test/hotspot/gtest/runtime/test_os.cpp line 625: > >> 623: } >> 624: ASSERT_EQ((size_t)0, pss.smallest()); >> 625: ASSERT_EQ((size_t)0, pss.largest()); > > This doesn't have to be inside a double nested for loop. This could be single check done once. I think I just remove it. Its pretty pointless, since we test for smallest=largest=0, and since we later test each bit individually in lines 645ff. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From iklam at openjdk.java.net Fri Dec 4 17:04:15 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 4 Dec 2020 17:04:15 GMT Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> Message-ID: On Fri, 4 Dec 2020 09:43:58 GMT, Aleksey Shipilev wrote: > I have a suggestion: let's wait until JDK 16 forks for stabilization before we do any `#include` reshuffling? There are build breakages from these changes, so it would be nice to have these breakages away from the stabilizing repository. OK, I'll push in JDK 17. ------------- PR: https://git.openjdk.java.net/jdk/pull/1610 From stuefe at openjdk.java.net Fri Dec 4 17:24:26 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 17:24:26 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v5] In-Reply-To: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: > Hi, > > may I please have reviews for the following very small improvement: > > While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: > > size_t os::_page_sizes[os::page_sizes_max]; > > is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. > > Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). > > That has the following advantages: > - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. > - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. > > ----- > > The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. > > > Testing: > - nightlies at SAP > - manual tests with UseLargePages > - the new gtests > - gh actions (with x86 still failing because of unrelated issues) > > Thank you, > > Thomas > > [1] https://bugs.openjdk.java.net/browse/JDK-8243315 > [2] https://bugs.openjdk.java.net/browse/JDK-8256155 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Feedback Stefan (2) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1522/files - new: https://git.openjdk.java.net/jdk/pull/1522/files/23569726..919d90bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=03-04 Stats: 38 lines in 3 files changed: 1 ins; 7 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/1522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1522/head:pull/1522 PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Fri Dec 4 17:24:26 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Dec 2020 17:24:26 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v4] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8QojbBOct76cXEzxdr-McnWvyFlr2BpMfn6QVi6srQQ=.ea1638e8-23e3-46c3-aa78-e372bafcee43@github.com> Message-ID: On Fri, 4 Dec 2020 14:23:43 GMT, Stefan Karlsson wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Feedback Stefan K > > I think this mostly looks good, but there are a number of cleanups that I'd like you to consider. Hi Stefan, I pushed a new commit with the changes you requested. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 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 jbhateja at openjdk.java.net Fri Dec 4 18:34:24 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 4 Dec 2020 18:34:24 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations Message-ID: A newly allocated memory is initialized either using user provided initialization values for various fields or setting the memory to zero as per java semantics (System initialization). C2 compiler creates ClearArray Node in order to perform system initialization. ClearArray accepts the number of Heap Words to be initialized, this number can be constant or a non-constant value. For constant number of heap words less than InitArrayShortSize (default value 64 bytes) currently compiler generates StoreL nodes which does the initialization at the granularity of 8 bytes. This patch vectorizes the initializing store operations for constant sized heap word less than InitArrayShortSize by emitting special instruction sequence for various tail sizes. In addition existing implementation for initialization under UseXMMForObjInit is extended to use masked operation to optimize tail initialization sequence. In case AVX3Threshold is set to 0 then new initialization sequence uses 64 byte ZMM registers. Following are the performance stats collected using micro-benchmark included with the patch. Testing : Tier1-Tier3 level tests are clean. System Configuration : Cascadelake, Intel Xeon Platinum 8280L @ 2.7 GHz, 2 socket, 28 cores per socket. Baseline: Benchmark Mode Cnt Score Error Units ClearMemory.testClearMemory3 thrpt 10 212508.522 ?? 14071.493 ops/s ClearMemory.testClearMemory4 thrpt 10 189530.643 ?? 12882.421 ops/s ClearMemory.testClearMemory5 thrpt 10 167878.803 ?? 10307.163 ops/s ClearMemory.testClearMemory6 thrpt 10 152732.184 ?? 8740.128 ops/s ClearMemory.testClearMemory7 thrpt 10 132111.536 ?? 5493.043 ops/s With Optimization: Benchmark Mode Cnt Score Error Units ClearMemory.testClearMemory3 thrpt 10 220378.082 ?? 18533.701 ops/s ClearMemory.testClearMemory4 thrpt 10 198023.913 ?? 15995.780 ops/s ClearMemory.testClearMemory5 thrpt 10 183476.886 ?? 13488.821 ops/s ClearMemory.testClearMemory6 thrpt 10 161710.750 ?? 9270.182 ops/s ClearMemory.testClearMemory7 thrpt 10 145059.426 ?? 8217.484 ops/s ------------- Commit messages: - 8257772: Vectorizing clear memory operation using AVX-512 masked operations Changes: https://git.openjdk.java.net/jdk/pull/1631/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1631&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257772 Stats: 349 lines in 7 files changed: 321 ins; 3 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/1631.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1631/head:pull/1631 PR: https://git.openjdk.java.net/jdk/pull/1631 From kvn at openjdk.java.net Fri Dec 4 18:58:14 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 4 Dec 2020 18:58:14 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 18:28:44 GMT, Jatin Bhateja wrote: > A newly allocated memory is initialized either using user provided initialization values for various fields or setting the memory to zero as per java semantics (System initialization). > > C2 compiler creates ClearArray Node in order to perform system initialization. ClearArray accepts the number of Heap Words to be initialized, this number can be constant or a non-constant value. For constant number of heap words less than InitArrayShortSize (default value 64 bytes) currently compiler generates StoreL nodes which does the initialization at the granularity of 8 bytes. > > This patch vectorizes the initializing store operations for constant sized heap word less than InitArrayShortSize by emitting special instruction sequence for various tail sizes. > > In addition existing implementation for initialization under UseXMMForObjInit is extended to use masked operation to optimize tail initialization sequence. In case AVX3Threshold is set to 0 then new initialization sequence uses 64 byte ZMM registers. > > Following are the performance stats collected using micro-benchmark included with the patch. > > Testing : Tier1-Tier3 level tests are clean. > > System Configuration : Cascadelake, Intel Xeon Platinum 8280L @ 2.7 GHz, 2 socket, 28 cores per socket. > > Baseline: > Benchmark Mode Cnt Score Error Units > ClearMemory.testClearMemory3 thrpt 10 212508.522 ?? 14071.493 ops/s > ClearMemory.testClearMemory4 thrpt 10 189530.643 ?? 12882.421 ops/s > ClearMemory.testClearMemory5 thrpt 10 167878.803 ?? 10307.163 ops/s > ClearMemory.testClearMemory6 thrpt 10 152732.184 ?? 8740.128 ops/s > ClearMemory.testClearMemory7 thrpt 10 132111.536 ?? 5493.043 ops/s > > With Optimization: > > Benchmark Mode Cnt Score Error Units > ClearMemory.testClearMemory3 thrpt 10 220378.082 ?? 18533.701 ops/s > ClearMemory.testClearMemory4 thrpt 10 198023.913 ?? 15995.780 ops/s > ClearMemory.testClearMemory5 thrpt 10 183476.886 ?? 13488.821 ops/s > ClearMemory.testClearMemory6 thrpt 10 161710.750 ?? 9270.182 ops/s > ClearMemory.testClearMemory7 thrpt 10 145059.426 ?? 8217.484 ops/s src/hotspot/cpu/x86/x86_64.ad line 10856: > 10854: %} > 10855: > 10856: instruct rep_stos_im(immL cnt, rRegP base, regD tmp, rRegI zero, Universe dummy, rFlagsReg cr) What about x86_32.ad? ------------- PR: https://git.openjdk.java.net/jdk/pull/1631 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 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: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 akozlov at openjdk.java.net Fri Dec 4 21:22:15 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 4 Dec 2020 21:22:15 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: Message-ID: <3A8yXtEkRQymlaf0L15jBPViSYPFlMIKxp7aefZyv2E=.25a4e984-17a7-4a38-9ce4-c37c2f0dc428@github.com> On Fri, 4 Dec 2020 16:12:24 GMT, Thomas Stuefe wrote: > > > 1. mmap(MAP_FIXED|MAP_NORESERVE, PROT_NONE) > > > 2. madvise(MADV_FREE) + mprotect(PROT_NONE) > > > > > > Or (2) does not work, as you claim. Then why bother at all? > > > > > > Right, (2) is an actual state. It does not work like we'd want to (at least not immediately accounted in RSS). But the OS provides this interface and claims to react in some way. > > > ``` > > > MADV_FREE Indicates that the application will not need the information contained in this address range, so the pages may be reused right away. The address range will remain valid. This is used with madvise() system call. > > > ``` > > > > > > It enables the OS release the memory sometime later, for example. In contrast, doing nothing will keep the memory that is garbage. > > > I wonder if [MAP_NORESERVE] gets even honored on MacOS > > > > > > Right, it's defined and not used, the only occurrence is https://github.com/apple/darwin-xnu/blob/0a798f6738bc1db01281fc08ae024145e84df927/bsd/sys/mman.h#L116 > > The use of MAP_NORESRVE slipped in from the original BSD pd_commit_memory code. I can delete it, if it bothers. > > > If MAP_NORESERVE has no meaning, we do not need to call mmap() for committing and uncommitting; mprotect, maybe combined with madvise(MADV_FREE), should suffice. > > > > > > I could not follow, sorry. Why it's so? > > Your original chain of thought, if I understand you correctly, was like this: > > * We want to provide MAP_JIT on a mapping. Apple tells us to. > * On reserve, we add it to the initial mmap call. Easy. > * But hotspot later - commit/uncommit - replaces that mapping again. With subsequent mmap calls. On those, MAP_FIXED is specified since the original mapping gets replaced. > * But on those secondary mmap calls we cannot add MAP_JIT. Because it cannot be combined with MAP_FIXED. > * Therefore we switch to: on commit, do mprotect(RW). On uncommit, madvise(MADV_FREE) + mprotect(NONE). > > Am I right so far? That's correct. > > My thought is this: > > In existing code, the technique used to commit and uncommit memory is to switch the MAP_NORESERVE flag on the mapping, combined with a change in protection. I read this as MAP_NORESERVE is supposed to be an attribute of the mapping. I don't think this is true. On Linux it specifies, can the system overcommit in statisfying this mapping (https://man7.org/linux/man-pages/man2/mmap.2.html) By default overcommit is enabled and MAP_NORESERVE is also a "noop" on Linux, i.e. it specifies the mode that is enabled for all mappings anyway. This also mean that you can drop MAP_NORESERVE flag from uncommit and it will work anyway, on Linux and macOS. What definition of MAP_NORESERVE do you use? > E.g. mmap(MAP_NORESERVE, PROT_NONE) to uncommit. No documentation says this releases memory. But from experience we see it work on Linux - the kernel takes the hint that the pages are not needed anymore. It's not a hint. From https://man7.org/linux/man-pages/man2/mmap.2.html: > If the memory region specified by addr and len overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) *will be discarded.* So one of uncommit's tasks is to release the memory. > If MAP_NORESERVE is a noop on Mac, the only other effect those mmap calls have is the protection change: in uncommit, the mmap(MAP_NORESERVE|MAP_FIXED, PROT_NONE) would be equivalent to a mprotect(PROT_NONE). mmap(MAP_NORESERVE, ...) is equal to mmap(...), but it does not mean that mmap(MAP_NORESERVE) is noop. Also, after you do mprotect(NONE), you can do mprotect(RWX) and get back the original content. But after you do mmap(FIXED) the memory content is discarded, you cannot reverse this operation. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 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 akozlov at openjdk.java.net Fri Dec 4 22:29:25 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 4 Dec 2020 22:29:25 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v7] In-Reply-To: References: Message-ID: <4mw_qwllDU7qLgqcm7Z_kxyGICpv18HZ_LrbidneSw4=.891574d8-45a6-4ecd-9dc9-be2070bdc3e6@github.com> > Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html > > On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, PROT_NONE), the function was made aware of exec permissions. > > For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference compared with old code. > > For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not shrink (if I haven't missed anything, by the implementation and in principle). > > Tested: > * local tier1 > * jdk-submit > * codesign[2] with hardened runtime and allow-jit but without > allow-unsigned-executable-memory entitlements[3] produce a working bundle. > > (adding GC group as suggested by @dholmes-ora) > > > [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 > [2] > > codesign \ > --sign - \ > --options runtime \ > --entitlements ents.plist \ > --timestamp \ > $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib > [3] > > > > > com.apple.security.cs.allow-jit > > com.apple.security.cs.disable-library-validation > > com.apple.security.cs.allow-dyld-environment-variables > > > Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision: - Fix style - JDK-8234930 v4: Use MAP_JIT when allocating pages for code cache on macOS - Revert "Separate executable_memory interface" This reverts commit 49253d8fe8963ce069f10783dcea5327079ba848. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/294/files - new: https://git.openjdk.java.net/jdk/pull/294/files/49253d8f..b3eb5b01 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=05-06 Stats: 363 lines in 29 files changed: 46 ins; 175 del; 142 mod Patch: https://git.openjdk.java.net/jdk/pull/294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/294/head:pull/294 PR: https://git.openjdk.java.net/jdk/pull/294 From coleenp at openjdk.java.net Fri Dec 4 23:25:12 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 4 Dec 2020 23:25:12 GMT Subject: RFR: 8243205: Modularize JVM flags declaration In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 21:51:42 GMT, Ioi Lam wrote: > This is the first step for modularizing the xxx_globals.hpp. The goals are > > - Improve modularization of HotSpot source > - Reduce JVM build time > > To prove that this works, I have moved compiler_globals.hpp outside of the monolithic globals.hpp. Before this fix, compiler_globals.hpp was included by 922 HotSpot .o files. After this fix, it's included by 283 .o files. > > I plan to do more refactoring later, such as: > > - move gc_globals.hpp out of globals.hpp > - move the flags related to tiered compilation (about 40 flags) out of globals.hpp > - move the platform-specific flags outside of globals.hpp > - these flags should be used only by platform-specific files. They shouldn't be used by shared files. > > Note: this is target for JDK 17. > > Testing: I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. Ok, this makes sense. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1608 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 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 david.holmes at oracle.com Sat Dec 5 05:00:36 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 5 Dec 2020 15:00:36 +1000 Subject: Linux large pages: why do we have UseSHM? In-Reply-To: References: Message-ID: <16b6ca70-8032-1c99-1af4-6af1a1c5795d@oracle.com> Hi Thomas, On 4/12/2020 4:48 am, Thomas St?fe wrote: > Hi, > > I wonder why we support two different ways (discounting THPs) to allocate > huge pages on Linux. > > We support allocating huge pages both via System V shm APIs (UseSHM) and > via the "newer" mmap Posix APIs (UseHugeTLBFS). The latter is default for > +UseLargePages. We had the UseSHM stuff first. The UseHugeTLBFS stuff came later. See this discussion: http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-April/004063.html and the related bug that made the changes: https://bugs.openjdk.java.net/browse/JDK-7034464 HTH. David > I do not see a practical difference beside the fact that: > - System V shm API is slightly fussier to use (eg no partial unmap possible) > - it requires kernel.shmmax to be correctly set, in addition to the > vm.nr_xxx_hugepages > - it requires more user permissions > > But in the end, we end up with kernel huge pages, one way or the other. > Both give access to 2M and 1G pages. > > I looked through mailing list archives and bug descriptions, but beyond > vague mentionings of "one way could fail, then try the other" I did not > find anything. > > I must be missing something. Does anyone have any closer knowledge > about this? > > Thank you! > > Thomas > From stuefe at openjdk.java.net Sat Dec 5 05:38:14 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 5 Dec 2020 05:38:14 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: <3A8yXtEkRQymlaf0L15jBPViSYPFlMIKxp7aefZyv2E=.25a4e984-17a7-4a38-9ce4-c37c2f0dc428@github.com> References: <3A8yXtEkRQymlaf0L15jBPViSYPFlMIKxp7aefZyv2E=.25a4e984-17a7-4a38-9ce4-c37c2f0dc428@github.com> Message-ID: On Fri, 4 Dec 2020 21:19:53 GMT, Anton Kozlov wrote: > > > > Your original chain of thought, if I understand you correctly, was like this: > > > > * We want to provide MAP_JIT on a mapping. Apple tells us to. > > * On reserve, we add it to the initial mmap call. Easy. > > * But hotspot later - commit/uncommit - replaces that mapping again. With subsequent mmap calls. On those, MAP_FIXED is specified since the original mapping gets replaced. > > * But on those secondary mmap calls we cannot add MAP_JIT. Because it cannot be combined with MAP_FIXED. > > * Therefore we switch to: on commit, do mprotect(RW). On uncommit, madvise(MADV_FREE) + mprotect(NONE). > > > > Am I right so far? > > That's correct. > > > My thought is this: > > In existing code, the technique used to commit and uncommit memory is to switch the MAP_NORESERVE flag on the mapping, combined with a change in protection. > > I read this as MAP_NORESERVE is supposed to be an attribute of the mapping. I don't think this is true. On Linux it specifies, can the system overcommit in statisfying this mapping (https://man7.org/linux/man-pages/man2/mmap.2.html) By default overcommit is enabled and MAP_NORESERVE is also a "noop" on Linux, i.e. it specifies the mode that is enabled for all mappings anyway. Thats not true. On Linux, if you mmap without specifying MAP_NORESERVE, the mmap size will increase your process commit charge. What that means depends on the overcommit setting. The default setting is a heuristic one where you are allowed some overcharging but there is a limit. My experience is that this mode gives us about 150% of the overcharge limit, after that you get allocation failures. > This also mean that you can drop MAP_NORESERVE flag from uncommit and it will work anyway, on Linux and macOS. > > What definition of MAP_NORESERVE do you use? > > > E.g. mmap(MAP_NORESERVE, PROT_NONE) to uncommit. No documentation says this releases memory. But from experience we see it work on Linux - the kernel takes the hint that the pages are not needed anymore. > > It's not a hint. From https://man7.org/linux/man-pages/man2/mmap.2.html: > > > If the memory region specified by addr and len > > overlaps pages of any existing mapping(s), then the overlapped > > part of the existing mapping(s) _will be discarded._ > > So one of uncommit's tasks is to release the memory. > > > If MAP_NORESERVE is a noop on Mac, the only other effect those mmap calls have is the protection change: in uncommit, the mmap(MAP_NORESERVE|MAP_FIXED, PROT_NONE) would be equivalent to a mprotect(PROT_NONE). > > mmap(MAP_NORESERVE, ...) is equal to mmap(...), but it does not mean that mmap(MAP_NORESERVE) is noop. > > Also, after you do mprotect(NONE), you can do mprotect(RWX) and get back the original content. But after you do mmap(FIXED) the memory content is discarded, you cannot reverse this operation. Oh you are right! I had this completely wrong. The reclaim effect is not caused by the fact that we specify MAP_NORELEASE. That's incidental. It comes from us plain replacing the old mapping with a blank new one and thereby discarding the old mapping? So MAP_NORESERVE may not matter but mmap is still needed. Strictly speaking probably not even PROT_NONE would matter to have a reclaim effect. You could just map the new mapping with full rights and the memory would still reclaimed and stay that way until next time you touch it. Then commit could be a no-op (this is how things work on AIX). Okay, I think I get closer to understanding the problem: - on reserve we create mapping 1 with MAP_JIT - on uncommit, we replace the mapping with mapping 2, discarding mapping 1. mapping 2 does not need MAP_JIT. If we never recommit thats fine. - but then, on re-commit, we replace mapping 2 with mapping 3. mapping 3 again needs MAP_JIT. But since this needs MAP_FIXED, MAP_JIT will not work. In other words, once a mapping with MAP_JIT is established, we must never replace it, since any subsequent mmap calls would need to be established with MAP_FIXED. Sigh. My only remaining question is: is there really an observable difference between replacing the mapping with mmap and calling madvice(MADV_FREE)? And if there is, does it matter in practice? I wonder if the perceived difference between madvise(MADV_FREE) and mmap() is just a display problem. Seems the kernel is lazy about reclaiming that memory - but that is fine and makes sense performance wise, it just throws off statistics. By that logic, using mmap() tries to second-guess what the kernel does could maybe be inferior to using madvise. I found this: https://stackoverflow.com/questions/7718964/how-can-i-force-macos-to-release-madv-freed-pages. One remark recommends MADV_FREE_REUSABLE to deal with the display problem; could that be a solution (still aiming for using madvise() for all, not just executable, mappings, thereby removing the need to pass exec to commit/uncommit). Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From david.holmes at oracle.com Sat Dec 5 05:41:02 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 5 Dec 2020 15:41:02 +1000 Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> Message-ID: On 4/12/2020 7:46 pm, Aleksey Shipilev wrote: > On Fri, 4 Dec 2020 00:48:16 GMT, Ioi Lam wrote: > >>>>> Make sure all builds are passed. >>>> >>>> @vnkozlov @coleenp I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. >>> >>> Good. Please, list testing in your PR descriptions so that we know what you did. >> >>>>> Make sure all builds are passed. >>>> >>>> >>>> @vnkozlov @coleenp I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. >>> >>> Good. Please, list testing in your PR descriptions so that we know what you did. >> >> Done. I updated the PR descriptions. > > I have a suggestion: let's wait until JDK 16 forks for stabilization before we do any `#include` reshuffling? There are build breakages from these changes, so it would be nice to have these breakages away from the stabilizing repository. With sufficient pre-integration testing this should not be an issue. It seems for JDK-8257563 no GitHub actions were run and so numerous build variants were missed. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1610 > From thomas.stuefe at gmail.com Sat Dec 5 06:25:58 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 5 Dec 2020 07:25:58 +0100 Subject: Linux large pages: why do we have UseSHM? In-Reply-To: <16b6ca70-8032-1c99-1af4-6af1a1c5795d@oracle.com> References: <16b6ca70-8032-1c99-1af4-6af1a1c5795d@oracle.com> Message-ID: Hi David, thanks a lot, David. This made a lot of things clearer (BTW I wish the patch links would work for these old bugs in JBS). So here is what I understand: UseSHM had been there first. Then JDK-7034464 introduced Transparent Huge Pages. Those needs madvise(MADV_HUGEPAGE). For TPH, allocating via mmap(MAP_HUGETLB) was added alongside the old shmget(). I am not sure why, would TPH not have worked with shmget()? But anyway, for a while TLBFS was synonymous with TPH. Later we had https://bugs.openjdk.java.net/browse/JDK-8024838, which claimed TPH were responsible for performance problems and switched support for them off by default. This left the mmap(MAP_HUGETLB) allocation intact but avoided now using TPH. So it gave us the new explicit-TLBFS mode (UseHugeTLBFS). Interestingly, one of the reasons JDK-7034464 gave for using mmap() instead of SHM was that mmap can be committed on demand. That is true (you can call mmap on every part of a mapping), but later with https://bugs.openjdk.java.net/browse/JDK-8007074 this capability had been switched off. Commit on demand would need to mmap(MAP_HUGETLBFS) to commit and uncommit a mapping, but that may fail if the huge page pool is exhausted, which would make the mmap call fail, which would introduce a hole in the reserved space which concurrently running code could accidentally mmap into... so, in effect, TLBFS is always committed now. There are still some holes in my understanding. But mainly, I wonder whether we still need UseSHM. Would love to hear opinions. Thanks! Thomas On Sat, Dec 5, 2020 at 6:33 AM David Holmes wrote: > Hi Thomas, > > On 4/12/2020 4:48 am, Thomas St?fe wrote: > > Hi, > > > > I wonder why we support two different ways (discounting THPs) to allocate > > huge pages on Linux. > > > > We support allocating huge pages both via System V shm APIs (UseSHM) and > > via the "newer" mmap Posix APIs (UseHugeTLBFS). The latter is default for > > +UseLargePages. > > We had the UseSHM stuff first. The UseHugeTLBFS stuff came later. See > this discussion: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-April/004063.html > > and the related bug that made the changes: > > https://bugs.openjdk.java.net/browse/JDK-7034464 > > HTH. > > David > > > I do not see a practical difference beside the fact that: > > - System V shm API is slightly fussier to use (eg no partial unmap > possible) > > - it requires kernel.shmmax to be correctly set, in addition to the > > vm.nr_xxx_hugepages > > - it requires more user permissions > > > > But in the end, we end up with kernel huge pages, one way or the other. > > Both give access to 2M and 1G pages. > > > > I looked through mailing list archives and bug descriptions, but beyond > > vague mentionings of "one way could fail, then try the other" I did not > > find anything. > > > > I must be missing something. Does anyone have any closer knowledge > > about this? > > > > Thank you! > > > > Thomas > > > From volker.simonis at gmail.com Sat Dec 5 06:43:39 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 5 Dec 2020 07:43:39 +0100 Subject: Linux large pages: why do we have UseSHM? In-Reply-To: References: <16b6ca70-8032-1c99-1af4-6af1a1c5795d@oracle.com> Message-ID: Thomas St?fe schrieb am Sa., 5. Dez. 2020, 07:26: > Hi David, > > thanks a lot, David. This made a lot of things clearer (BTW I wish the > patch links would work for these old bugs in JBS). > You probably already know this, so just for reference. The patch hashes are still valid in all existing Mercurial repositories, just some of the old team repos have disappeared. The easiest and quickest way to view such a change is to click on the commit link and than replace the team repo with the corresponding main repo. E.g. instead of: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/139667d9836a use: http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/139667d9836a > So here is what I understand: > > UseSHM had been there first. > > Then JDK-7034464 introduced Transparent Huge Pages. Those needs > madvise(MADV_HUGEPAGE). For TPH, allocating via mmap(MAP_HUGETLB) was added > alongside the old shmget(). I am not sure why, would TPH not have worked > with shmget()? But anyway, for a while TLBFS was synonymous with TPH. > > Later we had https://bugs.openjdk.java.net/browse/JDK-8024838, which > claimed TPH were responsible for performance problems and switched support > for them off by default. This left the mmap(MAP_HUGETLB) allocation intact > but avoided now using TPH. So it gave us the new explicit-TLBFS mode > (UseHugeTLBFS). > > Interestingly, one of the reasons JDK-7034464 gave for using mmap() instead > of SHM was that mmap can be committed on demand. That is true (you can call > mmap on every part of a mapping), but later with > https://bugs.openjdk.java.net/browse/JDK-8007074 this capability had been > switched off. Commit on demand would need to mmap(MAP_HUGETLBFS) to commit > and uncommit a mapping, but that may fail if the huge page pool is > exhausted, which would make the mmap call fail, which would introduce a > hole in the reserved space which concurrently running code could > accidentally mmap into... so, in effect, TLBFS is always committed now. > > There are still some holes in my understanding. But mainly, I wonder > whether we still need UseSHM. Would love to hear opinions. > > Thanks! Thomas > > On Sat, Dec 5, 2020 at 6:33 AM David Holmes > wrote: > > > Hi Thomas, > > > > On 4/12/2020 4:48 am, Thomas St?fe wrote: > > > Hi, > > > > > > I wonder why we support two different ways (discounting THPs) to > allocate > > > huge pages on Linux. > > > > > > We support allocating huge pages both via System V shm APIs (UseSHM) > and > > > via the "newer" mmap Posix APIs (UseHugeTLBFS). The latter is default > for > > > +UseLargePages. > > > > We had the UseSHM stuff first. The UseHugeTLBFS stuff came later. See > > this discussion: > > > > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-April/004063.html > > > > and the related bug that made the changes: > > > > https://bugs.openjdk.java.net/browse/JDK-7034464 > > > > HTH. > > > > David > > > > > I do not see a practical difference beside the fact that: > > > - System V shm API is slightly fussier to use (eg no partial unmap > > possible) > > > - it requires kernel.shmmax to be correctly set, in addition to the > > > vm.nr_xxx_hugepages > > > - it requires more user permissions > > > > > > But in the end, we end up with kernel huge pages, one way or the other. > > > Both give access to 2M and 1G pages. > > > > > > I looked through mailing list archives and bug descriptions, but beyond > > > vague mentionings of "one way could fail, then try the other" I did not > > > find anything. > > > > > > I must be missing something. Does anyone have any closer knowledge > > > about this? > > > > > > Thank you! > > > > > > Thomas > > > > > > From thomas.stuefe at gmail.com Sat Dec 5 06:51:44 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 5 Dec 2020 07:51:44 +0100 Subject: Linux large pages: why do we have UseSHM? In-Reply-To: References: <16b6ca70-8032-1c99-1af4-6af1a1c5795d@oracle.com> Message-ID: Thanks for the tip Volker! I ended up cloning the repo, but it is good to know that I don't have to. Cheers, Thomas On Sat, Dec 5, 2020 at 7:43 AM Volker Simonis wrote: > Thomas St?fe schrieb am Sa., 5. Dez. 2020, > 07:26: > >> Hi David, >> >> thanks a lot, David. This made a lot of things clearer (BTW I wish the >> patch links would work for these old bugs in JBS). >> > > You probably already know this, so just for reference. The patch hashes > are still valid in all existing Mercurial repositories, just some of the > old team repos have disappeared. > > The easiest and quickest way to view such a change is to click on the > commit link and than replace the team repo with the corresponding main > repo. E.g. instead of: > > http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/139667d9836a > > use: > > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/139667d9836a > > > >> So here is what I understand: >> >> UseSHM had been there first. >> >> Then JDK-7034464 introduced Transparent Huge Pages. Those needs >> madvise(MADV_HUGEPAGE). For TPH, allocating via mmap(MAP_HUGETLB) was >> added >> alongside the old shmget(). I am not sure why, would TPH not have worked >> with shmget()? But anyway, for a while TLBFS was synonymous with TPH. >> >> Later we had https://bugs.openjdk.java.net/browse/JDK-8024838, which >> claimed TPH were responsible for performance problems and switched support >> for them off by default. This left the mmap(MAP_HUGETLB) allocation intact >> but avoided now using TPH. So it gave us the new explicit-TLBFS mode >> (UseHugeTLBFS). >> >> Interestingly, one of the reasons JDK-7034464 gave for using mmap() >> instead >> of SHM was that mmap can be committed on demand. That is true (you can >> call >> mmap on every part of a mapping), but later with >> https://bugs.openjdk.java.net/browse/JDK-8007074 this capability had been >> switched off. Commit on demand would need to mmap(MAP_HUGETLBFS) to commit >> and uncommit a mapping, but that may fail if the huge page pool is >> exhausted, which would make the mmap call fail, which would introduce a >> hole in the reserved space which concurrently running code could >> accidentally mmap into... so, in effect, TLBFS is always committed now. >> >> There are still some holes in my understanding. But mainly, I wonder >> whether we still need UseSHM. Would love to hear opinions. >> >> Thanks! Thomas >> >> On Sat, Dec 5, 2020 at 6:33 AM David Holmes >> wrote: >> >> > Hi Thomas, >> > >> > On 4/12/2020 4:48 am, Thomas St?fe wrote: >> > > Hi, >> > > >> > > I wonder why we support two different ways (discounting THPs) to >> allocate >> > > huge pages on Linux. >> > > >> > > We support allocating huge pages both via System V shm APIs (UseSHM) >> and >> > > via the "newer" mmap Posix APIs (UseHugeTLBFS). The latter is default >> for >> > > +UseLargePages. >> > >> > We had the UseSHM stuff first. The UseHugeTLBFS stuff came later. See >> > this discussion: >> > >> > >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-April/004063.html >> > >> > and the related bug that made the changes: >> > >> > https://bugs.openjdk.java.net/browse/JDK-7034464 >> > >> > HTH. >> > >> > David >> > >> > > I do not see a practical difference beside the fact that: >> > > - System V shm API is slightly fussier to use (eg no partial unmap >> > possible) >> > > - it requires kernel.shmmax to be correctly set, in addition to the >> > > vm.nr_xxx_hugepages >> > > - it requires more user permissions >> > > >> > > But in the end, we end up with kernel huge pages, one way or the >> other. >> > > Both give access to 2M and 1G pages. >> > > >> > > I looked through mailing list archives and bug descriptions, but >> beyond >> > > vague mentionings of "one way could fail, then try the other" I did >> not >> > > find anything. >> > > >> > > I must be missing something. Does anyone have any closer knowledge >> > > about this? >> > > >> > > Thank you! >> > > >> > > Thomas >> > > >> > >> > From akozlov at openjdk.java.net Sat Dec 5 10:56:13 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Sat, 5 Dec 2020 10:56:13 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: <3A8yXtEkRQymlaf0L15jBPViSYPFlMIKxp7aefZyv2E=.25a4e984-17a7-4a38-9ce4-c37c2f0dc428@github.com> Message-ID: <0Rl1rgfPK8tQJ9KPwMTTTqlN_GjyxjIwBSUXtHIvUyo=.11610ef7-95f8-4d8d-872a-f38960d320ff@github.com> On Sat, 5 Dec 2020 05:34:57 GMT, Thomas Stuefe wrote: > I found this: https://stackoverflow.com/questions/7718964/how-can-i-force-macos-to-release-madv-freed-pages. One remark recommends MADV_FREE_REUSABLE to deal with the display problem; could that be a solution I'd found MADV_FREE_REUSABLE as well. One problem is that it's barely documented. The only description from the vendor I could find was #define MADV_FREE 5 /* pages unneeded, discard contents */ #define MADV_ZERO_WIRED_PAGES 6 /* zero the wired pages that have not been unwired before the entry is deleted */ #define MADV_FREE_REUSABLE 7 /* pages can be reused (by anyone) */ #define MADV_FREE_REUSE 8 /* caller wants to reuse those pages */ The other problem, it cannot substitute mmap completely, see below. > My only remaining question is: is there really an observable difference between replacing the mapping with mmap and calling madvice(MADV_FREE)? And if there is, does it matter in practice? Yes, it is. For a sample program after uncommit implemented by different ways, mmap the only way to reduce occupied memory size in Activity Monitor (system GUI application user will likely look to). * no uncommit ./test noop do not uncommit Physical footprint: 512.3M Physical footprint (peak): 512.3M VM_ALLOCATE 109951000-111951000 [128.0M 128.0M 128.0M 0K] rw-/rwx SM=COW VM_ALLOCATE 111951000-119951000 [128.0M 128.0M 128.0M 0K] rw-/rwx SM=COW VM_ALLOCATE 119951000-121951000 [128.0M 128.0M 128.0M 0K] rw-/rwx SM=COW VM_ALLOCATE 121951000-129951000 [128.0M 128.0M 128.0M 0K] rw-/rwx SM=COW VIRTUAL RESIDENT DIRTY SWAPPED VOLATILE NONVOL EMPTY REGION REGION TYPE SIZE SIZE SIZE SIZE SIZE SIZE SIZE COUNT (non-coalesced) =========== ======= ======== ===== ======= ======== ====== ===== ======= VM_ALLOCATE 512.0M 512.0M 512.0M 0K 0K 0K 0K 4 * MADV_FREE reduces Dirty size, but does not affect Rss and Physical footprint ./test madv_free madvise Physical footprint: 512.3M Physical footprint (peak): 512.3M VM_ALLOCATE 108269000-110269000 [128.0M 128.0M 0K 0K] rw-/rwx SM=COW VM_ALLOCATE 110269000-118269000 [128.0M 128.0M 0K 0K] rw-/rwx SM=COW VM_ALLOCATE 118269000-120269000 [128.0M 128.0M 0K 0K] rw-/rwx SM=COW VM_ALLOCATE 120269000-128269000 [128.0M 128.0M 0K 0K] rw-/rwx SM=COW VIRTUAL RESIDENT DIRTY SWAPPED VOLATILE NONVOL EMPTY REGION REGION TYPE SIZE SIZE SIZE SIZE SIZE SIZE SIZE COUNT (non-coalesced) =========== ======= ======== ===== ======= ======== ====== ===== ======= VM_ALLOCATE 512.0M 512.0M 0K 0K 0K 0K 0K 4 * MADV_FREE_REUSABLE reduces Physical footprint (whatever it is) ./test madv_free_reuse madvise reuse Physical footprint: 292K Physical footprint (peak): 512.3M VM_ALLOCATE 10d568000-115568000 [128.0M 128.0M 0K 0K] rw-/rwx SM=COW VM_ALLOCATE 115568000-11d568000 [128.0M 128.0M 0K 0K] rw-/rwx SM=COW VM_ALLOCATE 11d568000-125568000 [128.0M 128.0M 0K 0K] rw-/rwx SM=COW VM_ALLOCATE 125568000-12d568000 [128.0M 128.0M 0K 0K] rw-/rwx SM=COW VIRTUAL RESIDENT DIRTY SWAPPED VOLATILE NONVOL EMPTY REGION REGION TYPE SIZE SIZE SIZE SIZE SIZE SIZE SIZE COUNT (non-coalesced) =========== ======= ======== ===== ======= ======== ====== ===== ======= VM_ALLOCATE 512.0M 512.0M 0K 0K 0K 0K 0K 4 There is a problem that Activity Monitor apparently looks for Rss and reports no change: ![2020-12-05-130210_956x42_scrot](https://user-images.githubusercontent.com/919084/101240204-d51d6a80-36fe-11eb-806b-30c06ad90a81.png) * and mmap reduces Rss as well ./test mmap new mmap Physical footprint: 292K Physical footprint (peak): 512.3M VM_ALLOCATE 10df01000-12df01000 [512.0M 0K 0K 0K] ---/rwx SM=NUL VIRTUAL RESIDENT DIRTY SWAPPED VOLATILE NONVOL EMPTY REGION REGION TYPE SIZE SIZE SIZE SIZE SIZE SIZE SIZE COUNT (non-coalesced) =========== ======= ======== ===== ======= ======== ====== ===== ======= VM_ALLOCATE 512.0M 0K 0K 0K 0K 0K 0K Activity Monitor (results are OK now) ![2020-12-05-131429_973x36_scrot](https://user-images.githubusercontent.com/919084/101240215-ea929480-36fe-11eb-858a-cef8a0f3327e.png) So, when possible, we should do new mmap for uncommit. --- Source code for the test: #include #include #include #include #include int main(int argc, char *argv[]) { char r; int pagesize = 4096; int size = 512 * 1024 * 1024; char *a = mmap(NULL, size, PROT_NONE, MAP_ANON | MAP_PRIVATE, -1, 0); if (a == MAP_FAILED) { perror("mmap()"); return 1; } if (mprotect(a, size, PROT_READ | PROT_WRITE)) { perror("mprotect"); return 1; } for (int i = 0; i < size; i += 4096) { a[i] = 1; } if (!strcmp(argv[1], "madv_free")) { printf("madvise\n"); if (mprotect(a, PROT_NONE, size)) { perror("mprotect"); return 1; } if (madvise(a, size, MADV_FREE)) { perror("madvise"); return 1; } } else if (!strcmp(argv[1], "madv_free_reuse")) { printf("madvise reuse\n"); if (mprotect(a, PROT_NONE, size)) { perror("mprotect"); return 1; } if (madvise(a, size, MADV_FREE_REUSABLE)) { perror("madvise"); return 1; } } else if (!strcmp(argv[1], "mmap")) { printf("new mmap\n"); if (MAP_FAILED == mmap(a, size, PROT_NONE, MAP_ANON | MAP_PRIVATE| MAP_FIXED, -1, 0)) { perror("mmap2"); return 1; } } else { printf("do not uncommit\n"); } fflush(stdout); char cmd[128]; snprintf(cmd, sizeof(cmd), "vmmap %d | awk '/Phys/ || /VM_ALLOCATE/'", getpid()); system(cmd); read(0, &r, 1); return 0; } ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From redestad at openjdk.java.net Sat Dec 5 11:32:12 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Sat, 5 Dec 2020 11:32:12 GMT Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> Message-ID: On Fri, 4 Dec 2020 17:00:57 GMT, Ioi Lam wrote: >> I have a suggestion: let's wait until JDK 16 forks for stabilization before we do any `#include` reshuffling? There are build breakages from these changes, so it would be nice to have these breakages away from the stabilizing repository. > >> I have a suggestion: let's wait until JDK 16 forks for stabilization before we do any `#include` reshuffling? There are build breakages from these changes, so it would be nice to have these breakages away from the stabilizing repository. > > OK, I'll push in JDK 17. > With sufficient pre-integration testing this should not be an issue. It > seems for JDK-8257563 no GitHub actions were run and so numerous build > variants were missed. And since there's likely going to be some churn happening in tandem in both mainline and stabilization fork in the coming weeks, wouldn't it be better to get changes like these pushed _before_ rather than right after the JDK 16 stabilization fork is created? The second best option might be to hold off with large cleanups/reshuffling until RDP2 starts. ------------- PR: https://git.openjdk.java.net/jdk/pull/1610 From redestad at openjdk.java.net Sat Dec 5 13:18:20 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Sat, 5 Dec 2020 13:18:20 GMT Subject: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() Message-ID: This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. With PCH disabled, this reduces total includes from 276949 to 276332 ------------- Commit messages: - remote merge - Prepare for 1237 changes - Adjust includes after vmIntrinsic changes - Merge master - Outline is_call_site_target to remove include from ciField.hpp - Outline is_autobox_cache to remove include from ciField.hpp - Merge branch 'master' into ciSymbols - Fix bad definition - Define debug-only sid_ok in .cpp to avoid need to include vmSymbols.hpp in ciSymbol.hpp - Revert accidental include order swap - ... and 1 more: https://git.openjdk.java.net/jdk/compare/86b65756...b05957b8 Changes: https://git.openjdk.java.net/jdk/pull/1256/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1256&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256424 Stats: 174 lines in 32 files changed: 102 ins; 30 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/1256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1256/head:pull/1256 PR: https://git.openjdk.java.net/jdk/pull/1256 From stuefe at openjdk.java.net Sat Dec 5 13:26:14 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 5 Dec 2020 13:26:14 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: <0Rl1rgfPK8tQJ9KPwMTTTqlN_GjyxjIwBSUXtHIvUyo=.11610ef7-95f8-4d8d-872a-f38960d320ff@github.com> References: <3A8yXtEkRQymlaf0L15jBPViSYPFlMIKxp7aefZyv2E=.25a4e984-17a7-4a38-9ce4-c37c2f0dc428@github.com> <0Rl1rgfPK8tQJ9KPwMTTTqlN_GjyxjIwBSUXtHIvUyo=.11610ef7-95f8-4d8d-872a-f38960d320ff@github.com> Message-ID: On Sat, 5 Dec 2020 10:52:03 GMT, Anton Kozlov wrote: > > I found this: https://stackoverflow.com/questions/7718964/how-can-i-force-macos-to-release-madv-freed-pages. One remark recommends MADV_FREE_REUSABLE to deal with the display problem; could that be a solution > > I'd found MADV_FREE_REUSABLE as well. One problem is that it's barely documented. The only description from the vendor I could find was > > ``` > #define MADV_FREE 5 /* pages unneeded, discard contents */ > #define MADV_ZERO_WIRED_PAGES 6 /* zero the wired pages that have not been unwired before the entry is deleted */ > #define MADV_FREE_REUSABLE 7 /* pages can be reused (by anyone) */ > #define MADV_FREE_REUSE 8 /* caller wants to reuse those pages */ > ``` > > The other problem, it cannot substitute mmap completely, see below. > > > My only remaining question is: is there really an observable difference between replacing the mapping with mmap and calling madvice(MADV_FREE)? And if there is, does it matter in practice? > > Yes, it is. For a sample program after uncommit implemented by different ways, mmap the only way to reduce occupied memory size in Activity Monitor (system GUI application user will likely look to). > Okay, I see. Thanks for these tests, they are valuable. My one remaining doubt would be if the numbers were different in the face of memory pressure. But I don't like to block this PR anymore, I caused enough work and discussions. So I am fine with the general thrust of the change: - add exec to reserve and uncommit - with the contract being that the exec parameter handed in with commit and uncommit has to match the one used with reserve. Maybe we can have future improvements with these interfaces and reduce the complexity again (e.g. having an opaque handle structure holding mapping creation information). Is the current version review-worthy? Thanks a lot for your patience, ..Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From akozlov at openjdk.java.net Sat Dec 5 14:55:12 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Sat, 5 Dec 2020 14:55:12 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: References: <3A8yXtEkRQymlaf0L15jBPViSYPFlMIKxp7aefZyv2E=.25a4e984-17a7-4a38-9ce4-c37c2f0dc428@github.com> <0Rl1rgfPK8tQJ9KPwMTTTqlN_GjyxjIwBSUXtHIvUyo=.11610ef7-95f8-4d8d-872a-f38960d320ff@github.com> Message-ID: <3tNI7G1GOXjH1xIJQoGswrg3DC63zq6FE3_wSnhAd4Y=.952df04c-71d9-48a0-aff2-7c2d64dbfeda@github.com> On Sat, 5 Dec 2020 13:23:26 GMT, Thomas Stuefe wrote: > So I am fine with the general thrust of the change: > * add exec to reserve and uncommit > * with the contract being that the exec parameter handed in with commit and uncommit has to match the one used with reserve. The latest version implements this approach. It's ready for review. Thanks, Anton ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From jbhateja at openjdk.java.net Sat Dec 5 18:07:28 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sat, 5 Dec 2020 18:07:28 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v2] In-Reply-To: References: Message-ID: > A newly allocated memory is initialized either using user provided initialization values for various fields or setting the memory to zero as per java semantics (System initialization). > > C2 compiler creates ClearArray Node in order to perform system initialization. ClearArray accepts the number of Heap Words to be initialized, this number can be constant or a non-constant value. For constant number of heap words less than InitArrayShortSize (default value 64 bytes) currently compiler generates StoreL nodes which does the initialization at the granularity of 8 bytes. > > This patch vectorizes the initializing store operations for constant sized heap word less than InitArrayShortSize by emitting special instruction sequence for various tail sizes. > > In addition existing implementation for initialization under UseXMMForObjInit is extended to use masked operation to optimize tail initialization sequence. In case AVX3Threshold is set to 0 then new initialization sequence uses 64 byte ZMM registers. > > Following are the performance stats collected using micro-benchmark included with the patch. > > Testing : Tier1-Tier3 level tests are clean. > > System Configuration : Cascadelake, Intel Xeon Platinum 8280L @ 2.7 GHz, 2 socket, 28 cores per socket. > > Baseline: > Benchmark Mode Cnt Score Error Units > ClearMemory.testClearMemory3 thrpt 10 212508.522 ?? 14071.493 ops/s > ClearMemory.testClearMemory4 thrpt 10 189530.643 ?? 12882.421 ops/s > ClearMemory.testClearMemory5 thrpt 10 167878.803 ?? 10307.163 ops/s > ClearMemory.testClearMemory6 thrpt 10 152732.184 ?? 8740.128 ops/s > ClearMemory.testClearMemory7 thrpt 10 132111.536 ?? 5493.043 ops/s > > With Optimization: > > Benchmark Mode Cnt Score Error Units > ClearMemory.testClearMemory3 thrpt 10 220378.082 ?? 18533.701 ops/s > ClearMemory.testClearMemory4 thrpt 10 198023.913 ?? 15995.780 ops/s > ClearMemory.testClearMemory5 thrpt 10 183476.886 ?? 13488.821 ops/s > ClearMemory.testClearMemory6 thrpt 10 161710.750 ?? 9270.182 ops/s > ClearMemory.testClearMemory7 thrpt 10 145059.426 ?? 8217.484 ops/s Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8257772: Changes for 32 bit build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1631/files - new: https://git.openjdk.java.net/jdk/pull/1631/files/3abd47b9..cc024e7f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1631&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1631&range=00-01 Stats: 155 lines in 4 files changed: 77 ins; 67 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1631.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1631/head:pull/1631 PR: https://git.openjdk.java.net/jdk/pull/1631 From jbhateja at openjdk.java.net Sat Dec 5 18:10:14 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sat, 5 Dec 2020 18:10:14 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v2] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 18:54:57 GMT, Vladimir Kozlov wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8257772: Changes for 32 bit build > > src/hotspot/cpu/x86/x86_64.ad line 10856: > >> 10854: %} >> 10855: >> 10856: instruct rep_stos_im(immL cnt, rRegP base, regD tmp, rRegI zero, Universe dummy, rFlagsReg cr) > > What about x86_32.ad? Hi Vladimir, Pattern has been added in x86_32.ad ------------- PR: https://git.openjdk.java.net/jdk/pull/1631 From david.holmes at oracle.com Sun Dec 6 10:15:42 2020 From: david.holmes at oracle.com (David Holmes) Date: Sun, 6 Dec 2020 20:15:42 +1000 Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> Message-ID: On 5/12/2020 9:32 pm, Claes Redestad wrote: > On Fri, 4 Dec 2020 17:00:57 GMT, Ioi Lam wrote: > >>> I have a suggestion: let's wait until JDK 16 forks for stabilization before we do any `#include` reshuffling? There are build breakages from these changes, so it would be nice to have these breakages away from the stabilizing repository. >> >>> I have a suggestion: let's wait until JDK 16 forks for stabilization before we do any `#include` reshuffling? There are build breakages from these changes, so it would be nice to have these breakages away from the stabilizing repository. >> >> OK, I'll push in JDK 17. > >> With sufficient pre-integration testing this should not be an issue. It >> seems for JDK-8257563 no GitHub actions were run and so numerous build >> variants were missed. > > And since there's likely going to be some churn happening in tandem in both mainline and stabilization fork in the coming weeks, wouldn't it be better to get changes like these pushed _before_ rather than right after the JDK 16 stabilization fork is created? The second best option might be to hold off with large cleanups/reshuffling until RDP2 starts. I think the point was to defer to this to be 17 only so no churn at all in 16 RDP1 or RDP2. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1610 > From claes.redestad at oracle.com Sun Dec 6 11:23:28 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 6 Dec 2020 12:23:28 +0100 Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> Message-ID: On 2020-12-06 11:15, David Holmes wrote: >> >> And since there's likely going to be some churn happening in tandem in >> both mainline and stabilization fork in the coming weeks, wouldn't it >> be better to get changes like these pushed _before_ rather than right >> after the JDK 16 stabilization fork is created? The second best option >> might be to hold off with large cleanups/reshuffling until RDP2 starts. > > I think the point was to defer to this to be 17 only so no churn at all > in 16 RDP1 or RDP2. Seems we're talking past each other: - The churn I'm referring to is the regular weeks (or months) of bug fixing and forward-porting that happen after a stabilization fork - not some highly unlikely churnpocalypse resulting from this patch in particular. - Getting this into 17 right after the stabilization fork means we have an increased risk of merge conflicts etc, which means the automatic forward porting of pushes to 16 will be in peril. So what I'm suggesting here is to either: - Get this tested out on all platforms and pushed _now_ to reduce risk of conflicts during 16 stabilization OR - Wait until some time after 16 forks to get past the 16 stabilization churn to minimize risk of conflicts during stabilization that might prohibit automatic forward porting. I have a preference for the former. /Claes From david.holmes at oracle.com Sun Dec 6 13:19:31 2020 From: david.holmes at oracle.com (David Holmes) Date: Sun, 6 Dec 2020 23:19:31 +1000 Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> Message-ID: <3d1bba59-b949-3902-3b74-c4900c0b210b@oracle.com> On 6/12/2020 9:23 pm, Claes Redestad wrote: > On 2020-12-06 11:15, David Holmes wrote: >>> >>> And since there's likely going to be some churn happening in tandem >>> in both mainline and stabilization fork in the coming weeks, wouldn't >>> it be better to get changes like these pushed _before_ rather than >>> right after the JDK 16 stabilization fork is created? The second best >>> option might be to hold off with large cleanups/reshuffling until >>> RDP2 starts. >> >> I think the point was to defer to this to be 17 only so no churn at >> all in 16 RDP1 or RDP2. > > Seems we're talking past each other: > > - The churn I'm referring to is the regular weeks (or months) of bug > fixing and forward-porting that happen after a stabilization fork - not > some highly unlikely churnpocalypse resulting from this patch in > particular. I've no idea what you mean by this. > - Getting this into 17 right after the stabilization fork means we have > an increased risk of merge conflicts etc, which means the automatic > forward porting of pushes to 16 will be in peril. True this could impact the form of changes in 16 versus 17. > So what I'm suggesting here is to either: > > - Get this tested out on all platforms and pushed _now_ to reduce risk > of conflicts during 16 stabilization > > OR > > - Wait until some time after 16 forks to get past the 16 stabilization > churn to minimize risk of conflicts during stabilization that might > prohibit automatic forward porting. > > I have a preference for the former. Okay. I also prefer the former. The previous issue with this kind of patch was lack of testing, so as long as we have adequate testing this kind of refactoring should be a non-issue. Blocking this kind of change effectively introduces a de-facto RDP0. David ----- > /Claes > > > > From shade at openjdk.java.net Sun Dec 6 17:44:13 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 6 Dec 2020 17:44:13 GMT Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> Message-ID: <06cb7IIR-9ans5Ovq1CbI_-WTt6a8Wtpodne_YuL4GU=.e1834260-c908-4a0b-901d-d3317ad05c9a@github.com> On Sat, 5 Dec 2020 11:29:41 GMT, Claes Redestad wrote: >>> I have a suggestion: let's wait until JDK 16 forks for stabilization before we do any `#include` reshuffling? There are build breakages from these changes, so it would be nice to have these breakages away from the stabilizing repository. >> >> OK, I'll push in JDK 17. > >> With sufficient pre-integration testing this should not be an issue. It >> seems for JDK-8257563 no GitHub actions were run and so numerous build >> variants were missed. > > And since there's likely going to be some churn happening in tandem in both mainline and stabilization fork in the coming weeks, wouldn't it be better to get changes like these pushed _before_ rather than right after the JDK 16 stabilization fork is created? The second best option might be to hold off with large cleanups/reshuffling until RDP2 starts. I don't mind pushing it for JDK 16. I was just suggesting that we defer somewhat intrusive cleanups to JDK 17, as it customary to do (at least in my vicinity) in order to have everyone else build/test based on clean master in the days coming to JDK 16 cutoff. But we could instead pay more attention to the state of master and fix the follow-up build failure bugs even more promptly this week. ------------- PR: https://git.openjdk.java.net/jdk/pull/1610 From shade at openjdk.java.net Sun Dec 6 17:47:16 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 6 Dec 2020 17:47:16 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> Message-ID: On Fri, 4 Dec 2020 16:27:49 GMT, Andrew Haley wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Do not print void warning with -XX:-PrintWarnings > > AArch64 looks good. This is a substantial improvement. There's still a pesky volatile load of isDone inside the inner loop, but that's for another day. Thank you all, that was a wild ride. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Sun Dec 6 17:47:17 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Sun, 6 Dec 2020 17:47:17 GMT Subject: Integrated: 8252505: C1/C2 compiler support for blackholes In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 13:23:44 GMT, Aleksey Shipilev wrote: > JMH uses the [`Blackhole::consume`](https://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-core/src/main/java/org/openjdk/jmh/infra/Blackhole.java#l153) methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks: > > 1. Call costs dominate nanobenchmarks. On TR 3970X, the call cost is several nanoseconds. > 2. The work spent in Blackhole.consume dominates nanobenchmarks too. It takes about a nanosecond on TR 3970X. > 3. Argument preparation for call makes different argument types behave differently. This is prominent on architectures where calling conventions for passing e.g. floating-point arguments require elaborate dance. > > Supporting this directly in compilers would improve nanobenchmark fidelity. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its Blackhole methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. This is being prototyped as [CODETOOLS-7902762](https://bugs.openjdk.java.net/browse/CODETOOLS-7902762). It makes Blackholes behave [substantially better](http://cr.openjdk.java.net/~shade/8252505/bh-old-vs-new.png). > > C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. > > C2 code is more complicated. There were four attempts to implement this, and what you see in the PR is the final attempt. > > [First attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.01/) was to introduce fake store like `StoreV` ("store void"), and then lower them to nothing. It runs into a series of funky problems: you would like to have at least two shapes of the store to match the store type width not to confuse the optimizer, or even have the whole mirror of `Store*` hierarchy. Additionally, optimizer tweaks were needed. The awkward problem of GC barrier verification showed up: if `StoreV*` is a subclass of `Store*`, then verificators rightfully expect GC barriers before them. If we emit GC, then we need to handle walking over `StoreV*` nodes in optimizers. > > [Second attempt](http://cr.openjdk.java.net/~shade/8252505/webrev.04/) was to introduce the special `Blackhole` node that consumes the values -- basically like C1 implementation does it. Alas, the many attempts to make sure the new node is not DCE'd failed. Roland looked at it, and suggested that there seems to be no way to model the effects we are after: consume the value, but have no observable side effects. So, suggested we instead put the boolean flag onto `CallJavaNode`, and then match it to nothing in `.ad`. > > ...which is the essence of the third attempt. Drag the blackhole through C2 as if it has call-like side effects, and then emit nothing. Instead of boolean flag, the subsequent iteration introduced a full new `CallBlackhole` node, that is a call as far as optimizers are concerned, and then it is matched to nothing in `.ad`. > > The fourth, and hopefully final attempt is in this PR. It makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. This pull request has now been integrated. Changeset: e5906189 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/e5906189 Stats: 1520 lines in 30 files changed: 1518 ins; 0 del; 2 mod 8252505: C1/C2 compiler support for blackholes Reviewed-by: vlivanov, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From redestad at openjdk.java.net Sun Dec 6 18:42:12 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Sun, 6 Dec 2020 18:42:12 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> Message-ID: On Sun, 6 Dec 2020 17:42:52 GMT, Aleksey Shipilev wrote: >> AArch64 looks good. This is a substantial improvement. There's still a pesky volatile load of isDone inside the inner loop, but that's for another day. > > Thank you all, that was a wild ride. Looks much better! No platform dependent changes and seems relatively straightforward. Since it's only used by `BlackholeNode` then maybe `RegMask::All` should have been a field in `BlackholeNode` rather than a global? (Caught a cold last week and lost track of this - apologies for going silent and being late to the party here.) ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From ioi.lam at oracle.com Sun Dec 6 18:59:14 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 6 Dec 2020 10:59:14 -0800 Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: <06cb7IIR-9ans5Ovq1CbI_-WTt6a8Wtpodne_YuL4GU=.e1834260-c908-4a0b-901d-d3317ad05c9a@github.com> References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> <06cb7IIR-9ans5Ovq1CbI_-WTt6a8Wtpodne_YuL4GU=.e1834260-c908-4a0b-901d-d3317ad05c9a@github.com> Message-ID: On 12/6/20 9:44 AM, Aleksey Shipilev wrote: > On Sat, 5 Dec 2020 11:29:41 GMT, Claes Redestad wrote: > >>>> I have a suggestion: let's wait until JDK 16 forks for stabilization before we do any `#include` reshuffling? There are build breakages from these changes, so it would be nice to have these breakages away from the stabilizing repository. >>> OK, I'll push in JDK 17. >>> With sufficient pre-integration testing this should not be an issue. It >>> seems for JDK-8257563 no GitHub actions were run and so numerous build >>> variants were missed. >> And since there's likely going to be some churn happening in tandem in both mainline and stabilization fork in the coming weeks, wouldn't it be better to get changes like these pushed _before_ rather than right after the JDK 16 stabilization fork is created? The second best option might be to hold off with large cleanups/reshuffling until RDP2 starts. Just to be clear -- this is not a "disruptive" commit. It's unlikely to cause problems when backporting unrelated commits from the mainline back to JDK 16. This commit discovers existing problems in the HotSpot code -- many source files do not explicitly include header files for the APIs they reference. Instead, they rely on another header file (sometimes many recursions away) to include the required header files. For example: c1_LIRAssembler_aarch64.cpp calls StubRoutines::generic_arraycopy(). However, it didn't explicitly include stubRoutines.hpp, but relied on thread.hpp to do that. After stubRoutines.hpp is removed from thread.hpp, c1_LIRAssembler_aarch64.cpp fails to compile. So the majority of the the changes in this commit is *adding* #includes in the CPP files. This by definition can only cause FEWER build failures if this commit is pushed into JDK 16. Conversely, if this commit is not pushed in JDK 16, I can imagine in some edge scenarios that? an unrelated backport into 16 cannot be cleanly applied. But this will require a second backport that *removes* headers from an HPP file (which will be unlikely to be backported in the first place). In any case, even if this happens, any breakage can be easily fixed by adding #includes in the backport, and we have such backports from time to time anyway. So in my opinion, it doesn't really matter if this commit is in JDK 16 or not. > I don't mind pushing it for JDK 16. I was just suggesting that we defer somewhat intrusive cleanups to JDK 17, as it customary to do (at least in my vicinity) in order to have everyone else build/test based on clean master in the days coming to JDK 16 cutoff. But we could instead pay more attention to the state of master and fix the follow-up build failure bugs even more promptly this week. > I agree with this. In the event this commit breaks something in a build that I haven't tested, a follow-up commit needs to be pushed. It would be nice to push this commit after the cutoff to avoid the need to backport the follow-up commit. Thanks - Ioi From ioi.lam at oracle.com Sun Dec 6 19:18:55 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 6 Dec 2020 11:18:55 -0800 Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> Message-ID: On 12/6/20 3:23 AM, Claes Redestad wrote: > > > On 2020-12-06 11:15, David Holmes wrote: >>> >>> And since there's likely going to be some churn happening in tandem >>> in both mainline and stabilization fork in the coming weeks, >>> wouldn't it be better to get changes like these pushed _before_ >>> rather than right after the JDK 16 stabilization fork is created? >>> The second best option might be to hold off with large >>> cleanups/reshuffling until RDP2 starts. >> >> I think the point was to defer to this to be 17 only so no churn at >> all in 16 RDP1 or RDP2. > > Seems we're talking past each other: > > - The churn I'm referring to is the regular weeks (or months) of bug > fixing and forward-porting that happen after a stabilization fork - not > some highly unlikely churnpocalypse resulting from this patch in > particular. > > - Getting this into 17 right after the stabilization fork means we have > an increased risk of merge conflicts etc, which means the automatic > forward porting of pushes to 16 will be in peril. > > So what I'm suggesting here is to either: > > - Get this tested out on all platforms and pushed _now_ to reduce risk > of conflicts during 16 stabilization > > OR > > - Wait until some time after 16 forks to get past the 16 stabilization > churn to minimize risk of conflicts during stabilization that might > prohibit automatic forward porting. > Notwithstanding my claim that this commit is not a disruptive one .... Do we have a policy of withholding disruptive changes in the mainline during the RDP timeline? Thanks - Ioi > I have a preference for the former. > > /Claes > > > > From david.holmes at oracle.com Sun Dec 6 21:36:04 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Dec 2020 07:36:04 +1000 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> Message-ID: <33420129-5eb1-8dff-c5bc-9c5123699c0f@oracle.com> On 7/12/2020 3:47 am, Aleksey Shipilev wrote: > On Fri, 4 Dec 2020 16:27:49 GMT, Andrew Haley wrote: > >>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Do not print void warning with -XX:-PrintWarnings >> >> AArch64 looks good. This is a substantial improvement. There's still a pesky volatile load of isDone inside the inner loop, but that's for another day. > > Thank you all, that was a wild ride. The new tests you added are failing in numerous ways across all platforms in our CI testing. I will file a bug if noone has already. David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1203 > From github.com+5550412+thomaswue at openjdk.java.net Sun Dec 6 22:44:15 2020 From: github.com+5550412+thomaswue at openjdk.java.net (Thomas Wuerthinger) Date: Sun, 6 Dec 2020 22:44:15 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> Message-ID: On Sun, 6 Dec 2020 18:38:27 GMT, Claes Redestad wrote: >> Thank you all, that was a wild ride. > > Looks much better! No platform dependent changes and seems relatively straightforward. > > Since it's only used by `BlackholeNode` then maybe `RegMask::All` should have been a field in `BlackholeNode` rather than a global? > > (Caught a cold last week and lost track of this - apologies for going silent and being late to the party here.) Is this the first compile command that can be used to modify the functional behaviour of the Java user application? ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Mon Dec 7 07:02:16 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Dec 2020 07:02:16 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> Message-ID: On Sun, 6 Dec 2020 22:39:17 GMT, Thomas Wuerthinger wrote: > Is this the first compile command that can be used to modify the functional behaviour of the Java user application? I believe you can say that if we ignore `BreakAt*` commands. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From kim.barrett at oracle.com Mon Dec 7 08:02:34 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 7 Dec 2020 03:02:34 -0500 Subject: HotSpot Style Guide change process In-Reply-To: References: <376E1F97-57DE-46CD-B656-BC5340E0BA07@oracle.com> Message-ID: > On Dec 2, 2020, at 9:25 AM, Thomas St?fe wrote: > On Wed, Dec 2, 2020 at 12:04 PM Kim Barrett wrote: >> I?d still like to get some feedback on the mechanics. Is what I?ve done for a couple >> of changes working for folks? That is, is using a normal github PR for the change, >> with ?yes? votes via review approvals, good enough? Are there changes that would >> make this work better? I?m mostly worried that we seem to be getting more or less >> the same small group of people. I can?t tell if that?s because others aren?t bothering, >> or are they not noticing. We want high visibility on changes to the Style Guide. >> > > Hi Kim, > > For me, it is not lack of interest. But changes to the style guide often drift to the bottom of the pile since there is so much to do, and discussing them takes time. I understand that. I've been intentionally sticking to things I think should be uncontroversial for the initial few modifications from the recent big update, to help figure out details of the process. There are a number of items "in the queue" that I expect will be more contentious. > hotspot-dev being out of commission for so long in summer did not help either. Yes, having hotspot-dev be effectively Oracle-internal-only for a critical period was not at all helpful. > I sometimes do feel ambivalent about new features, like they don't bring enough to the table to justify the churn. One example, Uniform Initialization increased the number of idioms one has to know, without simplifying anything, since old-style initialization won't go away. But my emotions are never strong enough to publicly block such a proposal with a negative vote, especially in the face of exclusively positive feedback. Perhaps my expections of what should be uncontroversial might be a bit off? If you want to revisit that one, I'm fine with doing so. Obviously, I have opinions... The point of "rough consensus" is that it really isn't a vote, it's an attempt to determine both whether there is general support and, at least as importantly, whether there is something wrong with the proposal such that it needs to be fixed or something else should be done (including not making a change at all). > I have no ready proposals of how to improve the process, just the vague feeling that PRs are maybe a bit low-key. And sometimes move too fast. Especially since the mail flood increased a lot since we switched to skara tooling. That's part of why I've been intentionally sending them out with a time window for discussion, and not treating them like normal PRs that can be integrated as soon as the requisite number of reviews are obtained and comments addressed. But there isn't currently anything really highlighting these PRs and the associated email threads as "special", other than having "HotSpot Style Guide" in the subject. From stefank at openjdk.java.net Mon Dec 7 08:16:16 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 7 Dec 2020 08:16:16 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v5] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Fri, 4 Dec 2020 17:24:26 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Feedback Stefan (2) Thanks! Looks good. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1522 From stefank at openjdk.java.net Mon Dec 7 08:38:15 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 7 Dec 2020 08:38:15 GMT Subject: RFR: 8243205: Modularize JVM flags declaration In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 21:51:42 GMT, Ioi Lam wrote: > This is the first step for modularizing the xxx_globals.hpp. The goals are > > - Improve modularization of HotSpot source > - Reduce JVM build time > > To prove that this works, I have moved compiler_globals.hpp outside of the monolithic globals.hpp. Before this fix, compiler_globals.hpp was included by 922 HotSpot .o files. After this fix, it's included by 283 .o files. > > I plan to do more refactoring later, such as: > > - move gc_globals.hpp out of globals.hpp > - move the flags related to tiered compilation (about 40 flags) out of globals.hpp > - move the platform-specific flags outside of globals.hpp > - these flags should be used only by platform-specific files. They shouldn't be used by shared files. > > Note: this is target for JDK 17. > > Testing: I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. Thanks for tackling this. src/hotspot/share/compiler/compiler_globals_pd.hpp line 26: > 24: > 25: #ifndef SHARE_COMPILER_COMPILER_GLOBALS_DEF_HPP > 26: #define SHARE_COMPILER_COMPILER_GLOBALS_DEF_HPP Should this be SHARE_COMPILER_COMPILER_GLOBALS_PD_HPP src/hotspot/share/compiler/compiler_globals_pd.hpp line 44: > 42: // JVMCI has no platform-specific global definitions > 43: //#if INCLUDE_JVMCI > 44: //#include "jvmci/jvmci_globals_def.hpp" jvmci_globals_def.hpp => jvmci_globals_pd.hpp ? src/hotspot/share/runtime/flags/allFlags.hpp line 112: > 110: notproduct, \ > 111: range, \ > 112: constraint) RUNTIME / GC / RUNTIME_OS : Could the order be changed so that the RUNTIME macros are grouped together? src/hotspot/share/runtime/globals.hpp line 2502: > 2500: DECLARE_FLAGS(RUNTIME_OS_FLAGS) > 2501: DECLARE_FLAGS(RUNTIME_FLAGS) > 2502: DECLARE_ARCH_FLAGS(ARCH_FLAGS) This order is different to the one in allFlags.hpp. Maybe use the same order? src/hotspot/share/runtime/globals_shared.hpp line 101: > 99: DECLARE_NOTPRODUCT_FLAG, \ > 100: IGNORE_RANGE, \ > 101: IGNORE_CONSTRAINT) Suggestion: #define DECLARE_FLAGS(flag_group) \ flag_group(DECLARE_DEVELOPER_FLAG, \ DECLARE_PD_DEVELOPER_FLAG, \ DECLARE_PRODUCT_FLAG, \ DECLARE_PD_PRODUCT_FLAG, \ DECLARE_NOTPRODUCT_FLAG, \ IGNORE_RANGE, \ IGNORE_CONSTRAINT) src/hotspot/share/runtime/globals_shared.hpp line 108: > 106: DECLARE_NOTPRODUCT_FLAG, \ > 107: IGNORE_RANGE, \ > 108: IGNORE_CONSTRAINT) Suggestion: #define DECLARE_ARCH_FLAGS(flag_group) \ flag_group(DECLARE_DEVELOPER_FLAG, \ DECLARE_PRODUCT_FLAG, \ DECLARE_NOTPRODUCT_FLAG, \ IGNORE_RANGE, \ IGNORE_CONSTRAINT) src/hotspot/share/runtime/flags/allFlags.hpp line 117: > 115: COMPILER_CONSTRAINTS(f) \ > 116: RUNTIME_CONSTRAINTS(f) \ > 117: GC_CONSTRAINTS(f) Suggestion: #define ALL_CONSTRAINTS(f) \ COMPILER_CONSTRAINTS(f) \ RUNTIME_CONSTRAINTS(f) \ GC_CONSTRAINTS(f) ------------- Changes requested by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1608 From thartmann at openjdk.java.net Mon Dec 7 08:43:14 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 7 Dec 2020 08:43:14 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v2] In-Reply-To: References: Message-ID: <9HY90sUJYnM1wAbRS_WDqTrh-JBsWdrQG1zKEH9wjO8=.eb90017f-2622-4ac4-9921-05e6bc9a0aa7@github.com> On Sat, 5 Dec 2020 18:07:28 GMT, Jatin Bhateja wrote: >> A newly allocated memory is initialized either using user provided initialization values for various fields or setting the memory to zero as per java semantics (System initialization). >> >> C2 compiler creates ClearArray Node in order to perform system initialization. ClearArray accepts the number of Heap Words to be initialized, this number can be constant or a non-constant value. For constant number of heap words less than InitArrayShortSize (default value 64 bytes) currently compiler generates StoreL nodes which does the initialization at the granularity of 8 bytes. >> >> This patch vectorizes the initializing store operations for constant sized heap word less than InitArrayShortSize by emitting special instruction sequence for various tail sizes. >> >> In addition existing implementation for initialization under UseXMMForObjInit is extended to use masked operation to optimize tail initialization sequence. In case AVX3Threshold is set to 0 then new initialization sequence uses 64 byte ZMM registers. >> >> Following are the performance stats collected using micro-benchmark included with the patch. >> >> Testing : Tier1-Tier3 level tests are clean. >> >> System Configuration : Cascadelake, Intel Xeon Platinum 8280L @ 2.7 GHz, 2 socket, 28 cores per socket. >> >> Baseline: >> Benchmark Mode Cnt Score Error Units >> ClearMemory.testClearMemory3 thrpt 10 212508.522 ?? 14071.493 ops/s >> ClearMemory.testClearMemory4 thrpt 10 189530.643 ?? 12882.421 ops/s >> ClearMemory.testClearMemory5 thrpt 10 167878.803 ?? 10307.163 ops/s >> ClearMemory.testClearMemory6 thrpt 10 152732.184 ?? 8740.128 ops/s >> ClearMemory.testClearMemory7 thrpt 10 132111.536 ?? 5493.043 ops/s >> >> With Optimization: >> >> Benchmark Mode Cnt Score Error Units >> ClearMemory.testClearMemory3 thrpt 10 220378.082 ?? 18533.701 ops/s >> ClearMemory.testClearMemory4 thrpt 10 198023.913 ?? 15995.780 ops/s >> ClearMemory.testClearMemory5 thrpt 10 183476.886 ?? 13488.821 ops/s >> ClearMemory.testClearMemory6 thrpt 10 161710.750 ?? 9270.182 ops/s >> ClearMemory.testClearMemory7 thrpt 10 145059.426 ?? 8217.484 ops/s > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8257772: Changes for 32 bit build Submitted some quick testing for this and there are failures with tests in `compiler/c2/cr6340864/`: # Internal Error (workspace/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:8178), pid=27510, tid=27529 # assert(MaxVectorSize >= 32) failed: vector length should be >= 32 Current CompileTask: C2: 259 28 b java.lang.StringCoding::encodeASCII (158 bytes) Stack: [0x00007f2d144f8000,0x00007f2d145f9000], sp=0x00007f2d145f3750, free space=1005k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x13a326c] MacroAssembler::fill64_avx(RegisterImpl*, int, XMMRegisterImpl*, bool)+0x11c V [libjvm.so+0x13a3415] MacroAssembler::xmm_clear_mem(RegisterImpl*, RegisterImpl*, RegisterImpl*, XMMRegisterImpl*)+0x195 V [libjvm.so+0x13a458b] MacroAssembler::clear_mem(RegisterImpl*, RegisterImpl*, RegisterImpl*, XMMRegisterImpl*, bool)+0x19b V [libjvm.so+0x395487] rep_stosNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x167 V [libjvm.so+0x15b79da] PhaseOutput::scratch_emit_size(Node const*)+0x3fa V [libjvm.so+0x15ae88c] PhaseOutput::shorten_branches(unsigned int*)+0x2ac V [libjvm.so+0x15c045a] PhaseOutput::Output()+0xcda V [libjvm.so+0xa0a798] Compile::Code_Gen()+0x438 V [libjvm.so+0xa13fe7] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x1917 V [libjvm.so+0x8466ac] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1dc V [libjvm.so+0xa24498] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xe08 V [libjvm.so+0xa24fe8] CompileBroker::compiler_thread_loop()+0x5a8 V [libjvm.so+0x18ae756] JavaThread::thread_main_inner()+0x256 V [libjvm.so+0x18b50e0] Thread::call_run()+0x100 V [libjvm.so+0x1598346] thread_native_entry(Thread*)+0x116 Tests are executed with `-XX:CompileThreshold=100 -XX:-TieredCompilation`. ------------- Changes requested by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1631 From stuefe at openjdk.java.net Mon Dec 7 08:52:28 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 7 Dec 2020 08:52:28 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: > Hi, > > may I please have reviews for the following very small improvement: > > While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: > > size_t os::_page_sizes[os::page_sizes_max]; > > is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. > > Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). > > That has the following advantages: > - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. > - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. > > ----- > > The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. > > > Testing: > - nightlies at SAP > - manual tests with UseLargePages > - the new gtests > - gh actions (with x86 still failing because of unrelated issues) > > Thank you, > > Thomas > > [1] https://bugs.openjdk.java.net/browse/JDK-8243315 > [2] https://bugs.openjdk.java.net/browse/JDK-8256155 Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Add missing include (ppc,s390 builds failed) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1522/files - new: https://git.openjdk.java.net/jdk/pull/1522/files/919d90bb..163b308b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1522&range=04-05 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1522.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1522/head:pull/1522 PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Mon Dec 7 08:52:28 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 7 Dec 2020 08:52:28 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v5] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Mon, 7 Dec 2020 08:13:21 GMT, Stefan Karlsson wrote: > Thanks! Looks good. Thank you Stefan. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From tschatzl at openjdk.java.net Mon Dec 7 09:16:15 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 7 Dec 2020 09:16:15 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: <2ClzZGcOoqh1Qd9AfRteyNvfuMT6BfxsD72hZRoV0Ic=.8a451497-ba51-4b78-bd56-592df617cde9@github.com> On Mon, 7 Dec 2020 08:52:28 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Add missing include (ppc,s390 builds failed) Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From shade at openjdk.java.net Mon Dec 7 09:19:19 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Dec 2020 09:19:19 GMT Subject: RFR: 8257805: Add compiler/blackhole tests to tier1 Message-ID: JDK-8252505 added new tests. They are short, and were supposed to run in tier1. Unfortunately, they are in `compiler/blackhole` directory, not in `compiler/c1` or `compiler/c2`, which would get them included into tier1 automatically. So, we need to include them to tier1 directly. ------------- Commit messages: - Merge branch 'master' into JDK-8257805-bh-tier1 - 8257805: Add compiler/blackhole tests to tier1 Changes: https://git.openjdk.java.net/jdk/pull/1654/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1654&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257805 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1654.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1654/head:pull/1654 PR: https://git.openjdk.java.net/jdk/pull/1654 From stuefe at openjdk.java.net Mon Dec 7 10:36:16 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 7 Dec 2020 10:36:16 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: <2ClzZGcOoqh1Qd9AfRteyNvfuMT6BfxsD72hZRoV0Ic=.8a451497-ba51-4b78-bd56-592df617cde9@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <2ClzZGcOoqh1Qd9AfRteyNvfuMT6BfxsD72hZRoV0Ic=.8a451497-ba51-4b78-bd56-592df617cde9@github.com> Message-ID: On Mon, 7 Dec 2020 09:13:20 GMT, Thomas Schatzl wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing include (ppc,s390 builds failed) > > Marked as reviewed by tschatzl (Reviewer). Thanks Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Mon Dec 7 10:36:18 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 7 Dec 2020 10:36:18 GMT Subject: Integrated: JDK-8257588: Make os::_page_sizes a bitmask In-Reply-To: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: On Mon, 30 Nov 2020 16:48:35 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for the following very small improvement: > > While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: > > size_t os::_page_sizes[os::page_sizes_max]; > > is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. > > Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). > > That has the following advantages: > - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. > - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. > > ----- > > The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. > > > Testing: > - nightlies at SAP > - manual tests with UseLargePages > - the new gtests > - gh actions (with x86 still failing because of unrelated issues) > > Thank you, > > Thomas > > [1] https://bugs.openjdk.java.net/browse/JDK-8243315 > [2] https://bugs.openjdk.java.net/browse/JDK-8256155 This pull request has now been integrated. Changeset: 8e8e5845 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/8e8e5845 Stats: 228 lines in 7 files changed: 171 ins; 30 del; 27 mod 8257588: Make os::_page_sizes a bitmask Reviewed-by: tschatzl, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Mon Dec 7 10:40:13 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 7 Dec 2020 10:40:13 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v5] In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 00:07:12 GMT, Marcus G K Williams wrote: >> When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using >> Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). >> >> This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). >> >> In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > Remove remnant UseSHM change > > Signed-off-by: Marcus G K Williams Hi Marcus, I generally like this patch. I will do a more thorough review later. But could this wait please until after JDK16 has been forked off? Since I would like this to spend some more times cooking on our more exotic Linuxes. Cheers, Thomas src/hotspot/os/linux/os_linux.cpp line 3743: > 3741: // The kernel is using kB, hotspot uses bytes > 3742: if (page_size * K > (size_t)Linux::page_size()) { > 3743: if (!os::page_sizes().is_set(page_size * K)) { is_set is not needed, just call add ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+5550412+thomaswue at openjdk.java.net Mon Dec 7 10:51:14 2020 From: github.com+5550412+thomaswue at openjdk.java.net (Thomas Wuerthinger) Date: Mon, 7 Dec 2020 10:51:14 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> Message-ID: On Mon, 7 Dec 2020 06:59:34 GMT, Aleksey Shipilev wrote: >> Is this the first compile command that can be used to modify the functional behaviour of the Java user application? > >> Is this the first compile command that can be used to modify the functional behaviour of the Java user application? > > I believe you can say that if we ignore `BreakAt*` commands. That could set a dangerous precedent as it is otherwise a strongly assumed global invariant that the executing Java code has identical semantics independent of whether it is compiled or interpreted. It is also the first intrinsic that is dynamically configurable from the command line. I do agree introducing a whitebox API recognized by the compiler for microbenchmarking is the right approach; and much better than the previous one trying to outsmart the compiler with some complex Java code. Why did you dismiss the option to add a blackhole method to the JDK? ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Mon Dec 7 11:02:13 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Dec 2020 11:02:13 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> Message-ID: On Mon, 7 Dec 2020 10:48:04 GMT, Thomas Wuerthinger wrote: > That could set a dangerous precedent as it is otherwise a strongly assumed global invariant that the executing Java code has identical semantics independent of whether it is compiled or interpreted. It is also the first intrinsic that is dynamically configurable from the command line. As I said above, `BreakAt` already changes the semantics. Compiler commands is a low-level API to instruct compiler to do something special. Here, we want compiler to do something special. `blackhole` being treated as intrinsic in VM code is the implementation detail. The previous incarnations of the patch were not doing it, and it was only done to simplify the internal compiler hooks. > Why did you dismiss the option to add a blackhole method to the JDK? Because in my mind, public Java API does not carry its weight here, for a single-purpose use in JMH. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 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 github.com+5550412+thomaswue at openjdk.java.net Mon Dec 7 11:22:16 2020 From: github.com+5550412+thomaswue at openjdk.java.net (Thomas Wuerthinger) Date: Mon, 7 Dec 2020 11:22:16 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> Message-ID: On Mon, 7 Dec 2020 10:59:07 GMT, Aleksey Shipilev wrote: >> That could set a dangerous precedent as it is otherwise a strongly assumed global invariant that the executing Java code has identical semantics independent of whether it is compiled or interpreted. It is also the first intrinsic that is dynamically configurable from the command line. >> >> I do agree introducing a whitebox API recognized by the compiler for microbenchmarking is the right approach; and much better than the previous one trying to outsmart the compiler with some complex Java code. >> >> Why did you dismiss the option to add a blackhole method to the JDK? > >> That could set a dangerous precedent as it is otherwise a strongly assumed global invariant that the executing Java code has identical semantics independent of whether it is compiled or interpreted. It is also the first intrinsic that is dynamically configurable from the command line. > > As I said above, `BreakAt` already changes the semantics. Compiler commands is a low-level API to instruct compiler to do something special. Here, we want compiler to do something special. `blackhole` being treated as intrinsic in VM code is the implementation detail. The previous incarnations of the patch were not doing it, and it was only done to simplify the internal compiler hooks. > >> Why did you dismiss the option to add a blackhole method to the JDK? > > Because in my mind, public Java API does not carry its weight here, for a single-purpose use in JMH. It is not an "implementation detail" if the change in semantics is visible to the user application. We are forced to implement this new feature in the GraalVM compiler or there will be unexpected observable differences in behaviour when executing the same Java application with the same command line flags. It is still a public API if it is a flag on the Java command line. What do you mean by "does not carry its weight"? Is the process to introduce a Java API too heavy-weight and therefore this solution was chosen? ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From jbhateja at openjdk.java.net Mon Dec 7 11:37:29 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 7 Dec 2020 11:37:29 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v3] In-Reply-To: References: Message-ID: <93ml2lDW77Kaj0GCFWtB3FOLuK_WFxZ1UZAFWWZsGwE=.f6edbc8b-d292-43a1-a2d4-39df0cd1f31f@github.com> > A newly allocated memory is initialized either using user provided initialization values for various fields or setting the memory to zero as per java semantics (System initialization). > > C2 compiler creates ClearArray Node in order to perform system initialization. ClearArray accepts the number of Heap Words to be initialized, this number can be constant or a non-constant value. For constant number of heap words less than InitArrayShortSize (default value 64 bytes) currently compiler generates StoreL nodes which does the initialization at the granularity of 8 bytes. > > This patch vectorizes the initializing store operations for constant sized heap word less than InitArrayShortSize by emitting special instruction sequence for various tail sizes. > > In addition existing implementation for initialization under UseXMMForObjInit is extended to use masked operation to optimize tail initialization sequence. In case AVX3Threshold is set to 0 then new initialization sequence uses 64 byte ZMM registers. > > Following are the performance stats collected using micro-benchmark included with the patch. > > Testing : Tier1-Tier3 level tests are clean. > > System Configuration : Cascadelake, Intel Xeon Platinum 8280L @ 2.7 GHz, 2 socket, 28 cores per socket. > > Baseline: > Benchmark Mode Cnt Score Error Units > ClearMemory.testClearMemory3 thrpt 10 212508.522 ?? 14071.493 ops/s > ClearMemory.testClearMemory4 thrpt 10 189530.643 ?? 12882.421 ops/s > ClearMemory.testClearMemory5 thrpt 10 167878.803 ?? 10307.163 ops/s > ClearMemory.testClearMemory6 thrpt 10 152732.184 ?? 8740.128 ops/s > ClearMemory.testClearMemory7 thrpt 10 132111.536 ?? 5493.043 ops/s > > With Optimization: > > Benchmark Mode Cnt Score Error Units > ClearMemory.testClearMemory3 thrpt 10 220378.082 ?? 18533.701 ops/s > ClearMemory.testClearMemory4 thrpt 10 198023.913 ?? 15995.780 ops/s > ClearMemory.testClearMemory5 thrpt 10 183476.886 ?? 13488.821 ops/s > ClearMemory.testClearMemory6 thrpt 10 161710.750 ?? 9270.182 ops/s > ClearMemory.testClearMemory7 thrpt 10 145059.426 ?? 8217.484 ops/s Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8257772: Fix for hotspot minimal build failure. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1631/files - new: https://git.openjdk.java.net/jdk/pull/1631/files/cc024e7f..f96c01e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1631&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1631&range=01-02 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1631.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1631/head:pull/1631 PR: https://git.openjdk.java.net/jdk/pull/1631 From shade at openjdk.java.net Mon Dec 7 11:41:12 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Dec 2020 11:41:12 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> Message-ID: On Mon, 7 Dec 2020 11:19:09 GMT, Thomas Wuerthinger wrote: > It is not an "implementation detail" if the change in semantics is visible to the user application. We are forced to implement this new feature in the GraalVM compiler or there will be unexpected observable differences in behaviour when executing the same Java application with the same command line flags. The fact that `blackhole` is implemented as C1/C2 intrinsic *is* the implementation detail. It does not have to be, and it would not affect the externally usable `CompileCommand`. If Graal (or any other JIT compiler, for that matter) wants to hook into OpenJDK JIT compiler infrastructure, then I think it is reasonable to expect it reacts on compile commands in the similar manner. > It is still a public API if it is a flag on the Java command line. I think that redefines what public API is. JVM flags are not Java public API. > What do you mean by "does not carry its weight"? Is the process to introduce a Java API too heavy-weight and therefore this solution was chosen? Public Java API comes with the associated maintainability, reliability, security costs. Once you put the method into public Java API, there is (almost) no way back. If you have a bug in public Java API method, you have a problem. If that bug is a security one (e.g. crashing the JVM by 3rd party code), you have a huge problem. For the similar reasons, we have `-XX:CompileCommand=inline,*`, but `@ForceInline` is not a public API -- we can instruct compiler to do special thing, but that requires the explicit opt-in by those who control the JVM run. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From github.com+5550412+thomaswue at openjdk.java.net Mon Dec 7 12:06:16 2020 From: github.com+5550412+thomaswue at openjdk.java.net (Thomas Wuerthinger) Date: Mon, 7 Dec 2020 12:06:16 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> Message-ID: <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> On Mon, 7 Dec 2020 11:37:36 GMT, Aleksey Shipilev wrote: >> It is not an "implementation detail" if the change in semantics is visible to the user application. We are forced to implement this new feature in the GraalVM compiler or there will be unexpected observable differences in behaviour when executing the same Java application with the same command line flags. >> >> It is still a public API if it is a flag on the Java command line. >> >> What do you mean by "does not carry its weight"? Is the process to introduce a Java API too heavy-weight and therefore this solution was chosen? > >> It is not an "implementation detail" if the change in semantics is visible to the user application. We are forced to implement this new feature in the GraalVM compiler or there will be unexpected observable differences in behaviour when executing the same Java application with the same command line flags. > > The fact that `blackhole` is implemented as C1/C2 intrinsic *is* the implementation detail. It does not have to be, and it would not affect the externally usable `CompileCommand`. If Graal (or any other JIT compiler, for that matter) wants to hook into OpenJDK JIT compiler infrastructure, then I think it is reasonable to expect it reacts on compile commands in the similar manner. > >> It is still a public API if it is a flag on the Java command line. > > I think that redefines what public API is. JVM flags are not Java public API. > >> What do you mean by "does not carry its weight"? Is the process to introduce a Java API too heavy-weight and therefore this solution was chosen? > > Public Java API comes with the associated maintainability, reliability, security costs. Once you put the method into public Java API, there is (almost) no way back. If you have a bug in public Java API method, you have a problem. If that bug is a security one (e.g. crashing the JVM by 3rd party code), you have a huge problem. For the similar reasons, we have `-XX:CompileCommand=inline,*`, but `@ForceInline` is not a public API -- we can instruct compiler to do special thing, but that requires the explicit opt-in by those who control the JVM run. There are similar expectations for backwards compatibility and ongoing maintenance of command line flags (except the ones marked explicitly as "experimental"). There is certainly also an expectation that flags are not creating new security vulnerabilities. Whether a compiler inlines a method or not is not observable other than performance differences. This new command however can change the semantics of the Java program in unexpected ways by effectively removing the content of a method. The "inline" compile command and this new "blackhole" compile command are therefore not comparable. I think introducing a blackhole method in the JDK would be the right thing to do instead of short-cutting the process. Maintaining such a method would also be trivial as it is only a few lines of code. Even an empty method would be OK. The method becomes part of the API; the intrinsification is part of the "implementation detail". ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From jbhateja at openjdk.java.net Mon Dec 7 12:25:15 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 7 Dec 2020 12:25:15 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v2] In-Reply-To: <9HY90sUJYnM1wAbRS_WDqTrh-JBsWdrQG1zKEH9wjO8=.eb90017f-2622-4ac4-9921-05e6bc9a0aa7@github.com> References: <9HY90sUJYnM1wAbRS_WDqTrh-JBsWdrQG1zKEH9wjO8=.eb90017f-2622-4ac4-9921-05e6bc9a0aa7@github.com> Message-ID: On Mon, 7 Dec 2020 08:40:02 GMT, Tobias Hartmann wrote: > Submitted some quick testing for this and there are failures with tests in `compiler/c2/cr6340864/`: > > ``` > # Internal Error (workspace/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:8178), pid=27510, tid=27529 > # assert(MaxVectorSize >= 32) failed: vector length should be >= 32 > > Current CompileTask: > C2: 259 28 b java.lang.StringCoding::encodeASCII (158 bytes) > > Stack: [0x00007f2d144f8000,0x00007f2d145f9000], sp=0x00007f2d145f3750, free space=1005k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x13a326c] MacroAssembler::fill64_avx(RegisterImpl*, int, XMMRegisterImpl*, bool)+0x11c > V [libjvm.so+0x13a3415] MacroAssembler::xmm_clear_mem(RegisterImpl*, RegisterImpl*, RegisterImpl*, XMMRegisterImpl*)+0x195 > V [libjvm.so+0x13a458b] MacroAssembler::clear_mem(RegisterImpl*, RegisterImpl*, RegisterImpl*, XMMRegisterImpl*, bool)+0x19b > V [libjvm.so+0x395487] rep_stosNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x167 > V [libjvm.so+0x15b79da] PhaseOutput::scratch_emit_size(Node const*)+0x3fa > V [libjvm.so+0x15ae88c] PhaseOutput::shorten_branches(unsigned int*)+0x2ac > V [libjvm.so+0x15c045a] PhaseOutput::Output()+0xcda > V [libjvm.so+0xa0a798] Compile::Code_Gen()+0x438 > V [libjvm.so+0xa13fe7] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x1917 > V [libjvm.so+0x8466ac] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1dc > V [libjvm.so+0xa24498] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xe08 > V [libjvm.so+0xa24fe8] CompileBroker::compiler_thread_loop()+0x5a8 > V [libjvm.so+0x18ae756] JavaThread::thread_main_inner()+0x256 > V [libjvm.so+0x18b50e0] Thread::call_run()+0x100 > V [libjvm.so+0x1598346] thread_native_entry(Thread*)+0x116 > ``` > > Tests are executed with `-XX:CompileThreshold=100 -XX:-TieredCompilation`. Hi Tobi, thanks, I missed a safety check for MaxVectorSize >= 32 in xmm_clear_mem, for platforms supporting AVX feature, I have fixed this and running tests, can you kindly run the patch with default options over your internal performance suite and confirm there is no performance degradation. ------------- PR: https://git.openjdk.java.net/jdk/pull/1631 From chagedorn at openjdk.java.net Mon Dec 7 12:45:18 2020 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 7 Dec 2020 12:45:18 GMT Subject: RFR: 8245107: Use Unified Logging in trace_method_handle_stub() Message-ID: This changes the logging of method handles from specifying Verbose to using unified logging with level Trace. I only tested it on x86. Could anybody verify that it also works on ARM, S390 and PPC? Thanks, Christian ------------- Commit messages: - 8245107: Use Unified Logging in trace_method_handle_stub() Changes: https://git.openjdk.java.net/jdk/pull/1665/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1665&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8245107 Stats: 73 lines in 6 files changed: 16 ins; 3 del; 54 mod Patch: https://git.openjdk.java.net/jdk/pull/1665.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1665/head:pull/1665 PR: https://git.openjdk.java.net/jdk/pull/1665 From coleenp at openjdk.java.net Mon Dec 7 12:57:12 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 7 Dec 2020 12:57:12 GMT Subject: RFR: 8245107: Use Unified Logging in trace_method_handle_stub() In-Reply-To: References: Message-ID: <2cntLuRkJ52s02mLsT6xs8VrTZorGWoxJiZlXWIvjiY=.0e5fe92a-de91-415d-948f-e9608bbe14ad@github.com> On Mon, 7 Dec 2020 12:39:34 GMT, Christian Hagedorn wrote: > This changes the logging of method handles from specifying Verbose to using unified logging with level Trace. > > I only tested it on x86. Could anybody verify that it also works on ARM, S390 and PPC? > > Thanks, > Christian Thank you for doing this. I probably should have with my fix but it's better that someone who might read this information to do it. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1665 From chagedorn at openjdk.java.net Mon Dec 7 14:26:14 2020 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 7 Dec 2020 14:26:14 GMT Subject: RFR: 8245107: Use Unified Logging in trace_method_handle_stub() In-Reply-To: <2cntLuRkJ52s02mLsT6xs8VrTZorGWoxJiZlXWIvjiY=.0e5fe92a-de91-415d-948f-e9608bbe14ad@github.com> References: <2cntLuRkJ52s02mLsT6xs8VrTZorGWoxJiZlXWIvjiY=.0e5fe92a-de91-415d-948f-e9608bbe14ad@github.com> Message-ID: On Mon, 7 Dec 2020 12:54:29 GMT, Coleen Phillimore wrote: >> This changes the logging of method handles from specifying Verbose to using unified logging with level Trace. >> >> I only tested it on x86. Could anybody verify that it also works on ARM, S390 and PPC? >> >> Thanks, >> Christian > > Thank you for doing this. I probably should have with my fix but it's better that someone who might read this information to do it. Thanks Coleen for your review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1665 From mdoerr at openjdk.java.net Mon Dec 7 14:50:13 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 7 Dec 2020 14:50:13 GMT Subject: RFR: 8245107: Use Unified Logging in trace_method_handle_stub() In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 12:39:34 GMT, Christian Hagedorn wrote: > This changes the logging of method handles from specifying Verbose to using unified logging with level Trace. > > I only tested it on x86. Could anybody verify that it also works on ARM, S390 and PPC? > > Thanks, > Christian Looks correct. Works on PPC64 and s390. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1665 From redestad at openjdk.java.net Mon Dec 7 15:08:20 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 7 Dec 2020 15:08:20 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations Message-ID: This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp Naming is hard, but I think the following scheme is reasonable: - log2i: any integral type. 0-hostile - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) - exact_log2i: any integral type. value must be a power of two I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: [ RUN ] power_of_2.log2_long_micro [ OK ] power_of_2.log2_long_micro (3581 ms) [ RUN ] power_of_2.log2_long_small_micro [ OK ] power_of_2.log2_long_small_micro (549 ms) [ RUN ] power_of_2.log2i_micro [ OK ] power_of_2.log2i_micro (259 ms) [ RUN ] power_of_2.log2i_small_micro [ OK ] power_of_2.log2i_small_micro (113 ms) I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W (Intending this for 17) ------------- Commit messages: - Clean up exact_log2 comments - Invalid use of uintptr_t, use uint64_t to handle 64-bit integers properly on 32-bit - Renaming: log2_integral->log2i, _zero->_allow_zero - Merge branch 'master' into log2_template - Add simple microbenchmarks - fix log2_int use in c1_LIRGenerator_ppc/s390 - Merge branch 'master' into log2_template - Cast CPU_MAX_FEATURE to uint64_t - Move use of exact_log2_long to exact_log2_integral - Clear up exact_log2 preconditions, allow 0x8000... - ... and 3 more: https://git.openjdk.java.net/jdk/compare/566d77a2...e4a51060 Changes: https://git.openjdk.java.net/jdk/pull/1663/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257815 Stats: 324 lines in 40 files changed: 130 ins; 98 del; 96 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 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 chagedorn at openjdk.java.net Mon Dec 7 15:19:11 2020 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 7 Dec 2020 15:19:11 GMT Subject: RFR: 8245107: Use Unified Logging in trace_method_handle_stub() In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 14:47:36 GMT, Martin Doerr wrote: >> This changes the logging of method handles from specifying Verbose to using unified logging with level Trace. >> >> I only tested it on x86. Could anybody verify that it also works on ARM, S390 and PPC? >> >> Thanks, >> Christian > > Looks correct. Works on PPC64 and s390. Thanks Martin for your review and the verification on PPC64 and s390! ------------- PR: https://git.openjdk.java.net/jdk/pull/1665 From shade at openjdk.java.net Mon Dec 7 15:45:19 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Dec 2020 15:45:19 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> Message-ID: On Mon, 7 Dec 2020 12:03:05 GMT, Thomas Wuerthinger wrote: > There are similar expectations for backwards compatibility and ongoing maintenance of command line flags (except the ones marked explicitly as "experimental"). There is certainly also an expectation that flags are not creating new security vulnerabilities. > > Whether a compiler inlines a method or not is not observable other than performance differences. This new command however can change the semantics of the Java program in unexpected ways by effectively removing the content of a method. The "inline" compile command and this new "blackhole" compile command are therefore not comparable. `BreakAt` compile command *also* changes the semantics of the Java program. Speaking of Graal, I see that it [already intrinsifies](https://github.com/oracle/graal/blob/744654c108178d531c99fc802f451b55b72a48c9/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/StandardGraphBuilderPlugins.java#L1492) JMH `Blackhole` methods directly. I cannot see how escapes your argument: compiler changes the semantics by effectively removing the content of a method. And it does so without user explicitly asking for it? > I think introducing a blackhole method in the JDK would be the right thing to do instead of short-cutting the process. Maintaining such a method would also be trivial as it is only a few lines of code. Even an empty method would be OK. The method becomes part of the API; the intrinsification is part of the "implementation detail". I think you severely underestimate the costs of going that way. LOC count has little to do with the costs here. I have been on that road before, and that is why I believe it does not worth it ("does not carry its weight"), when there is a way to get what JMH wants with the VM-specific compile commands. You are welcome to try proposing the public APIs for this. I can retract the `-XX:CompileCommand` addition and intrinsify JMH methods directly, like Graal does. But I think that would be less nice, as it makes JDK aware about non-JDK code, and forces JMH to stick with the current `Blackhole` Java signatures. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From vlivanov at openjdk.java.net Mon Dec 7 15:45:19 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 7 Dec 2020 15:45:19 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> Message-ID: On Mon, 7 Dec 2020 12:22:35 GMT, Aleksey Shipilev wrote: >> There are similar expectations for backwards compatibility and ongoing maintenance of command line flags (except the ones marked explicitly as "experimental"). There is certainly also an expectation that flags are not creating new security vulnerabilities. >> >> Whether a compiler inlines a method or not is not observable other than performance differences. This new command however can change the semantics of the Java program in unexpected ways by effectively removing the content of a method. The "inline" compile command and this new "blackhole" compile command are therefore not comparable. >> >> I think introducing a blackhole method in the JDK would be the right thing to do instead of short-cutting the process. Maintaining such a method would also be trivial as it is only a few lines of code. Even an empty method would be OK. The method becomes part of the API; the intrinsification is part of the "implementation detail". > >> There are similar expectations for backwards compatibility and ongoing maintenance of command line flags (except the ones marked explicitly as "experimental"). There is certainly also an expectation that flags are not creating new security vulnerabilities. >> >> Whether a compiler inlines a method or not is not observable other than performance differences. This new command however can change the semantics of the Java program in unexpected ways by effectively removing the content of a method. The "inline" compile command and this new "blackhole" compile command are therefore not comparable. > > `BreakAt` compile command *also* changes the semantics of the Java program. > > Speaking of Graal, I see that it [already intrinsifies](https://github.com/oracle/graal/blob/744654c108178d531c99fc802f451b55b72a48c9/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/StandardGraphBuilderPlugins.java#L1492) JMH `Blackhole` methods directly. I cannot see how escapes your argument: compiler changes the semantics by effectively removing the content of a method. And it does so without user explicitly asking for it? > >> I think introducing a blackhole method in the JDK would be the right thing to do instead of short-cutting the process. Maintaining such a method would also be trivial as it is only a few lines of code. Even an empty method would be OK. The method becomes part of the API; the intrinsification is part of the "implementation detail". > > I think you severely underestimate the costs of going that way. LOC count has little to do with the costs here. I have been on that road before, and that is why I believe it does not worth it ("does not carry its weight"), when there is a way to get what JMH wants with the VM-specific compile commands. You are welcome to try proposing the public APIs for this. > > I can retract the `-XX:CompileCommand` addition and intrinsify JMH methods directly, like Graal does. But I think that would be less nice, as it makes JDK aware about non-JDK code, and forces JMH to stick with the current `Blackhole` Java signatures. As an afterthought, I would file a CSR request for this change (though CompileCommand has diagnostic nature, it is a product flag after all). If it turns out it's not an appropriate addition, a separate diagnostic/experimental flag can be added instead. (Though that would be unfortunate.) If possible change in behavior is a real concern, the implementation can be changed to affect only effect-free methods (e.g., applied only to empty methods). The upside of exposing the functionality as a command-line option (diagnostic or experimental, but even product) is it has much lower level of commitment associated with it. If there's enough motivation/justification to graduate it into public Java API, it can be done later when there's enough confidence that it's the right fit there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From vlivanov at openjdk.java.net Mon Dec 7 15:45:20 2020 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 7 Dec 2020 15:45:20 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> Message-ID: On Mon, 7 Dec 2020 12:25:16 GMT, Vladimir Ivanov wrote: > If it turns out it's not an appropriate addition, a separate diagnostic/experimental flag can be added instead. Or, as an alternative, `-XX:CompileCommand=blackhole` could require `-XX:+UnlockDiagnosticVMOptions`/`-XX:+UnlockExperimentalVMOptions` to have any effect (as if it was a non-product flag). ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From github.com+5550412+thomaswue at openjdk.java.net Mon Dec 7 15:45:20 2020 From: github.com+5550412+thomaswue at openjdk.java.net (Thomas Wuerthinger) Date: Mon, 7 Dec 2020 15:45:20 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> Message-ID: On Mon, 7 Dec 2020 12:25:16 GMT, Vladimir Ivanov wrote: > If possible change in behavior is a real concern, the implementation can be changed to affect only effect-free methods (e.g., applied only to empty methods). Yes, applying it only to effect-free methods would be perfect. For such methods it is indeed comparable with the other compiler commands. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From simonis at openjdk.java.net Mon Dec 7 15:45:20 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 7 Dec 2020 15:45:20 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> Message-ID: On Mon, 7 Dec 2020 12:29:08 GMT, Thomas Wuerthinger wrote: >> As an afterthought, I would file a CSR request for this change (though CompileCommand has diagnostic nature, it is a product flag after all). If it turns out it's not an appropriate addition, a separate diagnostic/experimental flag can be added instead. (Though that would be unfortunate.) >> >> If possible change in behavior is a real concern, the implementation can be changed to affect only effect-free methods (e.g., applied only to empty methods). >> >> The upside of exposing the functionality as a command-line option (diagnostic or experimental, but even product) is it has much lower level of commitment associated with it. If there's enough motivation/justification to graduate it into public Java API, it can be done later when there's enough confidence that it's the right fit there. > >> If possible change in behavior is a real concern, the implementation can be changed to affect only effect-free methods (e.g., applied only to empty methods). > > Yes, applying it only to effect-free methods would be perfect. For such methods it is indeed comparable with the other compiler commands. This change would have definitely required a CSR as described in [Hotspot Command-line Flags: Kinds, Lifecycle and the CSR Process](https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process). Besides that, I don't understand @thomaswue argumentation that he's "*forced to implement this new feature in the GraalVM compiler or there will be unexpected observable differences in behaviour when executing the same Java application with the same command line flags*". `-XX:` options are definitely an implementation detail of OpenJDK and as such not related to the Java SE specification in any way. The fact that the `-XX:` options are sub-devided into *product*, *diagnostic* and *experimental* options is again specific to the OpenJDK project and only denotes the level of support these options get within the project and not their relation to the Java SE specification. Misusing the new new option will already have unpredictable effects in OpenJDK itself and make it behave "Java SE" incompatible. I don't think there's a requirement that all configurations (i.e. all combinations of command line options) of a "Java SE" implementation have to be "Java SE" compatible and this is especially true for extended options like `-XX:`. And by the way, in addition to the `BreakAt*` command mentioned before, we already have other such options like for example `-XX:AbortVMOnException=` and `-XX:AbortVMOnExceptionMessage=` which make the OpenJDK behave non-Java SE compatible (not sure if you've implemented these in GraalVM in order to fully emulate OpenJDK :) As far as I can see, a CSR ([JDK-8257827](https://bugs.openjdk.java.net/browse/JDK-8257827)) for this issue has already been created, which is good. Details like declaring this new option *product*, *experimental* or *diagnostic* should be discussed in the CSR, but in the end I don't think the OpenJDK project has a responsibility to justify its implementation details to other projects which try to emulate its behaviour. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 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 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 mdoerr at openjdk.java.net Mon Dec 7 16:55:13 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 7 Dec 2020 16:55:13 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 12:00:48 GMT, Claes Redestad wrote: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Builds on PPC64le after JDK-8257798 was fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From shade at openjdk.java.net Mon Dec 7 17:00:15 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Dec 2020 17:00:15 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 16:52:01 GMT, Martin Doerr wrote: >> This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp >> >> Naming is hard, but I think the following scheme is reasonable: >> >> - log2i: any integral type. 0-hostile >> - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) >> - exact_log2i: any integral type. value must be a power of two >> >> I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. >> >> Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. >> >> To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: >> >> [ RUN ] power_of_2.log2_long_micro >> [ OK ] power_of_2.log2_long_micro (3581 ms) >> [ RUN ] power_of_2.log2_long_small_micro >> [ OK ] power_of_2.log2_long_small_micro (549 ms) >> [ RUN ] power_of_2.log2i_micro >> [ OK ] power_of_2.log2i_micro (259 ms) >> [ RUN ] power_of_2.log2i_small_micro >> [ OK ] power_of_2.log2i_small_micro (113 ms) >> >> I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W >> >> (Intending this for 17) > > Builds on PPC64le after JDK-8257798 was fixed. There seem to be `gtest/GTestWrapper.java` failures on x86_32. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From aph at redhat.com Mon Dec 7 17:01:51 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 7 Dec 2020 17:01:51 +0000 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> Message-ID: <751e13a8-6f71-d075-91ef-ca4205003e14@redhat.com> On 07/12/2020 11:02, Aleksey Shipilev wrote: >> Why did you dismiss the option to add a blackhole method to the JDK? > Because in my mind, public Java API does not carry its weight here, for a single-purpose use in JMH. I'm not at all sure that it is only useful in JMH. Other tools could well make use of it: JMH is not the only benchmark in town. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gziemski at openjdk.java.net Mon Dec 7 17:02:24 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Mon, 7 Dec 2020 17:02:24 GMT Subject: RFR: 8253742: POSIX signal code cleanup [v9] In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 06:52:12 GMT, Thomas Stuefe wrote: >> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: >> >> last tweaks > > AIX build went through, tests are fine so far. Looks good now. Ship it! Thank you David and Thomas for your reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/636 From joe.darcy at oracle.com Mon Dec 7 17:55:37 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 7 Dec 2020 09:55:37 -0800 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> Message-ID: <76a5114c-0096-0350-c8e4-9bfa2b0f46d6@oracle.com> The CSR process explicitly includes command line interfaces as part of general JDK API that is looked after by the process; it is not limited to Java APIs. Please file a retroactive CSR for this change. Thanks, -Joe On 12/7/2020 7:45 AM, Vladimir Ivanov wrote: > On Mon, 7 Dec 2020 12:22:35 GMT, Aleksey Shipilev wrote: > >>> There are similar expectations for backwards compatibility and ongoing maintenance of command line flags (except the ones marked explicitly as "experimental"). There is certainly also an expectation that flags are not creating new security vulnerabilities. >>> >>> Whether a compiler inlines a method or not is not observable other than performance differences. This new command however can change the semantics of the Java program in unexpected ways by effectively removing the content of a method. The "inline" compile command and this new "blackhole" compile command are therefore not comparable. >>> >>> I think introducing a blackhole method in the JDK would be the right thing to do instead of short-cutting the process. Maintaining such a method would also be trivial as it is only a few lines of code. Even an empty method would be OK. The method becomes part of the API; the intrinsification is part of the "implementation detail". >>> There are similar expectations for backwards compatibility and ongoing maintenance of command line flags (except the ones marked explicitly as "experimental"). There is certainly also an expectation that flags are not creating new security vulnerabilities. >>> >>> Whether a compiler inlines a method or not is not observable other than performance differences. This new command however can change the semantics of the Java program in unexpected ways by effectively removing the content of a method. The "inline" compile command and this new "blackhole" compile command are therefore not comparable. >> `BreakAt` compile command *also* changes the semantics of the Java program. >> >> Speaking of Graal, I see that it [already intrinsifies](https://github.com/oracle/graal/blob/744654c108178d531c99fc802f451b55b72a48c9/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/StandardGraphBuilderPlugins.java#L1492) JMH `Blackhole` methods directly. I cannot see how escapes your argument: compiler changes the semantics by effectively removing the content of a method. And it does so without user explicitly asking for it? >> >>> I think introducing a blackhole method in the JDK would be the right thing to do instead of short-cutting the process. Maintaining such a method would also be trivial as it is only a few lines of code. Even an empty method would be OK. The method becomes part of the API; the intrinsification is part of the "implementation detail". >> I think you severely underestimate the costs of going that way. LOC count has little to do with the costs here. I have been on that road before, and that is why I believe it does not worth it ("does not carry its weight"), when there is a way to get what JMH wants with the VM-specific compile commands. You are welcome to try proposing the public APIs for this. >> >> I can retract the `-XX:CompileCommand` addition and intrinsify JMH methods directly, like Graal does. But I think that would be less nice, as it makes JDK aware about non-JDK code, and forces JMH to stick with the current `Blackhole` Java signatures. > As an afterthought, I would file a CSR request for this change (though CompileCommand has diagnostic nature, it is a product flag after all). If it turns out it's not an appropriate addition, a separate diagnostic/experimental flag can be added instead. (Though that would be unfortunate.) > > If possible change in behavior is a real concern, the implementation can be changed to affect only effect-free methods (e.g., applied only to empty methods). > > The upside of exposing the functionality as a command-line option (diagnostic or experimental, but even product) is it has much lower level of commitment associated with it. If there's enough motivation/justification to graduate it into public Java API, it can be done later when there's enough confidence that it's the right fit there. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1203 From shade at openjdk.java.net Mon Dec 7 18:46:20 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Dec 2020 18:46:20 GMT Subject: RFR: 8257805: Add compiler/blackhole tests to tier1 In-Reply-To: References: Message-ID: <1YWt1j-hplwzIJZUNRVQL4WguyyxiR68bit8N6S12iA=.46c21c8f-f83d-44b1-a84b-073ed7a4159a@github.com> On Sun, 6 Dec 2020 23:13:24 GMT, Aleksey Shipilev wrote: > JDK-8252505 added new tests. They are short, and were supposed to run in tier1. Unfortunately, they are in `compiler/blackhole` directory, not in `compiler/c1` or `compiler/c2`, which would get them included into tier1 automatically. So, we need to include them to tier1 directly. Ping? I would like to have it in `tier1`, so further adjustments to blackhole support would get automatically tested in GH. ------------- PR: https://git.openjdk.java.net/jdk/pull/1654 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 kvn at openjdk.java.net Mon Dec 7 19:24:14 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 7 Dec 2020 19:24:14 GMT Subject: RFR: 8257805: Add compiler/blackhole tests to tier1 In-Reply-To: References: Message-ID: On Sun, 6 Dec 2020 23:13:24 GMT, Aleksey Shipilev wrote: > JDK-8252505 added new tests. They are short, and were supposed to run in tier1. Unfortunately, they are in `compiler/blackhole` directory, not in `compiler/c1` or `compiler/c2`, which would get them included into tier1 automatically. So, we need to include them to tier1 directly. It is reasonable. It adds 21 tests and about 1 min to tier1_compiler_1 which currently takes less time than tier1_compiler_2 and tier1_compiler_3. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1654 From shade at openjdk.java.net Mon Dec 7 19:29:15 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Dec 2020 19:29:15 GMT Subject: RFR: 8257805: Add compiler/blackhole tests to tier1 In-Reply-To: References: Message-ID: <53pqCXYJSNj04PRC58GA3rHBuYu-hQSXnfx14UjpnRg=.7e0de5cc-f959-43e1-a5bc-727dcf081a7d@github.com> On Mon, 7 Dec 2020 19:21:24 GMT, Vladimir Kozlov wrote: >> JDK-8252505 added new tests. They are short, and were supposed to run in tier1. Unfortunately, they are in `compiler/blackhole` directory, not in `compiler/c1` or `compiler/c2`, which would get them included into tier1 automatically. So, we need to include them to tier1 directly. > > It is reasonable. It adds 21 tests and about 1 min to tier1_compiler_1 which currently takes less time than tier1_compiler_2 and tier1_compiler_3. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/1654 From shade at openjdk.java.net Mon Dec 7 19:29:16 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 7 Dec 2020 19:29:16 GMT Subject: Integrated: 8257805: Add compiler/blackhole tests to tier1 In-Reply-To: References: Message-ID: On Sun, 6 Dec 2020 23:13:24 GMT, Aleksey Shipilev wrote: > JDK-8252505 added new tests. They are short, and were supposed to run in tier1. Unfortunately, they are in `compiler/blackhole` directory, not in `compiler/c1` or `compiler/c2`, which would get them included into tier1 automatically. So, we need to include them to tier1 directly. This pull request has now been integrated. Changeset: 36c06005 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/36c06005 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8257805: Add compiler/blackhole tests to tier1 Reviewed-by: kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1654 From redestad at openjdk.java.net Mon Dec 7 19:35:41 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 7 Dec 2020 19:35:41 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v2] In-Reply-To: References: Message-ID: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Claes Redestad 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 15 additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template - Ensure proper promotion from signed to unsigned for 32-bit signed values - Clean up exact_log2 comments - Invalid use of uintptr_t, use uint64_t to handle 64-bit integers properly on 32-bit - Renaming: log2_integral->log2i, _zero->_allow_zero - Merge branch 'master' into log2_template - Add simple microbenchmarks - fix log2_int use in c1_LIRGenerator_ppc/s390 - Merge branch 'master' into log2_template - Cast CPU_MAX_FEATURE to uint64_t - ... and 5 more: https://git.openjdk.java.net/jdk/compare/a97a7c38...93ae0924 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1663/files - new: https://git.openjdk.java.net/jdk/pull/1663/files/e4a51060..93ae0924 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=00-01 Stats: 6936 lines in 113 files changed: 3767 ins; 2616 del; 553 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 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 github.com+168222+mgkwill at openjdk.java.net Mon Dec 7 19:48:22 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Mon, 7 Dec 2020 19:48:22 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v6] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Thomas S. Feedback Signed-off-by: Marcus G K Williams - Merge branch 'master' into update_hlp - Remove remnant UseSHM change Signed-off-by: Marcus G K Williams - Adress Comments, Rework changes for PagesizeSet Signed-off-by: Marcus G K Williams - JDK-8257588: Make os::_page_sizes a bitmask #1522 - Merge branch 'master' into update_hlp - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp - Add 2M LargePages to _page_sizes Use 2m pages for large page requests less than 1g on linux when 1G are default pages - Add os::Linux::large_page_size_2m() that returns 2m as size - Add os::Linux::select_large_page_size() to return correct large page size for size_t bytes - Add 2m size to _page_sizes array - Update reserve_memory_special methods to set/use large_page_size based on bytes reserved - Update large page not reserved warnings to include large_page_size attempted - Update TestLargePageUseForAuxMemory.java to expect 2m large pages in some instances Signed-off-by: Marcus G K Williams - Merge remote-tracking branch 'upstream/master' into update_hlp - Add 2M LargePages to _page_sizes Use 2m pages for large page requests less than 1g on linux when 1G are default pages - Add os::Linux::large_page_size_2m() that returns 2m as size - Add os::Linux::select_large_page_size() to return correct large page size for size_t bytes - Add 2m size to _page_sizes array - Update reserve_memory_special methods to set/use large_page_size based on bytes reserved - Update large page not reserved warnings to include large_page_size attempted - Update TestLargePageUseForAuxMemory.java to expect 2m large pages in some instances Signed-off-by: Marcus G K Williams ------------- Changes: https://git.openjdk.java.net/jdk/pull/1153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=05 Stats: 71 lines in 4 files changed: 53 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 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 github.com+168222+mgkwill at openjdk.java.net Mon Dec 7 19:54:25 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Mon, 7 Dec 2020 19:54:25 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v7] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Fix merge mistakes Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1153/files - new: https://git.openjdk.java.net/jdk/pull/1153/files/1a33482b..5cd6d6a8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=05-06 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 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 github.com+168222+mgkwill at openjdk.java.net Mon Dec 7 19:59:28 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Mon, 7 Dec 2020 19:59:28 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v8] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp - Add newline at end of TestLargePageUseForAuxMemory.java Signed-off-by: Marcus G K Williams - Fix merge mistakes Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1153/files - new: https://git.openjdk.java.net/jdk/pull/1153/files/5cd6d6a8..073ffabe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Mon Dec 7 20:12:17 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Mon, 7 Dec 2020 20:12:17 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v5] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 10:37:31 GMT, Thomas Stuefe wrote: > Hi Marcus, > > I generally like this patch. I will do a more thorough review later. But could this wait please until after JDK16 has been forked off? Since I would like this to spend some more times cooking on our more exotic Linuxes. > > Cheers, Thomas Hi Thomas. I was pushing to get this patch in before JDK16 was forked. Can we run exotic Linux tests now? Is there anything else keeping this from inclusion in JDK16? As an aside, I will stand behind any patch I get upstream, including maintain it, discuss it or fix bugs. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Mon Dec 7 20:16:15 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Mon, 7 Dec 2020 20:16:15 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v5] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 20:09:37 GMT, Marcus G K Williams wrote: >> Hi Marcus, >> >> I generally like this patch. I will do a more thorough review later. But could this wait please until after JDK16 has been forked off? Since I would like this to spend some more times cooking on our more exotic Linuxes. >> >> Cheers, Thomas > >> Hi Marcus, >> >> I generally like this patch. I will do a more thorough review later. But could this wait please until after JDK16 has been forked off? Since I would like this to spend some more times cooking on our more exotic Linuxes. >> >> Cheers, Thomas > > Hi Thomas. I was pushing to get this patch in before JDK16 was forked. > > Can we run exotic Linux tests now? Is there anything else keeping this from inclusion in JDK16? > > As an aside, I will stand behind any patch I get upstream, including maintain it, discuss it or fix bugs. I've resolved comments and merged so that changes from pull #1522 are no longer in the diff. There are now only two files changed and a small amount of lines. I'd certainly appreciate any further detailed review or comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 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 kvn at openjdk.java.net Mon Dec 7 20:31:14 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 7 Dec 2020 20:31:14 GMT Subject: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() In-Reply-To: References: Message-ID: <6_fPBwlMcGHF7KghOrnbyRCxlNFHirfBS4mdZ2hc3dM=.7a101fd1-1295-4e4e-a86f-41ed9287b572@github.com> On Tue, 17 Nov 2020 12:53:48 GMT, Claes Redestad wrote: > This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. > > With PCH disabled, this reduces total includes from 276949 to 276332 Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1256 From redestad at openjdk.java.net Mon Dec 7 20:32:15 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 7 Dec 2020 20:32:15 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 16:57:49 GMT, Aleksey Shipilev wrote: >> Builds on PPC64le after JDK-8257798 was fixed. > > There seem to be `gtest/GTestWrapper.java` failures on x86_32. There was an issue with casting to uint64_t that only showed up in an existing test on 32-bit. I've implemented and tested a variant using `std::make_unsigned` which should be more robust by avoiding promoting 32-bit signed types to 64-bit unsigned ones. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From kvn at openjdk.java.net Mon Dec 7 20:41:13 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 7 Dec 2020 20:41:13 GMT Subject: RFR: 8254733: HotSpot Style Guide should permit using range-based for loops In-Reply-To: References: Message-ID: <50uneMIyFiuSVuYph2kW7-H_3keoeAwJDOczE5ut5-I=.75673157-db40-440f-a2a1-4f5b31e0faa7@github.com> On Sat, 28 Nov 2020 06:37:57 GMT, Kim Barrett wrote: > Please review and vote on this change to the HotSpot Style Guide to > permit the use of range-based `for` loops in HotSpot code. Range-based > `for` is a feature added in C++11. > > This is a modification of the Style Guide, so rough consensus among > the HotSpot Group members is required to make this change. Only Group > members should vote for approval (via the github PR), though reasoned > objectsions or comments from anyone will be considered. A decision on > this proposal will not be made before Monday 7-Dec-2020 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review > process to approve (click on Review Changes > Approve), rather than > sending a "vote: yes" email reply that would be normal for a CFV. > Other responses can still use email of course. Marked as reviewed by kvn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1488 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 david.holmes at oracle.com Mon Dec 7 23:09:06 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Dec 2020 09:09:06 +1000 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> Message-ID: On 8/12/2020 1:45 am, Volker Simonis wrote: > On Mon, 7 Dec 2020 12:29:08 GMT, Thomas Wuerthinger wrote: > >>> As an afterthought, I would file a CSR request for this change (though CompileCommand has diagnostic nature, it is a product flag after all). If it turns out it's not an appropriate addition, a separate diagnostic/experimental flag can be added instead. (Though that would be unfortunate.) >>> >>> If possible change in behavior is a real concern, the implementation can be changed to affect only effect-free methods (e.g., applied only to empty methods). >>> >>> The upside of exposing the functionality as a command-line option (diagnostic or experimental, but even product) is it has much lower level of commitment associated with it. If there's enough motivation/justification to graduate it into public Java API, it can be done later when there's enough confidence that it's the right fit there. >> >>> If possible change in behavior is a real concern, the implementation can be changed to affect only effect-free methods (e.g., applied only to empty methods). >> >> Yes, applying it only to effect-free methods would be perfect. For such methods it is indeed comparable with the other compiler commands. > > This change would have definitely required a CSR as described in [Hotspot Command-line Flags: Kinds, Lifecycle and the CSR Process](https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process). > > Besides that, I don't understand @thomaswue argumentation that he's "*forced to implement this new feature in the GraalVM compiler or there will be unexpected observable differences in behaviour when executing the same Java application with the same command line flags*". `-XX:` options are definitely an implementation detail of OpenJDK and as such not related to the Java SE specification in any way. The fact that the `-XX:` options are sub-devided into *product*, *diagnostic* and *experimental* options is again specific to the OpenJDK project and only denotes the level of support these options get within the project and not their relation to the Java SE specification. > Misusing the new new option will already have unpredictable effects in OpenJDK itself and make it behave "Java SE" incompatible. I don't think there's a requirement that all configurations (i.e. all combinations of command line options) of a "Java SE" implementation have to be "Java SE" compatible and this is especially true for extended options like `-XX:`. You would need to consult the TCK User Guide to understand Operating Modes and Product Configurations, and how Documented options (which includes -XX) relate to this. Our basic rule of thumb is that product flags (but not experimental or diagnostic) shouldn't change testable behaviour. David ----- > And by the way, in addition to the `BreakAt*` command mentioned before, we already have other such options like for example `-XX:AbortVMOnException=` and `-XX:AbortVMOnExceptionMessage=` which make the OpenJDK behave non-Java SE compatible (not sure if you've implemented these in GraalVM in order to fully emulate OpenJDK :) > > As far as I can see, a CSR ([JDK-8257827](https://bugs.openjdk.java.net/browse/JDK-8257827)) for this issue has already been created, which is good. Details like declaring this new option *product*, *experimental* or *diagnostic* should be discussed in the CSR, but in the end I don't think the OpenJDK project has a responsibility to justify its implementation details to other projects which try to emulate its behaviour. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1203 > From github.com+168222+mgkwill at openjdk.java.net Mon Dec 7 23:35:28 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Mon, 7 Dec 2020 23:35:28 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v9] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Fix space format, use Linux:: for local func. Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1153/files - new: https://git.openjdk.java.net/jdk/pull/1153/files/073ffabe..870e8a54 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=07-08 Stats: 8 lines in 1 file changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 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 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 kbarrett at openjdk.java.net Tue Dec 8 01:18:12 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 8 Dec 2020 01:18:12 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 12:00:48 GMT, Claes Redestad wrote: > Naming is hard, but I think the following scheme is reasonable: > > * log2i: any integral type. 0-hostile Not yet a review, but the "usual" name is "ilog2". Do a web search for that and you'll find lots of relevant hits. I like the short name having the non-zero precondition. Whether the longer version that tests for zero carry's it's weight is a question. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From kim.barrett at oracle.com Tue Dec 8 01:43:12 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 7 Dec 2020 20:43:12 -0500 Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: > On Dec 7, 2020, at 8:18 PM, Kim Barrett wrote: > > On Mon, 7 Dec 2020 12:00:48 GMT, Claes Redestad wrote: > >> Naming is hard, but I think the following scheme is reasonable: >> >> * log2i: any integral type. 0-hostile > > Not yet a review, but the "usual" name is "ilog2". Do a web search for that and you'll find lots of relevant hits. I like the short name having the non-zero precondition. Whether the longer version that tests for zero carry's it's weight is a question. I think the approach to dealing with negative values should be reconsidered. ------------------------------------------------------------------------------ src/hotspot/share/utilities/powerOfTwo.hpp 49 // Log2 of any integral value, i.e., largest i such that 2^i <= x 50 // Precondition: x != 0 51 // For negative values this will return 63 for 64-bit types, 31 for 52 // 32-bit types, and so on. I think the behavior for negative values here is wrong. The precondition should be x > 0. That flows through into the implementation. This also affects the design around the proposed _allow_zero function. ------------------------------------------------------------------------------ src/hotspot/share/utilities/powerOfTwo.hpp 80 inline int exact_log2(intptr_t value) { 81 return exact_log2i(value); 82 } This is widening the domain to include negative values, which were previously excluded since it had is_power_of_2 as a precondition, and that function is false for negative values. I think the old behavior is correct and the change is not. ------------------------------------------------------------------------------ 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 iklam at openjdk.java.net Tue Dec 8 03:55:13 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Dec 2020 03:55:13 GMT Subject: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 12:53:48 GMT, Claes Redestad wrote: > This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. > > With PCH disabled, this reduces total includes from 276949 to 276332 Changes requested by iklam (Reviewer). src/hotspot/share/ci/bcEscapeAnalyzer.hpp line 102: > 100: void compute_escape_info(); > 101: vmIntrinsicID known_intrinsic(); > 102: void compute_escape_for_intrinsic(vmIntrinsicID iid); I think the use of vmIntrinsics::ID in bcEscapeAnalyzer.cpp should also be changed to vmIntrinsicID for consistency, even though they are the same type. (The same for other hpp files such as ciMethod.hpp) src/hotspot/share/opto/library_call.cpp line 27: > 25: #include "precompiled.hpp" > 26: #include "asm/macroAssembler.hpp" > 27: #include "ci/ciSymbols.hpp" This file doesn't seem to use the exports from ciSymbols.hpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/1256 From iklam at openjdk.java.net Tue Dec 8 04:04:33 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Dec 2020 04:04:33 GMT Subject: RFR: 8243205: Modularize JVM flags declaration [v2] In-Reply-To: References: Message-ID: > This is the first step for modularizing the xxx_globals.hpp. The goals are > > - Improve modularization of HotSpot source > - Reduce JVM build time > > To prove that this works, I have moved compiler_globals.hpp outside of the monolithic globals.hpp. Before this fix, compiler_globals.hpp was included by 922 HotSpot .o files. After this fix, it's included by 283 .o files. > > I plan to do more refactoring later, such as: > > - move gc_globals.hpp out of globals.hpp > - move the flags related to tiered compilation (about 40 flags) out of globals.hpp > - move the platform-specific flags outside of globals.hpp > - these flags should be used only by platform-specific files. They shouldn't be used by shared files. > > Note: this is target for JDK 17. > > Testing: I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: stefank comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1608/files - new: https://git.openjdk.java.net/jdk/pull/1608/files/dc277faf..6b922fb7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1608&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1608&range=00-01 Stats: 23 lines in 4 files changed: 2 ins; 2 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/1608.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1608/head:pull/1608 PR: https://git.openjdk.java.net/jdk/pull/1608 From iklam at openjdk.java.net Tue Dec 8 04:04:34 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Dec 2020 04:04:34 GMT Subject: RFR: 8243205: Modularize JVM flags declaration [v2] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 08:20:02 GMT, Stefan Karlsson wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> stefank comments > > src/hotspot/share/compiler/compiler_globals_pd.hpp line 26: > >> 24: >> 25: #ifndef SHARE_COMPILER_COMPILER_GLOBALS_DEF_HPP >> 26: #define SHARE_COMPILER_COMPILER_GLOBALS_DEF_HPP > > Should this be SHARE_COMPILER_COMPILER_GLOBALS_PD_HPP Hi Stefan, thanks for the comments. I have posted a new commit with all of your suggestions (but I won't reply to each one to avoid excessive emails :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/1608 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 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 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 stefank at openjdk.java.net Tue Dec 8 08:08:11 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 8 Dec 2020 08:08:11 GMT Subject: RFR: 8243205: Modularize JVM flags declaration [v2] In-Reply-To: References: Message-ID: <2DyMl3PJhuj5PAEygd769GMD5WdCWovtSEOLn69R298=.2228945b-4216-4515-b6c2-7268afbb8756@github.com> On Tue, 8 Dec 2020 04:04:33 GMT, Ioi Lam wrote: >> This is the first step for modularizing the xxx_globals.hpp. The goals are >> >> - Improve modularization of HotSpot source >> - Reduce JVM build time >> >> To prove that this works, I have moved compiler_globals.hpp outside of the monolithic globals.hpp. Before this fix, compiler_globals.hpp was included by 922 HotSpot .o files. After this fix, it's included by 283 .o files. >> >> I plan to do more refactoring later, such as: >> >> - move gc_globals.hpp out of globals.hpp >> - move the flags related to tiered compilation (about 40 flags) out of globals.hpp >> - move the platform-specific flags outside of globals.hpp >> - these flags should be used only by platform-specific files. They shouldn't be used by shared files. >> >> Note: this is target for JDK 17. >> >> Testing: I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > stefank comments Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1608 From stuefe at openjdk.java.net Tue Dec 8 08:39:13 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 8 Dec 2020 08:39:13 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v5] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 20:09:37 GMT, Marcus G K Williams wrote: > /test Just re-run the gh actions. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From stuefe at openjdk.java.net Tue Dec 8 08:52:13 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 8 Dec 2020 08:52:13 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v5] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 20:09:37 GMT, Marcus G K Williams wrote: > > Hi Marcus, > > I generally like this patch. I will do a more thorough review later. But could this wait please until after JDK16 has been forked off? Since I would like this to spend some more times cooking on our more exotic Linuxes. > > Cheers, Thomas > > Hi Thomas. I was pushing to get this patch in before JDK16 was forked. > > Can we run exotic Linux tests now? Is there anything else keeping this from inclusion in JDK16? > > As an aside, I will stand behind any patch I get upstream, including maintain it, discuss it or fix bugs. Its a simple matter of cycles. Code freeze is Dec 10. I'm snowed in right now. Ideally I would liked to have run tests on ppc, s390 and aarch64 with multiple large page sizes enabled and used. A gtest for this scenario would also be good. Then, code wise, there are some things we should straighten out. Not necessarily in your patch, but it should happen either before or after your patch is pushed. For example: - we now have duplicate code for scanning the available huge pages - the new select_large_page_size() feels very similar to the existing os::page_size_for_region_xx() functions. I leave the decision to the others (@stefank @kstefanj ?). If they are fine with rushing this patch in its current form, its fine for me too. If problems arise in our platforms, we will deactivate this coding for non-Intel platforms before shipping jdk16. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From kbarrett at openjdk.java.net Tue Dec 8 09:29:11 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 8 Dec 2020 09:29:11 GMT Subject: RFR: 8254733: HotSpot Style Guide should permit using range-based for loops In-Reply-To: <50uneMIyFiuSVuYph2kW7-H_3keoeAwJDOczE5ut5-I=.75673157-db40-440f-a2a1-4f5b31e0faa7@github.com> References: <50uneMIyFiuSVuYph2kW7-H_3keoeAwJDOczE5ut5-I=.75673157-db40-440f-a2a1-4f5b31e0faa7@github.com> Message-ID: On Mon, 7 Dec 2020 20:38:33 GMT, Vladimir Kozlov wrote: >> Please review and vote on this change to the HotSpot Style Guide to >> permit the use of range-based `for` loops in HotSpot code. Range-based >> `for` is a feature added in C++11. >> >> This is a modification of the Style Guide, so rough consensus among >> the HotSpot Group members is required to make this change. Only Group >> members should vote for approval (via the github PR), though reasoned >> objectsions or comments from anyone will be considered. A decision on >> this proposal will not be made before Monday 7-Dec-2020 at 12h00 UTC. >> >> Since we're piggybacking on github PRs here, please use the PR review >> process to approve (click on Review Changes > Approve), rather than >> sending a "vote: yes" email reply that would be normal for a CFV. >> Other responses can still use email of course. > > Marked as reviewed by kvn (Reviewer). There have been no issues raised with the proposed change, and plenty of support. Thanks for all the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/1488 From kbarrett at openjdk.java.net Tue Dec 8 09:29:13 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 8 Dec 2020 09:29:13 GMT Subject: Integrated: 8254733: HotSpot Style Guide should permit using range-based for loops In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 06:37:57 GMT, Kim Barrett wrote: > Please review and vote on this change to the HotSpot Style Guide to > permit the use of range-based `for` loops in HotSpot code. Range-based > `for` is a feature added in C++11. > > This is a modification of the Style Guide, so rough consensus among > the HotSpot Group members is required to make this change. Only Group > members should vote for approval (via the github PR), though reasoned > objectsions or comments from anyone will be considered. A decision on > this proposal will not be made before Monday 7-Dec-2020 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review > process to approve (click on Review Changes > Approve), rather than > sending a "vote: yes" email reply that would be normal for a CFV. > Other responses can still use email of course. This pull request has now been integrated. Changeset: 52ab7212 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/52ab7212 Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod 8254733: HotSpot Style Guide should permit using range-based for loops Reviewed-by: dholmes, pliden, jrose, dcubed, iklam, eosterlund, tschatzl, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1488 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 sjohanss at openjdk.java.net Tue Dec 8 10:18:12 2020 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 8 Dec 2020 10:18:12 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v5] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 08:49:29 GMT, Thomas Stuefe wrote: >>> Hi Marcus, >>> >>> I generally like this patch. I will do a more thorough review later. But could this wait please until after JDK16 has been forked off? Since I would like this to spend some more times cooking on our more exotic Linuxes. >>> >>> Cheers, Thomas >> >> Hi Thomas. I was pushing to get this patch in before JDK16 was forked. >> >> Can we run exotic Linux tests now? Is there anything else keeping this from inclusion in JDK16? >> >> As an aside, I will stand behind any patch I get upstream, including maintain it, discuss it or fix bugs. > >> > Hi Marcus, >> > I generally like this patch. I will do a more thorough review later. But could this wait please until after JDK16 has been forked off? Since I would like this to spend some more times cooking on our more exotic Linuxes. >> > Cheers, Thomas >> >> Hi Thomas. I was pushing to get this patch in before JDK16 was forked. >> >> Can we run exotic Linux tests now? Is there anything else keeping this from inclusion in JDK16? >> >> As an aside, I will stand behind any patch I get upstream, including maintain it, discuss it or fix bugs. > > Its a simple matter of cycles. Code freeze is Dec 10. I'm snowed in right now. > > Ideally I would liked to have run tests on ppc, s390 and aarch64 with multiple large page sizes enabled and used. A gtest for this scenario would also be good. > > Then, code wise, there are some things we should straighten out. Not necessarily in your patch, but it should happen either before or after your patch is pushed. For example: > - we now have duplicate code for scanning the available huge pages > - the new select_large_page_size() feels very similar to the existing os::page_size_for_region_xx() functions. > > I leave the decision to the others (@stefank @kstefanj ?). If they are fine with rushing this patch in its current form, its fine for me too. If problems arise in our platforms, we will deactivate this coding for non-Intel platforms before shipping jdk16. > > Cheers, Thomas I will not be able to review this in time for the code freeze, so I also vote for not rushing it in. Don't consider this a block, if you get other reviews I'm fine with it getting pushed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+5550412+thomaswue at openjdk.java.net Tue Dec 8 10:42:16 2020 From: github.com+5550412+thomaswue at openjdk.java.net (Thomas Wuerthinger) Date: Tue, 8 Dec 2020 10:42:16 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> Message-ID: On Mon, 7 Dec 2020 15:41:26 GMT, Volker Simonis wrote: >>> If possible change in behavior is a real concern, the implementation can be changed to affect only effect-free methods (e.g., applied only to empty methods). >> >> Yes, applying it only to effect-free methods would be perfect. For such methods it is indeed comparable with the other compiler commands. > > This change would have definitely required a CSR as described in [Hotspot Command-line Flags: Kinds, Lifecycle and the CSR Process](https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process). > > Besides that, I don't understand @thomaswue argumentation that he's "*forced to implement this new feature in the GraalVM compiler or there will be unexpected observable differences in behaviour when executing the same Java application with the same command line flags*". `-XX:` options are definitely an implementation detail of OpenJDK and as such not related to the Java SE specification in any way. The fact that the `-XX:` options are sub-devided into *product*, *diagnostic* and *experimental* options is again specific to the OpenJDK project and only denotes the level of support these options get within the project and not their relation to the Java SE specification. > > Misusing the new new option will already have unpredictable effects in OpenJDK itself and make it behave "Java SE" incompatible. I don't think there's a requirement that all configurations (i.e. all combinations of command line options) of a "Java SE" implementation have to be "Java SE" compatible and this is especially true for extended options like `-XX:`. And by the way, in addition to the `BreakAt*` command mentioned before, we already have other such options like for example `-XX:AbortVMOnException=` and `-XX:AbortVMOnExceptionMessage=` which make the OpenJDK behave non-Java SE compatible (not sure if you've implemented these in GraalVM in order to fully emulate OpenJDK :) > > As far as I can see, a CSR ([JDK-8257827](https://bugs.openjdk.java.net/browse/JDK-8257827)) for this issue has already been created, which is good. Details like declaring this new option *product*, *experimental* or *diagnostic* should be discussed in the CSR, but in the end I don't think the OpenJDK project has a responsibility to justify its implementation details to other projects which try to emulate its behaviour. @simonis As one of the many OpenJDK downstream projects, GraalVM inherits by default all code and flags. We add one additional JIT compiler option and test thoroughly that there are zero observable differences other than performance when that option is enabled (which is the default in the GraalVM distribution). > I don't think the OpenJDK project has a responsibility to justify its implementation details to other projects which try to emulate its behaviour. My understanding as a member of the OpenJDK community was that a GitHub PR like this is the appropriate place to engage in collaborative discussions. Let me know if this kind of engagement is undesirable. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 From thartmann at openjdk.java.net Tue Dec 8 11:55:13 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 8 Dec 2020 11:55:13 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v2] In-Reply-To: References: <9HY90sUJYnM1wAbRS_WDqTrh-JBsWdrQG1zKEH9wjO8=.eb90017f-2622-4ac4-9921-05e6bc9a0aa7@github.com> Message-ID: On Mon, 7 Dec 2020 12:20:21 GMT, Jatin Bhateja wrote: >> Submitted some quick testing for this and there are failures with tests in `compiler/c2/cr6340864/`: >> # Internal Error (workspace/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:8178), pid=27510, tid=27529 >> # assert(MaxVectorSize >= 32) failed: vector length should be >= 32 >> >> Current CompileTask: >> C2: 259 28 b java.lang.StringCoding::encodeASCII (158 bytes) >> >> Stack: [0x00007f2d144f8000,0x00007f2d145f9000], sp=0x00007f2d145f3750, free space=1005k >> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x13a326c] MacroAssembler::fill64_avx(RegisterImpl*, int, XMMRegisterImpl*, bool)+0x11c >> V [libjvm.so+0x13a3415] MacroAssembler::xmm_clear_mem(RegisterImpl*, RegisterImpl*, RegisterImpl*, XMMRegisterImpl*)+0x195 >> V [libjvm.so+0x13a458b] MacroAssembler::clear_mem(RegisterImpl*, RegisterImpl*, RegisterImpl*, XMMRegisterImpl*, bool)+0x19b >> V [libjvm.so+0x395487] rep_stosNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x167 >> V [libjvm.so+0x15b79da] PhaseOutput::scratch_emit_size(Node const*)+0x3fa >> V [libjvm.so+0x15ae88c] PhaseOutput::shorten_branches(unsigned int*)+0x2ac >> V [libjvm.so+0x15c045a] PhaseOutput::Output()+0xcda >> V [libjvm.so+0xa0a798] Compile::Code_Gen()+0x438 >> V [libjvm.so+0xa13fe7] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x1917 >> V [libjvm.so+0x8466ac] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1dc >> V [libjvm.so+0xa24498] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xe08 >> V [libjvm.so+0xa24fe8] CompileBroker::compiler_thread_loop()+0x5a8 >> V [libjvm.so+0x18ae756] JavaThread::thread_main_inner()+0x256 >> V [libjvm.so+0x18b50e0] Thread::call_run()+0x100 >> V [libjvm.so+0x1598346] thread_native_entry(Thread*)+0x116 >> >> Tests are executed with `-XX:CompileThreshold=100 -XX:-TieredCompilation`. > >> Submitted some quick testing for this and there are failures with tests in `compiler/c2/cr6340864/`: >> >> ``` >> # Internal Error (workspace/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:8178), pid=27510, tid=27529 >> # assert(MaxVectorSize >= 32) failed: vector length should be >= 32 >> >> Current CompileTask: >> C2: 259 28 b java.lang.StringCoding::encodeASCII (158 bytes) >> >> Stack: [0x00007f2d144f8000,0x00007f2d145f9000], sp=0x00007f2d145f3750, free space=1005k >> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x13a326c] MacroAssembler::fill64_avx(RegisterImpl*, int, XMMRegisterImpl*, bool)+0x11c >> V [libjvm.so+0x13a3415] MacroAssembler::xmm_clear_mem(RegisterImpl*, RegisterImpl*, RegisterImpl*, XMMRegisterImpl*)+0x195 >> V [libjvm.so+0x13a458b] MacroAssembler::clear_mem(RegisterImpl*, RegisterImpl*, RegisterImpl*, XMMRegisterImpl*, bool)+0x19b >> V [libjvm.so+0x395487] rep_stosNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x167 >> V [libjvm.so+0x15b79da] PhaseOutput::scratch_emit_size(Node const*)+0x3fa >> V [libjvm.so+0x15ae88c] PhaseOutput::shorten_branches(unsigned int*)+0x2ac >> V [libjvm.so+0x15c045a] PhaseOutput::Output()+0xcda >> V [libjvm.so+0xa0a798] Compile::Code_Gen()+0x438 >> V [libjvm.so+0xa13fe7] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x1917 >> V [libjvm.so+0x8466ac] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1dc >> V [libjvm.so+0xa24498] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xe08 >> V [libjvm.so+0xa24fe8] CompileBroker::compiler_thread_loop()+0x5a8 >> V [libjvm.so+0x18ae756] JavaThread::thread_main_inner()+0x256 >> V [libjvm.so+0x18b50e0] Thread::call_run()+0x100 >> V [libjvm.so+0x1598346] thread_native_entry(Thread*)+0x116 >> ``` >> >> Tests are executed with `-XX:CompileThreshold=100 -XX:-TieredCompilation`. > > Hi Tobi, thanks, I missed a safety check for MaxVectorSize >= 32 in xmm_clear_mem, for platforms supporting AVX feature, I have fixed this and running tests, can you kindly run the patch with default options over your internal performance suite and confirm there is no performance degradation. Okay, will do and report back once it finished. ------------- PR: https://git.openjdk.java.net/jdk/pull/1631 From aph at redhat.com Tue Dec 8 12:21:04 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 8 Dec 2020 12:21:04 +0000 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> Message-ID: <057d136b-73ba-9f75-0daa-7cca6bad89c4@redhat.com> On 08/12/2020 10:42, Thomas Wuerthinger wrote: >> I don't think the OpenJDK project has a responsibility to justify >> its implementation details to other projects which try to emulate >> its behaviour. > My understanding as a member of the OpenJDK community was that a > GitHub PR like this is the appropriate place to engage in > collaborative discussions. Let me know if this kind of engagement is > undesirable. I hope that Volker will forgive me if I've misinterpreted him, but I don't think that it's a matter of where this discussion occurs. OpenJDK has to be able to make its own decisions about its internal implementation details without regard to other projects which choose to emulate all of the behaviour of OpenJDK. I think he's right about this. We can't keep looking over our shoulders to see what projects who consume some of OpenJDK might be doing. On the other hand, I believe that blackhole is a useful thing to have beyond merely JMH. (For example, it may lead to a sane implementation of Reference.reachabilityFence(). That would be nice.) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thartmann at openjdk.java.net Tue Dec 8 12:23:11 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 8 Dec 2020 12:23:11 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v2] In-Reply-To: References: <9HY90sUJYnM1wAbRS_WDqTrh-JBsWdrQG1zKEH9wjO8=.eb90017f-2622-4ac4-9921-05e6bc9a0aa7@github.com> Message-ID: On Tue, 8 Dec 2020 11:52:55 GMT, Tobias Hartmann wrote: >>> Submitted some quick testing for this and there are failures with tests in `compiler/c2/cr6340864/`: >>> >>> ``` >>> # Internal Error (workspace/open/src/hotspot/cpu/x86/macroAssembler_x86.cpp:8178), pid=27510, tid=27529 >>> # assert(MaxVectorSize >= 32) failed: vector length should be >= 32 >>> >>> Current CompileTask: >>> C2: 259 28 b java.lang.StringCoding::encodeASCII (158 bytes) >>> >>> Stack: [0x00007f2d144f8000,0x00007f2d145f9000], sp=0x00007f2d145f3750, free space=1005k >>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >>> V [libjvm.so+0x13a326c] MacroAssembler::fill64_avx(RegisterImpl*, int, XMMRegisterImpl*, bool)+0x11c >>> V [libjvm.so+0x13a3415] MacroAssembler::xmm_clear_mem(RegisterImpl*, RegisterImpl*, RegisterImpl*, XMMRegisterImpl*)+0x195 >>> V [libjvm.so+0x13a458b] MacroAssembler::clear_mem(RegisterImpl*, RegisterImpl*, RegisterImpl*, XMMRegisterImpl*, bool)+0x19b >>> V [libjvm.so+0x395487] rep_stosNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x167 >>> V [libjvm.so+0x15b79da] PhaseOutput::scratch_emit_size(Node const*)+0x3fa >>> V [libjvm.so+0x15ae88c] PhaseOutput::shorten_branches(unsigned int*)+0x2ac >>> V [libjvm.so+0x15c045a] PhaseOutput::Output()+0xcda >>> V [libjvm.so+0xa0a798] Compile::Code_Gen()+0x438 >>> V [libjvm.so+0xa13fe7] Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x1917 >>> V [libjvm.so+0x8466ac] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1dc >>> V [libjvm.so+0xa24498] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xe08 >>> V [libjvm.so+0xa24fe8] CompileBroker::compiler_thread_loop()+0x5a8 >>> V [libjvm.so+0x18ae756] JavaThread::thread_main_inner()+0x256 >>> V [libjvm.so+0x18b50e0] Thread::call_run()+0x100 >>> V [libjvm.so+0x1598346] thread_native_entry(Thread*)+0x116 >>> ``` >>> >>> Tests are executed with `-XX:CompileThreshold=100 -XX:-TieredCompilation`. >> >> Hi Tobi, thanks, I missed a safety check for MaxVectorSize >= 32 in xmm_clear_mem, for platforms supporting AVX feature, I have fixed this and running tests, can you kindly run the patch with default options over your internal performance suite and confirm there is no performance degradation. > > Okay, will do and report back once it finished. Just noticed that you didn't update the patch yet. Could you first push the fix? ------------- PR: https://git.openjdk.java.net/jdk/pull/1631 From claes.redestad at oracle.com Tue Dec 8 12:49:10 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 8 Dec 2020 13:49:10 +0100 Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: <716cb12d-0749-77b9-f449-61a1caf98490@oracle.com> Hi Kim, On 2020-12-08 02:43, Kim Barrett wrote: >> On Dec 7, 2020, at 8:18 PM, Kim Barrett wrote: >> >> On Mon, 7 Dec 2020 12:00:48 GMT, Claes Redestad wrote: >> >>> Naming is hard, but I think the following scheme is reasonable: >>> >>> * log2i: any integral type. 0-hostile >> >> Not yet a review, but the "usual" name is "ilog2". Do a web search for that and you'll find lots of relevant hits. I like the short name having the non-zero precondition. Whether the longer version that tests for zero carry's it's weight is a question. > > I think the approach to dealing with negative values should be reconsidered. I kind of agree, but... > > ------------------------------------------------------------------------------ > src/hotspot/share/utilities/powerOfTwo.hpp > 49 // Log2 of any integral value, i.e., largest i such that 2^i <= x > 50 // Precondition: x != 0 > 51 // For negative values this will return 63 for 64-bit types, 31 for > 52 // 32-bit types, and so on. > > I think the behavior for negative values here is wrong. The precondition > should be x > 0. That flows through into the implementation. This also > affects the design around the proposed _allow_zero function. > > ------------------------------------------------------------------------------ > src/hotspot/share/utilities/powerOfTwo.hpp > 80 inline int exact_log2(intptr_t value) { > 81 return exact_log2i(value); > 82 } > > This is widening the domain to include negative values, which were > previously excluded since it had is_power_of_2 as a precondition, and that > function is false for negative values. I think the old behavior is correct > and the change is not. > > ------------------------------------------------------------------------------ > I think you misread slightly: the behavior of the pre-existing code *is* to similarly treat signed values as unsigned wrt checking power_of_2: inline int exact_log2(intptr_t x) { assert(is_power_of_2((uintptr_t)x), "x must be a power of 2: " INTPTR_FORMAT, x); ... inline int exact_log2_long(jlong x) { assert(is_power_of_2((julong)x), "x must be a power of 2: " JLONG_FORMAT, x); exact_log2i does an equivalent check. So unless I'm misreading the context I'm _preserving_ this behavior. I agree we could opt for a stricter precondition in the new method (exact_ilog2?), while retrofitting exact_log/exact_log2_long to be backwards compatible w.r.t. accepting signed values that turn into 0x8000... when cast to unsigned. I think we should then follow-up and remove exact_log2/-_long. WDYT? /Claes From redestad at openjdk.java.net Tue Dec 8 13:22:22 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Dec 2020 13:22:22 GMT Subject: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() [v2] In-Reply-To: References: Message-ID: <6vBVdKB9tom6dPkNDPpDe9fOmnIsXHhqAczxVZeDNJ0=.64c95d40-f532-441e-9a18-e5512d9eaef7@github.com> > This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. > > With PCH disabled, this reduces total includes from 276949 to 276332 Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge branch 'master' into ciSymbols - @iklam reviews, additional cleanup - remote merge - Prepare for 1237 changes - Adjust includes after vmIntrinsic changes - Merge master - Outline is_call_site_target to remove include from ciField.hpp - Outline is_autobox_cache to remove include from ciField.hpp - Merge branch 'master' into ciSymbols - Fix bad definition - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d0c52651...b8c485b9 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1256/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1256&range=01 Stats: 182 lines in 32 files changed: 101 ins; 30 del; 51 mod Patch: https://git.openjdk.java.net/jdk/pull/1256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1256/head:pull/1256 PR: https://git.openjdk.java.net/jdk/pull/1256 From redestad at openjdk.java.net Tue Dec 8 13:28:37 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Dec 2020 13:28:37 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v3] In-Reply-To: References: Message-ID: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Claes Redestad 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 16 additional commits since the last revision: - Merge branch 'master' into log2_template - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template - Ensure proper promotion from signed to unsigned for 32-bit signed values - Clean up exact_log2 comments - Invalid use of uintptr_t, use uint64_t to handle 64-bit integers properly on 32-bit - Renaming: log2_integral->log2i, _zero->_allow_zero - Merge branch 'master' into log2_template - Add simple microbenchmarks - fix log2_int use in c1_LIRGenerator_ppc/s390 - Merge branch 'master' into log2_template - ... and 6 more: https://git.openjdk.java.net/jdk/compare/7d6878e9...0556faef ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1663/files - new: https://git.openjdk.java.net/jdk/pull/1663/files/93ae0924..0556faef Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=01-02 Stats: 1938 lines in 49 files changed: 1465 ins; 276 del; 197 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 From pliden at openjdk.java.net Tue Dec 8 13:46:21 2020 From: pliden at openjdk.java.net (Per Liden) Date: Tue, 8 Dec 2020 13:46:21 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap Message-ID: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> MaxVirtMemFraction limits the amount of address space the GC should use for the heap. This is used by the heuristics in Arguments::set_heap_size() to select an appropriate default max heap size. However, that heuristic can select a max heap size that will not fit with ZGC, since ZGC uses additional address space (for multi-mapping and the virtual-to-physical ratio). As a result, if the address space is limited, and -Xmx is not specified, then ZGC might refuse to start with the error: "Failed to reserve enough address space for Java heap" I propose we abstract MaxVirtMemFraction to make it configurable for each GC, so that the heuristics in Arguments::set_heap_size() will pick a default max heap size that also works for ZGC. Testing: Manual testing using different ulimit -v sizes. ------------- Commit messages: - 8257901: ZGC: Take virtual memory usage into account when sizing heap Changes: https://git.openjdk.java.net/jdk/pull/1696/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1696&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257901 Stats: 17 lines in 6 files changed: 15 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1696.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1696/head:pull/1696 PR: https://git.openjdk.java.net/jdk/pull/1696 From kim.barrett at oracle.com Tue Dec 8 13:46:24 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 8 Dec 2020 08:46:24 -0500 Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: <716cb12d-0749-77b9-f449-61a1caf98490@oracle.com> References: <716cb12d-0749-77b9-f449-61a1caf98490@oracle.com> Message-ID: > On Dec 8, 2020, at 7:49 AM, Claes Redestad wrote: > > Hi Kim, > > On 2020-12-08 02:43, Kim Barrett wrote: > > I think you misread slightly: the behavior of the pre-existing code *is* > to similarly treat signed values as unsigned wrt checking power_of_2: > > inline int exact_log2(intptr_t x) { > assert(is_power_of_2((uintptr_t)x), "x must be a power of 2: " INTPTR_FORMAT, x); > ... > > inline int exact_log2_long(jlong x) { > assert(is_power_of_2((julong)x), "x must be a power of 2: " JLONG_FORMAT, x); > > exact_log2i does an equivalent check. So unless I'm misreading the > context I'm _preserving_ this behavior. You are right, I missed those pesky ?u?s in those pesky casts. Yuck! > I agree we could opt for a stricter precondition in the new method > (exact_ilog2?), while retrofitting exact_log/exact_log2_long to be > backwards compatible w.r.t. accepting signed values that turn into > 0x8000... when cast to unsigned. I think we should then follow-up > and remove exact_log2/-_long. > > WDYT? That seems like a good plan to me. Similarly for ilog2. I think with that approach you don?t need the _allow_zero form either. It?s just a precondition of ilog2 that the argument is > 0. Also, exact_ilog2 should use count_trailing_zeros. 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 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 stuefe at openjdk.java.net Tue Dec 8 14:23:15 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 8 Dec 2020 14:23:15 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 01:15:46 GMT, Kim Barrett wrote: >> This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp >> >> Naming is hard, but I think the following scheme is reasonable: >> >> - log2i: any integral type. 0-hostile >> - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) >> - exact_log2i: any integral type. value must be a power of two >> >> I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. >> >> Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. >> >> To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: >> >> [ RUN ] power_of_2.log2_long_micro >> [ OK ] power_of_2.log2_long_micro (3581 ms) >> [ RUN ] power_of_2.log2_long_small_micro >> [ OK ] power_of_2.log2_long_small_micro (549 ms) >> [ RUN ] power_of_2.log2i_micro >> [ OK ] power_of_2.log2i_micro (259 ms) >> [ RUN ] power_of_2.log2i_small_micro >> [ OK ] power_of_2.log2i_small_micro (113 ms) >> >> I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W >> >> (Intending this for 17) > >> Naming is hard, but I think the following scheme is reasonable: >> >> * log2i: any integral type. 0-hostile > > Not yet a review, but the "usual" name is "ilog2". Do a web search for that and you'll find lots of relevant hits. I like the short name having the non-zero precondition. Whether the longer version that tests for zero carry's it's weight is a question. Do you guys test on big endian? To be sure I'll run this through our landscape. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 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 redestad at openjdk.java.net Tue Dec 8 14:44:34 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Dec 2020 14:44:34 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v4] In-Reply-To: References: Message-ID: <6g6nFK3B4gy4_79QFv6k2Jwr1JWbEPv6NtE5tzQ-PsM=.df6af0dc-87ea-48d9-ba89-c280ebb2b228@github.com> > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Rename exact_log2i exact_ilog2, make it stricter ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1663/files - new: https://git.openjdk.java.net/jdk/pull/1663/files/0556faef..6daaaf64 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=02-03 Stats: 62 lines in 21 files changed: 2 ins; 0 del; 60 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 From redestad at openjdk.java.net Tue Dec 8 14:52:15 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Dec 2020 14:52:15 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 14:20:21 GMT, Thomas Stuefe wrote: > Do you guys test on big endian? To be sure I'll run this through our landscape. Some big endian testing would be much appreciated. I'm redesigning the `log2i` function based on Kim's feedback, which might hit a few road bumps so I'm pushing it through some local sanity testing. Hold on. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 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 thomas.stuefe at gmail.com Tue Dec 8 15:00:46 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 8 Dec 2020 16:00:46 +0100 Subject: HotSpot Style Guide change process In-Reply-To: References: <376E1F97-57DE-46CD-B656-BC5340E0BA07@oracle.com> Message-ID: On Mon, Dec 7, 2020 at 9:02 AM Kim Barrett wrote: > > On Dec 2, 2020, at 9:25 AM, Thomas St?fe > wrote: > > On Wed, Dec 2, 2020 at 12:04 PM Kim Barrett > wrote: > >> I?d still like to get some feedback on the mechanics. Is what I?ve > done for a couple > >> of changes working for folks? That is, is using a normal github PR for > the change, > >> with ?yes? votes via review approvals, good enough? Are there changes > that would > >> make this work better? I?m mostly worried that we seem to be getting > more or less > >> the same small group of people. I can?t tell if that?s because others > aren?t bothering, > >> or are they not noticing. We want high visibility on changes to the > Style Guide. > >> > > > > Hi Kim, > > > > For me, it is not lack of interest. But changes to the style guide often > drift to the bottom of the pile since there is so much to do, and > discussing them takes time. > > I understand that. I've been intentionally sticking to things I think > should be uncontroversial for the initial few modifications from the > recent big update, to help figure out details of the process. There > are a number of items "in the queue" that I expect will be more > contentious. > I am awaiting some of them eagerly, e.g. the use of "override". > > hotspot-dev being out of commission for so long in summer did not help > either. > > Yes, having hotspot-dev be effectively Oracle-internal-only for a critical > period was not at all helpful. > > > I sometimes do feel ambivalent about new features, like they don't bring > enough to the table to justify the churn. One example, Uniform > Initialization increased the number of idioms one has to know, without > simplifying anything, since old-style initialization won't go away. But my > emotions are never strong enough to publicly block such a proposal with a > negative vote, especially in the face of exclusively positive feedback. > > Perhaps my expections of what should be uncontroversial might be a bit > off? If you want to revisit that one, I'm fine with doing so. Obviously, > I have opinions... > > I regret bringing up that point, since it served no purpose for this discussion. I brought this up to demonstrate that the silence does not mean nobody notices these decisions. This particular point is not important enough to rekindle the discussion. The point of "rough consensus" is that it really isn't a vote, it's an > attempt to determine both whether there is general support and, at > least as importantly, whether there is something wrong with the > proposal such that it needs to be fixed or something else should be > done (including not making a change at all). > I understand. > > I have no ready proposals of how to improve the process, just the vague > feeling that PRs are maybe a bit low-key. And sometimes move too fast. > Especially since the mail flood increased a lot since we switched to skara > tooling. > > That's part of why I've been intentionally sending them out with a > time window for discussion, and not treating them like normal PRs that > can be integrated as soon as the requisite number of reviews are > obtained and comments addressed. > > But there isn't currently anything really highlighting these PRs and > the associated email threads as "special", other than having "HotSpot > Style Guide" in the subject. > I'll set up a mail filter to highlight those. The only idea I came up with is since these discussions are easier at the start of a new release - everybody still has time - we could cluster them around that time? That would also introduce a rhythm which people can get used to. Personally, I'd also prefer if these discussions were held independently from a PR, since the Skara tooling causes too many mails and makes the archived ML threads fragmented, and we still have no solution for the fake-mail-address-problem. Thanks, Thomas 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 redestad at openjdk.java.net Tue Dec 8 15:14:27 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Dec 2020 15:14:27 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v5] In-Reply-To: References: Message-ID: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Rename log2i ilogi and make it only accept value > 0, rename log2i_allow_zero log2i_graceful, accepting any value ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1663/files - new: https://git.openjdk.java.net/jdk/pull/1663/files/6daaaf64..96c51b07 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=03-04 Stats: 99 lines in 21 files changed: 15 ins; 6 del; 78 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 From redestad at openjdk.java.net Tue Dec 8 15:23:13 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Dec 2020 15:23:13 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 14:49:09 GMT, Claes Redestad wrote: >> Do you guys test on big endian? To be sure I'll run this through our landscape. > >> Do you guys test on big endian? To be sure I'll run this through our landscape. > > Some big endian testing would be much appreciated. > > I'm redesigning the `log2i` function based on Kim's feedback, which might hit a few road bumps so I'm pushing it through some local sanity testing. Hold on. Revamped the non-exact variants as `ilog2` + `ilog2_graceful`. The former has `value > 0` as a precondition, the second accepts any value and is used when it's not obvious the input can be assumed to be a non-zero, positive value. I hope this is an acceptable compromise to reinstating the `log2_int`, `log2_long` etc variants. I've gone through all usage to see if there are some additional places where we now need to use the graceful variant, and will do another pass later after I've rested my eyes and the changes have worked through a few tiers of testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From stefank at openjdk.java.net Tue Dec 8 16:20:30 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 8 Dec 2020 16:20:30 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 15:19:48 GMT, Claes Redestad wrote: >>> Do you guys test on big endian? To be sure I'll run this through our landscape. >> >> Some big endian testing would be much appreciated. >> >> I'm redesigning the `log2i` function based on Kim's feedback, which might hit a few road bumps so I'm pushing it through some local sanity testing. Hold on. > > Revamped the non-exact variants as `ilog2` + `ilog2_graceful`. The former has `value > 0` as a precondition, the second accepts any value and is used when it's not obvious the input can be assumed to be a non-zero, positive value. I hope this is an acceptable compromise to reinstating the `log2_int`, `log2_long` etc variants. > > I've gone through all usage to see if there are some additional places where we now need to use the graceful variant, and will do another pass later after I've rested my eyes and the changes have worked through a few tiers of testing. I'm not sure about the ilog2 name. 1) If it's commonly used elsewhere then we're begging for a name clashes. 2) I don't like the discoverability of that name. If I write code where I need log2 then I'll look for functions named log2* not *log2. I know that's already a problem with exact_log2, but maybe that function also could be renamed? These are not hard objects, but maybe others agree? ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From redestad at openjdk.java.net Tue Dec 8 16:22:44 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Dec 2020 16:22:44 GMT Subject: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() [v3] In-Reply-To: References: Message-ID: > This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. > > With PCH disabled, this reduces total includes from 276949 to 276332 Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: ciMethod needs classfile/vmIntrinsics.hpp after 8252505 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1256/files - new: https://git.openjdk.java.net/jdk/pull/1256/files/b8c485b9..2144b16f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1256&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1256&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1256.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1256/head:pull/1256 PR: https://git.openjdk.java.net/jdk/pull/1256 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 iwalulya at openjdk.java.net Tue Dec 8 16:25:27 2020 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Tue, 8 Dec 2020 16:25:27 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v9] In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 23:35:28 GMT, Marcus G K Williams wrote: >> When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using >> Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). >> >> This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). >> >> In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > Fix space format, use Linux:: for local func. > > Signed-off-by: Marcus G K Williams Changes requested by iwalulya (Committer). src/hotspot/os/linux/os_linux.cpp line 3726: > 3724: } > 3725: > 3726: void os::Linux::register_large_page_sizes() { Please refactor to remove duplicated code with` find_large_page_size`, probably use `register_large_page_sizes` to eliminate the need for `find_large_page_size` src/hotspot/os/linux/os_linux.cpp line 4221: > 4219: } > 4220: > 4221: size_t os::Linux::select_large_page_size(size_t bytes) { As mentioned by @tstuefe , this is duplicating `size_t os::page_size_for_region(size_t region_size, size_t min_pages, bool must_be_aligned) ` ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 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 stuefe at openjdk.java.net Tue Dec 8 17:19:13 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 8 Dec 2020 17:19:13 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 16:12:40 GMT, Stefan Karlsson wrote: > I'm not sure about the ilog2 name. > > 1. If it's commonly used elsewhere then we're begging for a name clashes. > 2. I don't like the discoverability of that name. If I write code where I need log2 then I'll look for functions named log2* not *log2. I know that's already a problem with exact_log2, but maybe that function also could be renamed? > > These are not hard objects, but maybe others agree? I agree (including renaming exact_log2). ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 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 iklam at openjdk.java.net Tue Dec 8 17:23:17 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Dec 2020 17:23:17 GMT Subject: RFR: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() [v3] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 16:22:44 GMT, Claes Redestad wrote: >> This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. >> >> With PCH disabled, this reduces total includes from 276949 to 276332 > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > ciMethod needs classfile/vmIntrinsics.hpp after 8252505 Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1256 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 github.com+168222+mgkwill at openjdk.java.net Tue Dec 8 18:03:25 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Dec 2020 18:03:25 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v9] In-Reply-To: References: Message-ID: <8qgrg_WguUKoqYco2cHwDJPBLvgaSkZNHnxy0zucubo=.f3d6cf56-2178-4b0d-bebe-e269001b5f44@github.com> On Tue, 8 Dec 2020 16:19:27 GMT, Ivan Walulya wrote: >> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix space format, use Linux:: for local func. >> >> Signed-off-by: Marcus G K Williams > > src/hotspot/os/linux/os_linux.cpp line 4221: > >> 4219: } >> 4220: >> 4221: size_t os::Linux::select_large_page_size(size_t bytes) { > > As mentioned by @tstuefe , this is duplicating `size_t os::page_size_for_region(size_t region_size, size_t min_pages, bool must_be_aligned) ` In latest patch I removed os::Linux::select_large_page_size and use os::page_size_for_region instead. > src/hotspot/os/linux/os_linux.cpp line 3726: > >> 3724: } >> 3725: >> 3726: void os::Linux::register_large_page_sizes() { > > Please refactor to remove duplicated code with` find_large_page_size`, probably use `register_large_page_sizes` to eliminate the need for `find_large_page_size` In latest patch I removed Linux::find_large_page_size and use register_large_page_sizes. I tried to streamline Linux::setup_large_page_size. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Tue Dec 8 18:03:24 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Dec 2020 18:03:24 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v10] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Ivan W. Requested Changes Removed os::Linux::select_large_page_size and use os::page_size_for_region instead Removed Linux::find_large_page_size and use register_large_page_sizes. Streamlined Linux::setup_large_page_size Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1153/files - new: https://git.openjdk.java.net/jdk/pull/1153/files/870e8a54..0bfc0cbb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=08-09 Stats: 72 lines in 2 files changed: 12 ins; 51 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 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 github.com+168222+mgkwill at openjdk.java.net Tue Dec 8 18:14:08 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Dec 2020 18:14:08 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v9] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 16:22:35 GMT, Ivan Walulya wrote: >> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix space format, use Linux:: for local func. >> >> Signed-off-by: Marcus G K Williams > > Changes requested by iwalulya (Committer). Hi Ivan (@walulyai). Thanks for the review! I've addressed you and Thomas suggestion about duplication. Let me know if this meets your expectation or if further changes are required. Thanks, Marcus ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From jbhateja at openjdk.java.net Tue Dec 8 18:19:24 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 8 Dec 2020 18:19:24 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v4] In-Reply-To: References: Message-ID: > A newly allocated memory is initialized either using user provided initialization values for various fields or setting the memory to zero as per java semantics (System initialization). > > C2 compiler creates ClearArray Node in order to perform system initialization. ClearArray accepts the number of Heap Words to be initialized, this number can be constant or a non-constant value. For constant number of heap words less than InitArrayShortSize (default value 64 bytes) currently compiler generates StoreL nodes which does the initialization at the granularity of 8 bytes. > > This patch vectorizes the initializing store operations for constant sized heap word less than InitArrayShortSize by emitting special instruction sequence for various tail sizes. > > In addition existing implementation for initialization under UseXMMForObjInit is extended to use masked operation to optimize tail initialization sequence. In case AVX3Threshold is set to 0 then new initialization sequence uses 64 byte ZMM registers. > > Following are the performance stats collected using micro-benchmark included with the patch. > > Testing : Tier1-Tier3 level tests are clean. > > System Configuration : Cascadelake, Intel Xeon Platinum 8280L @ 2.7 GHz, 2 socket, 28 cores per socket. > > Baseline: > Benchmark Mode Cnt Score Error Units > ClearMemory.testClearMemory3 thrpt 10 212508.522 ?? 14071.493 ops/s > ClearMemory.testClearMemory4 thrpt 10 189530.643 ?? 12882.421 ops/s > ClearMemory.testClearMemory5 thrpt 10 167878.803 ?? 10307.163 ops/s > ClearMemory.testClearMemory6 thrpt 10 152732.184 ?? 8740.128 ops/s > ClearMemory.testClearMemory7 thrpt 10 132111.536 ?? 5493.043 ops/s > > With Optimization: > > Benchmark Mode Cnt Score Error Units > ClearMemory.testClearMemory3 thrpt 10 220378.082 ?? 18533.701 ops/s > ClearMemory.testClearMemory4 thrpt 10 198023.913 ?? 15995.780 ops/s > ClearMemory.testClearMemory5 thrpt 10 183476.886 ?? 13488.821 ops/s > ClearMemory.testClearMemory6 thrpt 10 161710.750 ?? 9270.182 ops/s > ClearMemory.testClearMemory7 thrpt 10 145059.426 ?? 8217.484 ops/s Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8257772: Changing the default value for UseXMMForObjInit and UseFastStosb flags. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1631/files - new: https://git.openjdk.java.net/jdk/pull/1631/files/f96c01e7..af1bf755 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1631&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1631&range=02-03 Stats: 90 lines in 3 files changed: 50 ins; 12 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/1631.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1631/head:pull/1631 PR: https://git.openjdk.java.net/jdk/pull/1631 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 jbhateja at openjdk.java.net Tue Dec 8 18:35:13 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 8 Dec 2020 18:35:13 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v2] In-Reply-To: References: <9HY90sUJYnM1wAbRS_WDqTrh-JBsWdrQG1zKEH9wjO8=.eb90017f-2622-4ac4-9921-05e6bc9a0aa7@github.com> Message-ID: On Tue, 8 Dec 2020 12:20:13 GMT, Tobias Hartmann wrote: > Just noticed that you didn't update the patch yet. Could you first push the fix? Done ------------- PR: https://git.openjdk.java.net/jdk/pull/1631 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 iwalulya at openjdk.java.net Tue Dec 8 18:48:10 2020 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Tue, 8 Dec 2020 18:48:10 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v9] In-Reply-To: <8qgrg_WguUKoqYco2cHwDJPBLvgaSkZNHnxy0zucubo=.f3d6cf56-2178-4b0d-bebe-e269001b5f44@github.com> References: <8qgrg_WguUKoqYco2cHwDJPBLvgaSkZNHnxy0zucubo=.f3d6cf56-2178-4b0d-bebe-e269001b5f44@github.com> Message-ID: On Tue, 8 Dec 2020 18:00:35 GMT, Marcus G K Williams wrote: >> src/hotspot/os/linux/os_linux.cpp line 3726: >> >>> 3724: } >>> 3725: >>> 3726: void os::Linux::register_large_page_sizes() { >> >> Please refactor to remove duplicated code with` find_large_page_size`, probably use `register_large_page_sizes` to eliminate the need for `find_large_page_size` > > In latest patch I removed Linux::find_large_page_size and use register_large_page_sizes. I tried to streamline Linux::setup_large_page_size. with those changes, you have created a bug on os::large_page_size(), I don't think _large_page_size is set (unless I missed it). ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Tue Dec 8 19:11:50 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Dec 2020 19:11:50 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v9] In-Reply-To: References: <8qgrg_WguUKoqYco2cHwDJPBLvgaSkZNHnxy0zucubo=.f3d6cf56-2178-4b0d-bebe-e269001b5f44@github.com> Message-ID: On Tue, 8 Dec 2020 18:44:54 GMT, Ivan Walulya wrote: >> In latest patch I removed Linux::find_large_page_size and use register_large_page_sizes. I tried to streamline Linux::setup_large_page_size. > > with those changes, you have created a bug on os::large_page_size(), I don't think _large_page_size is set (unless I missed it). You are correct. That escaped me, even though I was looking for where os::large_page_size() was set. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Tue Dec 8 19:11:46 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Dec 2020 19:11:46 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v11] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Fix os::large_page_size() in last update Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1153/files - new: https://git.openjdk.java.net/jdk/pull/1153/files/0bfc0cbb..85e75025 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=09-10 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From redestad at openjdk.java.net Tue Dec 8 19:32:01 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Dec 2020 19:32:01 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v6] In-Reply-To: References: Message-ID: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: x->value ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1663/files - new: https://git.openjdk.java.net/jdk/pull/1663/files/96c51b07..2abbb412 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 From redestad at openjdk.java.net Tue Dec 8 19:34:39 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Dec 2020 19:34:39 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 17:16:30 GMT, Thomas Stuefe wrote: >> I'm not sure about the ilog2 name. >> 1) If it's commonly used elsewhere then we're begging for a name clashes. >> 2) I don't like the discoverability of that name. If I write code where I need log2 then I'll look for functions named log2* not *log2. I know that's already a problem with exact_log2, but maybe that function also could be renamed? >> >> These are not hard objects, but maybe others agree? > >> I'm not sure about the ilog2 name. >> >> 1. If it's commonly used elsewhere then we're begging for a name clashes. >> 2. I don't like the discoverability of that name. If I write code where I need log2 then I'll look for functions named log2* not *log2. I know that's already a problem with exact_log2, but maybe that function also could be renamed? >> >> These are not hard objects, but maybe others agree? > > I agree (including renaming exact_log2). So how about: log2i log2i_exact log2i_graceful I'm not married to the `log2i_graceful`, but with a goal to get rid of it maybe that's ok? ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From volker.simonis at gmail.com Tue Dec 8 20:21:52 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 8 Dec 2020 21:21:52 +0100 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: <057d136b-73ba-9f75-0daa-7cca6bad89c4@redhat.com> References: <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> <057d136b-73ba-9f75-0daa-7cca6bad89c4@redhat.com> Message-ID: I've just realized that apparently, after PR was closed, comments on that PR are still forwarded to the corresponding mailing list thread whereas answers on the mailing list thread are not appended to the PR any more. This means that all the latest answers on the mailing list thread are not part of the PR anymore and have to be added manually if somebody thinks it is important. I'm not sure if this is intended behaviour or a bug but as the direction from "Closed PR" to "Mailling List Thread" is still working I'm inclined to call it a bug :) I think I should open a bug for this issue. On Tue, Dec 8, 2020 at 1:21 PM Andrew Haley wrote: > > On 08/12/2020 10:42, Thomas Wuerthinger wrote: > > >> I don't think the OpenJDK project has a responsibility to justify > >> its implementation details to other projects which try to emulate > >> its behaviour. > > > My understanding as a member of the OpenJDK community was that a > > GitHub PR like this is the appropriate place to engage in > > collaborative discussions. Let me know if this kind of engagement is > > undesirable. > > I hope that Volker will forgive me if I've misinterpreted him, but I > don't think that it's a matter of where this discussion occurs. > OpenJDK has to be able to make its own decisions about its internal > implementation details without regard to other projects which choose > to emulate all of the behaviour of OpenJDK. I think he's right about > this. We can't keep looking over our shoulders to see what projects > who consume some of OpenJDK might be doing. > > On the other hand, I believe that blackhole is a useful thing to have > beyond merely JMH. (For example, it may lead to a sane implementation > of Reference.reachabilityFence(). That would be nice.) > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From simonis at openjdk.java.net Tue Dec 8 20:59:37 2020 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 8 Dec 2020 20:59:37 GMT Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: References: <2JW2_FMNx0zr1O2c2rG_z9zDppiYRuu75p8JZztr4q8=.a3994a74-7001-4c71-b06c-55c79d9802f9@github.com> <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> Message-ID: On Tue, 8 Dec 2020 10:38:23 GMT, Thomas Wuerthinger wrote: >> This change would have definitely required a CSR as described in [Hotspot Command-line Flags: Kinds, Lifecycle and the CSR Process](https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process). >> >> Besides that, I don't understand @thomaswue argumentation that he's "*forced to implement this new feature in the GraalVM compiler or there will be unexpected observable differences in behaviour when executing the same Java application with the same command line flags*". `-XX:` options are definitely an implementation detail of OpenJDK and as such not related to the Java SE specification in any way. The fact that the `-XX:` options are sub-devided into *product*, *diagnostic* and *experimental* options is again specific to the OpenJDK project and only denotes the level of support these options get within the project and not their relation to the Java SE specification. >> >> Misusing the new new option will already have unpredictable effects in OpenJDK itself and make it behave "Java SE" incompatible. I don't think there's a requirement that all configurations (i.e. all combinations of command line options) of a "Java SE" implementation have to be "Java SE" compatible and this is especially true for extended options like `-XX:`. And by the way, in addition to the `BreakAt*` command mentioned before, we already have other such options like for example `-XX:AbortVMOnException=` and `-XX:AbortVMOnExceptionMessage=` which make the OpenJDK behave non-Java SE compatible (not sure if you've implemented these in GraalVM in order to fully emulate OpenJDK :) >> >> As far as I can see, a CSR ([JDK-8257827](https://bugs.openjdk.java.net/browse/JDK-8257827)) for this issue has already been created, which is good. Details like declaring this new option *product*, *experimental* or *diagnostic* should be discussed in the CSR, but in the end I don't think the OpenJDK project has a responsibility to justify its implementation details to other projects which try to emulate its behaviour. > > @simonis As one of the many OpenJDK downstream projects, GraalVM inherits by default all code and flags. We add one additional JIT compiler option and test thoroughly that there are zero observable differences other than performance when that option is enabled (which is the default in the GraalVM distribution). > >> I don't think the OpenJDK project has a responsibility to justify its implementation details to other projects which try to emulate its behaviour. > > My understanding as a member of the OpenJDK community was that a GitHub PR like this is the appropriate place to engage in collaborative discussions. Let me know if this kind of engagement is undesirable. I've just realized that apparently, after this PR was closed, comments on the PR were still forwarded to the corresponding mailing list thread whereas answers on the mailing list thread were not appended to this PR any more. If you want to enjoy the full conversation please have a look at the [hotspot-dev mailing list archive](https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-December/). PS: I've also opened [ SKARA-843: Mails are not forwarded to a closed PR any more](https://bugs.openjdk.java.net/browse/SKARA-843) for the Skara team to check this behaviour. ------------- PR: https://git.openjdk.java.net/jdk/pull/1203 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 github.com+168222+mgkwill at openjdk.java.net Tue Dec 8 22:17:45 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Dec 2020 22:17:45 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v9] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 18:10:54 GMT, Marcus G K Williams wrote: >> Changes requested by iwalulya (Committer). > > Hi Ivan (@walulyai). Thanks for the review! > > I've addressed you and Thomas suggestion about duplication. Let me know if this meets your expectation or if further changes are required. > > Thanks, > Marcus > > > Hi Marcus, > > > I generally like this patch. I will do a more thorough review later. But could this wait please until after JDK16 has been forked off? Since I would like this to spend some more times cooking on our more exotic Linuxes. > > > Cheers, Thomas > > > > > > Hi Thomas. I was pushing to get this patch in before JDK16 was forked. > > Can we run exotic Linux tests now? Is there anything else keeping this from inclusion in JDK16? > > As an aside, I will stand behind any patch I get upstream, including maintain it, discuss it or fix bugs. > > Its a simple matter of cycles. Code freeze is Dec 10. I'm snowed in right now. > > Ideally I would liked to have run tests on ppc, s390 and aarch64 with multiple large page sizes enabled and used. A gtest for this scenario would also be good. > > Then, code wise, there are some things we should straighten out. Not necessarily in your patch, but it should happen either before or after your patch is pushed. For example: > > * we now have duplicate code for scanning the available huge pages > * the new select_large_page_size() feels very similar to the existing os::page_size_for_region_xx() functions. > > I leave the decision to the others (@stefank @kstefanj ?). If they are fine with rushing this patch in its current form, its fine for me too. If problems arise in our platforms, we will deactivate this coding for non-Intel platforms before shipping jdk16. > > Cheers, Thomas I've been looking at gtests (test/hotspot/gtest/runtime/test_os_linux.cpp and test/hotspot/gtest/memory/test_virtualspace.cpp) and correct me if I'm wrong but it seems like a gtest for this scenario (1G + 2m large pages or any variation thereof on different platforms) would require the build system to support page sizes (1G pages in this case) on the VM used to run gtests. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Tue Dec 8 22:17:44 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Dec 2020 22:17:44 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v12] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge branch 'master' into update_hlp - Fix os::large_page_size() in last update Signed-off-by: Marcus G K Williams - Ivan W. Requested Changes Removed os::Linux::select_large_page_size and use os::page_size_for_region instead Removed Linux::find_large_page_size and use register_large_page_sizes. Streamlined Linux::setup_large_page_size Signed-off-by: Marcus G K Williams - Fix space format, use Linux:: for local func. Signed-off-by: Marcus G K Williams - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp - Fix merge mistakes Signed-off-by: Marcus G K Williams - Add newline at end of TestLargePageUseForAuxMemory.java Signed-off-by: Marcus G K Williams - Fix merge mistakes Signed-off-by: Marcus G K Williams - Thomas S. Feedback Signed-off-by: Marcus G K Williams - Merge branch 'master' into update_hlp - ... and 8 more: https://git.openjdk.java.net/jdk/compare/c47ab5f6...70bd9016 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=11 Stats: 63 lines in 2 files changed: 24 ins; 11 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Tue Dec 8 22:17:45 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Dec 2020 22:17:45 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v9] In-Reply-To: References: Message-ID: <25liSjMiaKbiCx42cTqv70gLl24lOVCrvUcVvMYhmw0=.e4d2cb3f-66a6-4b23-bea9-5a7f2b97a1a7@github.com> On Tue, 8 Dec 2020 19:24:20 GMT, Marcus G K Williams wrote: >> Hi Ivan (@walulyai). Thanks for the review! >> >> I've addressed you and Thomas suggestion about duplication. Let me know if this meets your expectation or if further changes are required. >> >> Thanks, >> Marcus > >> > > Hi Marcus, >> > > I generally like this patch. I will do a more thorough review later. But could this wait please until after JDK16 has been forked off? Since I would like this to spend some more times cooking on our more exotic Linuxes. >> > > Cheers, Thomas >> > >> > >> > Hi Thomas. I was pushing to get this patch in before JDK16 was forked. >> > Can we run exotic Linux tests now? Is there anything else keeping this from inclusion in JDK16? >> > As an aside, I will stand behind any patch I get upstream, including maintain it, discuss it or fix bugs. >> >> Its a simple matter of cycles. Code freeze is Dec 10. I'm snowed in right now. >> >> Ideally I would liked to have run tests on ppc, s390 and aarch64 with multiple large page sizes enabled and used. A gtest for this scenario would also be good. >> >> Then, code wise, there are some things we should straighten out. Not necessarily in your patch, but it should happen either before or after your patch is pushed. For example: >> >> * we now have duplicate code for scanning the available huge pages >> * the new select_large_page_size() feels very similar to the existing os::page_size_for_region_xx() functions. >> >> I leave the decision to the others (@stefank @kstefanj ?). If they are fine with rushing this patch in its current form, its fine for me too. If problems arise in our platforms, we will deactivate this coding for non-Intel platforms before shipping jdk16. >> >> Cheers, Thomas > > I've been looking at gtests (test/hotspot/gtest/runtime/test_os_linux.cpp and test/hotspot/gtest/memory/test_virtualspace.cpp) and correct me if I'm wrong but it seems like a gtest for this scenario (1G + 2m large pages or any variation thereof on different platforms) would require the build system to support page sizes (1G pages in this case) on the VM used to run gtests. Updated with a merge for changes from master. It appears that some failures were caused by previous merge. See https://bugs.openjdk.java.net/browse/JDK-8257855 ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 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 github.com+168222+mgkwill at openjdk.java.net Tue Dec 8 23:29:37 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 8 Dec 2020 23:29:37 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v9] In-Reply-To: <25liSjMiaKbiCx42cTqv70gLl24lOVCrvUcVvMYhmw0=.e4d2cb3f-66a6-4b23-bea9-5a7f2b97a1a7@github.com> References: <25liSjMiaKbiCx42cTqv70gLl24lOVCrvUcVvMYhmw0=.e4d2cb3f-66a6-4b23-bea9-5a7f2b97a1a7@github.com> Message-ID: On Tue, 8 Dec 2020 22:15:34 GMT, Marcus G K Williams wrote: >>> > > Hi Marcus, >>> > > I generally like this patch. I will do a more thorough review later. But could this wait please until after JDK16 has been forked off? Since I would like this to spend some more times cooking on our more exotic Linuxes. >>> > > Cheers, Thomas >>> > >>> > >>> > Hi Thomas. I was pushing to get this patch in before JDK16 was forked. >>> > Can we run exotic Linux tests now? Is there anything else keeping this from inclusion in JDK16? >>> > As an aside, I will stand behind any patch I get upstream, including maintain it, discuss it or fix bugs. >>> >>> Its a simple matter of cycles. Code freeze is Dec 10. I'm snowed in right now. >>> >>> Ideally I would liked to have run tests on ppc, s390 and aarch64 with multiple large page sizes enabled and used. A gtest for this scenario would also be good. >>> >>> Then, code wise, there are some things we should straighten out. Not necessarily in your patch, but it should happen either before or after your patch is pushed. For example: >>> >>> * we now have duplicate code for scanning the available huge pages >>> * the new select_large_page_size() feels very similar to the existing os::page_size_for_region_xx() functions. >>> >>> I leave the decision to the others (@stefank @kstefanj ?). If they are fine with rushing this patch in its current form, its fine for me too. If problems arise in our platforms, we will deactivate this coding for non-Intel platforms before shipping jdk16. >>> >>> Cheers, Thomas >> >> I've been looking at gtests (test/hotspot/gtest/runtime/test_os_linux.cpp and test/hotspot/gtest/memory/test_virtualspace.cpp) and correct me if I'm wrong but it seems like a gtest for this scenario (1G + 2m large pages or any variation thereof on different platforms) would require the build system to support page sizes (1G pages in this case) on the VM used to run gtests. > > Updated with a merge for changes from master. > > It appears that some failures were caused by previous merge. See https://bugs.openjdk.java.net/browse/JDK-8257855 There also appears to be an issue on TestSegments.java. See https://github.com/openjdk/jdk/pull/1688 https://bugs.openjdk.java.net/browse/JDK-8257887 ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 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 iklam at openjdk.java.net Wed Dec 9 01:40:41 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Dec 2020 01:40:41 GMT Subject: RFR: 8257912: Convert enum iteration to use range-based for loops Message-ID: * For JDK 17* Now that [range-based for loops](https://github.com/openjdk/jdk/pull/1488) are allowed by the [HotSpot Style Guide](https://github.com/openjdk/jdk/blob/52ab72127ddc3ca6575d9d58503ec39c5dff7ab1/doc/hotspot-style.md), I have converted the more verbose syntax: for (vmIntrinsicsIterator it = vmIntrinsicsRange.begin(); it != vmIntrinsicsRange.end(); ++it) { vmIntrinsicID index = *it; nt[as_int(index)] = string; } to for (vmIntrinsicID index : EnumRange{}) { nt[as_int(index)] = string; } I also removed the "convenient" declarations such as `vmIntrinsicsRange` and `vmIntrinsicsIterator` -- these are useful only when writing a traditional for loop, and are probably confusing to everyone else. I've left examples in enumIterator.hpp in case anyone wants to write a traditional for loop. I also added gtest cases for using range-based for loops with `EnumRange<>`. ------------- Commit messages: - 8257912: Convert enum iteration to use range-based for loops Changes: https://git.openjdk.java.net/jdk/pull/1707/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1707&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257912 Stats: 119 lines in 10 files changed: 71 ins; 24 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/1707.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1707/head:pull/1707 PR: https://git.openjdk.java.net/jdk/pull/1707 From kbarrett at openjdk.java.net Wed Dec 9 02:16:38 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 9 Dec 2020 02:16:38 GMT Subject: RFR: 8257912: Convert enum iteration to use range-based for loops In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 01:34:16 GMT, Ioi Lam wrote: > * For JDK 17* > > Now that [range-based for loops](https://github.com/openjdk/jdk/pull/1488) are allowed by the [HotSpot Style Guide](https://github.com/openjdk/jdk/blob/52ab72127ddc3ca6575d9d58503ec39c5dff7ab1/doc/hotspot-style.md), I have converted the more verbose syntax: > > for (vmIntrinsicsIterator it = vmIntrinsicsRange.begin(); it != vmIntrinsicsRange.end(); ++it) { > vmIntrinsicID index = *it; > nt[as_int(index)] = string; > } > > to > > for (vmIntrinsicID index : EnumRange{}) { > nt[as_int(index)] = string; > } > > I also removed the "convenient" declarations such as `vmIntrinsicsRange` and `vmIntrinsicsIterator` -- these are useful only when writing a traditional for loop, and are probably confusing to everyone else. I've left examples in enumIterator.hpp in case anyone wants to write a traditional for loop. > > I also added gtest cases for using range-based for loops with `EnumRange<>`. Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1707 From stefank at openjdk.java.net Wed Dec 9 07:59:37 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 9 Dec 2020 07:59:37 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap In-Reply-To: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: On Tue, 8 Dec 2020 13:41:56 GMT, Per Liden wrote: > MaxVirtMemFraction limits the amount of address space the GC should use for the heap. This is used by the heuristics in Arguments::set_heap_size() to select an appropriate default max heap size. However, that heuristic can select a max heap size that will not fit with ZGC, since ZGC uses additional address space (for multi-mapping and the virtual-to-physical ratio). As a result, if the address space is limited, and -Xmx is not specified, then ZGC might refuse to start with the error: > > "Failed to reserve enough address space for Java heap" > > I propose we abstract MaxVirtMemFraction to make it configurable for each GC, so that the heuristics in Arguments::set_heap_size() will pick a default max heap size that also works for ZGC. > > Testing: Manual testing using different ulimit -v sizes. The functionality seems fine. However, the naming of things are very misleading. Arguments::limit_by_allocatable_memory has no indication that this can only be used to limit the heap memory. The non-ZGC GCs use MaxVirtMemFraction, which doesn't sound like something that has to do with the heap size. But, if you read the description of that flag it's apparent that it's about the max heap size. The added ZGC implementation also highly depend on the fact that max_virtual_memory_fraction() means the "max fraction of virtual memory that can be used by the heap". I think it would be good to name max_virtual_memory_fraction to something that indicates this. Maybe max_heap_to_virtual_memory_fraction() (maybe there's a more succinct name, that still covers what it does?) And limit_by_allocatable_memory should also be changed, before anyone starts to use it as generic function that can be used by the rest of the JVM. If you agree maybe update the names in this PR, or create a separate RFE? ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1696 From stefank at openjdk.java.net Wed Dec 9 08:18:33 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 9 Dec 2020 08:18:33 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: Message-ID: <6ZbwkKDSm10gF-2amGIYxnK0oTm-WqCO4LO-Cz33HCY=.304d3924-b7e4-4929-a4e3-9cd605bdbc0b@github.com> On Tue, 8 Dec 2020 19:31:24 GMT, Claes Redestad wrote: >>> I'm not sure about the ilog2 name. >>> >>> 1. If it's commonly used elsewhere then we're begging for a name clashes. >>> 2. I don't like the discoverability of that name. If I write code where I need log2 then I'll look for functions named log2* not *log2. I know that's already a problem with exact_log2, but maybe that function also could be renamed? >>> >>> These are not hard objects, but maybe others agree? >> >> I agree (including renaming exact_log2). > > So how about: > log2i > log2i_exact > log2i_graceful > I'm not married to the `log2i_graceful`, but with a goal to get rid of it maybe that's ok? The name sounds good to me. I don't mind if you find a better name for the graceful version. As a follow-up we might want to add a log2i_accept_zero, with assert(v >= 0). There are a few places where we want to accept 0, but not negative values. In those places I think that name would be more telling and allow for a faster read-through of the code. BTW, I'm fine with some name churn in follow-up patches if you want to push this soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 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 stefank at openjdk.java.net Wed Dec 9 08:56:42 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 9 Dec 2020 08:56:42 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v6] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 19:32:01 GMT, Claes Redestad wrote: >> This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp >> >> Naming is hard, but I think the following scheme is reasonable: >> >> - log2i: any integral type. 0-hostile >> - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) >> - exact_log2i: any integral type. value must be a power of two >> >> I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. >> >> Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. >> >> To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: >> >> [ RUN ] power_of_2.log2_long_micro >> [ OK ] power_of_2.log2_long_micro (3581 ms) >> [ RUN ] power_of_2.log2_long_small_micro >> [ OK ] power_of_2.log2_long_small_micro (549 ms) >> [ RUN ] power_of_2.log2i_micro >> [ OK ] power_of_2.log2i_micro (259 ms) >> [ RUN ] power_of_2.log2i_small_micro >> [ OK ] power_of_2.log2i_small_micro (113 ms) >> >> I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W >> >> (Intending this for 17) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > x->value src/hotspot/cpu/ppc/ppc.ad line 9078: > 9076: long src2 = $src2$$constant; > 9077: long src3 = $src3$$constant; > 9078: long maskbits = src3 + exact_ilog2((jlong) (julong) (juint) -src2); I can't verify that this is correct. Someone else has to review this and similar changes below. src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp line 142: > 140: const size_t max_address_offset_bits = 44; // 16TB > 141: const size_t address_offset = round_up_power_of_2(MaxHeapSize * ZVirtualToPhysicalRatio); > 142: const size_t address_offset_bits = ilog2(address_offset); exact_ilog2? src/hotspot/share/compiler/compilerDefinitions.cpp line 120: > 118: // one bit shorter then the value of the notification frequency. Set > 119: // max_freq_bits accordingly. > 120: int max_freq_bits = InvocationCounter::number_of_count_bits + 1; Why was the type changed? src/hotspot/share/gc/g1/g1BiasedArray.hpp line 85: > 83: idx_t bias = (uintptr_t)bottom / mapping_granularity_in_bytes; > 84: address base = create_new_base_array(num_target_elems, target_elem_size_in_bytes); > 85: initialize_base(base, num_target_elems, bias, target_elem_size_in_bytes, ilog2(mapping_granularity_in_bytes)); exact_ilog2 src/hotspot/share/gc/g1/g1FreeIdSet.cpp line 47: > 45: // 2^shift must be greater than size. Equal is not permitted, because > 46: // size is the "end of list" value, and can be the index part of _head. > 47: uint shift = ilog2(size) + 1; It's not obvious that it's OK to change the type here. Could you change back so that we don't have to figure that out in this review? src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp line 124: > 122: array->oop_iterate_range(cl, 0, len); > 123: } else { > 124: int bits = ilog2_graceful(len); ilog2 ? len should > ObjArrayMarkingStride*2, so must be positive. src/hotspot/share/gc/z/zHeuristics.cpp line 48: > 46: // Enable medium pages > 47: ZPageSizeMedium = size; > 48: ZPageSizeMediumShift = ilog2(ZPageSizeMedium); exact_ilog2: Setup code is: const size_t min = ZGranuleSize; const size_t max = ZGranuleSize * 16; const size_t unclamped = MaxHeapSize * 0.03125; const size_t clamped = clamp(unclamped, min, max); const size_t size = round_down_power_of_2(clamped); if (size > ZPageSizeSmall) { // Enable medium pages ZPageSizeMedium = size; src/hotspot/share/utilities/powerOfTwo.hpp line 59: > 57: > 58: // Log2 of positive, integral value, i.e., largest i such that 2^i <= value > 59: // Returns ifZero if value is zero, defaulting to -1 Is this used anywhere? Should ifZero be if_zero? test/hotspot/gtest/utilities/test_powerOfTwo.cpp line 268: > 266: #define EXPECT_EQ_ILOG2(type) \ > 267: { \ > 268: int limit = sizeof (type) * BitsPerByte; \ sizeof (type) => sizeof(type) test/hotspot/gtest/utilities/test_powerOfTwo.cpp line 266: > 264: } > 265: > 266: #define EXPECT_EQ_ILOG2(type) \ Is there a reason why this is a macro and not a template function? test/hotspot/gtest/utilities/test_powerOfTwo.cpp line 277: > 275: { \ > 276: /* Test ilog2_graceful handles 0 input */ \ > 277: type var = 1; \ Unused? test/hotspot/gtest/utilities/test_powerOfTwo.cpp line 374: > 372: } > 373: EXPECT_TRUE(value <= 15) << "value: " << value; > 374: } Will these micro benchmarks be removed before pushing? ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From stefank at openjdk.java.net Wed Dec 9 08:56:43 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 9 Dec 2020 08:56:43 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v6] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 08:46:14 GMT, Stefan Karlsson wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> x->value > > test/hotspot/gtest/utilities/test_powerOfTwo.cpp line 266: > >> 264: } >> 265: >> 266: #define EXPECT_EQ_ILOG2(type) \ > > Is there a reason why this is a macro and not a template function? Ah, because you copied these tests. Maybe a future cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From stuefe at openjdk.java.net Wed Dec 9 09:10:36 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 9 Dec 2020 09:10:36 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v9] In-Reply-To: References: <25liSjMiaKbiCx42cTqv70gLl24lOVCrvUcVvMYhmw0=.e4d2cb3f-66a6-4b23-bea9-5a7f2b97a1a7@github.com> Message-ID: <5Z3qMVB7F933CRQ_GxJzvep6zsSrnoh4pBhNM_oAkd8=.d7ee01f9-e4b7-452f-b837-e4805fd2011c@github.com> On Tue, 8 Dec 2020 23:25:46 GMT, Marcus G K Williams wrote: >> Updated with a merge for changes from master. >> >> It appears that some failures were caused by previous merge. See https://bugs.openjdk.java.net/browse/JDK-8257855 > > There also appears to be an issue on TestSegments.java. See https://github.com/openjdk/jdk/pull/1688 > > https://bugs.openjdk.java.net/browse/JDK-8257887 > > https://github.com/mgkwill/jdk/runs/1520624742#step:13:15 Hi Marcus, Sorry, I changed my opinion about JDK16. According to Ivan, one of your last commits broke os::large_page_size(). That is fine, things happen. But what makes me nervous is that it took a reviewer to find this, this should have popped up in tests right away (eg runtime/test_os.cpp, "os_pagesizes" test). So we have holes in test coverage or in the way the tests are executed. The GH actions are of course not enough, since they do not run with large pages to my knowledge. What would be needed, in my opinion: - one jtreg test to test that the VM comes up with `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G` and allocates small-large-pages as expected. This is not only needed as a function proof but to prevent regressions when we reform the code (which will happen) - We should have a gtest run with large pages. I opened https://bugs.openjdk.java.net/browse/JDK-8257959 to track that. - This patch changes behavior insofar as that now we return memory to the caller with a page size which he may not expect. We _think_ this is fine, since committing/uncommitting this memory is disabled. But since this is used by GC and Compiler and potentially other consumers as well, this should be thoroughly tested. I think tier1...3 at least, plus gc stress tests? probably with LargePageSizeInBytes=1G specified for all those tests. Side note: gtests are not bound to the build. You can run them manually by launching the gtestlauncher: `./hotspot/variant-xxx/libjvm/gtest/gtestLauncher -jdk:./images/jdk` You can add VM options to it, e.g.: `./hotspot/variant-xxx/libjvm/gtest/gtestLauncher -jdk:./images/jdk -Xmx128m -XX:+UseLargePages -XX:LargePageSizeInBytes=1G` and you probably should run this at least manually for your patch. Note caveat: death tests will fail with LP, see JDK-8257229. Figuring all this out would be something we would assist you with. But you try to push this into JDK16, whose deadline is tomorrow. That puts us into an awkward position. The way it is now, we only could integrate this without having run many tests, without regression testing and without testing on non-Intel platforms. I do not think this is the right way. Note that if you think JDK16 is important you always can backport changes to older releases once the patch is in JDK17 and has been tested there. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From chagedorn at openjdk.java.net Wed Dec 9 09:12:37 2020 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Wed, 9 Dec 2020 09:12:37 GMT Subject: RFR: 8245107: Use Unified Logging in trace_method_handle_stub() In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 15:16:01 GMT, Christian Hagedorn wrote: >> Looks correct. Works on PPC64 and s390. > > Thanks Martin for your review and the verification on PPC64 and s390! Could anybody also quickly verify that the changes in `methodHandles_arm.cpp` build and are correct? ------------- PR: https://git.openjdk.java.net/jdk/pull/1665 From stefank at openjdk.java.net Wed Dec 9 09:13:36 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 9 Dec 2020 09:13:36 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v9] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 19:24:20 GMT, Marcus G K Williams wrote: > I leave the decision to the others (@stefank @kstefanj ?). If they are fine with rushing this patch in its current form, its fine for me too. If problems arise in our platforms, we will deactivate this coding for non-Intel platforms before shipping jdk16. I see that @tstuefe pinged me. I've talked to @walulyai and he's going to review this change and figure out if it makes it into JDK 16. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From stuefe at openjdk.java.net Wed Dec 9 09:14:35 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 9 Dec 2020 09:14:35 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: <6ZbwkKDSm10gF-2amGIYxnK0oTm-WqCO4LO-Cz33HCY=.304d3924-b7e4-4929-a4e3-9cd605bdbc0b@github.com> References: <6ZbwkKDSm10gF-2amGIYxnK0oTm-WqCO4LO-Cz33HCY=.304d3924-b7e4-4929-a4e3-9cd605bdbc0b@github.com> Message-ID: On Wed, 9 Dec 2020 08:16:11 GMT, Stefan Karlsson wrote: >> So how about: >> log2i >> log2i_exact >> log2i_graceful >> I'm not married to the `log2i_graceful`, but with a goal to get rid of it maybe that's ok? > > The name sounds good to me. I don't mind if you find a better name for the graceful version. As a follow-up we might want to add a log2i_accept_zero, with assert(v >= 0). There are a few places where we want to accept 0, but not negative values. In those places I think that name would be more telling and allow for a faster read-through of the code. > > BTW, I'm fine with some name churn in follow-up patches if you want to push this soon. All our debug builds failed tonight: abstractCompiler.cpp d:\priv\openjdk\nb\ntamd64\jdk-dev\src\hotspot\share\utilities/powerOfTwo.hpp(53): error C2065: 'x': undeclared identifier d:\priv\openjdk\nb\ntamd64\jdk-dev\src\hotspot\share\utilities/powerOfTwo.hpp(78): note: see reference to function template instantiation 'int ilog2(T)' being compiled with [ T=uintptr_t ] d:\priv\openjdk\nb\ntamd64\jdk-dev\src\hotspot\share\utilities/powerOfTwo.hpp(83): note: see reference to function template instantiation 'int exact_ilog2(T)' being compiled with [ T=uintptr_t ] ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From stefank at openjdk.java.net Wed Dec 9 09:39:37 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 9 Dec 2020 09:39:37 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v6] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 19:32:01 GMT, Claes Redestad wrote: >> This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp >> >> Naming is hard, but I think the following scheme is reasonable: >> >> - log2i: any integral type. 0-hostile >> - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) >> - exact_log2i: any integral type. value must be a power of two >> >> I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. >> >> Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. >> >> To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: >> >> [ RUN ] power_of_2.log2_long_micro >> [ OK ] power_of_2.log2_long_micro (3581 ms) >> [ RUN ] power_of_2.log2_long_small_micro >> [ OK ] power_of_2.log2_long_small_micro (549 ms) >> [ RUN ] power_of_2.log2i_micro >> [ OK ] power_of_2.log2i_micro (259 ms) >> [ RUN ] power_of_2.log2i_small_micro >> [ OK ] power_of_2.log2i_small_micro (113 ms) >> >> I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W >> >> (Intending this for 17) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > x->value src/hotspot/share/utilities/powerOfTwo.hpp line 76: > 74: inline int exact_ilog2(T value) { > 75: assert(is_power_of_2(value), > 76: "x must be a power of 2: " UINT64_FORMAT, x => value ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From stefank at openjdk.java.net Wed Dec 9 09:39:34 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 9 Dec 2020 09:39:34 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations In-Reply-To: References: <6ZbwkKDSm10gF-2amGIYxnK0oTm-WqCO4LO-Cz33HCY=.304d3924-b7e4-4929-a4e3-9cd605bdbc0b@github.com> Message-ID: On Wed, 9 Dec 2020 09:11:24 GMT, Thomas Stuefe wrote: >> The name sounds good to me. I don't mind if you find a better name for the graceful version. As a follow-up we might want to add a log2i_accept_zero, with assert(v >= 0). There are a few places where we want to accept 0, but not negative values. In those places I think that name would be more telling and allow for a faster read-through of the code. >> >> BTW, I'm fine with some name churn in follow-up patches if you want to push this soon. > > All our debug builds failed tonight: > > abstractCompiler.cpp > > d:\priv\openjdk\nb\ntamd64\jdk-dev\src\hotspot\share\utilities/powerOfTwo.hpp(53): error C2065: 'x': undeclared identifier > > d:\priv\openjdk\nb\ntamd64\jdk-dev\src\hotspot\share\utilities/powerOfTwo.hpp(78): note: see reference to function template instantiation 'int ilog2(T)' being compiled > > with > > [ > > T=uintptr_t > > ] > > d:\priv\openjdk\nb\ntamd64\jdk-dev\src\hotspot\share\utilities/powerOfTwo.hpp(83): note: see reference to function template instantiation 'int exact_ilog2(T)' being compiled > > with > > [ > > T=uintptr_t > > ] @tstuefe Are you testing the latest version? The current change set has the following on line 53: ` assert(value > T(0), "value must be > 0");` x has been renamed to value with: https://github.com/openjdk/jdk/pull/1663/commits/2abbb412117be91ee306e7fb1c8ed90604754144 ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From pliden at openjdk.java.net Wed Dec 9 09:41:49 2020 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 9 Dec 2020 09:41:49 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v2] In-Reply-To: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: > MaxVirtMemFraction limits the amount of address space the GC should use for the heap. This is used by the heuristics in Arguments::set_heap_size() to select an appropriate default max heap size. However, that heuristic can select a max heap size that will not fit with ZGC, since ZGC uses additional address space (for multi-mapping and the virtual-to-physical ratio). As a result, if the address space is limited, and -Xmx is not specified, then ZGC might refuse to start with the error: > > "Failed to reserve enough address space for Java heap" > > I propose we abstract MaxVirtMemFraction to make it configurable for each GC, so that the heuristics in Arguments::set_heap_size() will pick a default max heap size that also works for ZGC. > > Testing: Manual testing using different ulimit -v sizes. Per Liden has updated the pull request incrementally with one additional commit since the last revision: Review StefanK ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1696/files - new: https://git.openjdk.java.net/jdk/pull/1696/files/09bf660a..4370e0ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1696&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1696&range=00-01 Stats: 23 lines in 7 files changed: 3 ins; 3 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/1696.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1696/head:pull/1696 PR: https://git.openjdk.java.net/jdk/pull/1696 From pliden at openjdk.java.net Wed Dec 9 09:41:50 2020 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 9 Dec 2020 09:41:50 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v2] In-Reply-To: References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: On Wed, 9 Dec 2020 07:56:50 GMT, Stefan Karlsson wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Review StefanK > > The functionality seems fine. However, the naming of things are very misleading. Arguments::limit_by_allocatable_memory has no indication that this can only be used to limit the heap memory. The non-ZGC GCs use MaxVirtMemFraction, which doesn't sound like something that has to do with the heap size. But, if you read the description of that flag it's apparent that it's about the max heap size. The added ZGC implementation also highly depend on the fact that max_virtual_memory_fraction() means the "max fraction of virtual memory that can be used by the heap". I think it would be good to name max_virtual_memory_fraction to something that indicates this. Maybe max_heap_to_virtual_memory_fraction() (maybe there's a more succinct name, that still covers what it does?) And limit_by_allocatable_memory should also be changed, before anyone starts to use it as generic function that can be used by the rest of the JVM. > > If you agree maybe update the names in this PR, or create a separate RFE? @stefank Pushed an update to adjust the names. Also fixed copyrights. ------------- PR: https://git.openjdk.java.net/jdk/pull/1696 From stefank at openjdk.java.net Wed Dec 9 09:47:35 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 9 Dec 2020 09:47:35 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v2] In-Reply-To: References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: On Wed, 9 Dec 2020 09:41:49 GMT, Per Liden wrote: >> MaxVirtMemFraction limits the amount of address space the GC should use for the heap. This is used by the heuristics in Arguments::set_heap_size() to select an appropriate default max heap size. However, that heuristic can select a max heap size that will not fit with ZGC, since ZGC uses additional address space (for multi-mapping and the virtual-to-physical ratio). As a result, if the address space is limited, and -Xmx is not specified, then ZGC might refuse to start with the error: >> >> "Failed to reserve enough address space for Java heap" >> >> I propose we abstract MaxVirtMemFraction to make it configurable for each GC, so that the heuristics in Arguments::set_heap_size() will pick a default max heap size that also works for ZGC. >> >> Testing: Manual testing using different ulimit -v sizes. > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Review StefanK Thanks! ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1696 From yzheng at openjdk.java.net Wed Dec 9 10:08:38 2020 From: yzheng at openjdk.java.net (Yudi Zheng) Date: Wed, 9 Dec 2020 10:08:38 GMT Subject: RFR: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. Message-ID: <-dC7EkSsxPpLvZE5I5ds2CAw1QJfDGNIAxLec7s8o2w=.d8c74ba5-45c4-4041-8674-6edad6dc49a6@github.com> Update exception_seen flag in the MDO when no exception handler is found for caller during deoptimization, or when exception is thrown in the runtime. Plus, `-Xlog:exceptions=info` code and `AbortVMOnException` are adjusted in C1 runtime and jvmci runtime to be consistent with C2, i.e., before `JvmtiExport::can_post_on_exceptions` deoptimization and fast continuation when compiled handler is found. ------------- Commit messages: - Set exception_seen accordingly in the runtime. - Adjust TraceException dumping code in c1 and JVMCI runtimes. Changes: https://git.openjdk.java.net/jdk/pull/1713/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1713&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257910 Stats: 90 lines in 4 files changed: 62 ins; 28 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1713.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1713/head:pull/1713 PR: https://git.openjdk.java.net/jdk/pull/1713 From eosterlund at openjdk.java.net Wed Dec 9 10:18:34 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 9 Dec 2020 10:18:34 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v2] In-Reply-To: References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: On Wed, 9 Dec 2020 09:41:49 GMT, Per Liden wrote: >> MaxVirtMemFraction limits the amount of address space the GC should use for the heap. This is used by the heuristics in Arguments::set_heap_size() to select an appropriate default max heap size. However, that heuristic can select a max heap size that will not fit with ZGC, since ZGC uses additional address space (for multi-mapping and the virtual-to-physical ratio). As a result, if the address space is limited, and -Xmx is not specified, then ZGC might refuse to start with the error: >> >> "Failed to reserve enough address space for Java heap" >> >> I propose we abstract MaxVirtMemFraction to make it configurable for each GC, so that the heuristics in Arguments::set_heap_size() will pick a default max heap size that also works for ZGC. >> >> Testing: Manual testing using different ulimit -v sizes. > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Review StefanK Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1696 From aph at redhat.com Wed Dec 9 10:29:46 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 9 Dec 2020 10:29:46 +0000 Subject: RFR: 8252505: C1/C2 compiler support for blackholes [v24] In-Reply-To: <057d136b-73ba-9f75-0daa-7cca6bad89c4@redhat.com> References: <9RToinlZollRi8t0HsrqdQ8EAvr0hVUiNLSVNgi6BVw=.b8d0b42b-7a94-44dd-a5ab-dacedcc25d5c@github.com> <057d136b-73ba-9f75-0daa-7cca6bad89c4@redhat.com> Message-ID: On 08/12/2020 12:21, Andrew Haley wrote: > I hope that Volker will forgive me if I've misinterpreted him, but I ... My post seems to have been interpreted as saying that I don't think OpenJDK should consider downstream projects when making changes. I'm sorry for the misunderstanding. I didn't say that, and I hope I never would. The question at hand was about blackholes, and the crux of this issue is whether HotSpot support for blackholes should be considered a purely internal implementation detail of OpenJDK or something shared with other projects. Aleksey clearly intended this patch to be an internal OpenJDK thing only, but it doesn't seem to be working out that way. I strongly believe that every project has to care about its downstream projects, otherwise the community wouldn't function at all. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ayang at openjdk.java.net Wed Dec 9 10:43:34 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 9 Dec 2020 10:43:34 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v2] In-Reply-To: References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: On Wed, 9 Dec 2020 09:41:49 GMT, Per Liden wrote: >> MaxVirtMemFraction limits the amount of address space the GC should use for the heap. This is used by the heuristics in Arguments::set_heap_size() to select an appropriate default max heap size. However, that heuristic can select a max heap size that will not fit with ZGC, since ZGC uses additional address space (for multi-mapping and the virtual-to-physical ratio). As a result, if the address space is limited, and -Xmx is not specified, then ZGC might refuse to start with the error: >> >> "Failed to reserve enough address space for Java heap" >> >> I propose we abstract MaxVirtMemFraction to make it configurable for each GC, so that the heuristics in Arguments::set_heap_size() will pick a default max heap size that also works for ZGC. >> >> Testing: Manual testing using different ulimit -v sizes. > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Review StefanK Marked as reviewed by ayang (Author). src/hotspot/share/gc/z/zAddressSpaceLimit.cpp line 49: > 47: > 48: size_t ZAddressSpaceLimit::heap_view() { > 49: // Allow all heap views to occupy 50% of the address space The "50%" description is inaccurate, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/1696 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 tschatzl at openjdk.java.net Wed Dec 9 11:32:36 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 9 Dec 2020 11:32:36 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v2] In-Reply-To: References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: On Wed, 9 Dec 2020 09:41:49 GMT, Per Liden wrote: >> MaxVirtMemFraction limits the amount of address space the GC should use for the heap. This is used by the heuristics in Arguments::set_heap_size() to select an appropriate default max heap size. However, that heuristic can select a max heap size that will not fit with ZGC, since ZGC uses additional address space (for multi-mapping and the virtual-to-physical ratio). As a result, if the address space is limited, and -Xmx is not specified, then ZGC might refuse to start with the error: >> >> "Failed to reserve enough address space for Java heap" >> >> I propose we abstract MaxVirtMemFraction to make it configurable for each GC, so that the heuristics in Arguments::set_heap_size() will pick a default max heap size that also works for ZGC. >> >> Testing: Manual testing using different ulimit -v sizes. > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Review StefanK Changes requested by tschatzl (Reviewer). src/hotspot/share/gc/shared/gcArguments.cpp line 178: > 176: size_t GCArguments::heap_virtual_to_physical_ratio() { > 177: // Used by heap size heuristics to determine max amount > 178: // of address space to use for the heap. Could this explanation moved to the hpp file? Then some IDEs will automatically pick it up. I'd expect a comments to the implementation, i.e. of the value 1 here instead of a generic explanation of what the method does. src/hotspot/share/runtime/arguments.cpp line 1658: > 1656: } > 1657: > 1658: julong Arguments::limit_heap_by_allocatable_memory(julong limit) { If we are already messing with the name in this change, would it be possible to change return value and parameter to `size_t`? I'm good with moving this change of the parameter types to a different issue, but as mentioned, since we are already changing stuff around here... src/hotspot/share/runtime/arguments.hpp line 368: > 366: // limits the given memory size by the maximum amount of memory this process is > 367: // currently allowed to allocate or reserve. > 368: static julong limit_heap_by_allocatable_memory(julong size); Please clarify the documentation of this method also according to the results of this discussion. ------------- PR: https://git.openjdk.java.net/jdk/pull/1696 From kbarrett at openjdk.java.net Wed Dec 9 11:46:38 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 9 Dec 2020 11:46:38 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v6] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 19:32:01 GMT, Claes Redestad wrote: >> This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp >> >> Naming is hard, but I think the following scheme is reasonable: >> >> - log2i: any integral type. 0-hostile >> - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) >> - exact_log2i: any integral type. value must be a power of two >> >> I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. >> >> Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. >> >> To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: >> >> [ RUN ] power_of_2.log2_long_micro >> [ OK ] power_of_2.log2_long_micro (3581 ms) >> [ RUN ] power_of_2.log2_long_small_micro >> [ OK ] power_of_2.log2_long_small_micro (549 ms) >> [ RUN ] power_of_2.log2i_micro >> [ OK ] power_of_2.log2i_micro (259 ms) >> [ RUN ] power_of_2.log2i_small_micro >> [ OK ] power_of_2.log2i_small_micro (113 ms) >> >> I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W >> >> (Intending this for 17) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > x->value I didn't review the ppc or s390 changes, shenandoah changes, or x86_64.ad (I don't understand the language here). src/hotspot/share/utilities/powerOfTwo.hpp line 78: > 76: "x must be a power of 2: " UINT64_FORMAT, > 77: (uint64_t)static_cast::type>(value)); > 78: return ilog2(value); `count_trailing_zeros(value);` is more direct. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 3996: > 3994: /*is32*/false, (uint64_t)CompressedKlassPointers::base())) { > 3995: const uint64_t range_mask = > 3996: (1ULL << ilog2_graceful(CompressedKlassPointers::range())) - 1; I think use of ilog2_graceful is misleading, as a zero argument is not actually permitted here. If the argument is zero, that operation will return -1, which will be used as a shift quantity, which is UB. And since the argument's type is size_t, the "graceful" handling of negative values isn't relevant. src/hotspot/cpu/x86/vm_version_x86.cpp line 784: > 782: cpu_family(), _model, _stepping, os::cpu_microcode_revision()); > 783: assert(res > 0, "not enough temporary space allocated"); > 784: assert(exact_ilog2((uint64_t)CPU_MAX_FEATURE) + 1 == sizeof(_features_names) / sizeof(char*), "wrong size features_names"); Cast of CPU_MAX_FEATURE isn't needed. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1663 From kbarrett at openjdk.java.net Wed Dec 9 11:46:41 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 9 Dec 2020 11:46:41 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v6] In-Reply-To: References: Message-ID: <587x-wtnspJvRwAOBbYuw18LEIGuwJezwKxt3KKUYDY=.c8fa3b38-9070-4f48-afbc-a507a7cc1bd3@github.com> On Wed, 9 Dec 2020 08:25:31 GMT, Stefan Karlsson wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> x->value > > src/hotspot/share/compiler/compilerDefinitions.cpp line 120: > >> 118: // one bit shorter then the value of the notification frequency. Set >> 119: // max_freq_bits accordingly. >> 120: int max_freq_bits = InvocationCounter::number_of_count_bits + 1; > > Why was the type changed? Presumably the type change is so MIN2 can be used on line 127. And there's no obvious reason why the bit counts here should be intx. > src/hotspot/share/gc/g1/g1FreeIdSet.cpp line 47: > >> 45: // 2^shift must be greater than size. Equal is not permitted, because >> 46: // size is the "end of list" value, and can be the index part of _head. >> 47: uint shift = ilog2(size) + 1; > > It's not obvious that it's OK to change the type here. Could you change back so that we don't have to figure that out in this review? The type of `size` is manifestly `uint`. The cast doesn't do anything useful, and I have no idea why it's there, even though it looks like I wrote this code. It certainly seems out of character for me. And I wonder why I didn't use `log2_uint`? Maybe that was added later? ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From pliden at openjdk.java.net Wed Dec 9 11:59:36 2020 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 9 Dec 2020 11:59:36 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v2] In-Reply-To: References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: On Wed, 9 Dec 2020 10:40:20 GMT, Albert Mingkun Yang wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Review StefanK > > src/hotspot/share/gc/z/zAddressSpaceLimit.cpp line 49: > >> 47: >> 48: size_t ZAddressSpaceLimit::heap_view() { >> 49: // Allow all heap views to occupy 50% of the address space > > The "50%" description is inaccurate, right? No, that's still correct. ------------- PR: https://git.openjdk.java.net/jdk/pull/1696 From pliden at openjdk.java.net Wed Dec 9 11:59:40 2020 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 9 Dec 2020 11:59:40 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v2] In-Reply-To: References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: On Wed, 9 Dec 2020 11:26:17 GMT, Thomas Schatzl wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Review StefanK > > src/hotspot/share/gc/shared/gcArguments.cpp line 178: > >> 176: size_t GCArguments::heap_virtual_to_physical_ratio() { >> 177: // Used by heap size heuristics to determine max amount >> 178: // of address space to use for the heap. > > Could this explanation moved to the hpp file? Then some IDEs will automatically pick it up. I'd expect a comments to the implementation, i.e. of the value 1 here instead of a generic explanation of what the method does. Ok, I'll move the comment. > src/hotspot/share/runtime/arguments.cpp line 1658: > >> 1656: } >> 1657: >> 1658: julong Arguments::limit_heap_by_allocatable_memory(julong limit) { > > If we are already messing with the name in this change, would it be possible to change return value and parameter to `size_t`? I'm good with moving this change of the parameter types to a different issue, but as mentioned, since we are already changing stuff around here... I'd prefer to handle that as a separate issue, since such a change would propagate into `os::has_allocatable_memory_limit()` and affect all os:es. ------------- PR: https://git.openjdk.java.net/jdk/pull/1696 From pliden at openjdk.java.net Wed Dec 9 12:10:50 2020 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 9 Dec 2020 12:10:50 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v3] In-Reply-To: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: > MaxVirtMemFraction limits the amount of address space the GC should use for the heap. This is used by the heuristics in Arguments::set_heap_size() to select an appropriate default max heap size. However, that heuristic can select a max heap size that will not fit with ZGC, since ZGC uses additional address space (for multi-mapping and the virtual-to-physical ratio). As a result, if the address space is limited, and -Xmx is not specified, then ZGC might refuse to start with the error: > > "Failed to reserve enough address space for Java heap" > > I propose we abstract MaxVirtMemFraction to make it configurable for each GC, so that the heuristics in Arguments::set_heap_size() will pick a default max heap size that also works for ZGC. > > Testing: Manual testing using different ulimit -v sizes. Per Liden has updated the pull request incrementally with one additional commit since the last revision: Review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1696/files - new: https://git.openjdk.java.net/jdk/pull/1696/files/4370e0ed..eaaf4f97 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1696&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1696&range=01-02 Stats: 9 lines in 3 files changed: 5 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1696.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1696/head:pull/1696 PR: https://git.openjdk.java.net/jdk/pull/1696 From stefank at openjdk.java.net Wed Dec 9 12:10:38 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 9 Dec 2020 12:10:38 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v6] In-Reply-To: <587x-wtnspJvRwAOBbYuw18LEIGuwJezwKxt3KKUYDY=.c8fa3b38-9070-4f48-afbc-a507a7cc1bd3@github.com> References: <587x-wtnspJvRwAOBbYuw18LEIGuwJezwKxt3KKUYDY=.c8fa3b38-9070-4f48-afbc-a507a7cc1bd3@github.com> Message-ID: On Wed, 9 Dec 2020 11:15:32 GMT, Kim Barrett wrote: >> src/hotspot/share/compiler/compilerDefinitions.cpp line 120: >> >>> 118: // one bit shorter then the value of the notification frequency. Set >>> 119: // max_freq_bits accordingly. >>> 120: int max_freq_bits = InvocationCounter::number_of_count_bits + 1; >> >> Why was the type changed? > > Presumably the type change is so MIN2 can be used on line 127. And there's no obvious reason why the bit counts here should be intx. The reason is that ilog2 returns int. I incorrectly reasoned that ilog2 would use the same return type as the input argument. >> src/hotspot/share/gc/g1/g1FreeIdSet.cpp line 47: >> >>> 45: // 2^shift must be greater than size. Equal is not permitted, because >>> 46: // size is the "end of list" value, and can be the index part of _head. >>> 47: uint shift = ilog2(size) + 1; >> >> It's not obvious that it's OK to change the type here. Could you change back so that we don't have to figure that out in this review? > > The type of `size` is manifestly `uint`. The cast doesn't do anything useful, and I have no idea why it's there, even though it looks like I wrote this code. It certainly seems out of character for me. And I wonder why I didn't use `log2_uint`? Maybe that was added later? I agree. This seems fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From tschatzl at openjdk.java.net Wed Dec 9 12:10:50 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 9 Dec 2020 12:10:50 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v3] In-Reply-To: References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: On Wed, 9 Dec 2020 12:08:31 GMT, Per Liden wrote: >> MaxVirtMemFraction limits the amount of address space the GC should use for the heap. This is used by the heuristics in Arguments::set_heap_size() to select an appropriate default max heap size. However, that heuristic can select a max heap size that will not fit with ZGC, since ZGC uses additional address space (for multi-mapping and the virtual-to-physical ratio). As a result, if the address space is limited, and -Xmx is not specified, then ZGC might refuse to start with the error: >> >> "Failed to reserve enough address space for Java heap" >> >> I propose we abstract MaxVirtMemFraction to make it configurable for each GC, so that the heuristics in Arguments::set_heap_size() will pick a default max heap size that also works for ZGC. >> >> Testing: Manual testing using different ulimit -v sizes. > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Review Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1696 From pliden at openjdk.java.net Wed Dec 9 12:10:52 2020 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 9 Dec 2020 12:10:52 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v2] In-Reply-To: References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: On Wed, 9 Dec 2020 11:29:18 GMT, Thomas Schatzl wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Review StefanK > > Changes requested by tschatzl (Reviewer). Pushed an update which addresses @tschatzl's comments. > src/hotspot/share/runtime/arguments.hpp line 368: > >> 366: // limits the given memory size by the maximum amount of memory this process is >> 367: // currently allowed to allocate or reserve. >> 368: static julong limit_heap_by_allocatable_memory(julong size); > > Please clarify the documentation of this method also according to the results of this discussion. Will fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/1696 From tschatzl at openjdk.java.net Wed Dec 9 12:10:52 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 9 Dec 2020 12:10:52 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v2] In-Reply-To: References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: On Wed, 9 Dec 2020 11:56:42 GMT, Per Liden wrote: >> src/hotspot/share/runtime/arguments.cpp line 1658: >> >>> 1656: } >>> 1657: >>> 1658: julong Arguments::limit_heap_by_allocatable_memory(julong limit) { >> >> If we are already messing with the name in this change, would it be possible to change return value and parameter to `size_t`? I'm good with moving this change of the parameter types to a different issue, but as mentioned, since we are already changing stuff around here... > > I'd prefer to handle that as a separate issue, since such a change would propagate into `os::has_allocatable_memory_limit()` and affect all os:es. okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/1696 From tschatzl at openjdk.java.net Wed Dec 9 12:12:38 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 9 Dec 2020 12:12:38 GMT Subject: RFR: 8257912: Convert enum iteration to use range-based for loops In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 01:34:16 GMT, Ioi Lam wrote: > * For JDK 17* > > Now that [range-based for loops](https://github.com/openjdk/jdk/pull/1488) are allowed by the [HotSpot Style Guide](https://github.com/openjdk/jdk/blob/52ab72127ddc3ca6575d9d58503ec39c5dff7ab1/doc/hotspot-style.md), I have converted the more verbose syntax: > > for (vmIntrinsicsIterator it = vmIntrinsicsRange.begin(); it != vmIntrinsicsRange.end(); ++it) { > vmIntrinsicID index = *it; > nt[as_int(index)] = string; > } > > to > > for (vmIntrinsicID index : EnumRange{}) { > nt[as_int(index)] = string; > } > > I also removed the "convenient" declarations such as `vmIntrinsicsRange` and `vmIntrinsicsIterator` -- these are useful only when writing a traditional for loop, and are probably confusing to everyone else. I've left examples in enumIterator.hpp in case anyone wants to write a traditional for loop. > > I also added gtest cases for using range-based for loops with `EnumRange<>`. Lgtm ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1707 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 chagedorn at openjdk.java.net Wed Dec 9 14:35:41 2020 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Wed, 9 Dec 2020 14:35:41 GMT Subject: RFR: 8245107: Use Unified Logging in trace_method_handle_stub() In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 09:10:12 GMT, Christian Hagedorn wrote: >> Thanks Martin for your review and the verification on PPC64 and s390! > > Could anybody also quickly verify that the changes in `methodHandles_arm.cpp` build and are correct? Nevermind, I could verify that it builds correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/1665 From chagedorn at openjdk.java.net Wed Dec 9 14:39:36 2020 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Wed, 9 Dec 2020 14:39:36 GMT Subject: Integrated: 8245107: Use Unified Logging in trace_method_handle_stub() In-Reply-To: References: Message-ID: On Mon, 7 Dec 2020 12:39:34 GMT, Christian Hagedorn wrote: > This changes the logging of method handles from specifying Verbose to using unified logging with level Trace. > > I only tested it on x86. Could anybody verify that it also works on ARM, S390 and PPC? > > Thanks, > Christian This pull request has now been integrated. Changeset: f148915d Author: Christian Hagedorn URL: https://git.openjdk.java.net/jdk/commit/f148915d Stats: 73 lines in 6 files changed: 16 ins; 3 del; 54 mod 8245107: Use Unified Logging in trace_method_handle_stub() Reviewed-by: coleenp, mdoerr ------------- PR: https://git.openjdk.java.net/jdk/pull/1665 From doko at ubuntu.com Wed Dec 9 15:19:26 2020 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 9 Dec 2020 16:19:26 +0100 Subject: [patch] link libjvm with -latomic Message-ID: <90671a28-0464-37e7-fc3d-1372a1bf8a77@ubuntu.com> seen with 16+27, zero needs to be linked with -latomic for a few more architectures. Instead of hard-coding these architectures, would it be possible to link with -latomic unconditionally? It's the last library on the link command, so linking with -Wl,--as-needed -latomic should be do no harm. Even better link with -Wl,--push-state,--as-needed -latomic -Wl,--pop-state --push-state/--pop-state are implemented in binutils 2.28, released in 2017. It also looks like zero also build on ARM32 again. Matthias --- a/make/autoconf/libraries.m4 +++ b/make/autoconf/libraries.m4 @@ -127,9 +127,13 @@ AC_DEFUN_ONCE([LIB_SETUP_LIBRARIES], # Libatomic library # 32-bit MIPS needs fallback library for 8-byte atomic ops if test "x$OPENJDK_TARGET_OS" = xlinux && - (test "x$OPENJDK_TARGET_CPU" = xmips || - test "x$OPENJDK_TARGET_CPU" = xmipsel); then - BASIC_JVM_LIBS="$BASIC_JVM_LIBS -latomic" + (test "x$OPENJDK_TARGET_CPU" = xarm || + test "x$OPENJDK_TARGET_CPU" = xm68k || + test "x$OPENJDK_TARGET_CPU" = xmips || + test "x$OPENJDK_TARGET_CPU" = xmipsel || + test "x$OPENJDK_TARGET_CPU" = xppc || + test "x$OPENJDK_TARGET_CPU" = xsh); then + BASIC_JVM_LIBS="$BASIC_JVM_LIBS -Wl,--push-state,--as-needed -latomic -Wl,--pop-state" fi # perfstat lib From github.com+168222+mgkwill at openjdk.java.net Wed Dec 9 15:30:45 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 9 Dec 2020 15:30:45 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v13] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge branch 'master' into update_hlp - Merge branch 'master' into update_hlp - Fix os::large_page_size() in last update Signed-off-by: Marcus G K Williams - Ivan W. Requested Changes Removed os::Linux::select_large_page_size and use os::page_size_for_region instead Removed Linux::find_large_page_size and use register_large_page_sizes. Streamlined Linux::setup_large_page_size Signed-off-by: Marcus G K Williams - Fix space format, use Linux:: for local func. Signed-off-by: Marcus G K Williams - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp - Fix merge mistakes Signed-off-by: Marcus G K Williams - Add newline at end of TestLargePageUseForAuxMemory.java Signed-off-by: Marcus G K Williams - Fix merge mistakes Signed-off-by: Marcus G K Williams - Thomas S. Feedback Signed-off-by: Marcus G K Williams - ... and 9 more: https://git.openjdk.java.net/jdk/compare/6eff9315...8f1474a9 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=12 Stats: 63 lines in 2 files changed: 24 ins; 11 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From redestad at openjdk.java.net Wed Dec 9 17:00:02 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Dec 2020 17:00:02 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v7] In-Reply-To: References: Message-ID: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Claes Redestad 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 21 additional commits since the last revision: - Merge branch 'master' into log2_template - Renaming, adress review comments - x->value - Rename log2i ilogi and make it only accept value > 0, rename log2i_allow_zero log2i_graceful, accepting any value - Rename exact_log2i exact_ilog2, make it stricter - Merge branch 'master' into log2_template - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template - Ensure proper promotion from signed to unsigned for 32-bit signed values - Clean up exact_log2 comments - Invalid use of uintptr_t, use uint64_t to handle 64-bit integers properly on 32-bit - ... and 11 more: https://git.openjdk.java.net/jdk/compare/c1e99e92...8a794840 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1663/files - new: https://git.openjdk.java.net/jdk/pull/1663/files/2abbb412..8a794840 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=05-06 Stats: 5451 lines in 291 files changed: 3206 ins; 1272 del; 973 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 From redestad at openjdk.java.net Wed Dec 9 17:02:37 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Dec 2020 17:02:37 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v6] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 10:46:55 GMT, Kim Barrett wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> x->value > > src/hotspot/cpu/x86/vm_version_x86.cpp line 784: > >> 782: cpu_family(), _model, _stepping, os::cpu_microcode_revision()); >> 783: assert(res > 0, "not enough temporary space allocated"); >> 784: assert(exact_ilog2((uint64_t)CPU_MAX_FEATURE) + 1 == sizeof(_features_names) / sizeof(char*), "wrong size features_names"); > > Cast of CPU_MAX_FEATURE isn't needed. That's what I thought too, but GCC doesn't agree. It seems not even typed enums can be properly mapped to a template function. Apart from this I think I've adressed all review comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From redestad at openjdk.java.net Wed Dec 9 18:26:10 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Dec 2020 18:26:10 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v8] In-Reply-To: References: Message-ID: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Issue with using count_trailing_zeros with 64-bit values on 32-bit, revert and add TODO ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1663/files - new: https://git.openjdk.java.net/jdk/pull/1663/files/8a794840..e2332fb1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=06-07 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 From redestad at openjdk.java.net Wed Dec 9 18:26:11 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Dec 2020 18:26:11 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v6] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 10:19:30 GMT, Kim Barrett wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> x->value > > src/hotspot/share/utilities/powerOfTwo.hpp line 78: > >> 76: "x must be a power of 2: " UINT64_FORMAT, >> 77: (uint64_t)static_cast::type>(value)); >> 78: return ilog2(value); > > `count_trailing_zeros(value);` is more direct. This broke down on 32-bit JVMs. Reason is that `count_trailing_zeros` takes a `uintx`, so the 64-bit argument in vm_version_x86.cpp will be downcast to 32-bit and end up as zero. I reverted the changes, filed https://bugs.openjdk.java.net/browse/JDK-8257985 and added a TODO to log2i_exact ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From github.com+168222+mgkwill at openjdk.java.net Wed Dec 9 18:26:52 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 9 Dec 2020 18:26:52 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> Message-ID: <8OpPXlmtLpE7eD_0jDasbPemR7jGj6Iqh1agfClYfrQ=.72ad0ff0-7cf1-4e2b-a798-1bda355b4de9@github.com> On Mon, 7 Dec 2020 08:52:28 GMT, Thomas Stuefe wrote: >> Hi, >> >> may I please have reviews for the following very small improvement: >> >> While discussing JDK-8243315 [1], and aiming to make planned changes like JDK-8256155 [2] easier: >> >> size_t os::_page_sizes[os::page_sizes_max]; >> >> is an array used to keep all page sizes the hotspot can use. It is sorted by size and filled in at initialization time. >> >> Coding dealing with this can be simplified by making this a set (which is very easy since all page sizes are power-2-values so they lend themselves nicely to a bitmap). >> >> That has the following advantages: >> - makes adding new sizes simple since we do not have to re-sort the array. Coding is easier to read too. >> - it makes it possible to encode a set of page sizes in one number, so we can hand a set-of-page-sizes around as a value. >> >> ----- >> >> The patch adds a new class, os::PagesizeSet, which is a bitmap containing page sizes. It adds gtests for this class. It replaces the old os::_page_sizes with an object of that class. It also removes an unused function. >> >> >> Testing: >> - nightlies at SAP >> - manual tests with UseLargePages >> - the new gtests >> - gh actions (with x86 still failing because of unrelated issues) >> >> Thank you, >> >> Thomas >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8243315 >> [2] https://bugs.openjdk.java.net/browse/JDK-8256155 > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Add missing include (ppc,s390 builds failed) test/hotspot/gtest/runtime/test_os.cpp line 104: > 102: const size_t expected = os::page_sizes().next_smaller(s); > 103: if (expected != 0) { > 104: size_t actual = os::page_size_for_region_unaligned(expected - 17, 1); @tstuefe should **expected** here be **s** ? It seems like we are trying to compare the next smaller page size of S, with a slightly smaller size of the size S. `os::page_size_for_region_unaligned(expected - 17, 1);` vs. `os::page_size_for_region_unaligned(s - 17, 1);` Running these tests with 2 largepage sizes (3 total sizes) fails, however default of 2 page_sizes passes (4k and 2m or 1g): (./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk -Xms2G -Xmx2G -XX:+UseLargePages -XX:LargePageSizeInBytes=2M) > [----------] 17 tests from os [ RUN ] os.page_size_for_region_vm [ OK ] os.page_size_for_region_vm (0 ms) [ RUN ] os.page_size_for_region_aligned_vm [ OK ] os.page_size_for_region_aligned_vm (0 ms) [ RUN ] os.page_size_for_region_alignment_vm [ OK ] os.page_size_for_region_alignment_vm (0 ms) [ RUN ] os.page_size_for_region_unaligned_vm test/hotspot/gtest/runtime/test_os.cpp:106: Failure Expected equality of these values: a ctual Which is: 4096 expected Which is: 2097152 [ FAILED ] os.page_size_for_region_unaligned_vm (0 ms) This only happen when https://github.com/openjdk/jdk/pull/1153 is present in code, because otherwise you will only have two page_sizes, but still this should return the correct results. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From github.com+168222+mgkwill at openjdk.java.net Wed Dec 9 18:30:38 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 9 Dec 2020 18:30:38 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: <8OpPXlmtLpE7eD_0jDasbPemR7jGj6Iqh1agfClYfrQ=.72ad0ff0-7cf1-4e2b-a798-1bda355b4de9@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8OpPXlmtLpE7eD_0jDasbPemR7jGj6Iqh1agfClYfrQ=.72ad0ff0-7cf1-4e2b-a798-1bda355b4de9@github.com> Message-ID: <1QfsqW7YOmn-TeWge_8nrxpYtjB-Vl-qqb_r3eyTQ9o=.892d8845-6aef-4c11-853c-b9d4709a1d29@github.com> On Wed, 9 Dec 2020 17:26:43 GMT, Marcus G K Williams wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Add missing include (ppc,s390 builds failed) > > test/hotspot/gtest/runtime/test_os.cpp line 104: > >> 102: const size_t expected = os::page_sizes().next_smaller(s); >> 103: if (expected != 0) { >> 104: size_t actual = os::page_size_for_region_unaligned(expected - 17, 1); > > @tstuefe should **expected** here be **s** ? > > It seems like we are trying to compare the next smaller page size of S, with a slightly smaller size of the size S. > > `os::page_size_for_region_unaligned(expected - 17, 1);` > vs. > `os::page_size_for_region_unaligned(s - 17, 1);` > > Running these tests with 2 largepage sizes (3 total sizes) fails, however default of 2 page_sizes passes (4k and 2m or 1g): > (./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk -Xms2G -Xmx2G -XX:+UseLargePages -XX:LargePageSizeInBytes=2M) >> [----------] 17 tests from os [ RUN ] os.page_size_for_region_vm [ OK ] os.page_size_for_region_vm (0 ms) [ RUN ] os.page_size_for_region_aligned_vm [ OK ] os.page_size_for_region_aligned_vm (0 ms) [ RUN ] os.page_size_for_region_alignment_vm [ OK ] os.page_size_for_region_alignment_vm (0 ms) [ RUN ] os.page_size_for_region_unaligned_vm test/hotspot/gtest/runtime/test_os.cpp:106: Failure Expected equality of these values: actual Which is: 4096 expected Which is: 2097152 [ FAILED ] os.page_size_for_region_unaligned_vm (0 ms) > > This only happen when https://github.com/openjdk/jdk/pull/1153 is present in code, because otherwise you will only have two page_sizes, but still this should return the correct results. See https://github.com/openjdk/jdk/pull/1719 for fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From kvn at openjdk.java.net Wed Dec 9 18:33:38 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 9 Dec 2020 18:33:38 GMT Subject: RFR: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. In-Reply-To: <-dC7EkSsxPpLvZE5I5ds2CAw1QJfDGNIAxLec7s8o2w=.d8c74ba5-45c4-4041-8674-6edad6dc49a6@github.com> References: <-dC7EkSsxPpLvZE5I5ds2CAw1QJfDGNIAxLec7s8o2w=.d8c74ba5-45c4-4041-8674-6edad6dc49a6@github.com> Message-ID: On Wed, 9 Dec 2020 10:03:48 GMT, Yudi Zheng wrote: > Update exception_seen flag in the MDO when no exception handler is found for caller during deoptimization, or when exception is thrown in the runtime. > > Plus, `-Xlog:exceptions=info` code and `AbortVMOnException` are adjusted in C1 runtime and jvmci runtime to be consistent with C2, i.e., before `JvmtiExport::can_post_on_exceptions` deoptimization and fast continuation when compiled handler is found. Changes requested by kvn (Reviewer). src/hotspot/share/runtime/sharedRuntime.cpp line 604: > 602: > 603: #if INCLUDE_JVMCI > 604: if (EnableJVMCI) { I think this should also check `&& UseJVMCICompiler` ------------- PR: https://git.openjdk.java.net/jdk/pull/1713 From stuefe at openjdk.java.net Wed Dec 9 18:46:38 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 9 Dec 2020 18:46:38 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: <1QfsqW7YOmn-TeWge_8nrxpYtjB-Vl-qqb_r3eyTQ9o=.892d8845-6aef-4c11-853c-b9d4709a1d29@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8OpPXlmtLpE7eD_0jDasbPemR7jGj6Iqh1agfClYfrQ=.72ad0ff0-7cf1-4e2b-a798-1bda355b4de9@github.com> <1QfsqW7YOmn-TeWge_8nrxpYtjB-Vl-qqb_r3eyTQ9o=.892d8845-6aef-4c11-853c-b9d4709a1d29@github.com> Message-ID: On Wed, 9 Dec 2020 18:27:30 GMT, Marcus G K Williams wrote: >> test/hotspot/gtest/runtime/test_os.cpp line 104: >> >>> 102: const size_t expected = os::page_sizes().next_smaller(s); >>> 103: if (expected != 0) { >>> 104: size_t actual = os::page_size_for_region_unaligned(expected - 17, 1); >> >> @tstuefe should **expected** here be **s** ? >> >> It seems like we are trying to compare the next smaller page size of S, with a slightly smaller size of the size S. >> >> `os::page_size_for_region_unaligned(expected - 17, 1);` >> vs. >> `os::page_size_for_region_unaligned(s - 17, 1);` >> >> Running these tests with 2 largepage sizes (3 total sizes) fails, however default of 2 page_sizes passes (4k and 2m or 1g): >> (./hotspot/variant-server/libjvm/gtest/gtestLauncher -jdk:./images/jdk -Xms2G -Xmx2G -XX:+UseLargePages -XX:LargePageSizeInBytes=2M) >>> [----------] 17 tests from os [ RUN ] os.page_size_for_region_vm [ OK ] os.page_size_for_region_vm (0 ms) [ RUN ] os.page_size_for_region_aligned_vm [ OK ] os.page_size_for_region_aligned_vm (0 ms) [ RUN ] os.page_size_for_region_alignment_vm [ OK ] os.page_size_for_region_alignment_vm (0 ms) [ RUN ] os.page_size_for_region_unaligned_vm test/hotspot/gtest/runtime/test_os.cpp:106: Failure Expected equality of these values: actual Which is: 4096 expected Which is: 2097152 [ FAILED ] os.page_size_for_region_unaligned_vm (0 ms) >> >> This only happen when https://github.com/openjdk/jdk/pull/1153 is present in code, because otherwise you will only have two page_sizes, but still this should return the correct results. > > See https://github.com/openjdk/jdk/pull/1719 for fix. Yes, you are right, it should. I filed JDK-8257989. Feel free to fix it. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From stuefe at openjdk.java.net Wed Dec 9 18:46:39 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 9 Dec 2020 18:46:39 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8OpPXlmtLpE7eD_0jDasbPemR7jGj6Iqh1agfClYfrQ=.72ad0ff0-7cf1-4e2b-a798-1bda355b4de9@github.com> <1QfsqW7YOmn-TeWge_8nrxpYtjB-Vl-qqb_r3eyTQ9o=.892d8845-6aef-4c11-853c-b9d4709a1d29@github.com> Message-ID: <6qOMaxrRyvxlOW37nOSVHuPguOFaBssjdtcKb5d0x5g=.584eb3cd-a55a-4c1d-92ec-5f65f1b000f4@github.com> On Wed, 9 Dec 2020 18:39:15 GMT, Thomas Stuefe wrote: >> See https://github.com/openjdk/jdk/pull/1719 for fix. > > Yes, you are right, it should. I filed JDK-8257989. Feel free to fix it. > > Thanks, Thomas Oh, I see you already have a PR open, I reply there. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 From github.com+168222+mgkwill at openjdk.java.net Wed Dec 9 18:46:40 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 9 Dec 2020 18:46:40 GMT Subject: RFR: JDK-8257588: Make os::_page_sizes a bitmask [v6] In-Reply-To: <6qOMaxrRyvxlOW37nOSVHuPguOFaBssjdtcKb5d0x5g=.584eb3cd-a55a-4c1d-92ec-5f65f1b000f4@github.com> References: <62Vj_m83-rieumOMxc8MfQGb9cmTXy3KDH_hXS8G_7s=.8f3574dc-245c-4883-acce-5d3637e8181e@github.com> <8OpPXlmtLpE7eD_0jDasbPemR7jGj6Iqh1agfClYfrQ=.72ad0ff0-7cf1-4e2b-a798-1bda355b4de9@github.com> <1QfsqW7YOmn-TeWge_8nrxpYtjB-Vl-qqb_r3eyTQ9o=.892d8845-6aef-4c11-853c-b9d4709a1d29@github.com> <6qOMaxrRyvxlOW37nOSVHuPguOFaBssjdtcKb5d0x5g=.584eb3cd-a55a-4c1d-92ec-5f65f1b000f4@github.com> Message-ID: On Wed, 9 Dec 2020 18:41:32 GMT, Thomas Stuefe wrote: >> Yes, you are right, it should. I filed JDK-8257989. Feel free to fix it. >> >> Thanks, Thomas > > Oh, I see you already have a PR open, I reply there. Fixed in #1719. Thanks Thomas. ------------- PR: https://git.openjdk.java.net/jdk/pull/1522 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 stefank at openjdk.java.net Wed Dec 9 19:30:42 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 9 Dec 2020 19:30:42 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v8] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 18:26:10 GMT, Claes Redestad wrote: >> This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp >> >> Naming is hard, but I think the following scheme is reasonable: >> >> - log2i: any integral type. 0-hostile >> - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) >> - exact_log2i: any integral type. value must be a power of two >> >> I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. >> >> Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. >> >> To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: >> >> [ RUN ] power_of_2.log2_long_micro >> [ OK ] power_of_2.log2_long_micro (3581 ms) >> [ RUN ] power_of_2.log2_long_small_micro >> [ OK ] power_of_2.log2_long_small_micro (549 ms) >> [ RUN ] power_of_2.log2i_micro >> [ OK ] power_of_2.log2i_micro (259 ms) >> [ RUN ] power_of_2.log2i_small_micro >> [ OK ] power_of_2.log2i_small_micro (113 ms) >> >> I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W >> >> (Intending this for 17) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Issue with using count_trailing_zeros with 64-bit values on 32-bit, revert and add TODO I'm fine with the change as is. I have a few comments that you might want to consider. src/hotspot/share/utilities/powerOfTwo.hpp line 79: > 77: (uint64_t)static_cast::type>(value)); > 78: // TODO: this could be "return count_trailing_zeros(value)"", but that fails on > 79: // 32-bit builds since that takes uintx and is thus lossy for 64-bit values. I don't think we need to leave this bread crumbs in the code. If there's really something we want "to do", then we should create an RFE for it instead. src/hotspot/share/gc/z/zHeuristics.cpp line 48: > 46: // Enable medium pages > 47: ZPageSizeMedium = size; > 48: ZPageSizeMediumShift = log2i(ZPageSizeMedium); I think you missed the comment that this could be log2i_exact. src/hotspot/cpu/x86/vm_version_x86.cpp line 784: > 782: cpu_family(), _model, _stepping, os::cpu_microcode_revision()); > 783: assert(res > 0, "not enough temporary space allocated"); > 784: assert(log2i_exact((uint64_t)CPU_MAX_FEATURE) + 1 == sizeof(_features_names) / sizeof(char*), "wrong size features_names"); If you want to get rid of this cast (and the one added to interp_masm_x86.cpp, you could register your log2i functions to accept enums: -template ::value)> +template ::value || std::is_enum::value)> test/hotspot/gtest/utilities/test_powerOfTwo.cpp line 276: > 274: } > 275: { > 276: /* Test log2i_graceful handles 0 input */ Could convert /* */ to // ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1663 From gziemski at openjdk.java.net Wed Dec 9 19:47:32 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 9 Dec 2020 19:47:32 GMT Subject: RFR: 8257912: Convert enum iteration to use range-based for loops In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 01:34:16 GMT, Ioi Lam wrote: > * For JDK 17* > > Now that [range-based for loops](https://github.com/openjdk/jdk/pull/1488) are allowed by the [HotSpot Style Guide](https://github.com/openjdk/jdk/blob/52ab72127ddc3ca6575d9d58503ec39c5dff7ab1/doc/hotspot-style.md), I have converted the more verbose syntax: > > for (vmIntrinsicsIterator it = vmIntrinsicsRange.begin(); it != vmIntrinsicsRange.end(); ++it) { > vmIntrinsicID index = *it; > nt[as_int(index)] = string; > } > > to > > for (vmIntrinsicID index : EnumRange{}) { > nt[as_int(index)] = string; > } > > I also removed the "convenient" declarations such as `vmIntrinsicsRange` and `vmIntrinsicsIterator` -- these are useful only when writing a traditional for loop, and are probably confusing to everyone else. I've left examples in enumIterator.hpp in case anyone wants to write a traditional for loop. > > I also added gtest cases for using range-based for loops with `EnumRange<>`. Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1707 From gziemski at openjdk.java.net Wed Dec 9 19:47:32 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Wed, 9 Dec 2020 19:47:32 GMT Subject: RFR: 8257912: Convert enum iteration to use range-based for loops In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 12:09:41 GMT, Thomas Schatzl wrote: >> * For JDK 17* >> >> Now that [range-based for loops](https://github.com/openjdk/jdk/pull/1488) are allowed by the [HotSpot Style Guide](https://github.com/openjdk/jdk/blob/52ab72127ddc3ca6575d9d58503ec39c5dff7ab1/doc/hotspot-style.md), I have converted the more verbose syntax: >> >> for (vmIntrinsicsIterator it = vmIntrinsicsRange.begin(); it != vmIntrinsicsRange.end(); ++it) { >> vmIntrinsicID index = *it; >> nt[as_int(index)] = string; >> } >> >> to >> >> for (vmIntrinsicID index : EnumRange{}) { >> nt[as_int(index)] = string; >> } >> >> I also removed the "convenient" declarations such as `vmIntrinsicsRange` and `vmIntrinsicsIterator` -- these are useful only when writing a traditional for loop, and are probably confusing to everyone else. I've left examples in enumIterator.hpp in case anyone wants to write a traditional for loop. >> >> I also added gtest cases for using range-based for loops with `EnumRange<>`. > > Lgtm I like the change very much. Did you consider leaving the convenience symbol "vmSymbolsIterator" as is and then using it in the loop, so instead of: `for (vmSymbolID index : EnumRange{}) {` we would have: `for (vmSymbolID index : vmSymbolsIterator) {` which would be more concise (but less self-documenting I guess) and more similar to: `for (JVMFlagOrigin origin : range) {` ------------- PR: https://git.openjdk.java.net/jdk/pull/1707 From coleenp at openjdk.java.net Wed Dec 9 21:52:51 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 9 Dec 2020 21:52:51 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT Message-ID: Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. Tested with tier1-3 with product and fastdebug builds. Built with optimized. This is for JDK 17. ------------- Commit messages: - make crash test options develop options - 8252148: vmError::controlled_crash should be #ifdef ASSERT Changes: https://git.openjdk.java.net/jdk/pull/1723/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1723&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252148 Stats: 331 lines in 12 files changed: 141 ins; 165 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/1723.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1723/head:pull/1723 PR: https://git.openjdk.java.net/jdk/pull/1723 From iklam at openjdk.java.net Wed Dec 9 22:06:35 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Dec 2020 22:06:35 GMT Subject: RFR: 8257912: Convert enum iteration to use range-based for loops In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 19:45:12 GMT, Gerard Ziemski wrote: >> * For JDK 17* >> >> Now that [range-based for loops](https://github.com/openjdk/jdk/pull/1488) are allowed by the [HotSpot Style Guide](https://github.com/openjdk/jdk/blob/52ab72127ddc3ca6575d9d58503ec39c5dff7ab1/doc/hotspot-style.md), I have converted the more verbose syntax: >> >> for (vmIntrinsicsIterator it = vmIntrinsicsRange.begin(); it != vmIntrinsicsRange.end(); ++it) { >> vmIntrinsicID index = *it; >> nt[as_int(index)] = string; >> } >> >> to >> >> for (vmIntrinsicID index : EnumRange{}) { >> nt[as_int(index)] = string; >> } >> >> I also removed the "convenient" declarations such as `vmIntrinsicsRange` and `vmIntrinsicsIterator` -- these are useful only when writing a traditional for loop, and are probably confusing to everyone else. I've left examples in enumIterator.hpp in case anyone wants to write a traditional for loop. >> >> I also added gtest cases for using range-based for loops with `EnumRange<>`. > > Marked as reviewed by gziemski (Committer). > I like the change very much. > > Did you consider leaving the convenience symbol "vmSymbolsIterator" as is and then using it in the loop, so instead of: > > `for (vmSymbolID index : EnumRange{}) {` > > we would have: > > `for (vmSymbolID index : vmSymbolsIterator) {` > > which would be more concise (but less self-documenting I guess) and more similar to: > > `for (JVMFlagOrigin origin : range) {` Hi Gerard, thanks for the review. `vmSymbolsIterator` is the "cursor" type. I think you meant this: for (vmSymbolID index : vmSymbolsRange{}) {...} which is probably less readable, because you have to find out what `vmSymbolsRange` actually is. I think the following pattern is easier to read. It will also make the iteration of different enum types more consistent. Iteration of any enum type *E* can be done the same way with EnumRange<*E*>. You don't need to invent a new *E*Range type. for (MyEnumType e : EnumRange{}) {...}` Note that the `{}` is required here because we need to construct an instance of `EnumRange` with its no-arg constructor. You can also use `()` but I think that would be less readable -- it's not clear whether you are calling a function or constructing an object. With `{}`, it's clear that we are making an [initialization](https://en.cppreference.com/w/cpp/language/initialization) with the brace operator. You can also initialize a non-default range with `EnumRange{start, end}`, etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/1707 From mdoerr at openjdk.java.net Wed Dec 9 22:07:35 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 9 Dec 2020 22:07:35 GMT Subject: RFR: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack [v2] In-Reply-To: <1fZj0MQrD0HSC1OGd11d4i6I9l3aZFnelGveurPDyr8=.785e9701-d64a-4b2d-a7d1-8c5033b63dee@github.com> References: <1fZj0MQrD0HSC1OGd11d4i6I9l3aZFnelGveurPDyr8=.785e9701-d64a-4b2d-a7d1-8c5033b63dee@github.com> Message-ID: On Mon, 30 Nov 2020 11:06:19 GMT, Martin Doerr wrote: >> Thanks for the review! >> Unfortunatly, it's still not fully tested because PPC build is currently broken. I'll check again later. > > Tests have passed in the meantime. This solution still breaks NMT stack traces which require special os::current_frame(). ------------- PR: https://git.openjdk.java.net/jdk/pull/1394 From mdoerr at openjdk.java.net Wed Dec 9 22:07:37 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 9 Dec 2020 22:07:37 GMT Subject: Withdrawn: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 16:57:55 GMT, Martin Doerr wrote: > Method handle logging is broken in fastdebug builds. Problem is that os::current_frame() doesn't return the right frame in fastdebug builds. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1394 From redestad at openjdk.java.net Wed Dec 9 22:24:09 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Dec 2020 22:24:09 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v9] In-Reply-To: References: Message-ID: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Claes Redestad 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 24 additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template - More review comments adressed - Issue with using count_trailing_zeros with 64-bit values on 32-bit, revert and add TODO - Merge branch 'master' into log2_template - Renaming, adress review comments - x->value - Rename log2i ilogi and make it only accept value > 0, rename log2i_allow_zero log2i_graceful, accepting any value - Rename exact_log2i exact_ilog2, make it stricter - Merge branch 'master' into log2_template - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template - ... and 14 more: https://git.openjdk.java.net/jdk/compare/bbda576f...511a8f67 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1663/files - new: https://git.openjdk.java.net/jdk/pull/1663/files/e2332fb1..511a8f67 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=07-08 Stats: 399 lines in 26 files changed: 252 ins; 70 del; 77 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 From redestad at openjdk.java.net Wed Dec 9 22:27:36 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Dec 2020 22:27:36 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v8] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 19:26:47 GMT, Stefan Karlsson wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Issue with using count_trailing_zeros with 64-bit values on 32-bit, revert and add TODO > > src/hotspot/cpu/x86/vm_version_x86.cpp line 784: > >> 782: cpu_family(), _model, _stepping, os::cpu_microcode_revision()); >> 783: assert(res > 0, "not enough temporary space allocated"); >> 784: assert(log2i_exact((uint64_t)CPU_MAX_FEATURE) + 1 == sizeof(_features_names) / sizeof(char*), "wrong size features_names"); > > If you want to get rid of this cast (and the one added to interp_masm_x86.cpp, you could register your log2i functions to accept enums: > -template ::value)> > +template ::value || std::is_enum::value)> Good, but feels the extra conditions in the template function is hurting readability more than the single cast - and we should probably apply this more consistently if we go down this route. Mind if I leave this for a follow-up? I've adressed your other review comments. Thanks for being thorough! ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From yzheng at openjdk.java.net Wed Dec 9 23:06:47 2020 From: yzheng at openjdk.java.net (Yudi Zheng) Date: Wed, 9 Dec 2020 23:06:47 GMT Subject: RFR: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. [v2] In-Reply-To: <-dC7EkSsxPpLvZE5I5ds2CAw1QJfDGNIAxLec7s8o2w=.d8c74ba5-45c4-4041-8674-6edad6dc49a6@github.com> References: <-dC7EkSsxPpLvZE5I5ds2CAw1QJfDGNIAxLec7s8o2w=.d8c74ba5-45c4-4041-8674-6edad6dc49a6@github.com> Message-ID: > Update exception_seen flag in the MDO when no exception handler is found for caller during deoptimization, or when exception is thrown in the runtime. > > Plus, `-Xlog:exceptions=info` code and `AbortVMOnException` are adjusted in C1 runtime and jvmci runtime to be consistent with C2, i.e., before `JvmtiExport::can_post_on_exceptions` deoptimization and fast continuation when compiled handler is found. Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision: Address comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1713/files - new: https://git.openjdk.java.net/jdk/pull/1713/files/011462c4..bb4a3ff0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1713&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1713&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1713.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1713/head:pull/1713 PR: https://git.openjdk.java.net/jdk/pull/1713 From kvn at openjdk.java.net Thu Dec 10 00:15:37 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 10 Dec 2020 00:15:37 GMT Subject: RFR: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. [v2] In-Reply-To: References: <-dC7EkSsxPpLvZE5I5ds2CAw1QJfDGNIAxLec7s8o2w=.d8c74ba5-45c4-4041-8674-6edad6dc49a6@github.com> Message-ID: <0NTetrUQx05C-LAAtBlmqIpBpCpe52JbuPo8DI5_-iM=.63bf4393-1a1c-4a44-a0ed-ccf2fe2e24f0@github.com> On Wed, 9 Dec 2020 23:06:47 GMT, Yudi Zheng wrote: >> Update exception_seen flag in the MDO when no exception handler is found for caller during deoptimization, or when exception is thrown in the runtime. >> >> Plus, `-Xlog:exceptions=info` code and `AbortVMOnException` are adjusted in C1 runtime and jvmci runtime to be consistent with C2, i.e., before `JvmtiExport::can_post_on_exceptions` deoptimization and fast continuation when compiled handler is found. > > Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Address comments. Changes requested by kvn (Reviewer). src/hotspot/share/jvmci/jvmciRuntime.cpp line 282: > 280: } > 281: // for AbortVMOnException flag > 282: NOT_PRODUCT(Exceptions::debug_check_abort(exception)); All other places calls debug_check_abort() in product too. It seems 8136577 changes missed JVMCI: https://github.com/openjdk/jdk/commit/a25ce80e782a73390ae1109250dfa6fe6a48fcbe Please, update to call it in product for JVMCI too. Note, AbortVMOnException is diagnostic flag now. src/hotspot/share/c1/c1_Runtime1.cpp line 547: > 545: stringStream tempst; > 546: assert(nm->method() != NULL, "Unexpected NULL method()"); > 547: tempst.print("compiled method <%s>\n" Can you change message to?: "C1 compiled method <%s>\n" src/hotspot/share/jvmci/jvmciRuntime.cpp line 276: > 274: stringStream tempst; > 275: assert(cm->method() != NULL, "Unexpected null method()"); > 276: tempst.print("compiled method <%s>\n" Can you change message to?: "JVMCI compiled method <%s>\n" ------------- PR: https://git.openjdk.java.net/jdk/pull/1713 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 iklam at openjdk.java.net Thu Dec 10 07:37:42 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Dec 2020 07:37:42 GMT Subject: RFR: 8258018: Remove arrayOop.inline.hpp Message-ID: Please review this trivial change. arrayOop.inline.hpp is not needed and its contents can be safely moved into arrayOop.hpp. Testing with mach5 tier1,builds-tier2,builds-tier3,builds-tier4,builds-tier5 ------------- Commit messages: - 8258018: Remove arrayOop.inline.hpp Changes: https://git.openjdk.java.net/jdk/pull/1728/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1728&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258018 Stats: 49 lines in 10 files changed: 3 ins; 36 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/1728.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1728/head:pull/1728 PR: https://git.openjdk.java.net/jdk/pull/1728 From thartmann at openjdk.java.net Thu Dec 10 07:47:40 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 10 Dec 2020 07:47:40 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v4] In-Reply-To: References: Message-ID: On Tue, 8 Dec 2020 18:19:24 GMT, Jatin Bhateja wrote: >> A newly allocated memory is initialized either using user provided initialization values for various fields or setting the memory to zero as per java semantics (System initialization). >> >> C2 compiler creates ClearArray Node in order to perform system initialization. ClearArray accepts the number of Heap Words to be initialized, this number can be constant or a non-constant value. For constant number of heap words less than InitArrayShortSize (default value 64 bytes) currently compiler generates StoreL nodes which does the initialization at the granularity of 8 bytes. >> >> This patch vectorizes the initializing store operations for constant sized heap word less than InitArrayShortSize by emitting special instruction sequence for various tail sizes. >> >> In addition existing implementation for initialization under UseXMMForObjInit is extended to use masked operation to optimize tail initialization sequence. In case AVX3Threshold is set to 0 then new initialization sequence uses 64 byte ZMM registers. >> >> Following are the performance stats collected using micro-benchmark included with the patch. >> >> Testing : Tier1-Tier3 level tests are clean. >> >> System Configuration : Cascadelake, Intel Xeon Platinum 8280L @ 2.7 GHz, 2 socket, 28 cores per socket. >> >> ### Baseline: >> Benchmark Mode Cnt Score Error Units >> ClearMemory.testClearMemory16K thrpt 2 1427741.069 ops/s >> ClearMemory.testClearMemory1K thrpt 2 47628368.596 ops/s >> ClearMemory.testClearMemory1M thrpt 2 27388.979 ops/s >> ClearMemory.testClearMemory24B thrpt 2 167681010.419 ops/s >> ClearMemory.testClearMemory2K thrpt 2 22043948.290 ops/s >> ClearMemory.testClearMemory32B thrpt 2 168599498.817 ops/s >> ClearMemory.testClearMemory32K thrpt 2 775985.067 ops/s >> ClearMemory.testClearMemory40B thrpt 2 153375273.800 ops/s >> ClearMemory.testClearMemory48B thrpt 2 145328531.804 ops/s >> ClearMemory.testClearMemory4K thrpt 2 6492257.452 ops/s >> ClearMemory.testClearMemory56B thrpt 2 122376321.652 ops/s >> ClearMemory.testClearMemory8K thrpt 2 2857444.413 ops/s >> ClearMemory.testClearMemory8M thrpt 2 3461.674 ops/s >> ### With Optimization: >> Benchmark Mode Cnt Score Error Units >> ClearMemory.testClearMemory16K thrpt 2 2529701.368 ops/s >> ClearMemory.testClearMemory1K thrpt 2 50276682.550 ops/s >> ClearMemory.testClearMemory1M thrpt 2 27458.588 ops/s >> ClearMemory.testClearMemory24B thrpt 2 178751174.642 ops/s >> ClearMemory.testClearMemory2K thrpt 2 22574802.694 ops/s >> ClearMemory.testClearMemory32B thrpt 2 176630844.950 ops/s >> ClearMemory.testClearMemory32K thrpt 2 1297627.181 ops/s >> ClearMemory.testClearMemory40B thrpt 2 167469550.653 ops/s >> ClearMemory.testClearMemory48B thrpt 2 159391163.006 ops/s >> ClearMemory.testClearMemory4K thrpt 2 9045158.643 ops/s >> ClearMemory.testClearMemory56B thrpt 2 134550172.421 ops/s >> ClearMemory.testClearMemory8K thrpt 2 4581450.664 ops/s >> ClearMemory.testClearMemory8M thrpt 2 3446.834 ops/s > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8257772: Changing the default value for UseXMMForObjInit and UseFastStosb flags. Performance numbers look good. No regression and some nice improvements (up to 13%) for some crypto microbenchmarks. Code looks reasonable to me but assembly snippets are hard to review. I've added some style comments. @shipilev who implemented [JDK-8146801](https://bugs.openjdk.java.net/browse/JDK-8146801) might also want to have a look. For stability, this should wait until JDK 17 repos are forked today. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4949: > 4947: BIND(L_loop); > 4948: if (MaxVectorSize >= 32) { > 4949: fill64_avx(base, 0, xtmp, use64byteVector); Extra whitespace after `base, ` test/micro/org/openjdk/bench/vm/compiler/ClearMemory.java line 45: > 43: public class ClearMemory { > 44: class Payload8 { > 45: public long f0; For Java code we use 4 whitespace indentation. src/hotspot/cpu/x86/x86_64.ad line 10860: > 10858: predicate(!((ClearArrayNode*)n)->is_large() && n->in(2)->bottom_type()->is_long()->is_con()); > 10859: match(Set dummy (ClearArray cnt base)); > 10860: effect(TEMP tmp,TEMP zero, KILL cr); -> `(TEMP tmp, TEMP zero, KILL cr);` src/hotspot/cpu/x86/x86_32.ad line 11553: > 11551: predicate(!((ClearArrayNode*)n)->is_large() && n->in(2)->bottom_type()->is_int()->is_con()); > 11552: match(Set dummy (ClearArray cnt base)); > 11553: effect(TEMP tmp,TEMP zero, KILL cr); -> `effect(TEMP tmp, TEMP zero, KILL cr);` src/hotspot/cpu/x86/macroAssembler_x86_arrayCopy_avx3.cpp line 251: > 249: } > 250: > 251: Remove extra newline. src/hotspot/cpu/x86/macroAssembler_x86.hpp line 1854: > 1852: bool use64byteVector = false); > 1853: > 1854: Remove extra newline. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 8184: > 8182: } > 8183: > 8184: One newline between methods is sufficient (same for at other places). src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5028: > 5026: } > 5027: break; > 5028: case 6: Please order case statements by increasing value. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4937: > 4935: // base - start address, qword aligned. > 4936: Label L_zero_64_bytes, L_loop, L_sloop, L_tail, L_end; > 4937: bool use64byteVector = MaxVectorSize == 64 && AVX3Threshold == 0; The comment for `AVX3Threshold` says: "Minimum array size in bytes to use AVX512 intrinsics" "for copy, inflate and fill. When this value is set as zero" "compare operations can also use AVX512 intrinsics.") Should we mention clear memory there as well? ------------- Changes requested by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1631 From stefank at openjdk.java.net Thu Dec 10 08:12:37 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 10 Dec 2020 08:12:37 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v8] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 19:27:58 GMT, Stefan Karlsson wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Issue with using count_trailing_zeros with 64-bit values on 32-bit, revert and add TODO > > I'm fine with the change as is. I have a few comments that you might want to consider. Yes, I'm happy with the current patch. Thanks for considering my suggestions. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From stefank at openjdk.java.net Thu Dec 10 08:17:33 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 10 Dec 2020 08:17:33 GMT Subject: RFR: 8258018: Remove arrayOop.inline.hpp In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 06:31:08 GMT, Ioi Lam wrote: > Please review this trivial change. arrayOop.inline.hpp is not needed and its contents can be safely moved into arrayOop.hpp. > > Testing with mach5 tier1,builds-tier2,builds-tier3,builds-tier4,builds-tier5 Thanks for cleaning this up! ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1728 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 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 pliden at openjdk.java.net Thu Dec 10 09:41:49 2020 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 10 Dec 2020 09:41:49 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v4] In-Reply-To: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: <5gK5mwZmODZhwJZ9pmGBS7x9HuX2JjNF7mkpWNrZBGw=.cb2853de-695c-428f-b757-90100af94fe4@github.com> > MaxVirtMemFraction limits the amount of address space the GC should use for the heap. This is used by the heuristics in Arguments::set_heap_size() to select an appropriate default max heap size. However, that heuristic can select a max heap size that will not fit with ZGC, since ZGC uses additional address space (for multi-mapping and the virtual-to-physical ratio). As a result, if the address space is limited, and -Xmx is not specified, then ZGC might refuse to start with the error: > > "Failed to reserve enough address space for Java heap" > > I propose we abstract MaxVirtMemFraction to make it configurable for each GC, so that the heuristics in Arguments::set_heap_size() will pick a default max heap size that also works for ZGC. > > Testing: Manual testing using different ulimit -v sizes. Per Liden has updated the pull request incrementally with one additional commit since the last revision: Add workaround for AggressiveHeap ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1696/files - new: https://git.openjdk.java.net/jdk/pull/1696/files/eaaf4f97..36a099c8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1696&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1696&range=02-03 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1696.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1696/head:pull/1696 PR: https://git.openjdk.java.net/jdk/pull/1696 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 stefank at openjdk.java.net Thu Dec 10 09:45:35 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 10 Dec 2020 09:45:35 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v3] In-Reply-To: References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: <6Z-svAi41RqamblvzMAlTqsVbffv-h23VCWX_lqUupU=.02693e68-1f52-459e-b203-d61572cdf59d@github.com> On Wed, 9 Dec 2020 12:07:53 GMT, Thomas Schatzl wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Review > > Marked as reviewed by tschatzl (Reviewer). Latest update looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1696 From kbarrett at openjdk.java.net Thu Dec 10 09:57:46 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Dec 2020 09:57:46 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v9] In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 22:24:09 GMT, Claes Redestad wrote: >> This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp >> >> Naming is hard, but I think the following scheme is reasonable: >> >> - log2i: any integral type. 0-hostile >> - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) >> - exact_log2i: any integral type. value must be a power of two >> >> I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. >> >> Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. >> >> To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: >> >> [ RUN ] power_of_2.log2_long_micro >> [ OK ] power_of_2.log2_long_micro (3581 ms) >> [ RUN ] power_of_2.log2_long_small_micro >> [ OK ] power_of_2.log2_long_small_micro (549 ms) >> [ RUN ] power_of_2.log2i_micro >> [ OK ] power_of_2.log2i_micro (259 ms) >> [ RUN ] power_of_2.log2i_small_micro >> [ OK ] power_of_2.log2i_small_micro (113 ms) >> >> I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W >> >> (Intending this for 17) > > Claes Redestad 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 24 additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template > - More review comments adressed > - Issue with using count_trailing_zeros with 64-bit values on 32-bit, revert and add TODO > - Merge branch 'master' into log2_template > - Renaming, adress review comments > - x->value > - Rename log2i ilogi and make it only accept value > 0, rename log2i_allow_zero log2i_graceful, accepting any value > - Rename exact_log2i exact_ilog2, make it stricter > - Merge branch 'master' into log2_template > - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template > - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b1e50588...511a8f67 Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 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 kbarrett at openjdk.java.net Thu Dec 10 10:15:34 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 10 Dec 2020 10:15:34 GMT Subject: RFR: 8258018: Remove arrayOop.inline.hpp In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 06:31:08 GMT, Ioi Lam wrote: > Please review this trivial change. arrayOop.inline.hpp is not needed and its contents can be safely moved into arrayOop.hpp. > > Testing with mach5 tier1,builds-tier2,builds-tier3,builds-tier4,builds-tier5 Marked as reviewed by kbarrett (Reviewer). src/hotspot/share/oops/arrayOop.hpp line 93: > 91: // Returns the address of the first element. The elements in the array will not > 92: // relocate from this address until a subsequent thread transition. > 93: inline void* base(BasicType type) const { Drop the unnecessary "inline". ------------- PR: https://git.openjdk.java.net/jdk/pull/1728 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 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 eosterlund at openjdk.java.net Thu Dec 10 10:54:36 2020 From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 10 Dec 2020 10:54:36 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v4] In-Reply-To: <5gK5mwZmODZhwJZ9pmGBS7x9HuX2JjNF7mkpWNrZBGw=.cb2853de-695c-428f-b757-90100af94fe4@github.com> References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> <5gK5mwZmODZhwJZ9pmGBS7x9HuX2JjNF7mkpWNrZBGw=.cb2853de-695c-428f-b757-90100af94fe4@github.com> Message-ID: On Thu, 10 Dec 2020 09:41:49 GMT, Per Liden wrote: >> MaxVirtMemFraction limits the amount of address space the GC should use for the heap. This is used by the heuristics in Arguments::set_heap_size() to select an appropriate default max heap size. However, that heuristic can select a max heap size that will not fit with ZGC, since ZGC uses additional address space (for multi-mapping and the virtual-to-physical ratio). As a result, if the address space is limited, and -Xmx is not specified, then ZGC might refuse to start with the error: >> >> "Failed to reserve enough address space for Java heap" >> >> I propose we abstract MaxVirtMemFraction to make it configurable for each GC, so that the heuristics in Arguments::set_heap_size() will pick a default max heap size that also works for ZGC. >> >> Testing: Manual testing using different ulimit -v sizes. > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Add workaround for AggressiveHeap Marked as reviewed by eosterlund (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1696 From pliden at openjdk.java.net Thu Dec 10 11:13:33 2020 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 10 Dec 2020 11:13:33 GMT Subject: RFR: 8257901: ZGC: Take virtual memory usage into account when sizing heap [v4] In-Reply-To: References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> <5gK5mwZmODZhwJZ9pmGBS7x9HuX2JjNF7mkpWNrZBGw=.cb2853de-695c-428f-b757-90100af94fe4@github.com> Message-ID: On Thu, 10 Dec 2020 10:51:47 GMT, Erik ?sterlund wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Add workaround for AggressiveHeap > > Marked as reviewed by eosterlund (Reviewer). Thanks all for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/1696 From pliden at openjdk.java.net Thu Dec 10 11:13:35 2020 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 10 Dec 2020 11:13:35 GMT Subject: Integrated: 8257901: ZGC: Take virtual memory usage into account when sizing heap In-Reply-To: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> References: <0kFZqrSdGPSNne6tTzMxMhKtKlvg3ud2L42h-w4ltho=.58198ded-4f44-4ae2-9a32-79dc349b90e2@github.com> Message-ID: On Tue, 8 Dec 2020 13:41:56 GMT, Per Liden wrote: > MaxVirtMemFraction limits the amount of address space the GC should use for the heap. This is used by the heuristics in Arguments::set_heap_size() to select an appropriate default max heap size. However, that heuristic can select a max heap size that will not fit with ZGC, since ZGC uses additional address space (for multi-mapping and the virtual-to-physical ratio). As a result, if the address space is limited, and -Xmx is not specified, then ZGC might refuse to start with the error: > > "Failed to reserve enough address space for Java heap" > > I propose we abstract MaxVirtMemFraction to make it configurable for each GC, so that the heuristics in Arguments::set_heap_size() will pick a default max heap size that also works for ZGC. > > Testing: Manual testing using different ulimit -v sizes. This pull request has now been integrated. Changeset: 0a0691eb Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/0a0691eb Stats: 38 lines in 7 files changed: 24 ins; 0 del; 14 mod 8257901: ZGC: Take virtual memory usage into account when sizing heap Reviewed-by: stefank, eosterlund, ayang, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/1696 From yzheng at openjdk.java.net Thu Dec 10 13:19:52 2020 From: yzheng at openjdk.java.net (Yudi Zheng) Date: Thu, 10 Dec 2020 13:19:52 GMT Subject: RFR: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. [v3] In-Reply-To: <-dC7EkSsxPpLvZE5I5ds2CAw1QJfDGNIAxLec7s8o2w=.d8c74ba5-45c4-4041-8674-6edad6dc49a6@github.com> References: <-dC7EkSsxPpLvZE5I5ds2CAw1QJfDGNIAxLec7s8o2w=.d8c74ba5-45c4-4041-8674-6edad6dc49a6@github.com> Message-ID: <5smSQbY8dNu8xNzGsicw9x60GAHn-QQx_8FfwZSHfG4=.ee93c38d-f424-4174-bb3d-508cbb517ea7@github.com> > Update exception_seen flag in the MDO when no exception handler is found for caller during deoptimization, or when exception is thrown in the runtime. > > Plus, `-Xlog:exceptions=info` code and `AbortVMOnException` are adjusted in C1 runtime and jvmci runtime to be consistent with C2, i.e., before `JvmtiExport::can_post_on_exceptions` deoptimization and fast continuation when compiled handler is found. Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision: Address comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1713/files - new: https://git.openjdk.java.net/jdk/pull/1713/files/bb4a3ff0..d5d6968b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1713&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1713&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1713.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1713/head:pull/1713 PR: https://git.openjdk.java.net/jdk/pull/1713 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 iklam at openjdk.java.net Thu Dec 10 13:24:48 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Dec 2020 13:24:48 GMT Subject: RFR: 8258018: Remove arrayOop.inline.hpp [v2] In-Reply-To: References: Message-ID: > Please review this trivial change. arrayOop.inline.hpp is not needed and its contents can be safely moved into arrayOop.hpp. > > Testing with mach5 tier1,builds-tier2,builds-tier3,builds-tier4,builds-tier5 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: kimbarrett review; reverted unintended change in barrierSet.inline.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1728/files - new: https://git.openjdk.java.net/jdk/pull/1728/files/3fff8505..0dd0931b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1728&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1728&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1728.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1728/head:pull/1728 PR: https://git.openjdk.java.net/jdk/pull/1728 From coleenp at openjdk.java.net Thu Dec 10 13:30:35 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 10 Dec 2020 13:30:35 GMT Subject: RFR: 8258018: Remove arrayOop.inline.hpp [v2] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 13:24:48 GMT, Ioi Lam wrote: >> Please review this trivial change. arrayOop.inline.hpp is not needed and its contents can be safely moved into arrayOop.hpp. >> >> Testing with mach5 tier1,builds-tier2,builds-tier3,builds-tier4,builds-tier5 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > kimbarrett review; reverted unintended change in barrierSet.inline.hpp LGTM. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1728 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 redestad at openjdk.java.net Thu Dec 10 14:14:42 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 10 Dec 2020 14:14:42 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v9] In-Reply-To: References: Message-ID: <6DB21Etpz1-NWwBg1rmFKdR5R9vV7ZeLQ9ZQaPEujjI=.8fbad735-9c2e-43f4-9499-13bcb45e38d2@github.com> On Thu, 10 Dec 2020 09:55:07 GMT, Kim Barrett wrote: >> Claes Redestad 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 24 additional commits since the last revision: >> >> - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template >> - More review comments adressed >> - Issue with using count_trailing_zeros with 64-bit values on 32-bit, revert and add TODO >> - Merge branch 'master' into log2_template >> - Renaming, adress review comments >> - x->value >> - Rename log2i ilogi and make it only accept value > 0, rename log2i_allow_zero log2i_graceful, accepting any value >> - Rename exact_log2i exact_ilog2, make it stricter >> - Merge branch 'master' into log2_template >> - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template >> - ... and 14 more: https://git.openjdk.java.net/jdk/compare/bfe6d606...511a8f67 > > Marked as reviewed by kbarrett (Reviewer). @kimbarrett @stefank - thank you for reviews! @tstuefe - re-testing latest on BE (ppc and s390?) would be much appreciated. I'm going to hold off on pushing this until some time after 16 forks off, so there's no rush. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 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 pliden at openjdk.java.net Thu Dec 10 14:48:41 2020 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 10 Dec 2020 14:48:41 GMT Subject: RFR: 8257970: Remove julong types in os::limit_heap_by_allocatable_memory Message-ID: Please review this cleanup. In the review of JDK-8257901, the request came up to change the `julong` types (return value, arguments) in `os::limit_heap_by_allocatable_memory()` to `size_t`. This change of types also propagates to `os::has_allocatable_memory_limit()`. ------------- Commit messages: - 8257970: Remove julong types in os::limit_heap_by_allocatable_memory Changes: https://git.openjdk.java.net/jdk/pull/1736/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1736&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257970 Stats: 19 lines in 6 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/1736.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1736/head:pull/1736 PR: https://git.openjdk.java.net/jdk/pull/1736 From stefank at openjdk.java.net Thu Dec 10 15:21:34 2020 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 10 Dec 2020 15:21:34 GMT Subject: RFR: 8257970: Remove julong types in os::limit_heap_by_allocatable_memory In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 14:44:00 GMT, Per Liden wrote: > Please review this cleanup. In the review of JDK-8257901, the request came up to change the `julong` types (return value, arguments) in `os::limit_heap_by_allocatable_memory()` to `size_t`. This change of types also propagates to `os::has_allocatable_memory_limit()`. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1736 From tschatzl at openjdk.java.net Thu Dec 10 15:32:35 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 10 Dec 2020 15:32:35 GMT Subject: RFR: 8257970: Remove julong types in os::limit_heap_by_allocatable_memory In-Reply-To: References: Message-ID: <-XoCDuk_zyN9RR6fnX0-JTFsJQzMziH0FNsl7HbPcwA=.d7fd6317-6ae1-41ff-a626-5a7295a42a1b@github.com> On Thu, 10 Dec 2020 14:44:00 GMT, Per Liden wrote: > Please review this cleanup. In the review of JDK-8257901, the request came up to change the `julong` types (return value, arguments) in `os::limit_heap_by_allocatable_memory()` to `size_t`. This change of types also propagates to `os::has_allocatable_memory_limit()`. Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1736 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 dawid.weiss at gmail.com Thu Dec 10 16:25:15 2020 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 10 Dec 2020 17:25:15 +0100 Subject: Impossible (?) code path resulting in IllegalStateException on jdk14+ Message-ID: 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 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 kvn at openjdk.java.net Thu Dec 10 17:05:59 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 10 Dec 2020 17:05:59 GMT Subject: RFR: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. [v3] In-Reply-To: <5smSQbY8dNu8xNzGsicw9x60GAHn-QQx_8FfwZSHfG4=.ee93c38d-f424-4174-bb3d-508cbb517ea7@github.com> References: <-dC7EkSsxPpLvZE5I5ds2CAw1QJfDGNIAxLec7s8o2w=.d8c74ba5-45c4-4041-8674-6edad6dc49a6@github.com> <5smSQbY8dNu8xNzGsicw9x60GAHn-QQx_8FfwZSHfG4=.ee93c38d-f424-4174-bb3d-508cbb517ea7@github.com> Message-ID: <8Vc-U4GJkexL9HEK9ihSqnc6AY70JXkaWc0BcYFPtZU=.907bd152-b2c0-4233-8d98-33af4ae34ab9@github.com> On Thu, 10 Dec 2020 13:19:52 GMT, Yudi Zheng wrote: >> Update exception_seen flag in the MDO when no exception handler is found for caller during deoptimization, or when exception is thrown in the runtime. >> >> Plus, `-Xlog:exceptions=info` code and `AbortVMOnException` are adjusted in C1 runtime and jvmci runtime to be consistent with C2, i.e., before `JvmtiExport::can_post_on_exceptions` deoptimization and fast continuation when compiled handler is found. > > Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision: > > Address comments. Looks good. Unfortunately it missed JDK16 fork but because it is P3 bug it can be fixed there without approval for now (RDP1 phase). Please, create PR based on https://github.com/openjdk/jdk16 (create your fork for it) and I will approve it. After push the fix will be auto-forwarded into JDK 17 (current https://github.com/openjdk/jdk) ------------- Changes requested by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1713 From iklam at openjdk.java.net Thu Dec 10 17:06:58 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Dec 2020 17:06:58 GMT Subject: RFR: 8258018: Remove arrayOop.inline.hpp [v2] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 08:14:20 GMT, Stefan Karlsson wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> kimbarrett review; reverted unintended change in barrierSet.inline.hpp > > Thanks for cleaning this up! Thanks @stefank @coleenp @kimbarrett for the review. Mach5 tests passed for tier1,builds-tier2,builds-tier3,builds-tier4,builds-tier5 ------------- PR: https://git.openjdk.java.net/jdk/pull/1728 From iklam at openjdk.java.net Thu Dec 10 17:07:00 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Dec 2020 17:07:00 GMT Subject: Integrated: 8258018: Remove arrayOop.inline.hpp In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 06:31:08 GMT, Ioi Lam wrote: > Please review this trivial change. arrayOop.inline.hpp is not needed and its contents can be safely moved into arrayOop.hpp. > > Testing with mach5 tier1,builds-tier2,builds-tier3,builds-tier4,builds-tier5 This pull request has now been integrated. Changeset: 1e5e790b Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/1e5e790b Stats: 48 lines in 9 files changed: 3 ins; 36 del; 9 mod 8258018: Remove arrayOop.inline.hpp Reviewed-by: stefank, kbarrett, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1728 From redestad at openjdk.java.net Thu Dec 10 17:26:00 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 10 Dec 2020 17:26:00 GMT Subject: Integrated: 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 12:53:48 GMT, Claes Redestad wrote: > This moves the mirroring of vmSymbols in ciSymbols to a separate file, ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol namespace). In a few places code is moved from .hpp to .cpp to facilitate this. > > With PCH disabled, this reduces total includes from 276949 to 276332 This pull request has now been integrated. Changeset: f5740561 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/f5740561 Stats: 183 lines in 32 files changed: 102 ins; 30 del; 51 mod 8256424: Move ciSymbol::symbol_name() to ciSymbols::symbol_name() Reviewed-by: kvn, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/1256 From yzheng at openjdk.java.net Thu Dec 10 18:00:04 2020 From: yzheng at openjdk.java.net (Yudi Zheng) Date: Thu, 10 Dec 2020 18:00:04 GMT Subject: [jdk16] RFR: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. Message-ID: Update exception_seen flag in the MDO when no exception handler is found for caller during deoptimization, or when exception is thrown in the runtime. Plus, -Xlog:exceptions=info code and AbortVMOnException are adjusted in C1 runtime and jvmci runtime to be consistent with C2, i.e., before JvmtiExport::can_post_on_exceptions deoptimization and fast continuation when compiled handler is found. ------------- Commit messages: - Set exception_seen accordingly in the runtime. - Adjust log:exceptions dumping code in C1 and JVMCI runtimes. Changes: https://git.openjdk.java.net/jdk16/pull/2/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=2&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257910 Stats: 90 lines in 4 files changed: 62 ins; 28 del; 0 mod Patch: https://git.openjdk.java.net/jdk16/pull/2.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/2/head:pull/2 PR: https://git.openjdk.java.net/jdk16/pull/2 From yzheng at openjdk.java.net Thu Dec 10 18:01:03 2020 From: yzheng at openjdk.java.net (Yudi Zheng) Date: Thu, 10 Dec 2020 18:01:03 GMT Subject: RFR: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. [v3] In-Reply-To: <8Vc-U4GJkexL9HEK9ihSqnc6AY70JXkaWc0BcYFPtZU=.907bd152-b2c0-4233-8d98-33af4ae34ab9@github.com> References: <-dC7EkSsxPpLvZE5I5ds2CAw1QJfDGNIAxLec7s8o2w=.d8c74ba5-45c4-4041-8674-6edad6dc49a6@github.com> <5smSQbY8dNu8xNzGsicw9x60GAHn-QQx_8FfwZSHfG4=.ee93c38d-f424-4174-bb3d-508cbb517ea7@github.com> <8Vc-U4GJkexL9HEK9ihSqnc6AY70JXkaWc0BcYFPtZU=.907bd152-b2c0-4233-8d98-33af4ae34ab9@github.com> Message-ID: On Thu, 10 Dec 2020 17:03:01 GMT, Vladimir Kozlov wrote: >> Yudi Zheng has updated the pull request incrementally with one additional commit since the last revision: >> >> Address comments. > > Looks good. Unfortunately it missed JDK16 fork but because it is P3 bug it can be fixed there without approval for now (RDP1 phase). > Please, create PR based on https://github.com/openjdk/jdk16 (create your fork for it) and I will approve it. After push the fix will be auto-forwarded into JDK 17 (current https://github.com/openjdk/jdk) Thanks @vnkozlov ! Created https://github.com/openjdk/jdk16/pull/2 and took the opportunity to squash commits. ------------- PR: https://git.openjdk.java.net/jdk/pull/1713 From github.com+11656534+maurolacy at openjdk.java.net Thu Dec 10 18:01:11 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Thu, 10 Dec 2020 18:01:11 GMT Subject: RFR: 8193234: When using -Xcheck:jni an internally allocated buffer can leak (original issue). Message-ID: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> Hello, I'm a contributor of the [jni-rs](https://github.com/jni-rs/jni-rs/) project. Rust bindings to the JNI. When running tests against OpenJDK with the flag "-Xcheck:jni" enabled, we detected the following: the behaviour of the `JNI_COMMIT` mode of `ReleasePrimitiveArrayCritical` seems to be inconsistent, when running with `-Xcheck:jni` enabled, vs. without `-Xcheck:jni`. If using "-Xcheck:jni" we're hitting a double free using `ReleasePrimitiveArrayCritical` with `JNI_COMMIT`, when we attempt to release the buffer at the end. It is our understanding that the behaviour of `ReleasePrimitiveArrayCritical` must be consistent, independently of whether the check JNI mode is enabled or not. You can check [https://github.com/jni-rs/jni-rs/issues/283](https://github.com/jni-rs/jni-rs/issues/283) for details / comments on this. We've tracked down the issue to this February 2019 commit: [openjdk commit 3e904a4](https://github.com/openjdk/jdk/commit/3e904a4801b2bf2e988ba096e5cb64a17fd5fce7). The related discussion is here: [openjdk bug JDK-8193234](https://bugs.openjdk.java.net/browse/JDK-8193234). As there are no associated tests or functionality in the OpenJDK code base, I've simply reverted the commit. Just in case, I've also built and tested the JDK, without issues. Not sure what tests are the ones mentioned in the discussions that led to the introduction of this behaviour. It is our understanding that tests of `JNI_COMMIT` functionality must still make a call to `ReleasePrimitiveArrayCritical` with a proper mode (`0` or `JNI_ABORT`) at the end, to release the buffer. And this, independently of `-Xcheck:jni` being enabled or not. If there are any issues related to this that we're not aware of, please let us know. This reverts commit 3e904a4801b2bf2e988ba096e5cb64a17fd5fce7. ------------- Commit messages: - Revert "8193234: When using -Xcheck:jni an internally allocated buffer can leak" Changes: https://git.openjdk.java.net/jdk/pull/1697/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1697&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8193234 Stats: 7 lines in 1 file changed: 4 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1697.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1697/head:pull/1697 PR: https://git.openjdk.java.net/jdk/pull/1697 From github.com+11656534+maurolacy at openjdk.java.net Thu Dec 10 18:01:11 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Thu, 10 Dec 2020 18:01:11 GMT Subject: RFR: 8193234: When using -Xcheck:jni an internally allocated buffer can leak (original issue). In-Reply-To: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> Message-ID: <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> On Tue, 8 Dec 2020 14:01:48 GMT, Mauro Lacy wrote: > Hello, > > I'm a contributor of the [jni-rs](https://github.com/jni-rs/jni-rs/) project. Rust bindings to the JNI. > > When running tests against OpenJDK with the flag "-Xcheck:jni" enabled, we detected the following: the behaviour of the `JNI_COMMIT` mode of `ReleasePrimitiveArrayCritical` seems to be inconsistent, when running with `-Xcheck:jni` enabled, vs. without `-Xcheck:jni`. > > If using "-Xcheck:jni" we're hitting a double free using `ReleasePrimitiveArrayCritical` with `JNI_COMMIT`, when we attempt to release the buffer at the end. It is our understanding that the behaviour of `ReleasePrimitiveArrayCritical` must be consistent, independently of whether the check JNI mode is enabled or not. > > You can check [https://github.com/jni-rs/jni-rs/issues/283](https://github.com/jni-rs/jni-rs/issues/283) for details / comments on this. > > We've tracked down the issue to this February 2019 commit: [openjdk commit 3e904a4](https://github.com/openjdk/jdk/commit/3e904a4801b2bf2e988ba096e5cb64a17fd5fce7). The related discussion is here: [openjdk bug JDK-8193234](https://bugs.openjdk.java.net/browse/JDK-8193234). > > As there are no associated tests or functionality in the OpenJDK code base, I've simply reverted the commit. Just in case, I've also built and tested the JDK, without issues. > > Not sure what tests are the ones mentioned in the discussions that led to the introduction of this behaviour. It is our understanding that tests of `JNI_COMMIT` functionality must still make a call to `ReleasePrimitiveArrayCritical` with a proper mode (`0` or `JNI_ABORT`) at the end, to release the buffer. And this, independently of `-Xcheck:jni` being enabled or not. > > If there are any issues related to this that we're not aware of, please let us know. > > This reverts commit 3e904a4801b2bf2e988ba096e5cb64a17fd5fce7. issue 8193234: When using -Xcheck:jni an internally allocated buffer can leak (original issue). ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From github.com+168222+mgkwill at openjdk.java.net Thu Dec 10 18:10:10 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 10 Dec 2020 18:10:10 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v14] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge branch 'master' into update_hlp - Remove extraneous ' from warning Signed-off-by: Marcus G K Williams - Merge branch 'master' into update_hlp - Merge branch 'master' into update_hlp - Merge branch 'master' into update_hlp - Fix os::large_page_size() in last update Signed-off-by: Marcus G K Williams - Ivan W. Requested Changes Removed os::Linux::select_large_page_size and use os::page_size_for_region instead Removed Linux::find_large_page_size and use register_large_page_sizes. Streamlined Linux::setup_large_page_size Signed-off-by: Marcus G K Williams - Fix space format, use Linux:: for local func. Signed-off-by: Marcus G K Williams - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp - Fix merge mistakes Signed-off-by: Marcus G K Williams - ... and 12 more: https://git.openjdk.java.net/jdk/compare/f5740561...81ff7c53 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=13 Stats: 63 lines in 2 files changed: 24 ins; 11 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From kvn at openjdk.java.net Thu Dec 10 18:19:58 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 10 Dec 2020 18:19:58 GMT Subject: [jdk16] RFR: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 17:54:45 GMT, Yudi Zheng wrote: > Update exception_seen flag in the MDO when no exception handler is found for caller during deoptimization, or when exception is thrown in the runtime. > > Plus, -Xlog:exceptions=info code and AbortVMOnException are adjusted in C1 runtime and jvmci runtime to be consistent with C2, i.e., before JvmtiExport::can_post_on_exceptions deoptimization and fast continuation when compiled handler is found. Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/2 From gziemski at openjdk.java.net Thu Dec 10 18:23:58 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 10 Dec 2020 18:23:58 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 21:47:31 GMT, Coleen Phillimore wrote: > Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. > > Tested with tier1-3 with product and fastdebug builds. Built with optimized. > > This is for JDK 17. Changes requested by gziemski (Committer). src/hotspot/share/utilities/debug.cpp line 250: > 248: // message to be printed in one short line to stderr (see TEST_VM_ASSERT_MSG) and > 249: // cannot be tweaked to accept our normal assert message. > 250: jio_vsnprintf(_detail_msg, sizeof(_detail_msg), detail_fmt, detail_args); Does `'static char _detail_msg[1024];` need to be outside of `print_error_for_unit_test()` Why not put it inside the `print_error_for_unit_test()` just before `jio_vsnprintf ` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From gziemski at openjdk.java.net Thu Dec 10 18:23:58 2020 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 10 Dec 2020 18:23:58 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 18:18:37 GMT, Gerard Ziemski wrote: >> Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. >> >> Tested with tier1-3 with product and fastdebug builds. Built with optimized. >> >> This is for JDK 17. > > Changes requested by gziemski (Committer). Very nice cleanup. I like moving the majority of that code to a gtest. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 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 yzheng at openjdk.java.net Thu Dec 10 18:55:55 2020 From: yzheng at openjdk.java.net (Yudi Zheng) Date: Thu, 10 Dec 2020 18:55:55 GMT Subject: [jdk16] RFR: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 18:17:14 GMT, Vladimir Kozlov wrote: >> Update exception_seen flag in the MDO when no exception handler is found for caller during deoptimization, or when exception is thrown in the runtime. >> >> Plus, -Xlog:exceptions=info code and AbortVMOnException are adjusted in C1 runtime and jvmci runtime to be consistent with C2, i.e., before JvmtiExport::can_post_on_exceptions deoptimization and fast continuation when compiled handler is found. > > Good. @vnkozlov I am not a committer, would you please sponsor this change? ------------- PR: https://git.openjdk.java.net/jdk16/pull/2 From kvn at openjdk.java.net Thu Dec 10 20:01:55 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 10 Dec 2020 20:01:55 GMT Subject: [jdk16] RFR: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 18:53:26 GMT, Yudi Zheng wrote: >> Good. > > @vnkozlov I am not a committer, would you please sponsor this change? I will sponsor it after testing. ------------- PR: https://git.openjdk.java.net/jdk16/pull/2 From akozlov at openjdk.java.net Thu Dec 10 20:08:00 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 10 Dec 2020 20:08:00 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v6] In-Reply-To: <3tNI7G1GOXjH1xIJQoGswrg3DC63zq6FE3_wSnhAd4Y=.952df04c-71d9-48a0-aff2-7c2d64dbfeda@github.com> References: <3A8yXtEkRQymlaf0L15jBPViSYPFlMIKxp7aefZyv2E=.25a4e984-17a7-4a38-9ce4-c37c2f0dc428@github.com> <0Rl1rgfPK8tQJ9KPwMTTTqlN_GjyxjIwBSUXtHIvUyo=.11610ef7-95f8-4d8d-872a-f38960d320ff@github.com> <3tNI7G1GOXjH1xIJQoGswrg3DC63zq6FE3_wSnhAd4Y=.952df04c-71d9-48a0-aff2-7c2d64dbfeda@github.com> Message-ID: On Sat, 5 Dec 2020 14:52:32 GMT, Anton Kozlov wrote: >>> > I found this: https://stackoverflow.com/questions/7718964/how-can-i-force-macos-to-release-madv-freed-pages. One remark recommends MADV_FREE_REUSABLE to deal with the display problem; could that be a solution >>> >>> I'd found MADV_FREE_REUSABLE as well. One problem is that it's barely documented. The only description from the vendor I could find was >>> >>> ``` >>> #define MADV_FREE 5 /* pages unneeded, discard contents */ >>> #define MADV_ZERO_WIRED_PAGES 6 /* zero the wired pages that have not been unwired before the entry is deleted */ >>> #define MADV_FREE_REUSABLE 7 /* pages can be reused (by anyone) */ >>> #define MADV_FREE_REUSE 8 /* caller wants to reuse those pages */ >>> ``` >>> >>> The other problem, it cannot substitute mmap completely, see below. >>> >>> > My only remaining question is: is there really an observable difference between replacing the mapping with mmap and calling madvice(MADV_FREE)? And if there is, does it matter in practice? >>> >>> Yes, it is. For a sample program after uncommit implemented by different ways, mmap the only way to reduce occupied memory size in Activity Monitor (system GUI application user will likely look to). >>> >> >> Okay, I see. Thanks for these tests, they are valuable. My one remaining doubt would be if the numbers were different in the face of memory pressure. >> >> But I don't like to block this PR anymore, I caused enough work and discussions. So I am fine with the general thrust of the change: >> - add exec to reserve and uncommit >> - with the contract being that the exec parameter handed in with commit and uncommit has to match the one used with reserve. >> Maybe we can have future improvements with these interfaces and reduce the complexity again (e.g. having an opaque handle structure holding mapping creation information). >> >> Is the current version review-worthy? >> >> Thanks a lot for your patience, >> >> ..Thomas > >> So I am fine with the general thrust of the change: >> * add exec to reserve and uncommit >> * with the contract being that the exec parameter handed in with commit and uncommit has to match the one used with reserve. > > The latest version implements this approach. It's ready for review. > > Thanks, > Anton Hi. Could someone else review the patch? AFAIK Thomas is unable to do this on this week. And building broader consensus is not worthless. Unfortunately, we've reverted to an older version of the patch, so @iklam 's review applies to almost completely different code. I'm sorry for that. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From iklam at openjdk.java.net Thu Dec 10 20:33:14 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Dec 2020 20:33:14 GMT Subject: RFR: 8257912: Convert enum iteration to use range-based for loops [v2] In-Reply-To: References: Message-ID: > Now that [range-based for loops](https://github.com/openjdk/jdk/pull/1488) are allowed by the [HotSpot Style Guide](https://github.com/openjdk/jdk/blob/52ab72127ddc3ca6575d9d58503ec39c5dff7ab1/doc/hotspot-style.md), I have converted the more verbose syntax: > > for (vmIntrinsicsIterator it = vmIntrinsicsRange.begin(); it != vmIntrinsicsRange.end(); ++it) { > vmIntrinsicID index = *it; > nt[as_int(index)] = string; > } > > to > > for (vmIntrinsicID index : EnumRange{}) { > nt[as_int(index)] = string; > } > > I also removed the "convenient" declarations such as `vmIntrinsicsRange` and `vmIntrinsicsIterator` -- these are useful only when writing a traditional for loop, and are probably confusing to everyone else. I've left examples in enumIterator.hpp in case anyone wants to write a traditional for loop. > > I also added gtest cases for using range-based for loops with `EnumRange<>`. Ioi Lam 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 8257912-range-based-for-loop - 8257912: Convert enum iteration to use range-based for loops ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1707/files - new: https://git.openjdk.java.net/jdk/pull/1707/files/26ad3f0d..ceaebeeb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1707&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1707&range=00-01 Stats: 15530 lines in 289 files changed: 13089 ins; 1590 del; 851 mod Patch: https://git.openjdk.java.net/jdk/pull/1707.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1707/head:pull/1707 PR: https://git.openjdk.java.net/jdk/pull/1707 From iklam at openjdk.java.net Thu Dec 10 20:35:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Dec 2020 20:35:57 GMT Subject: Integrated: 8257912: Convert enum iteration to use range-based for loops In-Reply-To: References: Message-ID: <_htce-V-1Zj7-CcwtpcIbxdXk7ix--NA0ShePQK1jBI=.c39d9e2e-cdf0-4417-80ef-79f68cf6bf16@github.com> On Wed, 9 Dec 2020 01:34:16 GMT, Ioi Lam wrote: > Now that [range-based for loops](https://github.com/openjdk/jdk/pull/1488) are allowed by the [HotSpot Style Guide](https://github.com/openjdk/jdk/blob/52ab72127ddc3ca6575d9d58503ec39c5dff7ab1/doc/hotspot-style.md), I have converted the more verbose syntax: > > for (vmIntrinsicsIterator it = vmIntrinsicsRange.begin(); it != vmIntrinsicsRange.end(); ++it) { > vmIntrinsicID index = *it; > nt[as_int(index)] = string; > } > > to > > for (vmIntrinsicID index : EnumRange{}) { > nt[as_int(index)] = string; > } > > I also removed the "convenient" declarations such as `vmIntrinsicsRange` and `vmIntrinsicsIterator` -- these are useful only when writing a traditional for loop, and are probably confusing to everyone else. I've left examples in enumIterator.hpp in case anyone wants to write a traditional for loop. > > I also added gtest cases for using range-based for loops with `EnumRange<>`. This pull request has now been integrated. Changeset: 80dac5a8 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/80dac5a8 Stats: 119 lines in 10 files changed: 71 ins; 24 del; 24 mod 8257912: Convert enum iteration to use range-based for loops Reviewed-by: kbarrett, tschatzl, gziemski ------------- PR: https://git.openjdk.java.net/jdk/pull/1707 From burban at openjdk.java.net Thu Dec 10 21:46:58 2020 From: burban at openjdk.java.net (Bernhard Urban-Forster) Date: Thu, 10 Dec 2020 21:46:58 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v7] In-Reply-To: <4mw_qwllDU7qLgqcm7Z_kxyGICpv18HZ_LrbidneSw4=.891574d8-45a6-4ecd-9dc9-be2070bdc3e6@github.com> References: <4mw_qwllDU7qLgqcm7Z_kxyGICpv18HZ_LrbidneSw4=.891574d8-45a6-4ecd-9dc9-be2070bdc3e6@github.com> Message-ID: On Fri, 4 Dec 2020 22:29:25 GMT, Anton Kozlov wrote: >> Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html >> >> On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, PROT_NONE), the function was made aware of exec permissions. >> >> For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference compared with old code. >> >> For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not shrink (if I haven't missed anything, by the implementation and in principle). >> >> Tested: >> * local tier1 >> * jdk-submit >> * codesign[2] with hardened runtime and allow-jit but without >> allow-unsigned-executable-memory entitlements[3] produce a working bundle. >> >> (adding GC group as suggested by @dholmes-ora) >> >> >> [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 >> [2] >> >> codesign \ >> --sign - \ >> --options runtime \ >> --entitlements ents.plist \ >> --timestamp \ >> $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib >> [3] >> >> >> >> >> com.apple.security.cs.allow-jit >> >> com.apple.security.cs.disable-library-validation >> >> com.apple.security.cs.allow-dyld-environment-variables >> >> >> > > Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision: > > - Fix style > - JDK-8234930 v4: Use MAP_JIT when allocating pages for code cache on macOS > - Revert "Separate executable_memory interface" > > This reverts commit 49253d8fe8963ce069f10783dcea5327079ba848. I read through the discussion and it makes sense to me. Thanks for the `mprotect`/`madvice` tests, they are pretty interesting. Patch looks good too (but I'm not a Reviewer). src/hotspot/os/bsd/os_bsd.cpp line 1937: > 1935: // Bsd mmap allows caller to pass an address as hint; give it a try first, > 1936: // if kernel honors the hint then we can return immediately. > 1937: char * addr = anon_mmap(requested_addr, bytes, false/*executable*/); use `!ExecMem`? src/hotspot/os/linux/os_linux.cpp line 3275: > 3273: struct bitmask* os::Linux::_numa_membind_bitmask; > 3274: > 3275: bool os::pd_uncommit_memory(char* addr, size_t size, bool exec) { nit: I'm irritated by `bool exec` in `pd_uncommit_memory`, but `bool executable` in `pd_reserve_memory`. Choose one :-) ------------- Marked as reviewed by burban (Author). PR: https://git.openjdk.java.net/jdk/pull/294 From kvn at openjdk.java.net Thu Dec 10 22:45:57 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 10 Dec 2020 22:45:57 GMT Subject: [jdk16] RFR: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 19:58:58 GMT, Vladimir Kozlov wrote: >> @vnkozlov I am not a committer, would you please sponsor this change? > > I will sponsor it after testing. Passed hs-tier1-3 JDK 16 testing. ------------- PR: https://git.openjdk.java.net/jdk16/pull/2 From yzheng at openjdk.java.net Thu Dec 10 22:45:58 2020 From: yzheng at openjdk.java.net (Yudi Zheng) Date: Thu, 10 Dec 2020 22:45:58 GMT Subject: [jdk16] Integrated: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 17:54:45 GMT, Yudi Zheng wrote: > Update exception_seen flag in the MDO when no exception handler is found for caller during deoptimization, or when exception is thrown in the runtime. > > Plus, -Xlog:exceptions=info code and AbortVMOnException are adjusted in C1 runtime and jvmci runtime to be consistent with C2, i.e., before JvmtiExport::can_post_on_exceptions deoptimization and fast continuation when compiled handler is found. This pull request has now been integrated. Changeset: 58dca925 Author: Yudi Zheng Committer: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk16/commit/58dca925 Stats: 90 lines in 4 files changed: 62 ins; 28 del; 0 mod 8257910: [JVMCI] Set exception_seen accordingly in the runtime. Reviewed-by: kvn ------------- PR: https://git.openjdk.java.net/jdk16/pull/2 From iklam at openjdk.java.net Thu Dec 10 22:48:00 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Dec 2020 22:48:00 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT In-Reply-To: References: Message-ID: <6qGvPa71-OuM2c92ac99gBEjtYdJimHxwf4s_YlUgn0=.5d24bf67-1cc4-44e4-be1f-3fa435e86f9a@github.com> On Wed, 9 Dec 2020 21:47:31 GMT, Coleen Phillimore wrote: > Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. > > Tested with tier1-3 with product and fastdebug builds. Built with optimized. > > This is for JDK 17. Marked as reviewed by iklam (Reviewer). src/hotspot/share/utilities/vmError.cpp line 1818: > 1816: fatal("Crashing with number %d", how); > 1817: } > 1818: tty->print_cr("VMError::controlled_crash: survived intentional crash. Did you suppress the assert?"); The message should be changed: `VMError::controlled_crash` -> `controlled_crash` ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From iklam at openjdk.java.net Thu Dec 10 22:51:19 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Dec 2020 22:51:19 GMT Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp [v2] In-Reply-To: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> Message-ID: > stubRoutines.hpp is unnecessarily included by thread.hpp and copy.hpp. This causes a large number of header files related to native code generation to be included by almost all HotSpot .o files. > > - Before the fix, stubRoutines.hpp is included by 803 .o files. > - After the fix, stubRoutines.hpp is included by 117 .o files. > > The total number of included header files decreased from 252893 to 247631, or about 2%. > > Note: the main change is the removal of stubRoutines.hpp in thread.hpp and copy.hpp. Unfortunately I have to fix quite a few missing dependencies in other source files that are revealed by the removal. > > Testing: I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. Ioi Lam 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 8257731-reduce-include-of-stubRoutines-hpp - 8257731: Remove excessive include of stubRoutines.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1610/files - new: https://git.openjdk.java.net/jdk/pull/1610/files/9baf9a50..c4f2d8ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1610&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1610&range=00-01 Stats: 32306 lines in 742 files changed: 24130 ins; 5389 del; 2787 mod Patch: https://git.openjdk.java.net/jdk/pull/1610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1610/head:pull/1610 PR: https://git.openjdk.java.net/jdk/pull/1610 From iklam at openjdk.java.net Fri Dec 11 00:00:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 00:00:57 GMT Subject: RFR: 8257731: Remove excessive include of stubRoutines.hpp [v2] In-Reply-To: <06cb7IIR-9ans5Ovq1CbI_-WTt6a8Wtpodne_YuL4GU=.e1834260-c908-4a0b-901d-d3317ad05c9a@github.com> References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> <9GZtbgjbCfhchZ5lTW2ycnI5pbWBmwc492or0W_Yym4=.0c9bcf13-71c8-4561-b10c-118747213c67@github.com> <06cb7IIR-9ans5Ovq1CbI_-WTt6a8Wtpodne_YuL4GU=.e1834260-c908-4a0b-901d-d3317ad05c9a@github.com> Message-ID: <1zJHkJKWBMjKZTSSxGUzTgOilra4vBiIipKFiC2nkSw=.8a007fc3-3960-49f9-a149-155a7b2ffafe@github.com> On Sun, 6 Dec 2020 17:41:25 GMT, Aleksey Shipilev wrote: >>> With sufficient pre-integration testing this should not be an issue. It >>> seems for JDK-8257563 no GitHub actions were run and so numerous build >>> variants were missed. >> >> And since there's likely going to be some churn happening in tandem in both mainline and stabilization fork in the coming weeks, wouldn't it be better to get changes like these pushed _before_ rather than right after the JDK 16 stabilization fork is created? The second best option might be to hold off with large cleanups/reshuffling until RDP2 starts. > > I don't mind pushing it for JDK 16. I was just suggesting that we defer somewhat intrusive cleanups to JDK 17, as it customary to do (at least in my vicinity) in order to have everyone else build/test based on clean master in the days coming to JDK 16 cutoff. But we could instead pay more attention to the state of master and fix the follow-up build failure bugs even more promptly this week. Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. ------------- PR: https://git.openjdk.java.net/jdk/pull/1610 From iklam at openjdk.java.net Fri Dec 11 00:00:59 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 00:00:59 GMT Subject: Integrated: 8257731: Remove excessive include of stubRoutines.hpp In-Reply-To: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> References: <7Fy7-sQJbIzAKO9sJwgqUMhlpF-7Dx-OHuiBHaQ2QN8=.705f435c-91f0-4e5b-bfa4-5601257d0597@github.com> Message-ID: On Thu, 3 Dec 2020 23:20:33 GMT, Ioi Lam wrote: > stubRoutines.hpp is unnecessarily included by thread.hpp and copy.hpp. This causes a large number of header files related to native code generation to be included by almost all HotSpot .o files. > > - Before the fix, stubRoutines.hpp is included by 803 .o files. > - After the fix, stubRoutines.hpp is included by 117 .o files. > > The total number of included header files decreased from 252893 to 247631, or about 2%. > > Note: the main change is the removal of stubRoutines.hpp in thread.hpp and copy.hpp. Unfortunately I have to fix quite a few missing dependencies in other source files that are revealed by the removal. > > Testing: I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. This pull request has now been integrated. Changeset: d4282b0c Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/d4282b0c Stats: 99 lines in 59 files changed: 73 ins; 10 del; 16 mod 8257731: Remove excessive include of stubRoutines.hpp Reviewed-by: coleenp, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1610 From iklam at openjdk.java.net Fri Dec 11 03:39:07 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 03:39:07 GMT Subject: RFR: 8243205: Modularize JVM flags declaration [v3] In-Reply-To: References: Message-ID: > This is the first step for modularizing the xxx_globals.hpp. The goals are > > - Improve modularization of HotSpot source > - Reduce JVM build time > > To prove that this works, I have moved compiler_globals.hpp outside of the monolithic globals.hpp. Before this fix, compiler_globals.hpp was included by 922 HotSpot .o files. After this fix, it's included by 283 .o files. > > I plan to do more refactoring later, such as: > > - move gc_globals.hpp out of globals.hpp > - move the flags related to tiered compilation (about 40 flags) out of globals.hpp > - move the platform-specific flags outside of globals.hpp > - these flags should be used only by platform-specific files. They shouldn't be used by shared files. > > Note: this is target for JDK 17. > > Testing: I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into 8243205-modularize-globals-hpp - stefank comments - 8243205: Modularize global variable declaration for JVM flag macros ------------- Changes: https://git.openjdk.java.net/jdk/pull/1608/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1608&range=02 Stats: 494 lines in 27 files changed: 303 ins; 158 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/1608.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1608/head:pull/1608 PR: https://git.openjdk.java.net/jdk/pull/1608 From iklam at openjdk.java.net Fri Dec 11 04:21:54 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 04:21:54 GMT Subject: RFR: 8243205: Modularize JVM flags declaration [v2] In-Reply-To: <2DyMl3PJhuj5PAEygd769GMD5WdCWovtSEOLn69R298=.2228945b-4216-4515-b6c2-7268afbb8756@github.com> References: <2DyMl3PJhuj5PAEygd769GMD5WdCWovtSEOLn69R298=.2228945b-4216-4515-b6c2-7268afbb8756@github.com> Message-ID: On Tue, 8 Dec 2020 08:05:08 GMT, Stefan Karlsson wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> stefank comments > > Marked as reviewed by stefank (Reviewer). Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. ------------- PR: https://git.openjdk.java.net/jdk/pull/1608 From iklam at openjdk.java.net Fri Dec 11 04:21:55 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 04:21:55 GMT Subject: Integrated: 8243205: Modularize JVM flags declaration In-Reply-To: References: Message-ID: <3td8KGXb5JNVbsx9QE5Jk1gbvNqHNyFyrCZFX0o_X1s=.55f1af4f-cd5f-4de6-8dc4-368b8e51fa8a@github.com> On Thu, 3 Dec 2020 21:51:42 GMT, Ioi Lam wrote: > This is the first step for modularizing the xxx_globals.hpp. The goals are > > - Improve modularization of HotSpot source > - Reduce JVM build time > > To prove that this works, I have moved compiler_globals.hpp outside of the monolithic globals.hpp. Before this fix, compiler_globals.hpp was included by 922 HotSpot .o files. After this fix, it's included by 283 .o files. > > I plan to do more refactoring later, such as: > > - move gc_globals.hpp out of globals.hpp > - move the flags related to tiered compilation (about 40 flags) out of globals.hpp > - move the platform-specific flags outside of globals.hpp > - these flags should be used only by platform-specific files. They shouldn't be used by shared files. > > Note: this is target for JDK 17. > > Testing: I've tested tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. This pull request has now been integrated. Changeset: 1d15ebe1 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/1d15ebe1 Stats: 494 lines in 27 files changed: 303 ins; 158 del; 33 mod 8243205: Modularize JVM flags declaration Reviewed-by: kvn, coleenp, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/1608 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 iklam at openjdk.java.net Fri Dec 11 05:33:06 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 05:33:06 GMT Subject: RFR: 8258074: Move some flags related to compiler to compiler_globals.hpp Message-ID: Many flags in globals.hpp are related to the compiler, and are mostly used only by the compiler source files. These flags should be moved to compiler_globals.hpp Examples: - CompileCommandFile - Tier2CompileThreshold - HugeMethodLimit This speeds up HotSpot build time, and improves modularity. This RFE is the first step -- it moves a few dozen flags that are straight-forward to move. Other flags may be moved by follow-up RFEs. ------------- Commit messages: - 8258074: Move some flags related to compiler to compiler_globals.hpp Changes: https://git.openjdk.java.net/jdk/pull/1746/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1746&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258074 Stats: 909 lines in 11 files changed: 469 ins; 429 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1746.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1746/head:pull/1746 PR: https://git.openjdk.java.net/jdk/pull/1746 From david.holmes at oracle.com Fri Dec 11 06:02:44 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Dec 2020 16:02:44 +1000 Subject: RFR: 8193234: When using -Xcheck:jni an internally allocated buffer can leak (original issue). In-Reply-To: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> Message-ID: <766710ad-0a59-e60d-c714-572f90a6d666@oracle.com> Hi Mauro, On 11/12/2020 4:01 am, Mauro Lacy wrote: > Hello, > > I'm a contributor of the [jni-rs](https://github.com/jni-rs/jni-rs/) project. Rust bindings to the JNI. > > When running tests against OpenJDK with the flag "-Xcheck:jni" enabled, we detected the following: the behaviour of the `JNI_COMMIT` mode of `ReleasePrimitiveArrayCritical` seems to be inconsistent, when running with `-Xcheck:jni` enabled, vs. without `-Xcheck:jni`. > > If using "-Xcheck:jni" we're hitting a double free using `ReleasePrimitiveArrayCritical` with `JNI_COMMIT`, when we attempt to release the buffer at the end. It is our understanding that the behaviour of `ReleasePrimitiveArrayCritical` must be consistent, independently of whether the check JNI mode is enabled or not. > > You can check [https://github.com/jni-rs/jni-rs/issues/283](https://github.com/jni-rs/jni-rs/issues/283) for details / comments on this. > > We've tracked down the issue to this February 2019 commit: [openjdk commit 3e904a4](https://github.com/openjdk/jdk/commit/3e904a4801b2bf2e988ba096e5cb64a17fd5fce7). The related discussion is here: [openjdk bug JDK-8193234](https://bugs.openjdk.java.net/browse/JDK-8193234). > > As there are no associated tests or functionality in the OpenJDK code base, I've simply reverted the commit. Just in case, I've also built and tested the JDK, without issues. > > Not sure what tests are the ones mentioned in the discussions that led to the introduction of this behaviour. It is our understanding that tests of `JNI_COMMIT` functionality must still make a call to `ReleasePrimitiveArrayCritical` with a proper mode (`0` or `JNI_ABORT`) at the end, to release the buffer. And this, independently of `-Xcheck:jni` being enabled or not. > > If there are any issues related to this that we're not aware of, please let us know. If you just reverse the previous fix then you have reintroduced the memory leak that it was fixing - so we can't just do that. I will take a closer look to understand the double-free issue that you are seeing. Note that your PR is not valid as you can't create a PR for an issue that is already closed and fixed. This will need a new issue created in JBS and then a PR created for that. Please close the PR you opened for this. Thanks, David > This reverts commit 3e904a4801b2bf2e988ba096e5cb64a17fd5fce7. > > ------------- > > Commit messages: > - Revert "8193234: When using -Xcheck:jni an internally allocated buffer can leak" > > Changes: https://git.openjdk.java.net/jdk/pull/1697/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1697&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8193234 > Stats: 7 lines in 1 file changed: 4 ins; 3 del; 0 mod > Patch: https://git.openjdk.java.net/jdk/pull/1697.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/1697/head:pull/1697 > > PR: https://git.openjdk.java.net/jdk/pull/1697 > 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 dholmes at openjdk.java.net Fri Dec 11 07:22:05 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 11 Dec 2020 07:22:05 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> Message-ID: On Thu, 10 Dec 2020 17:55:30 GMT, Mauro Lacy wrote: >> Hello, >> >> I'm a contributor of the [jni-rs](https://github.com/jni-rs/jni-rs/) project. Rust bindings to the JNI. >> >> When running tests against OpenJDK with the flag "-Xcheck:jni" enabled, we detected the following: the behaviour of the `JNI_COMMIT` mode of `ReleasePrimitiveArrayCritical` seems to be inconsistent, when running with `-Xcheck:jni` enabled, vs. without `-Xcheck:jni`. >> >> If using "-Xcheck:jni", we're hitting a double free calling `ReleasePrimitiveArrayCritical` with `JNI_COMMIT`, when we attempt to release the buffer at the end. It is our understanding that the behaviour of `ReleasePrimitiveArrayCritical` must be consistent, independently of whether the check JNI mode is enabled or not. >> >> You can check [https://github.com/jni-rs/jni-rs/issues/283](https://github.com/jni-rs/jni-rs/issues/283) for details / comments on this. >> >> We've tracked down the issue to this February 2019 commit: [openjdk commit 3e904a4](https://github.com/openjdk/jdk/commit/3e904a4801b2bf2e988ba096e5cb64a17fd5fce7). The related discussion is here: [openjdk bug JDK-8193234](https://bugs.openjdk.java.net/browse/JDK-8193234). >> >> As there are no associated tests or functionality in the OpenJDK code base, I've simply reverted the commit. Just in case, I've also built and tested the JDK, without issues. >> >> Not sure what tests are the ones mentioned in the discussions that led to the introduction of this behaviour. It is our understanding that tests of `JNI_COMMIT` functionality must still make a call to `ReleasePrimitiveArrayCritical` with a proper mode (`0` or `JNI_ABORT`) at the end, to release the buffer. And this, independently of `-Xcheck:jni` being enabled or not. >> >> If there are any issues related to this that we're not aware of, please let us know. >> >> This reverts commit 3e904a4801b2bf2e988ba096e5cb64a17fd5fce7. > > issue 8193234: When using -Xcheck:jni an internally allocated buffer can leak (original issue). I've filed: https://bugs.openjdk.java.net/browse/JDK-8258077 Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From iklam at openjdk.java.net Fri Dec 11 07:22:19 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 07:22:19 GMT Subject: RFR: 8258074: Move some flags related to compiler to compiler_globals.hpp [v2] In-Reply-To: References: Message-ID: <9nBHyQNqGlItycVc3uY9HXZmq3nw_1bzXmz95c9mq6w=.9b5c24cb-7ec0-4b20-939c-086245d39879@github.com> > Many flags in globals.hpp are related to the compiler, and are mostly used only by the compiler source files. These flags should be moved to compiler_globals.hpp > > Examples: > > - CompileCommandFile > - Tier2CompileThreshold > - HugeMethodLimit > > This speeds up HotSpot build time, and improves modularity. > > This RFE is the first step -- it moves a few dozen flags that are straight-forward to move. Other flags may be moved by follow-up RFEs. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: fixed gtest ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1746/files - new: https://git.openjdk.java.net/jdk/pull/1746/files/d6718880..c218bd66 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1746&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1746&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1746.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1746/head:pull/1746 PR: https://git.openjdk.java.net/jdk/pull/1746 From github.com+11656534+maurolacy at openjdk.java.net Fri Dec 11 07:22:07 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Fri, 11 Dec 2020 07:22:07 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> Message-ID: On Fri, 11 Dec 2020 06:23:04 GMT, David Holmes wrote: >> issue 8193234: When using -Xcheck:jni an internally allocated buffer can leak (original issue). > > I've filed: https://bugs.openjdk.java.net/browse/JDK-8258077 > > Cheers, > David Hi David, Thanks for the issue, I'll change the title to properly reference it. The point is that I couldn't find those memory leaks. At least in the openjdk code base, I couldn't find tests for that functionality, so, no memory leaks. And, in any case, if there are tests in another code base, they are leaking because they are incorrect (IMO). In that they are not always following the right calling pattern for `ReleasePrimitiveArrayCritical`. `ReleasePrimitiveArrayCritical`, despite its name (and to the best of our knowledge), does **not** release the buffer when called with `JNI_COMMIT`. So, it must be called again with a different release mode, to properly release the buffer. And this, independently of the JVM flags. Or, it will manifest inconsistent behaviour; which is what's happening. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From github.com+11656534+maurolacy at openjdk.java.net Fri Dec 11 07:22:07 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Fri, 11 Dec 2020 07:22:07 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> Message-ID: On Fri, 11 Dec 2020 06:45:09 GMT, Mauro Lacy wrote: >> I've filed: https://bugs.openjdk.java.net/browse/JDK-8258077 >> >> Cheers, >> David > > Hi David, > > Thanks for the issue, I'll change the title to properly reference it. > > The point is that I couldn't find those memory leaks. At least in the openjdk code base, I couldn't find tests for that functionality, so, no memory leaks. > > And, in any case, if there are tests in another code base, they are leaking because they are incorrect (IMO). In that they are not always following the right calling pattern for `ReleasePrimitiveArrayCritical`. > > `ReleasePrimitiveArrayCritical`, despite its name (and to the best of our knowledge), does **not** release the buffer when called with `JNI_COMMIT`. So, it must be called again with a different release mode, to properly release the buffer. > > And this, independently of the JVM flags. Or, it will manifest inconsistent behaviour; which is what's happening. issue 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From dholmes at openjdk.java.net Fri Dec 11 07:22:08 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 11 Dec 2020 07:22:08 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> Message-ID: <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> On Fri, 11 Dec 2020 06:46:06 GMT, Mauro Lacy wrote: >> Hi David, >> >> Thanks for the issue, I'll change the title to properly reference it. >> >> The point is that I couldn't find those memory leaks. At least in the openjdk code base, I couldn't find tests for that functionality, so, no memory leaks. >> >> And, in any case, if there are tests in another code base, they are leaking because they are incorrect (IMO). In that they are not always following the right calling pattern for `ReleasePrimitiveArrayCritical`. >> >> `ReleasePrimitiveArrayCritical`, despite its name (and to the best of our knowledge), does **not** release the buffer when called with `JNI_COMMIT`. So, it must be called again with a different release mode, to properly release the buffer. >> >> And this, independently of the JVM flags. Or, it will manifest inconsistent behaviour; which is what's happening. > > issue 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 There are no tests for this, this was about external users of JNI encountering the leak. I also just re-checked the JDK source and it seems this code also suffers from the COMMIT-only problem: ./jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c The debate is over what constitutes correct and incorrect usage here - as I just wrote in the bug report. I will see if there is a reasonable way to support both. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 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 github.com+11656534+maurolacy at openjdk.java.net Fri Dec 11 08:22:58 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Fri, 11 Dec 2020 08:22:58 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: On Fri, 11 Dec 2020 07:17:09 GMT, David Holmes wrote: > There are no tests for this, this was about external users of JNI encountering the leak. I also just re-checked the JDK source and it seems this code also suffers from the COMMIT-only problem: > > ./jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c > > The debate is over what constitutes correct and incorrect usage here - as I just wrote in the bug report. Yes. The fact that the method name starts with `Release`, and is being used for `COMMIT` doesn't help in that regard. This is probably for another place / discussion, but IMO that functionality should be in different API calls (`CommitPrimitiveArrayCritical`, and `CommitArrayElements`) which do just that: commit the buffer changes. The use of `JNI_COMMIT` in `ReleasePrimitiveArrayCritical` and `ReleaseArrayElements` is misleading, to say the least. In fact, in the Rust lib we just separated those into different methods. Ref. [ReleaseMode](https://github.com/jni-rs/jni-rs/blob/master/src/wrapper/objects/release_mode.rs) vs. [commit()](https://github.com/jni-rs/jni-rs/blob/ff6aafd98974fb8d9fff2eac4a05bf477002af09/src/wrapper/objects/auto_primitive_array.rs#L50). > I will see if there is a reasonable way to support both. I don't think so. Not consistently, at least. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From stuefe at openjdk.java.net Fri Dec 11 08:32:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 11 Dec 2020 08:32:00 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 21:47:31 GMT, Coleen Phillimore wrote: > Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. > > Tested with tier1-3 with product and fastdebug builds. Built with optimized. > > This is for JDK 17. Hi Coleen, this is a good cleanup, I like this a lot. About moving ErrorHandlerTest.java to gtest: this is a slick way of doing these tests. However, some things to consider: - Strictly speaking we now do not test the real error handler output but the artificial output `ExecutingUnitTests` gives us. The real printing code is now untested. This may have bitten you right here, since I believe in `print_error_for_unit_test` you miss a `va_copy` which should have messed up detail_args and garbled the real output later on. - moving these tests out of jtreg means we give up flexibility (excluding them or moving them to another tier). Do they impact the gtest run time noticeably? There are also remaining problems with gtest death tests, which I hope we can fix at some point. I don't hold my breath though since we decided to not own the gtest code and cannot make modifications: - Death tests are easily confused by stderr output. See: https://bugs.openjdk.java.net/browse/JDK-8257229. So whenever we have unconditional stderr output in the VM (eg if some large page alloc failed) these death tests fail too. - Death tests don't tell you the assert message which happened if it did not match their expectations. Thats plain annoying. See https://bugs.openjdk.java.net/browse/JDK-8257227. src/hotspot/share/utilities/vmError.cpp line 1800: > 1798: case 2: guarantee(how == 0, "test guarantee"); break; > 1799: > 1800: // The other cases are unused. I like that you cut down on the cases. Most of them were obsolete or not working correctly. How about compacting the cases? And maybe use a real enum. But this could also be done in a separate RFE. src/hotspot/share/utilities/vmError.hpp line 187: > 185: > 186: // Test vmassert(), fatal(), guarantee(), etc. > 187: DEBUG_ONLY(static void test_error_handler();) May I suggest: - remove the almost empty `test_error_handler` completely - remove the "case 0" in `controlled_crash` - leave `controlled_crash` public - In create_vm, doing this instead: if (ErrorHandlerTest != 0) { VMError::controlled_crash(ErrorHandlerTest); } This would have two advantages, it would be clearer and leave us with a "controlled_crash" API to use in quick tests (I do that sometimes). Both are not hard reasons and a matter of taste, so feel free to ignore my proposal. test/hotspot/gtest/unittest.hpp line 138: > 136: ASSERT_EXIT(child_ ## category ## _ ## name ## _(), \ > 137: ::testing::ExitedWithCode(1), \ > 138: "^assert failed: .*" msg); \ Good! src/hotspot/share/utilities/debug.cpp line 246: > 244: #ifdef ASSERT > 245: if (ExecutingUnitTests) { > 246: if (detail_fmt != NULL) { You miss va_copy for detail_args here. src/hotspot/share/utilities/debug.cpp line 243: > 241: static char _detail_msg[1024]; > 242: > 243: static void print_error_for_unit_test(const char* message, const char* detail_fmt, va_list detail_args) { Trying to understand why you changed this code (beside factoring it out). We have: - report_vm_out_of_memory -> message=NULL, detail set - report_and_die from real crash -> message=NULL, detail="" - report_fatal -> message="fatal error", detail set - report_vm_error (assert, guarantee) -> message="assert (bla) failed", detail is set so sometimes message is NULL, sometimes details are empty. What a mess :( Since you do gtests for all these cases now, you need to print the assert message correctly for them. You use _detail_msg as scratch buffer, since its already there. Later we print the detail message again into it. But I think that is fine. I have a patch on the back burner somewhere simplifying these functions. Maybe we can improve matters. Then this function becomes easier too. ------------- Changes requested by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1723 From github.com+11656534+maurolacy at openjdk.java.net Fri Dec 11 08:44:57 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Fri, 11 Dec 2020 08:44:57 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: On Fri, 11 Dec 2020 08:17:13 GMT, Mauro Lacy wrote: >> There are no tests for this, this was about external users of JNI encountering the leak. I also just re-checked the JDK source and it seems this code also suffers from the COMMIT-only problem: >> >> ./jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c >> >> The debate is over what constitutes correct and incorrect usage here - as I just wrote in the bug report. I will see if there is a reasonable way to support both. > >> There are no tests for this, this was about external users of JNI encountering the leak. I also just re-checked the JDK source and it seems this code also suffers from the COMMIT-only problem: >> >> ./jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c >> >> The debate is over what constitutes correct and incorrect usage here - as I just wrote in the bug report. > > Yes. The fact that the method name starts with `Release`, and is being used for `COMMIT` doesn't help in that regard. > This is probably for another place / discussion, but IMO that functionality should be in different API calls (`CommitPrimitiveArrayCritical`, and `CommitArrayElements`) which do just that: commit the buffer changes. > The use of `JNI_COMMIT` in `ReleasePrimitiveArrayCritical` and `ReleaseArrayElements` is misleading, to say the least. > > In fact, in the Rust lib we just separated those into different methods. > Ref. [ReleaseMode](https://github.com/jni-rs/jni-rs/blob/master/src/wrapper/objects/release_mode.rs) vs. [commit()](https://github.com/jni-rs/jni-rs/blob/ff6aafd98974fb8d9fff2eac4a05bf477002af09/src/wrapper/objects/auto_primitive_array.rs#L50). > >> I will see if there is a reasonable way to support both. > > I don't think so. Not consistently, at least. David, I can't comment in the issue page (AFAIK), but I agree with what you wrote there. Just one more thing: The behaviour of `ReleasePrimitiveArrayCritical` with `JNI_COMMIT` **changes** depending on if you use the `-Xcheck:jni` flag or not. This is inconsistent behaviour. Probably introduced when trying to satisfy both use cases. Besides, I don't think the same is true of the other `Release` methods. This happens only with the `Critical` variant. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 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 pliden at openjdk.java.net Fri Dec 11 10:20:58 2020 From: pliden at openjdk.java.net (Per Liden) Date: Fri, 11 Dec 2020 10:20:58 GMT Subject: RFR: 8257970: Remove julong types in os::limit_heap_by_allocatable_memory In-Reply-To: <-XoCDuk_zyN9RR6fnX0-JTFsJQzMziH0FNsl7HbPcwA=.d7fd6317-6ae1-41ff-a626-5a7295a42a1b@github.com> References: <-XoCDuk_zyN9RR6fnX0-JTFsJQzMziH0FNsl7HbPcwA=.d7fd6317-6ae1-41ff-a626-5a7295a42a1b@github.com> Message-ID: On Thu, 10 Dec 2020 15:29:32 GMT, Thomas Schatzl wrote: >> Please review this cleanup. In the review of JDK-8257901, the request came up to change the `julong` types (return value, arguments) in `os::limit_heap_by_allocatable_memory()` to `size_t`. This change of types also propagates to `os::has_allocatable_memory_limit()`. > > Marked as reviewed by tschatzl (Reviewer). Thanks for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/1736 From pliden at openjdk.java.net Fri Dec 11 10:20:59 2020 From: pliden at openjdk.java.net (Per Liden) Date: Fri, 11 Dec 2020 10:20:59 GMT Subject: Integrated: 8257970: Remove julong types in os::limit_heap_by_allocatable_memory In-Reply-To: References: Message-ID: <5f0t_MGc1liF4tIDxFgcPPaublqcQXO57UeKHJE-ayQ=.51d09bac-230e-4b9a-9340-837252a57db0@github.com> On Thu, 10 Dec 2020 14:44:00 GMT, Per Liden wrote: > Please review this cleanup. In the review of JDK-8257901, the request came up to change the `julong` types (return value, arguments) in `os::limit_heap_by_allocatable_memory()` to `size_t`. This change of types also propagates to `os::has_allocatable_memory_limit()`. This pull request has now been integrated. Changeset: b5592c05 Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/b5592c05 Stats: 19 lines in 6 files changed: 0 ins; 0 del; 19 mod 8257970: Remove julong types in os::limit_heap_by_allocatable_memory Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/1736 From magnus.ihse.bursie at oracle.com Fri Dec 11 10:29:09 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 11 Dec 2020 11:29:09 +0100 Subject: [patch] link libjvm with -latomic In-Reply-To: <90671a28-0464-37e7-fc3d-1372a1bf8a77@ubuntu.com> References: <90671a28-0464-37e7-fc3d-1372a1bf8a77@ubuntu.com> Message-ID: <845e9d8c-d25c-b1d2-df62-e5130481d297@oracle.com> If we need -latomic on certain platforms we should add it on those platforms, but I would prefer not to add it unconditionally. But then again, if you want to add it for a bunch of system which are only supported on zero, I will not argue hard against it. (Also, build-dev is the proper list to discuss changes in the build system) /Magnus On 2020-12-09 16:19, Matthias Klose wrote: > seen with 16+27, zero needs to be linked with -latomic for a few more > architectures. Instead of hard-coding these architectures, would it be possible > to link with -latomic unconditionally? It's the last library on the link > command, so linking with -Wl,--as-needed -latomic should be do no harm. Even > better link with > > -Wl,--push-state,--as-needed -latomic -Wl,--pop-state > > --push-state/--pop-state are implemented in binutils 2.28, released in 2017. > > It also looks like zero also build on ARM32 again. > > Matthias > > > --- a/make/autoconf/libraries.m4 > +++ b/make/autoconf/libraries.m4 > @@ -127,9 +127,13 @@ AC_DEFUN_ONCE([LIB_SETUP_LIBRARIES], > # Libatomic library > # 32-bit MIPS needs fallback library for 8-byte atomic ops > if test "x$OPENJDK_TARGET_OS" = xlinux && > - (test "x$OPENJDK_TARGET_CPU" = xmips || > - test "x$OPENJDK_TARGET_CPU" = xmipsel); then > - BASIC_JVM_LIBS="$BASIC_JVM_LIBS -latomic" > + (test "x$OPENJDK_TARGET_CPU" = xarm || > + test "x$OPENJDK_TARGET_CPU" = xm68k || > + test "x$OPENJDK_TARGET_CPU" = xmips || > + test "x$OPENJDK_TARGET_CPU" = xmipsel || > + test "x$OPENJDK_TARGET_CPU" = xppc || > + test "x$OPENJDK_TARGET_CPU" = xsh); then > + BASIC_JVM_LIBS="$BASIC_JVM_LIBS -Wl,--push-state,--as-needed -latomic > -Wl,--pop-state" > fi > > # perfstat lib From redestad at openjdk.java.net Fri Dec 11 11:19:03 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 11:19:03 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM Message-ID: Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. ------------- Commit messages: - Fix malformed Windows code - Merge branch 'master' into ctz_template - Add support for 8 and 16-bit types, refactor tests to test all types - 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM Changes: https://git.openjdk.java.net/jdk/pull/1747/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257985 Stats: 102 lines in 2 files changed: 72 ins; 0 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/1747.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1747/head:pull/1747 PR: https://git.openjdk.java.net/jdk/pull/1747 From redestad at openjdk.java.net Fri Dec 11 11:24:08 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 11:24:08 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v2] In-Reply-To: References: Message-ID: > Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. > > Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. > > Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Fix Windows 32-bit variant, improve commentary ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1747/files - new: https://git.openjdk.java.net/jdk/pull/1747/files/7ecdd76b..1b012194 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1747.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1747/head:pull/1747 PR: https://git.openjdk.java.net/jdk/pull/1747 From github.com+11656534+maurolacy at openjdk.java.net Fri Dec 11 11:36:02 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Fri, 11 Dec 2020 11:36:02 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: On Fri, 11 Dec 2020 08:17:13 GMT, Mauro Lacy wrote: > I also just re-checked the JDK source and it seems this code also suffers from the COMMIT-only problem: > > ./jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c I've taken a look and yes, I think you're right. The line ` (*env)->ReleasePrimitiveArrayCritical(env, jOut, outBufP, JNI_COMMIT);` should probably use `JNI_ABORT` if there's an error, and `0` if it's a normal cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From github.com+11656534+maurolacy at openjdk.java.net Fri Dec 11 11:48:55 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Fri, 11 Dec 2020 11:48:55 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: On Fri, 11 Dec 2020 11:33:41 GMT, Mauro Lacy wrote: >>> There are no tests for this, this was about external users of JNI encountering the leak. I also just re-checked the JDK source and it seems this code also suffers from the COMMIT-only problem: >>> >>> ./jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c >>> >>> The debate is over what constitutes correct and incorrect usage here - as I just wrote in the bug report. >> >> Yes. The fact that the method name starts with `Release`, and is being used for `COMMIT` doesn't help in that regard. >> This is probably for another place / discussion, but IMO that functionality should be in different API calls (`CommitPrimitiveArrayCritical`, and `CommitArrayElements`) which do just that: commit the buffer changes. >> The use of `JNI_COMMIT` in `ReleasePrimitiveArrayCritical` and `ReleaseArrayElements` is misleading, to say the least. >> >> In fact, in the Rust lib we just separated those into different methods. >> Ref. [ReleaseMode](https://github.com/jni-rs/jni-rs/blob/master/src/wrapper/objects/release_mode.rs) vs. [commit()](https://github.com/jni-rs/jni-rs/blob/ff6aafd98974fb8d9fff2eac4a05bf477002af09/src/wrapper/objects/auto_primitive_array.rs#L50). >> >>> I will see if there is a reasonable way to support both. >> >> I don't think so. Not consistently, at least. > >> I also just re-checked the JDK source and it seems this code also suffers from the COMMIT-only problem: >> >> ./jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c > > I've taken a look and yes, I think you're right. The line > ` (*env)->ReleasePrimitiveArrayCritical(env, jOut, outBufP, JNI_COMMIT);` > > should probably use `JNI_ABORT` if there's an error, and `0` if it's a normal cleanup. > > On second look, `0` looks like the obvious choice. If there's a jump due to an error, `outBufP` will be `NULL`, and the line wouldn't be executed in the first place. I'll send a PR for that cryptoki fix too, if you like. I'll now try to register into the issue tracker, so I can create a proper issue for it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From github.com+11656534+maurolacy at openjdk.java.net Fri Dec 11 13:10:59 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Fri, 11 Dec 2020 13:10:59 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: On Fri, 11 Dec 2020 11:45:59 GMT, Mauro Lacy wrote: >>> I also just re-checked the JDK source and it seems this code also suffers from the COMMIT-only problem: >>> >>> ./jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c >> >> I've taken a look and yes, I think you're right. The line >> ` (*env)->ReleasePrimitiveArrayCritical(env, jOut, outBufP, JNI_COMMIT);` >> >> should probably use `JNI_ABORT` if there's an error, and `0` if it's a normal cleanup. >> >> On second look, `0` looks like the obvious choice. If there's a jump due to an error, `outBufP` will be `NULL`, and the line wouldn't be executed in the first place. > > I'll send a PR for that cryptoki fix too, if you like. I'll now try to register into the issue tracker, so I can create a proper issue for it. Hmmm, crypto stuff. I wonder if... ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From redestad at openjdk.java.net Fri Dec 11 13:11:16 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 13:11:16 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v3] In-Reply-To: References: Message-ID: > Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. > > Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. > > Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: @tschatzl review fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1747/files - new: https://git.openjdk.java.net/jdk/pull/1747/files/1b012194..90c0fde5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=01-02 Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1747.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1747/head:pull/1747 PR: https://git.openjdk.java.net/jdk/pull/1747 From tschatzl at openjdk.java.net Fri Dec 11 13:11:17 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 11 Dec 2020 13:11:17 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v2] In-Reply-To: References: Message-ID: <0yPqXli9NVx2A5Kt8N5Y0s5MGOFWjnKc7CHiOk47s50=.3d4b5fdf-9f22-4e23-912f-4b6729dfe612@github.com> On Fri, 11 Dec 2020 11:24:08 GMT, Claes Redestad wrote: >> Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. >> >> Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. >> >> Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Fix Windows 32-bit variant, improve commentary Changes requested by tschatzl (Reviewer). src/hotspot/share/utilities/count_trailing_zeros.hpp line 98: > 96: if (index == 0) { > 97: _BitScanForward(&index, (uint32_t)(v >> 32)); > 98: if (index > 0) { Shouldn't this check be superfluous if the code previously asserted v != 0, and we know that the lower 32 bits are zero? Also the MSDN documentation does not state that `index == 0` if no bit has been found, but the return value of the method is 0. I.e. shouldn't the implementation be something like: if (_BitScanForward(&index, (uint32_t)v) == 0) { // no bit found? If so, try the upper dword. Otherwise index already contains the result _BitScanForward(&index, v >> 32); // no need for the uint32_t cast. >> is well defined on unsigned longs. // one could assert that the result of this invocation is non-zero, but it should be 1 if v != 0. index += 32; } return index; ------------- PR: https://git.openjdk.java.net/jdk/pull/1747 From redestad at openjdk.java.net Fri Dec 11 13:11:18 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 13:11:18 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v2] In-Reply-To: <0yPqXli9NVx2A5Kt8N5Y0s5MGOFWjnKc7CHiOk47s50=.3d4b5fdf-9f22-4e23-912f-4b6729dfe612@github.com> References: <0yPqXli9NVx2A5Kt8N5Y0s5MGOFWjnKc7CHiOk47s50=.3d4b5fdf-9f22-4e23-912f-4b6729dfe612@github.com> Message-ID: <6TSlbNpQ6opeeAOFwgy2CJvJ_WCbya8BVFlNQJAlyCs=.33d71860-c553-4211-bf02-496c7739954b@github.com> On Fri, 11 Dec 2020 12:16:35 GMT, Thomas Schatzl wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Windows 32-bit variant, improve commentary > > src/hotspot/share/utilities/count_trailing_zeros.hpp line 98: > >> 96: if (index == 0) { >> 97: _BitScanForward(&index, (uint32_t)(v >> 32)); >> 98: if (index > 0) { > > Shouldn't this check be superfluous if the code previously asserted v != 0, and we know that the lower 32 bits are zero? > > Also the MSDN documentation does not state that `index == 0` if no bit has been found, but the return value of the method is 0. I.e. shouldn't the implementation be something like: > > if (_BitScanForward(&index, (uint32_t)v) == 0) { // no bit found? If so, try the upper dword. Otherwise index already contains the result > _BitScanForward(&index, v >> 32); // no need for the uint32_t cast. >> is well defined on unsigned longs. > // one could assert that the result of this invocation is non-zero, but it should be 1 if v != 0. > index += 32; > } > return index; Yes, I misread the MSDN documentation and it appears index is undefined if there are no bits and we should rely on the return value. Omitting the cast on `v >> 32` seems fine, but the comment is a bit off since `v` can be a signed type here. ------------- PR: https://git.openjdk.java.net/jdk/pull/1747 From tschatzl at openjdk.java.net Fri Dec 11 13:11:19 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 11 Dec 2020 13:11:19 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v2] In-Reply-To: <6TSlbNpQ6opeeAOFwgy2CJvJ_WCbya8BVFlNQJAlyCs=.33d71860-c553-4211-bf02-496c7739954b@github.com> References: <0yPqXli9NVx2A5Kt8N5Y0s5MGOFWjnKc7CHiOk47s50=.3d4b5fdf-9f22-4e23-912f-4b6729dfe612@github.com> <6TSlbNpQ6opeeAOFwgy2CJvJ_WCbya8BVFlNQJAlyCs=.33d71860-c553-4211-bf02-496c7739954b@github.com> Message-ID: On Fri, 11 Dec 2020 12:34:11 GMT, Claes Redestad wrote: >> src/hotspot/share/utilities/count_trailing_zeros.hpp line 98: >> >>> 96: if (index == 0) { >>> 97: _BitScanForward(&index, (uint32_t)(v >> 32)); >>> 98: if (index > 0) { >> >> Shouldn't this check be superfluous if the code previously asserted v != 0, and we know that the lower 32 bits are zero? >> >> Also the MSDN documentation does not state that `index == 0` if no bit has been found, but the return value of the method is 0. I.e. shouldn't the implementation be something like: >> >> if (_BitScanForward(&index, (uint32_t)v) == 0) { // no bit found? If so, try the upper dword. Otherwise index already contains the result >> _BitScanForward(&index, v >> 32); // no need for the uint32_t cast. >> is well defined on unsigned longs. >> // one could assert that the result of this invocation is non-zero, but it should be 1 if v != 0. >> index += 32; >> } >> return index; > > Yes, I misread the MSDN documentation and it appears index is undefined if there are no bits and we should rely on the return value. > > Omitting the cast on `v >> 32` seems fine, but the comment is a bit off since `v` can be a signed type here. You are right about `v` possibly being anything, I did not look correctly. But then the new code does indeed need some cast here because the result of `something signed >> 32` is compiler dependent (at least until C++20). Since this code path is specific to Windows (i.e. Visual Studio), it might still be true that this is the case for all platforms (ie. even ARM64), but I'd prefer the explicit cast. ------------- PR: https://git.openjdk.java.net/jdk/pull/1747 From david.holmes at oracle.com Fri Dec 11 13:21:14 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Dec 2020 23:21:14 +1000 Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: Hi Mauro, On 11/12/2020 9:48 pm, Mauro Lacy wrote: > On Fri, 11 Dec 2020 11:33:41 GMT, Mauro Lacy wrote: >>> I also just re-checked the JDK source and it seems this code also suffers from the COMMIT-only problem: >>> >>> ./jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c >> >> I've taken a look and yes, I think you're right. The line >> ` (*env)->ReleasePrimitiveArrayCritical(env, jOut, outBufP, JNI_COMMIT);` >> >> should probably use `JNI_ABORT` if there's an error, and `0` if it's a normal cleanup. >> >> On second look, `0` looks like the obvious choice. If there's a jump due to an error, `outBufP` will be `NULL`, and the line wouldn't be executed in the first place. > > I'll send a PR for that cryptoki fix too, if you like. I'll now try to register into the issue tracker, so I can create a proper issue for it. You can't "register" for the OpenJDK JBS, you are only granted write access once you have Author status in the OpenJDK project. I will file an issue but the security-libs folk will need to decide what to do about it. With regards to an earlier comment regarding the inconsistent behaviour - yes this is only a -Xcheck:jni issue because it is only in that case that any buffer copying every occurs and so freeing actually does something. Otherwise hotspot never copies and the release mode is irrelevant with regard to freeing anything. Again I will look further into this, on Monday. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1697 > From akozlov at openjdk.java.net Fri Dec 11 13:25:14 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 11 Dec 2020 13:25:14 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v8] In-Reply-To: References: Message-ID: > Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html > > On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, PROT_NONE), the function was made aware of exec permissions. > > For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference compared with old code. > > For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not shrink (if I haven't missed anything, by the implementation and in principle). > > Tested: > * local tier1 > * jdk-submit > * codesign[2] with hardened runtime and allow-jit but without > allow-unsigned-executable-memory entitlements[3] produce a working bundle. > > (adding GC group as suggested by @dholmes-ora) > > > [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 > [2] > > codesign \ > --sign - \ > --options runtime \ > --entitlements ents.plist \ > --timestamp \ > $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib > [3] > > > > > com.apple.security.cs.allow-jit > > com.apple.security.cs.disable-library-validation > > com.apple.security.cs.allow-dyld-environment-variables > > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Update style ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/294/files - new: https://git.openjdk.java.net/jdk/pull/294/files/b3eb5b01..31fe1fb0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=06-07 Stats: 19 lines in 8 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/294/head:pull/294 PR: https://git.openjdk.java.net/jdk/pull/294 From akozlov at openjdk.java.net Fri Dec 11 13:32:59 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 11 Dec 2020 13:32:59 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v7] In-Reply-To: References: <4mw_qwllDU7qLgqcm7Z_kxyGICpv18HZ_LrbidneSw4=.891574d8-45a6-4ecd-9dc9-be2070bdc3e6@github.com> Message-ID: On Thu, 10 Dec 2020 21:16:36 GMT, Bernhard Urban-Forster wrote: >> Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision: >> >> - Fix style >> - JDK-8234930 v4: Use MAP_JIT when allocating pages for code cache on macOS >> - Revert "Separate executable_memory interface" >> >> This reverts commit 49253d8fe8963ce069f10783dcea5327079ba848. > > src/hotspot/os/bsd/os_bsd.cpp line 1937: > >> 1935: // Bsd mmap allows caller to pass an address as hint; give it a try first, >> 1936: // if kernel honors the hint then we can return immediately. >> 1937: char * addr = anon_mmap(requested_addr, bytes, false/*executable*/); > > use `!ExecMem`? Agree, fixed. I've avoided that, as formally it's for `os::` interface layer. But unlikely it's worth even a bit of readability ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From redestad at openjdk.java.net Fri Dec 11 13:35:10 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 13:35:10 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v4] In-Reply-To: References: Message-ID: > Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. > > Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. > > Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Explicit cast to unsigned ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1747/files - new: https://git.openjdk.java.net/jdk/pull/1747/files/90c0fde5..ac1174f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1747.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1747/head:pull/1747 PR: https://git.openjdk.java.net/jdk/pull/1747 From redestad at openjdk.java.net Fri Dec 11 13:35:10 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 13:35:10 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v2] In-Reply-To: References: <0yPqXli9NVx2A5Kt8N5Y0s5MGOFWjnKc7CHiOk47s50=.3d4b5fdf-9f22-4e23-912f-4b6729dfe612@github.com> <6TSlbNpQ6opeeAOFwgy2CJvJ_WCbya8BVFlNQJAlyCs=.33d71860-c553-4211-bf02-496c7739954b@github.com> Message-ID: On Fri, 11 Dec 2020 12:42:52 GMT, Thomas Schatzl wrote: >> Yes, I misread the MSDN documentation and it appears index is undefined if there are no bits and we should rely on the return value. >> >> Omitting the cast on `v >> 32` seems fine, but the comment is a bit off since `v` can be a signed type here. > > You are right about `v` possibly being anything, I did not look correctly. But then the new code does indeed need some cast here because the result of `something signed >> 32` is compiler dependent (at least until C++20). > > Since this code path is specific to Windows (i.e. Visual Studio), it might still be true that this is the case for all platforms (ie. even ARM64), but I'd prefer the explicit cast. Right, I think what I have works on Windows x64, but let's be explicit ------------- PR: https://git.openjdk.java.net/jdk/pull/1747 From tschatzl at openjdk.java.net Fri Dec 11 13:40:59 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 11 Dec 2020 13:40:59 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v4] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 13:35:10 GMT, Claes Redestad wrote: >> Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. >> >> Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. >> >> Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Explicit cast to unsigned Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1747 From akozlov at openjdk.java.net Fri Dec 11 13:42:58 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 11 Dec 2020 13:42:58 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v7] In-Reply-To: References: <4mw_qwllDU7qLgqcm7Z_kxyGICpv18HZ_LrbidneSw4=.891574d8-45a6-4ecd-9dc9-be2070bdc3e6@github.com> Message-ID: <9Y08fwmleXTIxeAUCxqYGB5zRdTciI9Dma3wlhEe4UU=.57decef8-8e68-4d1d-b5d3-92685b1def49@github.com> On Thu, 10 Dec 2020 21:17:59 GMT, Bernhard Urban-Forster wrote: >> Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision: >> >> - Fix style >> - JDK-8234930 v4: Use MAP_JIT when allocating pages for code cache on macOS >> - Revert "Separate executable_memory interface" >> >> This reverts commit 49253d8fe8963ce069f10783dcea5327079ba848. > > src/hotspot/os/linux/os_linux.cpp line 3275: > >> 3273: struct bitmask* os::Linux::_numa_membind_bitmask; >> 3274: >> 3275: bool os::pd_uncommit_memory(char* addr, size_t size, bool exec) { > > nit: I'm irritated by `bool exec` in `pd_uncommit_memory`, but `bool executable` in `pd_reserve_memory`. Choose one :-) Thanks, fixed. Too much of code shuffling. Now these should be consistent with the surroundings. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From kbarrett at openjdk.java.net Fri Dec 11 13:46:59 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 11 Dec 2020 13:46:59 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v4] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 13:35:10 GMT, Claes Redestad wrote: >> Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. >> >> Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. >> >> Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Explicit cast to unsigned This can be much simpler: #if defined(TARGET_COMPILER_gcc) inline unsigned count_trailing_zeros_32(uint32_t x) { return __builtin_ctz(x); } inline unsigned count_trailing_zeros_64(uint64_t x) { return __builtin_ctzll(x); } #elif ... ... #endif template::value), ENABLE_IF(sizeof(T) <= sizeof(uint64_t))> inline unsigned count_trailing_zeros(T x) { assert(x != 0, "precondition"); return (sizeof(x) <= sizeof(uint32_t)) ? count_trailing_zeros_32(x) : count_trailing_zeros_64(x); } } ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1747 From redestad at openjdk.java.net Fri Dec 11 13:58:09 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 13:58:09 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v5] In-Reply-To: References: Message-ID: > Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. > > Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. > > Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Simplify based on @kimbarrett review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1747/files - new: https://git.openjdk.java.net/jdk/pull/1747/files/ac1174f3..c16f9b05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=03-04 Stats: 52 lines in 1 file changed: 4 ins; 15 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/1747.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1747/head:pull/1747 PR: https://git.openjdk.java.net/jdk/pull/1747 From redestad at openjdk.java.net Fri Dec 11 14:03:09 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 14:03:09 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v6] In-Reply-To: References: Message-ID: > Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. > > Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. > > Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Simplify based on @kimbarrett review comments pt 2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1747/files - new: https://git.openjdk.java.net/jdk/pull/1747/files/c16f9b05..9b613682 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=04-05 Stats: 21 lines in 1 file changed: 11 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1747.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1747/head:pull/1747 PR: https://git.openjdk.java.net/jdk/pull/1747 From kbarrett at openjdk.java.net Fri Dec 11 14:03:10 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 11 Dec 2020 14:03:10 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v4] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 13:44:16 GMT, Kim Barrett wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Explicit cast to unsigned > > This can be much simpler: > > #if defined(TARGET_COMPILER_gcc) > > inline unsigned count_trailing_zeros_32(uint32_t x) { > return __builtin_ctz(x); > } > > inline unsigned count_trailing_zeros_64(uint64_t x) { > return __builtin_ctzll(x); > } > > #elif ... > > ... > > #endif > > template ENABLE_IF(std::is_integral::value), > ENABLE_IF(sizeof(T) <= sizeof(uint64_t))> > inline unsigned count_trailing_zeros(T x) { > assert(x != 0, "precondition"); > return (sizeof(x) <= sizeof(uint32_t)) ? > count_trailing_zeros_32(x) : > count_trailing_zeros_64(x); > } > } > This can be much simpler: > > ``` > [...] > template ENABLE_IF(std::is_integral::value), > ENABLE_IF(sizeof(T) <= sizeof(uint64_t))> > inline unsigned count_trailing_zeros(T x) { > assert(x != 0, "precondition"); > return (sizeof(x) <= sizeof(uint32_t)) ? > count_trailing_zeros_32(x) : > count_trailing_zeros_64(x); > } > } > ``` It's possible that some compiler will whine about the implicit narrowing conversion when sizeof(x) > sizeof(uint32_t). If so, a cast should silence it, i.e. `count_trailing_zeros_32(static_cast(x))`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1747 From redestad at openjdk.java.net Fri Dec 11 14:07:08 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 14:07:08 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v7] In-Reply-To: References: Message-ID: > Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. > > Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. > > Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Explicit static_cast ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1747/files - new: https://git.openjdk.java.net/jdk/pull/1747/files/9b613682..a7829d5e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1747.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1747/head:pull/1747 PR: https://git.openjdk.java.net/jdk/pull/1747 From kbarrett at openjdk.java.net Fri Dec 11 14:53:57 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 11 Dec 2020 14:53:57 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v7] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 14:07:08 GMT, Claes Redestad wrote: >> Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. >> >> Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. >> >> Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Explicit static_cast Changes requested by kbarrett (Reviewer). src/hotspot/share/utilities/count_trailing_zeros.hpp line 81: > 79: if (_BitScanForward(&index, (uint32_t)x) == 0) { > 80: // no bit found? If so, try the upper dword. Otherwise index already contains the result > 81: _BitScanForward(&index, x >> 32); If the first BSF needs a cast then this one probably does too. The shift result is still uint64_t. src/hotspot/share/utilities/count_trailing_zeros.hpp line 79: > 77: _BitScanForward64(&index, x); > 78: #else > 79: if (_BitScanForward(&index, (uint32_t)x) == 0) { Is the cast needed? That is, does the implicit conversion from uint64_t to (32bit) unsigned long not work? If it's needed, please use static_cast. src/hotspot/share/utilities/count_trailing_zeros.hpp line 82: > 80: // no bit found? If so, try the upper dword. Otherwise index already contains the result > 81: _BitScanForward(&index, x >> 32); > 82: assert(index > 0, "invariant since x != 0"); I'm not sure this assert really does anything useful. If both of the BSFs failed because the value is zero (which shouldn't happen because we checked for that), then the value of index is undefined. ------------- PR: https://git.openjdk.java.net/jdk/pull/1747 From dawid.weiss at gmail.com Fri Dec 11 14:56:36 2020 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Fri, 11 Dec 2020 15:56:36 +0100 Subject: Impossible (?) code path resulting in IllegalStateException on jdk14+ In-Reply-To: References: Message-ID: 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 kbarrett at openjdk.java.net Fri Dec 11 14:57:58 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 11 Dec 2020 14:57:58 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v7] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 14:07:08 GMT, Claes Redestad wrote: >> Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. >> >> Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. >> >> Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Explicit static_cast Changes requested by kbarrett (Reviewer). src/hotspot/share/utilities/count_trailing_zeros.hpp line 65: > 63: #pragma intrinsic(_BitScanForward64) > 64: #else > 65: #pragma intrinsic(_BitScanForward) _BitScanForward needs to be "declared" intrinsic unconditionally, since it's now also used in _LP64 mode. ------------- PR: https://git.openjdk.java.net/jdk/pull/1747 From redestad at openjdk.java.net Fri Dec 11 15:02:09 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 15:02:09 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v8] In-Reply-To: References: Message-ID: > Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. > > Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. > > Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Windows impl. cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1747/files - new: https://git.openjdk.java.net/jdk/pull/1747/files/a7829d5e..f65a7f5e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=06-07 Stats: 5 lines in 1 file changed: 1 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1747.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1747/head:pull/1747 PR: https://git.openjdk.java.net/jdk/pull/1747 From coleenp at openjdk.java.net Fri Dec 11 15:03:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 15:03:57 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 17:58:41 GMT, Gerard Ziemski wrote: >> Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. >> >> Tested with tier1-3 with product and fastdebug builds. Built with optimized. >> >> This is for JDK 17. > > src/hotspot/share/utilities/debug.cpp line 250: > >> 248: // message to be printed in one short line to stderr (see TEST_VM_ASSERT_MSG) and >> 249: // cannot be tweaked to accept our normal assert message. >> 250: jio_vsnprintf(_detail_msg, sizeof(_detail_msg), detail_fmt, detail_args); > > Does `'static char _detail_msg[1024];` need to be outside of `print_error_for_unit_test()` > > Why not put it inside the `print_error_for_unit_test()` just before `jio_vsnprintf ` ? Ok, I fixed that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From coleenp at openjdk.java.net Fri Dec 11 15:03:59 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 15:03:59 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT In-Reply-To: <6qGvPa71-OuM2c92ac99gBEjtYdJimHxwf4s_YlUgn0=.5d24bf67-1cc4-44e4-be1f-3fa435e86f9a@github.com> References: <6qGvPa71-OuM2c92ac99gBEjtYdJimHxwf4s_YlUgn0=.5d24bf67-1cc4-44e4-be1f-3fa435e86f9a@github.com> Message-ID: On Thu, 10 Dec 2020 22:45:05 GMT, Ioi Lam wrote: >> Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. >> >> Tested with tier1-3 with product and fastdebug builds. Built with optimized. >> >> This is for JDK 17. > > src/hotspot/share/utilities/vmError.cpp line 1818: > >> 1816: fatal("Crashing with number %d", how); >> 1817: } >> 1818: tty->print_cr("VMError::controlled_crash: survived intentional crash. Did you suppress the assert?"); > > The message should be changed: `VMError::controlled_crash` -> `controlled_crash` Ok, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From kim.barrett at oracle.com Fri Dec 11 15:04:45 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Dec 2020 10:04:45 -0500 Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v7] In-Reply-To: References: Message-ID: > On Dec 11, 2020, at 9:53 AM, Kim Barrett wrote: > src/hotspot/share/utilities/count_trailing_zeros.hpp line 82: > >> 80: // no bit found? If so, try the upper dword. Otherwise index already contains the result >> 81: _BitScanForward(&index, x >> 32); >> 82: assert(index > 0, "invariant since x != 0"); > > I'm not sure this assert really does anything useful. If both of the BSFs failed because the value is zero (which shouldn't happen because we checked for that), then the value of index is undefined. Actually, it?s worse than that. The assert is just wrong. index will be zero if bit zero of the high half is set. But it looks like you?ve already removed the assert. From coleenp at openjdk.java.net Fri Dec 11 15:11:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 15:11:57 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 07:18:06 GMT, Thomas Stuefe wrote: >> Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. >> >> Tested with tier1-3 with product and fastdebug builds. Built with optimized. >> >> This is for JDK 17. > > src/hotspot/share/utilities/vmError.cpp line 1800: > >> 1798: case 2: guarantee(how == 0, "test guarantee"); break; >> 1799: >> 1800: // The other cases are unused. > > I like that you cut down on the cases. Most of them were obsolete or not working correctly. > > How about compacting the cases? And maybe use a real enum. But this could also be done in a separate RFE. I thought it was kind of strange but then I didn't think it was worth the time to change it. The command line processing doesn't have a way to pass enums through -XX:ErrorHandlerTest=plainSEGV or something like that. So in the end I didn't think it was something bad enough to change. Answers above: On my machine, the additional gtests add about 3 seconds to the run time where the gtests on the debug build take about a minute. Since the gtests are thought to be a more efficient and direct testing mechanism, I don't think anyone's thought about ways to reduce the testing to account for performance. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From github.com+11656534+maurolacy at openjdk.java.net Fri Dec 11 15:12:54 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Fri, 11 Dec 2020 15:12:54 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: On Fri, 11 Dec 2020 12:07:44 GMT, Mauro Lacy wrote: >> I'll send a PR for that cryptoki fix too, if you like. I'll now try to register into the issue tracker, so I can create a proper issue for it. > > Hmmm, crypto stuff. I wonder if... ?? > You can't "register" for the OpenJDK JBS, you are only granted write > access once you have Author status in the OpenJDK project. I will file > an issue but the security-libs folk will need to decide what to do about it. OK. Please let me know the issue #, so I can keep an eye on it. > > With regards to an earlier comment regarding the inconsistent behaviour > - yes this is only a -Xcheck:jni issue because it is only in that case > that any buffer copying every occurs and so freeing actually does > something. Otherwise hotspot never copies and the release mode is > irrelevant with regard to freeing anything. Fair enough. So, as you said earlier, this is in the end a matter of interpretation of what constitutes correct usage. > > Again I will look further into this, on Monday. Have a nice weekend. Mauro > > Cheers, > David ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From github.com+11656534+maurolacy at openjdk.java.net Fri Dec 11 15:26:55 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Fri, 11 Dec 2020 15:26:55 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: <6VZMqLpeMULXdYE_25YbmRYB0d6qmzMVJ4RVLpKMVTg=.1d893206-8004-4f57-aa5e-83fbe4f1f16a@github.com> On Fri, 11 Dec 2020 15:10:37 GMT, Mauro Lacy wrote: >> Hmmm, crypto stuff. I wonder if... ?? > >> You can't "register" for the OpenJDK JBS, you are only granted write >> access once you have Author status in the OpenJDK project. I will file >> an issue but the security-libs folk will need to decide what to do about it. > > OK. Please let me know the issue #, so I can keep an eye on it. > >> >> With regards to an earlier comment regarding the inconsistent behaviour >> - yes this is only a -Xcheck:jni issue because it is only in that case >> that any buffer copying every occurs and so freeing actually does >> something. Otherwise hotspot never copies and the release mode is >> irrelevant with regard to freeing anything. > > Fair enough. So, as you said earlier, this is in the end a matter of interpretation of what constitutes correct usage. > >> >> Again I will look further into this, on Monday. > > Have a nice weekend. > Mauro > >> >> Cheers, >> David One last comment: if `JNI_COMMIT` implies copying and freeing the buffer when it is a copy, then it's no different than mode `0`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From redestad at openjdk.java.net Fri Dec 11 15:31:09 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Dec 2020 15:31:09 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v9] In-Reply-To: References: Message-ID: > Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. > > Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. > > Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Explicit, static_cast to 32-bit unsigned ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1747/files - new: https://git.openjdk.java.net/jdk/pull/1747/files/f65a7f5e..408a64f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1747&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1747.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1747/head:pull/1747 PR: https://git.openjdk.java.net/jdk/pull/1747 From tschatzl at openjdk.java.net Fri Dec 11 15:43:58 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 11 Dec 2020 15:43:58 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v9] In-Reply-To: References: Message-ID: <6uDROfAGxyaWgSWpYKTd_6NoHFYOkSsqrpfIRenjWm8=.1931c7ee-00f5-4afb-9fc2-4582fcdcbd2f@github.com> On Fri, 11 Dec 2020 15:31:09 GMT, Claes Redestad wrote: >> Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. >> >> Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. >> >> Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Explicit, static_cast to 32-bit unsigned These casts are actually not needed - (unsigned) long on Windows is always 32 bits so there is already an implicit cast that is sufficient in both cases. I think @kimbarrett correctly identified them as such. ------------- PR: https://git.openjdk.java.net/jdk/pull/1747 From mdoerr at openjdk.java.net Fri Dec 11 15:59:07 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Fri, 11 Dec 2020 15:59:07 GMT Subject: RFR: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack [v2] In-Reply-To: References: Message-ID: <2m9ZJRPouKFwVn0C_q60Of6Olw_G4DMrsXJndE_skmI=.c3e9bb12-9fb4-48de-af83-3a6df42d2a78@github.com> > Method handle logging is broken in fastdebug builds. Problem is that os::current_frame() doesn't return the right frame in fastdebug builds. > Unfortunately, fixing os::current_frame() would break NMT stack traces (runtime/NMT/CheckForProperDetailStackTrace.java). Martin Doerr has updated the pull request incrementally with one additional commit since the last revision: Use Richard's proposal to fix NMT/CheckForProperDetailStackTrace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1724/files - new: https://git.openjdk.java.net/jdk/pull/1724/files/125faee6..aef98cb2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1724&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1724&range=00-01 Stats: 12 lines in 4 files changed: 8 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1724.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1724/head:pull/1724 PR: https://git.openjdk.java.net/jdk/pull/1724 From coleenp at openjdk.java.net Fri Dec 11 16:01:12 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 16:01:12 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v2] In-Reply-To: References: Message-ID: > Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. > > Tested with tier1-3 with product and fastdebug builds. Built with optimized. > > This is for JDK 17. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fixed va_copy problem, and added changes from pull request. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1723/files - new: https://git.openjdk.java.net/jdk/pull/1723/files/fa795402..e3b6a555 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1723&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1723&range=00-01 Stats: 21 lines in 5 files changed: 5 ins; 9 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1723.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1723/head:pull/1723 PR: https://git.openjdk.java.net/jdk/pull/1723 From coleenp at openjdk.java.net Fri Dec 11 16:01:14 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 16:01:14 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v2] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 08:24:27 GMT, Thomas Stuefe wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed va_copy problem, and added changes from pull request. > > src/hotspot/share/utilities/debug.cpp line 243: > >> 241: static char _detail_msg[1024]; >> 242: >> 243: static void print_error_for_unit_test(const char* message, const char* detail_fmt, va_list detail_args) { > > Trying to understand why you changed this code (beside factoring it out). We have: > > - report_vm_out_of_memory -> message=NULL, detail set > - report_and_die from real crash -> message=NULL, detail="" > - report_fatal -> message="fatal error", detail set > - report_vm_error (assert, guarantee) -> message="assert (bla) failed", detail is set > > so sometimes message is NULL, sometimes details are empty. What a mess :( Since you do gtests for all these cases now, you need to print the assert message correctly for them. You use _detail_msg as scratch buffer, since its already there. Later we print the detail message again into it. But I think that is fine. > > I have a patch on the back burner somewhere simplifying these functions. Maybe we can improve matters. Then this function becomes easier too. I changed it to factor it out. I think I got the combinations. > src/hotspot/share/utilities/debug.cpp line 246: > >> 244: #ifdef ASSERT >> 245: if (ExecutingUnitTests) { >> 246: if (detail_fmt != NULL) { > > You miss va_copy for detail_args here. va_list detail_args_copy; va_copy(detail_args_copy, detail_args); jio_vsnprintf(_detail_msg, sizeof(_detail_msg), detail_fmt, detail_args_copy); I fixed this but I didn't see the message garbled (?) You're right in your comment that we are testing the assert message through print_error_for_unit_test. I think the original motivation was to move the test that checked for a specific message out of the error handling tests, and these other ones just came for the ride. > src/hotspot/share/utilities/vmError.hpp line 187: > >> 185: >> 186: // Test vmassert(), fatal(), guarantee(), etc. >> 187: DEBUG_ONLY(static void test_error_handler();) > > May I suggest: > - remove the almost empty `test_error_handler` completely > - remove the "case 0" in `controlled_crash` > - leave `controlled_crash` public > - In create_vm, doing this instead: > if (ErrorHandlerTest != 0) { > VMError::controlled_crash(ErrorHandlerTest); > } > > This would have two advantages, it would be clearer and leave us with a "controlled_crash" API to use in quick tests (I do that sometimes). > > Both are not hard reasons and a matter of taste, so feel free to ignore my proposal. Yes, I like this suggestion. I'll do this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From coleenp at openjdk.java.net Fri Dec 11 16:01:15 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 16:01:15 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v2] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 15:09:21 GMT, Coleen Phillimore wrote: >> src/hotspot/share/utilities/vmError.cpp line 1800: >> >>> 1798: case 2: guarantee(how == 0, "test guarantee"); break; >>> 1799: >>> 1800: // The other cases are unused. >> >> I like that you cut down on the cases. Most of them were obsolete or not working correctly. >> >> How about compacting the cases? And maybe use a real enum. But this could also be done in a separate RFE. > > I thought it was kind of strange but then I didn't think it was worth the time to change it. The command line processing doesn't have a way to pass enums through -XX:ErrorHandlerTest=plainSEGV or something like that. So in the end I didn't think it was something bad enough to change. > > Answers above: On my machine, the additional gtests add about 3 seconds to the run time where the gtests on the debug build take about a minute. Since the gtests are thought to be a more efficient and direct testing mechanism, I don't think anyone's thought about ways to reduce the testing to account for performance. Answered in conversation. I couldn't really motivate the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From kim.barrett at oracle.com Fri Dec 11 16:01:53 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Dec 2020 11:01:53 -0500 Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v9] In-Reply-To: <6uDROfAGxyaWgSWpYKTd_6NoHFYOkSsqrpfIRenjWm8=.1931c7ee-00f5-4afb-9fc2-4582fcdcbd2f@github.com> References: <6uDROfAGxyaWgSWpYKTd_6NoHFYOkSsqrpfIRenjWm8=.1931c7ee-00f5-4afb-9fc2-4582fcdcbd2f@github.com> Message-ID: > On Dec 11, 2020, at 10:43 AM, Thomas Schatzl wrote: > > On Fri, 11 Dec 2020 15:31:09 GMT, Claes Redestad wrote: > >>> Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. >>> >>> Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. >>> >>> Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. >> >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Explicit, static_cast to 32-bit unsigned > > These casts are actually not needed - (unsigned) long on Windows is always 32 bits so there is already an implicit cast that is sufficient in both cases. I think @kimbarrett correctly identified them as such. That should be true. However (1) These are intrinsics; I don?t know if the rules for them differ from normal functions. (2) These are narrowing conversions, which a compiler *might* warn about if left implicit, possibly depending on compiler settings. (-Wconversion anyone?) From coleenp at openjdk.java.net Fri Dec 11 16:17:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 16:17:58 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v2] In-Reply-To: References: Message-ID: <12u_D8ESMulPst0VcqkZ5OGs5_TXPTg7_vgxvGiXpzM=.cfca021f-0be8-4f86-a449-3d16be6994a5@github.com> On Fri, 11 Dec 2020 08:29:11 GMT, Thomas Stuefe wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed va_copy problem, and added changes from pull request. > > Hi Coleen, > > this is a good cleanup, I like this a lot. > > About moving ErrorHandlerTest.java to gtest: this is a slick way of doing these tests. However, some things to consider: > - Strictly speaking we now do not test the real error handler output but the artificial output `ExecutingUnitTests` gives us. The real printing code is now untested. This may have bitten you right here, since I believe in `print_error_for_unit_test` you miss a `va_copy` which should have messed up detail_args and garbled the real output later on. > - moving these tests out of jtreg means we give up flexibility (excluding them or moving them to another tier). Do they impact the gtest run time noticeably? > > There are also remaining problems with gtest death tests, which I hope we can fix at some point. I don't hold my breath though since we decided to not own the gtest code and cannot make modifications: > - Death tests are easily confused by stderr output. See: https://bugs.openjdk.java.net/browse/JDK-8257229. So whenever we have unconditional stderr output in the VM (eg if some large page alloc failed) these death tests fail too. > - Death tests don't tell you the assert message which happened if it did not match their expectations. Thats plain annoying. See https://bugs.openjdk.java.net/browse/JDK-8257227. I posted a comment on https://bugs.openjdk.java.net/browse/JDK-8257227. I don't know how to deal with https://bugs.openjdk.java.net/browse/JDK-8257229. These tests would fail because of that also. The assert message tests are nice and imo better than having crashing jtreg tests, but they have these limitations. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From iklam at openjdk.java.net Fri Dec 11 17:27:03 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 17:27:03 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v2] In-Reply-To: <12u_D8ESMulPst0VcqkZ5OGs5_TXPTg7_vgxvGiXpzM=.cfca021f-0be8-4f86-a449-3d16be6994a5@github.com> References: <12u_D8ESMulPst0VcqkZ5OGs5_TXPTg7_vgxvGiXpzM=.cfca021f-0be8-4f86-a449-3d16be6994a5@github.com> Message-ID: <1asDJgbkNnlIpon9H_zbqY9G67BC8WmU5h8iUKbVYBY=.c40af654-5943-462f-97e0-baf895e0e6ac@github.com> On Fri, 11 Dec 2020 16:15:02 GMT, Coleen Phillimore wrote: > I posted a comment on https://bugs.openjdk.java.net/browse/JDK-8257227. I don't know how to deal with https://bugs.openjdk.java.net/browse/JDK-8257229. These tests would fail because of that also. The assert message tests are nice and imo better than having crashing jtreg tests, but they have these limitations. [JDK-8257229](https://bugs.openjdk.java.net/browse/JDK-8257229) is being fixed in https://github.com/openjdk/jdk/pull/1748 ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From stuefe at openjdk.java.net Fri Dec 11 17:34:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 11 Dec 2020 17:34:00 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v2] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 15:23:00 GMT, Coleen Phillimore wrote: >> src/hotspot/share/utilities/debug.cpp line 246: >> >>> 244: #ifdef ASSERT >>> 245: if (ExecutingUnitTests) { >>> 246: if (detail_fmt != NULL) { >> >> You miss va_copy for detail_args here. > > va_list detail_args_copy; > va_copy(detail_args_copy, detail_args); > jio_vsnprintf(_detail_msg, sizeof(_detail_msg), detail_fmt, detail_args_copy); > > I fixed this but I didn't see the message garbled (?) > > You're right in your comment that we are testing the assert message through print_error_for_unit_test. I think the original motivation was to move the test that checked for a specific message out of the error handling tests, and these other ones just came for the ride. Thats fine, I like this. Its a good simplification. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From stuefe at openjdk.java.net Fri Dec 11 17:33:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 11 Dec 2020 17:33:59 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v2] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 16:01:12 GMT, Coleen Phillimore wrote: >> Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. >> >> Tested with tier1-3 with product and fastdebug builds. Built with optimized. >> >> This is for JDK 17. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fixed va_copy problem, and added changes from pull request. Hi Coleen, sorry for forgetting to mention va_end too. That's still missing, otherwise we leak the copied va_list. Otherwise this looks nice, this is a good cleanup. Thanks, Thomas src/hotspot/share/utilities/debug.cpp line 264: > 262: } > 263: } > 264: ::fflush(stderr); You miss now a va_end(detail_args_copy) here to got with the va_copy. ------------- Changes requested by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1723 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 coleenp at openjdk.java.net Fri Dec 11 18:21:13 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 18:21:13 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v3] In-Reply-To: References: Message-ID: > Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. > > Tested with tier1-3 with product and fastdebug builds. Built with optimized. > > This is for JDK 17. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: add missing va_end() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1723/files - new: https://git.openjdk.java.net/jdk/pull/1723/files/e3b6a555..6405181b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1723&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1723&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1723.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1723/head:pull/1723 PR: https://git.openjdk.java.net/jdk/pull/1723 From coleenp at openjdk.java.net Fri Dec 11 18:21:14 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 18:21:14 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v3] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 07:27:28 GMT, Thomas Stuefe wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> add missing va_end() > > test/hotspot/gtest/unittest.hpp line 138: > >> 136: ASSERT_EXIT(child_ ## category ## _ ## name ## _(), \ >> 137: ::testing::ExitedWithCode(1), \ >> 138: "^assert failed: .*" msg); \ > > Good! So if I take out '^' here, I've also fixed https://bugs.openjdk.java.net/browse/JDK-8257229 ? I had a version without ^. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From coleenp at openjdk.java.net Fri Dec 11 18:21:15 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 18:21:15 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v2] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 17:28:07 GMT, Thomas Stuefe wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed va_copy problem, and added changes from pull request. > > src/hotspot/share/utilities/debug.cpp line 264: > >> 262: } >> 263: } >> 264: ::fflush(stderr); > > You miss now a va_end(detail_args_copy) here to got with the va_copy. Oh yeah. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From stuefe at openjdk.java.net Fri Dec 11 18:31:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 11 Dec 2020 18:31:56 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v3] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 18:21:13 GMT, Coleen Phillimore wrote: >> Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. >> >> Tested with tier1-3 with product and fastdebug builds. Built with optimized. >> >> This is for JDK 17. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > add missing va_end() Thanks, looks good now. ..Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1723 From kvn at openjdk.java.net Fri Dec 11 18:32:57 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 11 Dec 2020 18:32:57 GMT Subject: RFR: 8258074: Move some flags related to compiler to compiler_globals.hpp [v2] In-Reply-To: <9nBHyQNqGlItycVc3uY9HXZmq3nw_1bzXmz95c9mq6w=.9b5c24cb-7ec0-4b20-939c-086245d39879@github.com> References: <9nBHyQNqGlItycVc3uY9HXZmq3nw_1bzXmz95c9mq6w=.9b5c24cb-7ec0-4b20-939c-086245d39879@github.com> Message-ID: <5oH23oAJR4obLniV9p4FSrrECuog6TCKHR6EQ0sX_5Y=.e5f92055-1845-411e-bebc-18961aac051b@github.com> On Fri, 11 Dec 2020 07:22:19 GMT, Ioi Lam wrote: >> Many flags in globals.hpp are related to the compiler, and are mostly used only by the compiler source files. These flags should be moved to compiler_globals.hpp >> >> Examples: >> >> - CompileCommandFile >> - Tier2CompileThreshold >> - HugeMethodLimit >> >> This speeds up HotSpot build time, and improves modularity. >> >> This RFE is the first step -- it moves a few dozen flags that are straight-forward to move. Other flags may be moved by follow-up RFEs. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed gtest Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1746 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 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 minqi at openjdk.java.net Fri Dec 11 20:11:09 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 11 Dec 2020 20:11:09 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" Message-ID: Hi, Please review (This is redo for https://github.com/openjdk/jdk/pull/1657) 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 spaces. To do so, we need release the whole first then do the reserve again on the split, 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, go to other way, but do not do the 'real' split for the whole reserved space, keep the whole region reserved and released as a whole. Also fixed issues that when loading shared archive failed, bitmap region should be unmapped or it will cause mismatch in reserved/committed size calculation for NMT. Fixed reserved region name for adding committed region for NMT, it should use the reserved region name not "Unknown" the default. A test case added for testing the failed case which is caused by mismatch of class path. Tests:tier1-5,tier7 ------------- Commit messages: - 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" Changes: https://git.openjdk.java.net/jdk/pull/1750/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1750&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255917 Stats: 190 lines in 8 files changed: 143 ins; 10 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/1750.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1750/head:pull/1750 PR: https://git.openjdk.java.net/jdk/pull/1750 From iklam at openjdk.java.net Fri Dec 11 20:11:57 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 20:11:57 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v3] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 18:14:38 GMT, Coleen Phillimore wrote: >> test/hotspot/gtest/unittest.hpp line 138: >> >>> 136: ASSERT_EXIT(child_ ## category ## _ ## name ## _(), \ >>> 137: ::testing::ExitedWithCode(1), \ >>> 138: "^assert failed: .*" msg); \ >> >> Good! > > So if I take out '^' here, I've also fixed https://bugs.openjdk.java.net/browse/JDK-8257229 ? I had a version without ^. I think it's better to fix JDK-8257229 separately, so it's easier to track the issues. Adding `.*` here affects all tests, and it might make the match more liberal than necessary. E.g., if we have `msg = "end of the world"`, the regexp would inadvertently match assert failed: some unrelated assert Whew, we avoided the end of the world It would be better to add the .* in a specific test like TEST_VM_ASSERT_MSG(vmErrorTest, assert1, ".*assert.str == NULL. failed: expected null") { ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From iklam at openjdk.java.net Fri Dec 11 20:24:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 20:24:56 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v3] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 20:09:38 GMT, Ioi Lam wrote: >> So if I take out '^' here, I've also fixed https://bugs.openjdk.java.net/browse/JDK-8257229 ? I had a version without ^. > > I think it's better to fix JDK-8257229 separately, so it's easier to track the issues. > > Adding `.*` here affects all tests, and it might make the match more liberal than necessary. E.g., if we have `msg = "end of the world"`, the regexp would inadvertently match > > assert failed: some unrelated assert > Whew, we avoided the end of the world > > It would be better to add the .* in a specific test like > > TEST_VM_ASSERT_MSG(vmErrorTest, assert1, ".*assert.str == NULL. failed: expected null") { A better example for not adding the `.*` : `TEST_VM_ASSERT_MSG(...., "a == true")` would incorrectly match `assert failed: !a == true` ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From gkorland at gmail.com Fri Dec 11 20:49:17 2020 From: gkorland at gmail.com (Guy Korland) Date: Fri, 11 Dec 2020 22:49:17 +0200 Subject: Embedded JDK how to replace the default allocator Message-ID: Hi, I'm sorry if that is not the right mailing list for such questions, please point me to the right one if it's not. We're embedding the OpenJDK in a C application, we already managed to make it work and run Java bytecode, but we are still missing one last piece, we need a way to replace the default memory allocator to use our allocator. Is there a way to do it? Thanks, Guy Korland From coleenp at openjdk.java.net Fri Dec 11 20:50:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 20:50:01 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v3] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 20:22:15 GMT, Ioi Lam wrote: >> I think it's better to fix JDK-8257229 separately, so it's easier to track the issues. >> >> Adding `.*` here affects all tests, and it might make the match more liberal than necessary. E.g., if we have `msg = "end of the world"`, the regexp would inadvertently match >> >> assert failed: some unrelated assert >> Whew, we avoided the end of the world >> >> It would be better to add the .* in a specific test like >> >> TEST_VM_ASSERT_MSG(vmErrorTest, assert1, ".*assert.str == NULL. failed: expected null") { > > A better example for not adding the `.*` : `TEST_VM_ASSERT_MSG(...., "a == true")` would incorrectly match `assert failed: !a == true` I reviewed your change. There are 19 pre-existing tests that only want to test the message, which seems legitimate. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From coleenp at openjdk.java.net Fri Dec 11 21:26:14 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 21:26:14 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v4] In-Reply-To: References: Message-ID: > Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. > > Tested with tier1-3 with product and fastdebug builds. Built with optimized. > > This is for JDK 17. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Removed the ".*" in unittest.hpp and moved to the tests instead. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1723/files - new: https://git.openjdk.java.net/jdk/pull/1723/files/6405181b..ca06a07e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1723&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1723&range=02-03 Stats: 23 lines in 9 files changed: 4 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/1723.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1723/head:pull/1723 PR: https://git.openjdk.java.net/jdk/pull/1723 From coleenp at openjdk.java.net Fri Dec 11 21:26:14 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 11 Dec 2020 21:26:14 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v4] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 20:47:15 GMT, Coleen Phillimore wrote: >> A better example for not adding the `.*` : `TEST_VM_ASSERT_MSG(...., "a == true")` would incorrectly match `assert failed: !a == true` > > I reviewed your change. There are 19 pre-existing tests that only want to test the message, which seems legitimate. I fixed he other tests with a combination of adding the assert or adding a ".*" in front of the expected message. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From iklam at openjdk.java.net Fri Dec 11 22:21:56 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 22:21:56 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT [v4] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 21:26:14 GMT, Coleen Phillimore wrote: >> Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. >> >> Tested with tier1-3 with product and fastdebug builds. Built with optimized. >> >> This is for JDK 17. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Removed the ".*" in unittest.hpp and moved to the tests instead. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From iklam at openjdk.java.net Fri Dec 11 22:40:03 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Dec 2020 22:40:03 GMT Subject: RFR: 8258075: Use auto variable declarations for enum iteration Message-ID: The pattern used in https://github.com/openjdk/jdk/pull/1707 for (vmIntrinsicID index : EnumRange{}) { nt[as_int(index)] = string; } can be further simplified to the following without loss of readability, since the type of `index` would obviously be the type enclosed by `EnumRange<>` for (auto index : EnumRange{}) { nt[as_int(index)] = string; } (as suggested by John Rose) ------------- Commit messages: - 8258075: Use auto variable declarations for enum iteration Changes: https://git.openjdk.java.net/jdk/pull/1751/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1751&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258075 Stats: 16 lines in 6 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1751.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1751/head:pull/1751 PR: https://git.openjdk.java.net/jdk/pull/1751 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 jrose at openjdk.java.net Fri Dec 11 23:15:56 2020 From: jrose at openjdk.java.net (John R Rose) Date: Fri, 11 Dec 2020 23:15:56 GMT Subject: RFR: 8258075: Use auto variable declarations for enum iteration In-Reply-To: References: Message-ID: <-HGnAfYGfngDuZ2XAxGHf_YZwcizZLD50sl_ifjRdds=.67bb8e43-be9a-4e7c-954d-57be3d7a2019@github.com> On Fri, 11 Dec 2020 22:33:33 GMT, Ioi Lam wrote: > The pattern used in https://github.com/openjdk/jdk/pull/1707 > > for (vmIntrinsicID index : EnumRange{}) { > nt[as_int(index)] = string; > } > > can be further simplified to the following without loss of readability, since the type of `index` would obviously be the type enclosed by `EnumRange<>` > > for (auto index : EnumRange{}) { > nt[as_int(index)] = string; > } > > (as suggested by John Rose) Marked as reviewed by jrose (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1751 From ccheung at openjdk.java.net Sat Dec 12 00:04:55 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Sat, 12 Dec 2020 00:04:55 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" In-Reply-To: References: Message-ID: <7sO1P9J6e2XJAat1sae9PVLGLzvV7z5xKlEdmwSKwOo=.af9ee029-3d40-4639-b9a6-de024d43bdb5@github.com> On Fri, 11 Dec 2020 20:06:34 GMT, Yumin Qi wrote: > Hi, Please review > (This is redo for https://github.com/openjdk/jdk/pull/1657) > 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 spaces. To do so, we need release the whole first then do the reserve again on the split, 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, go to other way, but do not do the 'real' split for the whole reserved space, keep the whole region reserved and released as a whole. > Also fixed issues that when loading shared archive failed, bitmap region should be unmapped or it will cause mismatch in reserved/committed size calculation for NMT. > Fixed reserved region name for adding committed region for NMT, it should use the reserved region name not "Unknown" the default. > A test case added for testing the failed case which is caused by mismatch of class path. > > Tests:tier1-5,tier7 test/hotspot/jtreg/runtime/cds/appcds/MismatchedPathTriggerMemoryRelease.java line 31: > 29: * @library /test/lib > 30: * @compile test-classes/Hello.java > 31: * @run main/timeout=240 MismatchedPathTriggerMemoryRelease Does this test requires more than the default timeout (120s) to run? ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From ccheung at openjdk.java.net Sat Dec 12 00:07:54 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Sat, 12 Dec 2020 00:07:54 GMT Subject: RFR: 8258075: Use auto variable declarations for enum iteration In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 22:33:33 GMT, Ioi Lam wrote: > The pattern used in https://github.com/openjdk/jdk/pull/1707 > > for (vmIntrinsicID index : EnumRange{}) { > nt[as_int(index)] = string; > } > > can be further simplified to the following without loss of readability, since the type of `index` would obviously be the type enclosed by `EnumRange<>` > > for (auto index : EnumRange{}) { > nt[as_int(index)] = string; > } > > (as suggested by John Rose) Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1751 From minqi at openjdk.java.net Sat Dec 12 00:21:57 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Sat, 12 Dec 2020 00:21:57 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" In-Reply-To: <7sO1P9J6e2XJAat1sae9PVLGLzvV7z5xKlEdmwSKwOo=.af9ee029-3d40-4639-b9a6-de024d43bdb5@github.com> References: <7sO1P9J6e2XJAat1sae9PVLGLzvV7z5xKlEdmwSKwOo=.af9ee029-3d40-4639-b9a6-de024d43bdb5@github.com> Message-ID: <8mB4jKLetKmpls8oBjt2wa81wHUFKxfRG5vIWmiQ-64=.9cb841ff-4b02-4932-a74a-6af5614664f2@github.com> On Sat, 12 Dec 2020 00:02:31 GMT, Calvin Cheung wrote: > Does this test requires more than the default timeout (120s) to run? No, I will fix it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From minqi at openjdk.java.net Sat Dec 12 00:28:12 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Sat, 12 Dec 2020 00:28:12 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v2] In-Reply-To: References: Message-ID: > Hi, Please review > (This is redo for https://github.com/openjdk/jdk/pull/1657) > 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 spaces. To do so, we need release the whole first then do the reserve again on the split, 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, go to other way, but do not do the 'real' split for the whole reserved space, keep the whole region reserved and released as a whole. > Also fixed issues that when loading shared archive failed, bitmap region should be unmapped or it will cause mismatch in reserved/committed size calculation for NMT. > Fixed reserved region name for adding committed region for NMT, it should use the reserved region name not "Unknown" the default. > A test case added for testing the failed case which is caused by mismatch of class path. > > Tests:tier1-5,tier7 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Use default timeout number (120) for the test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1750/files - new: https://git.openjdk.java.net/jdk/pull/1750/files/905dd80b..e5323f51 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1750&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1750&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1750.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1750/head:pull/1750 PR: https://git.openjdk.java.net/jdk/pull/1750 From ccheung at openjdk.java.net Sat Dec 12 00:48:56 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Sat, 12 Dec 2020 00:48:56 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v2] In-Reply-To: References: Message-ID: <5psc_1iEpzMF13HEci0Om_qEUjlijEWw0rAwymzWl3Q=.54975782-5d91-4bf6-882b-b0664fd40a25@github.com> On Sat, 12 Dec 2020 00:28:12 GMT, Yumin Qi wrote: >> Hi, Please review >> (This is redo for https://github.com/openjdk/jdk/pull/1657) >> 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 spaces. To do so, we need release the whole first then do the reserve again on the split, 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, go to other way, but do not do the 'real' split for the whole reserved space, keep the whole region reserved and released as a whole. >> Also fixed issues that when loading shared archive failed, bitmap region should be unmapped or it will cause mismatch in reserved/committed size calculation for NMT. >> Fixed reserved region name for adding committed region for NMT, it should use the reserved region name not "Unknown" the default. >> A test case added for testing the failed case which is caused by mismatch of class path. >> >> Tests:tier1-5,tier7 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Use default timeout number (120) for the test One more comment regarding the test. Up to you if you want to make the change. test/hotspot/jtreg/runtime/cds/appcds/MismatchedPathTriggerMemoryRelease.java line 61: > 59: "-XX:NativeMemoryTracking=detail", > 60: "-XX:SharedBaseAddress=0", > 61: "Hello"); Instead of `TestCommon.exec`, you could use `TestCommon.execAuto` and no need to pass the `-Xshare:auto` argument. ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From stuefe at openjdk.java.net Sat Dec 12 09:31:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 12 Dec 2020 09:31:59 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v8] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 13:25:14 GMT, Anton Kozlov wrote: >> Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html >> >> On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, PROT_NONE), the function was made aware of exec permissions. >> >> For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference compared with old code. >> >> For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not shrink (if I haven't missed anything, by the implementation and in principle). >> >> Tested: >> * local tier1 >> * jdk-submit >> * codesign[2] with hardened runtime and allow-jit but without >> allow-unsigned-executable-memory entitlements[3] produce a working bundle. >> >> (adding GC group as suggested by @dholmes-ora) >> >> >> [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 >> [2] >> >> codesign \ >> --sign - \ >> --options runtime \ >> --entitlements ents.plist \ >> --timestamp \ >> $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib >> [3] >> >> >> >> >> com.apple.security.cs.allow-jit >> >> com.apple.security.cs.disable-library-validation >> >> com.apple.security.cs.allow-dyld-environment-variables >> >> >> > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Update style Hi Anton, 1) can you please make the executable parameter on os::uncommit() default false? Lets minimize the impact for the vast majority of callers which do not need protected memory. The only caller needing this is ReservedSpace. Would also be more in sync with the default false for executable on os::reserve(). 2) Personal nit, I really find this `ExecMem` jarring. We don't do this (pass named aliases for boolean flags) for any other arguments AFAICS. The usual way to emphasize arg names is with comments: bool result = os::commit_memory(base, size, /*exec*/ false); If you still prefer to use it, could you leave at least those places unchanged which are unaffected by your patch? 3) There is some code explicitly dealing with the supposed inability of attempt_reserve_memory_at() using MAP_JIT. I don't understand. I thought the problem was thjat MAP_JIT and MAP_FIXED don't mix. But attempt_reserve_memory_at() does explicitely not use MAP_FIXED, it just attempts to map at a non-null wish address. Does that also not work with MAP_JIT? 4) For my taste there are too many unrelated changes, especially in ReservedSpace. Making all those file scope static helpers members of ReservedSpace causes a lot of diffs. Makes sense cleanup-wise but will make backporting your patch more difficult later (I expect this will be a strong candidate for backporting). Please tone down the patch a bit. I pointed some parts out directly below. Beyond those, I leave it up to you how far you minimize the patch. Thanks, Thomas src/hotspot/os/bsd/os_bsd.cpp line 1690: > 1688: if (::mprotect(addr, size, prot) == 0) { > 1689: return true; > 1690: } You need to handle mprotect failure here too. Probably just by returning false. There is no point in doing the mmap below as fallback. The same applies for the OpenBSD path too. mprotect may, at least on Linux, fail if the new mapping introduced by changing the protection would bring the process above the system limit for numbrer of mappings. I strongly believe there must be a similar error scenario on Mac. At least on BSD there is (https://man.openbsd.org/mprotect.2), see ENOMEM. src/hotspot/share/runtime/os.hpp line 326: > 324: // Does not overwrite existing mappings. > 325: // It's intentionally cannot reserve executable mapping, as some platforms does not allow that > 326: // (e.g. macOS with proper MAP_JIT use). This is a note to a future implementor, not to the user. I would move this out of the header to the posix implementation. Also, see my question above, why would this not work? src/hotspot/share/memory/virtualspace.cpp line 88: > 86: } > 87: assert(!_special, "should not call this"); > 88: assert(!_executable, "unsupported"); Why is this unsupported? Could I not use MAP_JIT without MAP_FIXED but with a non-null attach address? src/hotspot/share/memory/virtualspace.cpp line 311: > 309: _base -= _noaccess_prefix; > 310: _size += _noaccess_prefix; > 311: Since you revert the steps taken at establish_noaccess_prefix, I'd move the _noaccess_prefix=0 up to here. For aestethic reasons mainly :) alternatively, I'd use temp variables like the code did before. src/hotspot/share/memory/virtualspace.hpp line 61: > 59: char* reserve_memory(size_t size); > 60: char* reserve_memory_aligned(size_t size, size_t alignment); > 61: void release_memory(char* base, size_t size); I liked the old names (..._map_or_reserve_....) better. Can you please rename them back? Their whole point is multiplexing between anonymous and mmaped reservation calls. Also, in their current form they read identical to the os::... functions which is really confusing. For release I propose `release_mapped_or_reserved_memory'. Its a mouthful but it clearly states what it does. src/hotspot/share/memory/virtualspace.cpp line 399: > 397: p2i(base), alignment); > 398: } else { > 399: _special = false; special->_special: This change has no connection to your patch. Can you leave this out please? I have nothing against cleanups but please in a separate RFE. Makes the patch clearer and easier to backport later. src/hotspot/share/memory/virtualspace.cpp line 194: > 192: p2i(base), alignment); > 193: } else { > 194: _special = false; Changes (special->_special) are Cleanup, please do them in a separate RFE if needed. ------------- Changes requested by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/294 From stuefe at openjdk.java.net Sat Dec 12 09:32:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Sat, 12 Dec 2020 09:32:00 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v8] In-Reply-To: References: Message-ID: On Sat, 12 Dec 2020 07:43:12 GMT, Thomas Stuefe wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update style > > src/hotspot/os/bsd/os_bsd.cpp line 1690: > >> 1688: if (::mprotect(addr, size, prot) == 0) { >> 1689: return true; >> 1690: } > > You need to handle mprotect failure here too. Probably just by returning false. There is no point in doing the mmap below as fallback. The same applies for the OpenBSD path too. > > mprotect may, at least on Linux, fail if the new mapping introduced by changing the protection would bring the process above the system limit for numbrer of mappings. I strongly believe there must be a similar error scenario on Mac. At least on BSD there is (https://man.openbsd.org/mprotect.2), see ENOMEM. Also, this is asymetric to uncommit now for the !exec case. There, we mmap(MAP_NORESERVE, PROT_NONE). We have established that MAP_NORESERVE is a noop, so this would be probably fine. Still, I'd do the mmap(PROT_RW) for commit instead for !exec: if (exec) // Do not replace MAP_JIT mappings, see JDK-8234930 return mprotect() == 0; } else { mmap ... } If not, I would remove MAP_NORESERVE from this code. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From aph at redhat.com Sat Dec 12 10:47:17 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 12 Dec 2020 10:47:17 +0000 Subject: Embedded JDK how to replace the default allocator In-Reply-To: References: Message-ID: On 11/12/2020 20:49, Guy Korland wrote: > I'm sorry if that is not the right mailing list for such questions, please > point me to the right one if it's not. > > We're embedding the OpenJDK in a C application, we already managed to make > it work and run Java bytecode, but we are still missing one last piece, we > need a way to replace the default memory allocator to use our allocator. > > Is there a way to do it? Sure. Look in src/hotspot/share/gc/epsilon for an example of the simplest- possible garbage collector and its interface. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From github.com+7531824+dmitry-timofeev at openjdk.java.net Sat Dec 12 20:31:59 2020 From: github.com+7531824+dmitry-timofeev at openjdk.java.net (Dmitry Timofeev) Date: Sat, 12 Dec 2020 20:31:59 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: <6VZMqLpeMULXdYE_25YbmRYB0d6qmzMVJ4RVLpKMVTg=.1d893206-8004-4f57-aa5e-83fbe4f1f16a@github.com> References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> <6VZMqLpeMULXdYE_25YbmRYB0d6qmzMVJ4RVLpKMVTg=.1d893206-8004-4f57-aa5e-83fbe4f1f16a@github.com> Message-ID: On Fri, 11 Dec 2020 15:23:20 GMT, Mauro Lacy wrote: >>> You can't "register" for the OpenJDK JBS, you are only granted write >>> access once you have Author status in the OpenJDK project. I will file >>> an issue but the security-libs folk will need to decide what to do about it. >> >> OK. Please let me know the issue #, so I can keep an eye on it. >> >>> >>> With regards to an earlier comment regarding the inconsistent behaviour >>> - yes this is only a -Xcheck:jni issue because it is only in that case >>> that any buffer copying every occurs and so freeing actually does >>> something. Otherwise hotspot never copies and the release mode is >>> irrelevant with regard to freeing anything. >> >> Fair enough. So, as you said earlier, this is in the end a matter of interpretation of what constitutes correct usage. >> >>> >>> Again I will look further into this, on Monday. >> >> Have a nice weekend. >> >>> >>> Cheers, >>> David > > One last comment: if `JNI_COMMIT` implies copying and freeing the buffer when it is a copy, then it's no different than mode `0`. Hi David, Thanks for taking a look at the issue! I've investigated this issue with Mauro. > -Xcheck:jni issue because it is only in that case that any buffer copying every occurs and so freeing actually does something. Otherwise hotspot never copies and the release mode is irrelevant with regard to freeing anything. I might be missing something, but it seems it depends on which method is used: - In `GetCriticalArrayElements`, Hotspot never copies. - In `GetXArrayElements`, Hotspot [always copies](https://github.com/openjdk/jdk/blob/6bc493188b265b1f9776aa62f77c161d75fc591e/src/hotspot/share/prims/jni.cpp#L2579) a Java array (except the case of 0-length array), hence it is essential to call `Release...` with `0` to eventually release the JVM-allocated buffer (or `JNI_ABORT`). `ReleaseXArrayElements` in normal mode, with no extra checks, is consistent with the specification: [it does not free the array on commit](https://github.com/openjdk/jdk/blob/6bc493188b265b1f9776aa62f77c161d75fc591e/src/hotspot/share/prims/jni.cpp#L2631-L2635). For comparison, Android VM [sometimes](https://cs.android.com/android/platform/superproject/+/master:art/runtime/jni/jni_internal.cc;l=2660;drc=master) copies. --- > I'm more inclined today to think that the spec should have made it clear that multiple release calls are needed if you only COMMIT first. I agree that the spec could have made it clearer that a call to `Release...` with `JNI_COMMIT` must be followed by a `Release` with either `JNI_ABORT` or `0`. For example, JNI tips for Android say it explicitly in bold: https://developer.android.com/training/articles/perf-jni#primitive-arrays > Also note that the JNI_COMMIT flag does not release the array, and you will need to call Release again with a different flag eventually. To be fair, the JNI specification does say that most application shall use "0" mode, and other modes are for some advanced use-cases. I checked the usage of GetXArrayElements with JNI_COMMIT in Google code base, and all of the usages actually meant mode "0" and had to be patched. Also, we have a RAII wrapper similar to one in jni-rs with a separate `Commit()` method, and there are no usages of this method :) > But we can't revert JDK-8193234 without reintroducing the leak for anyone using only COMMIT mode - which we've implicitly endorsed now. It seems that for users of `GetXArrayElements` the leak is always there: any code that uses `JNI_COMMIT` _instead of_ `0` leaks on a VM that copies (e.g., on Hotspot and on Android VM). That doesn't seem to be true for the critical flavour, because it does not copy in normal mode, but such client code is still broken according to the spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From github.com+7531824+dmitry-timofeev at openjdk.java.net Sat Dec 12 20:38:54 2020 From: github.com+7531824+dmitry-timofeev at openjdk.java.net (Dmitry Timofeev) Date: Sat, 12 Dec 2020 20:38:54 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> <6VZMqLpeMULXdYE_25YbmRYB0d6qmzMVJ4RVLpKMVTg=.1d893206-8004-4f57-aa5e-83fbe4f1f16a@github.com> Message-ID: On Sat, 12 Dec 2020 20:24:55 GMT, Dmitry Timofeev wrote: >> One last comment: if `JNI_COMMIT` implies copying and freeing the buffer when it is a copy, then it's no different than mode `0`. > > Hi David, > > Thanks for taking a look at the issue! I've investigated this issue with Mauro. > >> -Xcheck:jni issue because it is only in that case > that any buffer copying every occurs and so freeing actually does > something. Otherwise hotspot never copies and the release mode is > irrelevant with regard to freeing anything. > > I might be missing something, but it seems it depends on which method is used: > - In `GetCriticalArrayElements`, Hotspot never copies. > - In `GetXArrayElements`, Hotspot [always copies](https://github.com/openjdk/jdk/blob/6bc493188b265b1f9776aa62f77c161d75fc591e/src/hotspot/share/prims/jni.cpp#L2579) a Java array (except the case of 0-length array), hence it is essential to call `Release...` with `0` to eventually release the JVM-allocated buffer (or `JNI_ABORT`). `ReleaseXArrayElements` in normal mode, with no extra checks, is consistent with the specification: [it does not free the array on commit](https://github.com/openjdk/jdk/blob/6bc493188b265b1f9776aa62f77c161d75fc591e/src/hotspot/share/prims/jni.cpp#L2631-L2635). For comparison, Android VM [sometimes](https://cs.android.com/android/platform/superproject/+/master:art/runtime/jni/jni_internal.cc;l=2660;drc=master) copies. > > --- >> I'm more inclined today to think that the spec should have made it clear that multiple release calls are needed if you only COMMIT first. > > I agree that the spec could have made it clearer that a call to `Release...` with `JNI_COMMIT` must be followed by a `Release` with either `JNI_ABORT` or `0`. For example, JNI tips for Android say it explicitly in bold: https://developer.android.com/training/articles/perf-jni#primitive-arrays > >> Also note that the JNI_COMMIT flag does not release the array, and you will need to call Release again with a different flag eventually. > > To be fair, the JNI specification does say that most application shall use "0" mode, and other modes are for some advanced use-cases. I checked the usage of GetXArrayElements with JNI_COMMIT in Google code base, and all of the usages actually meant mode "0" and had to be patched. Also, we have a RAII wrapper similar to one in jni-rs with a separate `Commit()` method, and there are no usages of this method :) > >> But we can't revert JDK-8193234 without reintroducing the leak for anyone using only COMMIT mode - which we've implicitly endorsed now. > > It seems that for users of `GetXArrayElements` the leak is always there: any code that uses `JNI_COMMIT` _instead of_ `0` leaks on a VM that copies (e.g., on Hotspot and on Android VM). That doesn't seem to be true for the critical flavour, because it does not copy in normal mode, but such client code is still broken according to the spec. Also, searched for `JNI_COMMIT` on Github and sampled several results from non-toy projects ? all use `JNI_COMMIT` incorrectly instead of `0`. It would be lovely to add a clarification to the spec similar to one in Android JNI tips; and to raise awareness about `Xcheck:jni` mode, possibly, mention it prominently in the spec, so that more people use it to catch issues early in tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From thomas.stuefe at gmail.com Sun Dec 13 10:15:35 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 13 Dec 2020 11:15:35 +0100 Subject: Embedded JDK how to replace the default allocator In-Reply-To: References: Message-ID: Hi Guy, What do you mean by default allocator? C-Heap? Mmap/shmat? And what OS are you targeting? Cheers, Thomas On Fri, Dec 11, 2020 at 9:49 PM Guy Korland wrote: > Hi, > > I'm sorry if that is not the right mailing list for such questions, please > point me to the right one if it's not. > > We're embedding the OpenJDK in a C application, we already managed to make > it work and run Java bytecode, but we are still missing one last piece, we > need a way to replace the default memory allocator to use our allocator. > > Is there a way to do it? > > Thanks, > Guy Korland > 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 david.holmes at oracle.com Mon Dec 14 04:15:53 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Dec 2020 14:15:53 +1000 Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> <6VZMqLpeMULXdYE_25YbmRYB0d6qmzMVJ4RVLpKMVTg=.1d893206-8004-4f57-aa5e-83fbe4f1f16a@github.com> Message-ID: <12056477-534f-fef5-e3d1-d00ba19701e7@oracle.com> Hi Dmitry, Mauro, Sorry for the top-post but just to summarise: This particular issue is only about the GetCritical API in relation to the change in JDK-8193234 which introduced the explicit free of the internally allocated buffer used only for Xcheck:jni. Through (arguably) incorrect usage that internal buffer was causing a memory leak. I will try to address the specific double-free problem that relates to this issue (8258077). There is a broader issue of the lack of clear documentation for the GetCritical and GetXArrayElements APIs in regards to the correct way to use the different modes. I've filed a spec bug for that: https://bugs.openjdk.java.net/browse/JDK-8258185 There are cases where JNI_COMMIT is being used in the JDK when it probably should not e.g. the crypto code. I've filed a bug for that too: https://bugs.openjdk.java.net/browse/JDK-8258186 Thanks, David ----- On 13/12/2020 6:38 am, Dmitry Timofeev wrote: > On Sat, 12 Dec 2020 20:24:55 GMT, Dmitry Timofeev wrote: > >>> One last comment: if `JNI_COMMIT` implies copying and freeing the buffer when it is a copy, then it's no different than mode `0`. >> >> Hi David, >> >> Thanks for taking a look at the issue! I've investigated this issue with Mauro. >> >>> -Xcheck:jni issue because it is only in that case >> that any buffer copying every occurs and so freeing actually does >> something. Otherwise hotspot never copies and the release mode is >> irrelevant with regard to freeing anything. >> >> I might be missing something, but it seems it depends on which method is used: >> - In `GetCriticalArrayElements`, Hotspot never copies. >> - In `GetXArrayElements`, Hotspot [always copies](https://github.com/openjdk/jdk/blob/6bc493188b265b1f9776aa62f77c161d75fc591e/src/hotspot/share/prims/jni.cpp#L2579) a Java array (except the case of 0-length array), hence it is essential to call `Release...` with `0` to eventually release the JVM-allocated buffer (or `JNI_ABORT`). `ReleaseXArrayElements` in normal mode, with no extra checks, is consistent with the specification: [it does not free the array on commit](https://github.com/openjdk/jdk/blob/6bc493188b265b1f9776aa62f77c161d75fc591e/src/hotspot/share/prims/jni.cpp#L2631-L2635). For comparison, Android VM [sometimes](https://cs.android.com/android/platform/superproject/+/master:art/runtime/jni/jni_internal.cc;l=2660;drc=master) copies. >> >> --- >>> I'm more inclined today to think that the spec should have made it clear that multiple release calls are needed if you only COMMIT first. >> >> I agree that the spec could have made it clearer that a call to `Release...` with `JNI_COMMIT` must be followed by a `Release` with either `JNI_ABORT` or `0`. For example, JNI tips for Android say it explicitly in bold: https://developer.android.com/training/articles/perf-jni#primitive-arrays >> >>> Also note that the JNI_COMMIT flag does not release the array, and you will need to call Release again with a different flag eventually. >> >> To be fair, the JNI specification does say that most application shall use "0" mode, and other modes are for some advanced use-cases. I checked the usage of GetXArrayElements with JNI_COMMIT in Google code base, and all of the usages actually meant mode "0" and had to be patched. Also, we have a RAII wrapper similar to one in jni-rs with a separate `Commit()` method, and there are no usages of this method :) >> >>> But we can't revert JDK-8193234 without reintroducing the leak for anyone using only COMMIT mode - which we've implicitly endorsed now. >> >> It seems that for users of `GetXArrayElements` the leak is always there: any code that uses `JNI_COMMIT` _instead of_ `0` leaks on a VM that copies (e.g., on Hotspot and on Android VM). That doesn't seem to be true for the critical flavour, because it does not copy in normal mode, but such client code is still broken according to the spec. > > Also, searched for `JNI_COMMIT` on Github and sampled several results from non-toy projects ? all use `JNI_COMMIT` incorrectly instead of `0`. It would be lovely to add a clarification to the spec similar to one in Android JNI tips; and to raise awareness about `Xcheck:jni` mode, possibly, mention it prominently in the spec, so that more people use it to catch issues early in tests. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1697 > From jbhateja at openjdk.java.net Mon Dec 14 05:00:19 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 14 Dec 2020 05:00:19 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v5] In-Reply-To: References: Message-ID: > A newly allocated memory is initialized either using user provided initialization values for various fields or setting the memory to zero as per java semantics (System initialization). > > C2 compiler creates ClearArray Node in order to perform system initialization. ClearArray accepts the number of Heap Words to be initialized, this number can be constant or a non-constant value. For constant number of heap words less than InitArrayShortSize (default value 64 bytes) currently compiler generates StoreL nodes which does the initialization at the granularity of 8 bytes. > > This patch vectorizes the initializing store operations for constant sized heap word less than InitArrayShortSize by emitting special instruction sequence for various tail sizes. > > In addition existing implementation for initialization under UseXMMForObjInit is extended to use masked operation to optimize tail initialization sequence. In case AVX3Threshold is set to 0 then new initialization sequence uses 64 byte ZMM registers. > > Following are the performance stats collected using micro-benchmark included with the patch. > > Testing : Tier1-Tier3 level tests are clean. > > System Configuration : Cascadelake, Intel Xeon Platinum 8280L @ 2.7 GHz, 2 socket, 28 cores per socket. > > ### Baseline: > Benchmark Mode Cnt Score Error Units > ClearMemory.testClearMemory16K thrpt 2 1427741.069 ops/s > ClearMemory.testClearMemory1K thrpt 2 47628368.596 ops/s > ClearMemory.testClearMemory1M thrpt 2 27388.979 ops/s > ClearMemory.testClearMemory24B thrpt 2 167681010.419 ops/s > ClearMemory.testClearMemory2K thrpt 2 22043948.290 ops/s > ClearMemory.testClearMemory32B thrpt 2 168599498.817 ops/s > ClearMemory.testClearMemory32K thrpt 2 775985.067 ops/s > ClearMemory.testClearMemory40B thrpt 2 153375273.800 ops/s > ClearMemory.testClearMemory48B thrpt 2 145328531.804 ops/s > ClearMemory.testClearMemory4K thrpt 2 6492257.452 ops/s > ClearMemory.testClearMemory56B thrpt 2 122376321.652 ops/s > ClearMemory.testClearMemory8K thrpt 2 2857444.413 ops/s > ClearMemory.testClearMemory8M thrpt 2 3461.674 ops/s > ### With Optimization: > Benchmark Mode Cnt Score Error Units > ClearMemory.testClearMemory16K thrpt 2 2529701.368 ops/s > ClearMemory.testClearMemory1K thrpt 2 50276682.550 ops/s > ClearMemory.testClearMemory1M thrpt 2 27458.588 ops/s > ClearMemory.testClearMemory24B thrpt 2 178751174.642 ops/s > ClearMemory.testClearMemory2K thrpt 2 22574802.694 ops/s > ClearMemory.testClearMemory32B thrpt 2 176630844.950 ops/s > ClearMemory.testClearMemory32K thrpt 2 1297627.181 ops/s > ClearMemory.testClearMemory40B thrpt 2 167469550.653 ops/s > ClearMemory.testClearMemory48B thrpt 2 159391163.006 ops/s > ClearMemory.testClearMemory4K thrpt 2 9045158.643 ops/s > ClearMemory.testClearMemory56B thrpt 2 134550172.421 ops/s > ClearMemory.testClearMemory8K thrpt 2 4581450.664 ops/s > ClearMemory.testClearMemory8M thrpt 2 3446.834 ops/s Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolution. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1631/files - new: https://git.openjdk.java.net/jdk/pull/1631/files/af1bf755..717e71c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1631&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1631&range=03-04 Stats: 168 lines in 6 files changed: 21 ins; 25 del; 122 mod Patch: https://git.openjdk.java.net/jdk/pull/1631.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1631/head:pull/1631 PR: https://git.openjdk.java.net/jdk/pull/1631 From jbhateja at openjdk.java.net Mon Dec 14 05:00:21 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 14 Dec 2020 05:00:21 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v4] In-Reply-To: References: Message-ID: On Thu, 10 Dec 2020 07:43:36 GMT, Tobias Hartmann wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8257772: Changing the default value for UseXMMForObjInit and UseFastStosb flags. > > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4937: > >> 4935: // base - start address, qword aligned. >> 4936: Label L_zero_64_bytes, L_loop, L_sloop, L_tail, L_end; >> 4937: bool use64byteVector = MaxVectorSize == 64 && AVX3Threshold == 0; > > The comment for `AVX3Threshold` says: > "Minimum array size in bytes to use AVX512 intrinsics" > "for copy, inflate and fill. When this value is set as zero" > "compare operations can also use AVX512 intrinsics.") > > Should we mention clear memory there as well? Hi Nils, comments already cover "fill", clear memory is semantically equivalent to fill by zero. ------------- PR: https://git.openjdk.java.net/jdk/pull/1631 From qingfeng.yy at alibaba-inc.com Mon Dec 14 05:03:18 2020 From: qingfeng.yy at alibaba-inc.com (=?UTF-8?B?5p2o5piTKOmdkumjjik=?=) Date: Mon, 14 Dec 2020 13:03:18 +0800 Subject: =?UTF-8?B?QSBzb2x1dGlvbiB0byBkZXRlY3QgdGhlIGZvb3RwcmludCBvZiBKYXZhIHRocmVhZCBzdGFj?= =?UTF-8?B?aw==?= Message-ID: <94dc25af-5a11-4414-bcba-45eca74014fc.qingfeng.yy@alibaba-inc.com> Hi all, We occasionally get stack overflow errors if the application has too many deep callings. The usual solution is to increase -Xss, but there is no guiding opinion telling us in advance that the thread stack space is not enough. This patch attempts to address this issue. It introduces a new stack zone(warning_zone) for Hotspot VM, which can be used to detect whether the footprint ratio of the thread stack has reached the watermark set by the user. The current stack layout is as follows: stack_base stack_end --------------------------------------------------------------------------------------------------------------------------- | | shadow zone | warning zone(added) | reserved zone | yellow zone | red zone | --------------------------------------------------------------------------------------------------------------------------- ^rsp |<-StackWarningRatio % of available stack-> Users can set the option -XX:StackWarningRatio=0 to turn off this feature(which is also the default value) and there will be no warning zone, the stack layout is the same as usual. If the user sets -XX:StackWarningRatio to 50, the VM will protect 50% of the available stack space(let all = available+reserved+yellow+red;) as stack warning zone. When the footprint of available stack space reaches 50%, that is, when the application accesses the stack warning zone, the sigsegv signal will be triggered, and then the signal handler will warn this access in some ways(e.g. send the JFR event, logging) and resume current execution. As a prototype, this feature is only implemented on x86_posix, it can be implemented on more platforms as needed. Could anyone give some suggestions? If you think this is a useful feature, I will file an issue and support it on all platforms. Looking forward to your comments. Patch: https://github.com/kelthuzadx/jdk/commit/a145b2ebb4ac568e3bb090cbe3e7f091e1dc69ea Diff: https://github.com/kelthuzadx/jdk/compare/37dc675..a145b2e Best, Yang Yi From stuefe at openjdk.java.net Mon Dec 14 06:01:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 14 Dec 2020 06:01:57 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest [v4] In-Reply-To: References: Message-ID: <4QCKlZp1zq8PtQSTAnfIOTa21TG93VQ9r4_ZBO3v7M8=.b7677eb5-902d-4c81-8ee2-cf675488e613@github.com> On Fri, 11 Dec 2020 22:19:23 GMT, Ioi Lam wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed the ".*" in unittest.hpp and moved to the tests instead. > > Marked as reviewed by iklam (Reviewer). Hi Coleen, sorry, found another issue. In `print_error_for_unit_test` multiple threads may race and overwrite each others _detail_fmt buffer. Later on we block all threads but the first to report an error. But not here yet. So, maybe just use a C-heap allocated buffer or a stack buffer. I also don't think it has to be 1024, I guess 128 or so would be enough. We can make it larger if needed. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 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 iklam at openjdk.java.net Mon Dec 14 07:01:00 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 14 Dec 2020 07:01:00 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v2] In-Reply-To: References: Message-ID: <3S1Bcf2NGiNVvb3krJvsliX_3zVp0Ac4t2lxOS3kDWY=.7c7ef18d-538e-4efd-bb04-8cd4c3c6fb9e@github.com> On Sat, 12 Dec 2020 00:28:12 GMT, Yumin Qi wrote: >> Hi, Please review >> (This is redo for https://github.com/openjdk/jdk/pull/1657) >> 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 spaces. To do so, we need release the whole first then do the reserve again on the split, 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, go to other way, but do not do the 'real' split for the whole reserved space, keep the whole region reserved and released as a whole. >> Also fixed issues that when loading shared archive failed, bitmap region should be unmapped or it will cause mismatch in reserved/committed size calculation for NMT. >> Fixed reserved region name for adding committed region for NMT, it should use the reserved region name not "Unknown" the default. >> A test case added for testing the failed case which is caused by mismatch of class path. >> >> Tests:tier1-5,tier7 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Use default timeout number (120) for the test Changes requested by iklam (Reviewer). src/hotspot/share/runtime/os.cpp line 1727: > 1725: } > 1726: if (!res) { > 1727: log_info(os)("os::release_memory(" PTR_FORMAT ", " SIZE_FORMAT ") failed", p2i(addr), bytes); I think it's better to use `"os::release_memory failed (" PTR_FORMAT ", " SIZE_FORMAT ")"`. That way it's easy to match the error message in the test case with a simple substring test of `"os::release_memory failed"`. Otherwise it's hard to see that the regexp in the test ` "os::release_memory\(0x[0-9a-fA-F]*,\\s[0-9]*\)\\sfailed"` indeed would match the error message. ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From thartmann at openjdk.java.net Mon Dec 14 07:37:59 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 14 Dec 2020 07:37:59 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v5] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 05:00:19 GMT, Jatin Bhateja wrote: >> A newly allocated memory is initialized either using user provided initialization values for various fields or setting the memory to zero as per java semantics (System initialization). >> >> C2 compiler creates ClearArray Node in order to perform system initialization. ClearArray accepts the number of Heap Words to be initialized, this number can be constant or a non-constant value. For constant number of heap words less than InitArrayShortSize (default value 64 bytes) currently compiler generates StoreL nodes which does the initialization at the granularity of 8 bytes. >> >> This patch vectorizes the initializing store operations for constant sized heap word less than InitArrayShortSize by emitting special instruction sequence for various tail sizes. >> >> In addition existing implementation for initialization under UseXMMForObjInit is extended to use masked operation to optimize tail initialization sequence. In case AVX3Threshold is set to 0 then new initialization sequence uses 64 byte ZMM registers. >> >> Following are the performance stats collected using micro-benchmark included with the patch. >> >> Testing : Tier1-Tier3 level tests are clean. >> >> System Configuration : Cascadelake, Intel Xeon Platinum 8280L @ 2.7 GHz, 2 socket, 28 cores per socket. >> >> ### Baseline: >> Benchmark Mode Cnt Score Error Units >> ClearMemory.testClearMemory16K thrpt 2 1427741.069 ops/s >> ClearMemory.testClearMemory1K thrpt 2 47628368.596 ops/s >> ClearMemory.testClearMemory1M thrpt 2 27388.979 ops/s >> ClearMemory.testClearMemory24B thrpt 2 167681010.419 ops/s >> ClearMemory.testClearMemory2K thrpt 2 22043948.290 ops/s >> ClearMemory.testClearMemory32B thrpt 2 168599498.817 ops/s >> ClearMemory.testClearMemory32K thrpt 2 775985.067 ops/s >> ClearMemory.testClearMemory40B thrpt 2 153375273.800 ops/s >> ClearMemory.testClearMemory48B thrpt 2 145328531.804 ops/s >> ClearMemory.testClearMemory4K thrpt 2 6492257.452 ops/s >> ClearMemory.testClearMemory56B thrpt 2 122376321.652 ops/s >> ClearMemory.testClearMemory8K thrpt 2 2857444.413 ops/s >> ClearMemory.testClearMemory8M thrpt 2 3461.674 ops/s >> ### With Optimization: >> Benchmark Mode Cnt Score Error Units >> ClearMemory.testClearMemory16K thrpt 2 2529701.368 ops/s >> ClearMemory.testClearMemory1K thrpt 2 50276682.550 ops/s >> ClearMemory.testClearMemory1M thrpt 2 27458.588 ops/s >> ClearMemory.testClearMemory24B thrpt 2 178751174.642 ops/s >> ClearMemory.testClearMemory2K thrpt 2 22574802.694 ops/s >> ClearMemory.testClearMemory32B thrpt 2 176630844.950 ops/s >> ClearMemory.testClearMemory32K thrpt 2 1297627.181 ops/s >> ClearMemory.testClearMemory40B thrpt 2 167469550.653 ops/s >> ClearMemory.testClearMemory48B thrpt 2 159391163.006 ops/s >> ClearMemory.testClearMemory4K thrpt 2 9045158.643 ops/s >> ClearMemory.testClearMemory56B thrpt 2 134550172.421 ops/s >> ClearMemory.testClearMemory8K thrpt 2 4581450.664 ops/s >> ClearMemory.testClearMemory8M thrpt 2 3446.834 ops/s > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolution. Looks good to me but @vnkozlov should also finish his review before this is integrated. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1631 From thartmann at openjdk.java.net Mon Dec 14 07:38:01 2020 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 14 Dec 2020 07:38:01 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v4] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 04:57:29 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 4937: >> >>> 4935: // base - start address, qword aligned. >>> 4936: Label L_zero_64_bytes, L_loop, L_sloop, L_tail, L_end; >>> 4937: bool use64byteVector = MaxVectorSize == 64 && AVX3Threshold == 0; >> >> The comment for `AVX3Threshold` says: >> "Minimum array size in bytes to use AVX512 intrinsics" >> "for copy, inflate and fill. When this value is set as zero" >> "compare operations can also use AVX512 intrinsics.") >> >> Should we mention clear memory there as well? > > Hi Nils, comments already cover "fill", clear memory is semantically equivalent to fill by zero. Okay, that's fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/1631 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 kbarrett at openjdk.java.net Mon Dec 14 09:11:59 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 14 Dec 2020 09:11:59 GMT Subject: RFR: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM [v9] In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 15:31:09 GMT, Claes Redestad wrote: >> Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. >> >> Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. >> >> Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Explicit, static_cast to 32-bit unsigned Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1747 From aph at openjdk.java.net Mon Dec 14 10:02:55 2020 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 14 Dec 2020 10:02:55 GMT Subject: RFR: 8256820: AArch64: Optimize vector rotate (immediate) with shift and insert instructions In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 05:57:36 GMT, Dong Bo wrote: > 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`. This patch is very hard to review because much of it is just moving things around. Please do this as two PRs, one which does all the moves and one with the substantive changes. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1761 From aph at redhat.com Mon Dec 14 10:04:49 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Dec 2020 10:04:49 +0000 Subject: RFR: 8256820: AArch64: Optimize vector rotate (immediate) with shift and insert instructions In-Reply-To: References: Message-ID: <7e6281fb-2895-4ece-ade8-b3aaa1da262f@redhat.com> On 14/12/2020 06:02, Dong Bo wrote: > 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. I am seriously wondering if this change is worth doing. To find out, we'd have to test on all of the different AArch64 systems in use. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Dec 14 10:18:24 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 14 Dec 2020 10:18:24 +0000 Subject: RFR: 8256820: AArch64: Optimize vector rotate (immediate) with shift and insert instructions In-Reply-To: <7e6281fb-2895-4ece-ade8-b3aaa1da262f@redhat.com> References: <7e6281fb-2895-4ece-ade8-b3aaa1da262f@redhat.com> Message-ID: On 14/12/2020 10:04, Andrew Haley wrote: > I am seriously wondering if this change is worth doing. To find out, > we'd have to test on all of the different AArch64 systems in use. Just to explain a little more. We've never had many really processor- microarchitecture-specific optimizations in AArch64 HotSpot. I'm not very happy that we should do so, because the resulting complexity would make the port hard to manage. I wonder if this optimization would ever make a significant difference to any workload other than one specifically written to test it. If you know of any, please tell us. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rrich at openjdk.java.net Mon Dec 14 10:49:55 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 14 Dec 2020 10:49:55 GMT Subject: RFR: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack In-Reply-To: <2puMIw9J1QtaMxcHkYId04ckZSUrydOelw0-CrqjtTo=.046a45bf-2ca0-4ed0-80b1-37b1e095134a@github.com> References: <3qdP98TKpomuXicHcyJhjpEFazYe9A4QfJBz-ku3lec=.e00b696a-fe7b-4e45-a6ca-da6805c0e3b2@github.com> <2puMIw9J1QtaMxcHkYId04ckZSUrydOelw0-CrqjtTo=.046a45bf-2ca0-4ed0-80b1-37b1e095134a@github.com> Message-ID: On Fri, 11 Dec 2020 10:18:38 GMT, Martin Doerr wrote: >>> >>> I tested it successfully on Linux and AIX with the fastdebug build (RedefineClasses.java with -XX:+Verbose). >> >> Tests succeeded also in slowdebug and release on Linux/PPC64 (-XX:+Verbose is not supported in release though). >> >> test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java failed in slowdebug on AIX. But that's no showstopper, is it? >> My attempt to build also release on AIX failed because of an internal compiler error raised building libharfbuzz. > > Thanks for your proposal. I'll try it. > >> test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java failed in slowdebug on AIX. But that's no showstopper, is it? > > If it fails without this change, it'd be no regression and hence ok. > >> My attempt to build also release on AIX failed because of an internal compiler error raised building libharfbuzz. > > That's a known xlc bug. Workaround: > --- a/make/modules/java.desktop/lib/Awt2dLibraries.gmk > +++ b/make/modules/java.desktop/lib/Awt2dLibraries.gmk > @@ -475,6 +475,9 @@ else > # > > LIBHARFBUZZ_OPTIMIZATION := HIGH > + ifeq ($(call isTargetOs, aix), true) > + LIBHARFBUZZ_OPTIMIZATION := LOW > + endif > > LIBHARFBUZZ_CFLAGS += $(X_CFLAGS) -DLE_STANDALONE -DHEADLESS Hi Martin we can even do without _NMT_NOINLINE_. diff --git a/src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp b/src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp index 2eaf38d05cd..83f8af3b751 100644 --- a/src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp +++ b/src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp @@ -159,13 +159,9 @@ frame os::get_sender_for_C_frame(frame* fr) { frame os::current_frame() { - intptr_t* csp = (intptr_t*) *((intptr_t*) os::current_stack_pointer()); - // hack. - frame topframe(csp, (address)0x8); - // Return sender of sender of current topframe which hopefully - // both have pc != NULL. - frame tmp = os::get_sender_for_C_frame(&topframe); - return os::get_sender_for_C_frame(&tmp); + intptr_t* csp = *(intptr_t**) __builtin_frame_address(0); + frame topframe(csp, CAST_FROM_FN_PTR(address, os::current_frame)); + return os::get_sender_for_C_frame(&topframe); } bool PosixSignals::pd_hotspot_signal_handler(int sig, siginfo_t* info, diff --git a/src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp b/src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp index 5d68c4b3407..8e0af2acecc 100644 --- a/src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp +++ b/src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp @@ -179,13 +179,9 @@ frame os::get_sender_for_C_frame(frame* fr) { frame os::current_frame() { - intptr_t* csp = (intptr_t*) *((intptr_t*) os::current_stack_pointer()); - // hack. - frame topframe(csp, (address)0x8); - // Return sender of sender of current topframe which hopefully - // both have pc != NULL. - frame tmp = os::get_sender_for_C_frame(&topframe); - return os::get_sender_for_C_frame(&tmp); + intptr_t* csp = *(intptr_t**) __builtin_frame_address(0); + frame topframe(csp, CAST_FROM_FN_PTR(address, os::current_frame)); + return os::get_sender_for_C_frame(&topframe); } bool PosixSignals::pd_hotspot_signal_handler(int sig, siginfo_t* info, diff --git a/src/hotspot/share/utilities/nativeCallStack.cpp b/src/hotspot/share/utilities/nativeCallStack.cpp index 1093a13eaec..45a29424fd7 100644 --- a/src/hotspot/share/utilities/nativeCallStack.cpp +++ b/src/hotspot/share/utilities/nativeCallStack.cpp @@ -36,7 +36,7 @@ NativeCallStack::NativeCallStack(int toSkip, bool fillStack) : // to call os::get_native_stack. A tail call is used if _NMT_NOINLINE_ is not defined // (which means this is not a slowdebug build), and we are on 64-bit (except Windows). // This is not necessarily a rule, but what has been obvserved to date. -#if (defined(_NMT_NOINLINE_) || defined(_WINDOWS) || !defined(_LP64)) +#if (defined(_NMT_NOINLINE_) || defined(_WINDOWS) || !defined(_LP64) || defined(PPC64)) // Not a tail call. toSkip++; #if (defined(_NMT_NOINLINE_) && defined(BSD) && defined(_LP64)) diff --git a/test/hotspot/jtreg/runtime/logging/RedefineClasses.java b/test/hotspot/jtreg/runtime/logging/RedefineClasses.java My manual tests succeed with this on aix and linuxppc64le, except for the slowdebug build on aix where test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java fails with _and_ without the fix. Currently I don't understand why the result of __builtin_frame_address(0) has to be dereferenced? Looking at the disassembly of the slowdebug build it returns the sp of os::current_frame(). The head revision does the same though. (gdb) disass /s 0x7fffb71ed974,+64 Dump of assembler code from 0x7fffb71ed974 to 0x7fffb71ed9b4: 181 frame os::current_frame() { 0x00007fffb71ed974 : addis r2,r12,161 0x00007fffb71ed978 : addi r2,r2,-31604 0x00007fffb71ed97c : mflr r0 0x00007fffb71ed980 : std r0,16(r1) 0x00007fffb71ed984 : std r31,-8(r1) 0x00007fffb71ed988 : stdu r1,-128(r1) 0x00007fffb71ed98c : mr r31,r1 0x00007fffb71ed990 : std r3,40(r31) 182 intptr_t* csp = *(intptr_t**) __builtin_frame_address(0); 0x00007fffb71ed994 : mr r9,r31 0x00007fffb71ed998 : ld r9,0(r9) 0x00007fffb71ed99c : std r9,56(r31) 183 // hack. 184 frame topframe(csp, CAST_FROM_FN_PTR(address, os::current_frame)); 0x00007fffb71ed9a0 : addi r9,r31,64 0x00007fffb71ed9a4 : addis r5,r2,-161 0x00007fffb71ed9a8 : addi r5,r5,31604 0x00007fffb71ed9ac : ld r4,56(r31) 0x00007fffb71ed9b0 : mr r3,r9 ------------- PR: https://git.openjdk.java.net/jdk/pull/1724 From dongbo at openjdk.java.net Mon Dec 14 11:48:10 2020 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 14 Dec 2020 11:48:10 GMT Subject: RFR: 8256820: AArch64: Optimize vector rotate (immediate) with shift and insert instructions [v2] In-Reply-To: References: 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`. Dong Bo has updated the pull request incrementally with one additional commit since the last revision: delete all moves ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1761/files - new: https://git.openjdk.java.net/jdk/pull/1761/files/ef4e5aee..88ab26ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1761&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1761&range=00-01 Stats: 2341 lines in 3 files changed: 1014 ins; 1327 del; 0 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 dongbo at openjdk.java.net Mon Dec 14 11:48:10 2020 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 14 Dec 2020 11:48:10 GMT Subject: RFR: 8256820: AArch64: Optimize vector rotate (immediate) with shift and insert instructions [v2] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 09:59:42 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> delete all moves > > This patch is very hard to review because much of it is just moving things around. Please do this as two PRs, one which does all the moves and one with the substantive changes. Thanks. Thanks for the quick reply. Deleted all the moves in the updated version. We tested this on the two servers we have by hand now. It is a pity for us that we didn't see performance improvements on `Cortex-A72`. Because we have detected microarchitecture in the code already, I thought we could make full use of the flexibility it provided. We find the shift and insert instructions are used in Linux OS for serveral crypto algorithms for all CPUs [1, 2, 3]. But as of now, we only have the micro benchmarks for JDK as shown before. I'll try to investigate to see if there is any workload can benifit from this. Maybe someone from the community can help test this on other CPUs, like `ThunderX`, `Cortex-A73`? Thanks. :) [1] https://github.com/torvalds/linux/blob/master/arch/arm64/crypto/chacha-neon-core.S [2] https://github.com/torvalds/linux/blob/master/arch/arm64/crypto/crct10dif-ce-core.S [3] https://github.com/torvalds/linux/blob/master/arch/arm64/crypto/sha512-armv8.pl ------------- PR: https://git.openjdk.java.net/jdk/pull/1761 From redestad at openjdk.java.net Mon Dec 14 12:02:55 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 14 Dec 2020 12:02:55 GMT Subject: Integrated: 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 08:57:54 GMT, Claes Redestad wrote: > Re-implement count_trailing_zeros as a template function similar to count_leading_zeros, adding support for 8 and 16 bit types as well as for 64-bit types on 32-bit builds, which is currently not supported. This prohibits implementing the log2i_exact proposed by #1663 using count_trailing_zeros, as suggested during review. > > Compared to count_leading_zeros the implementation can be slightly simpler since subword specializations can simply use the internal 32-bit variant. > > Windows doesn't define _BitScanForward64 on 32-bit targets, so the 32-bit variant for handling 64-bit values becomes more convoluted. This pull request has now been integrated. Changeset: e69ae07f Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/e69ae07f Stats: 91 lines in 2 files changed: 66 ins; 6 del; 19 mod 8257985: count_trailing_zeros doesn't handle 64-bit values on 32-bit JVM Reviewed-by: kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/1747 From redestad at openjdk.java.net Mon Dec 14 12:07:33 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 14 Dec 2020 12:07:33 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v10] In-Reply-To: References: Message-ID: <_QkE1j9qE56EBddhNFuaMjdRqNqZrEHt_NaBYi3cYiM=.5d556e98-ccb3-4099-8542-02b6d8a77c05@github.com> > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Claes Redestad 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 26 additional commits since the last revision: - With JDK-8257985 fixed, use count_trailing_zeros to implement log2i_exact - Merge branch 'master' into log2_template - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template - More review comments adressed - Issue with using count_trailing_zeros with 64-bit values on 32-bit, revert and add TODO - Merge branch 'master' into log2_template - Renaming, adress review comments - x->value - Rename log2i ilogi and make it only accept value > 0, rename log2i_allow_zero log2i_graceful, accepting any value - Rename exact_log2i exact_ilog2, make it stricter - ... and 16 more: https://git.openjdk.java.net/jdk/compare/45d01a4b...42b75337 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1663/files - new: https://git.openjdk.java.net/jdk/pull/1663/files/511a8f67..42b75337 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=08-09 Stats: 13644 lines in 361 files changed: 11801 ins; 1136 del; 707 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 From kbarrett at openjdk.java.net Mon Dec 14 12:57:10 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 14 Dec 2020 12:57:10 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v10] In-Reply-To: <_QkE1j9qE56EBddhNFuaMjdRqNqZrEHt_NaBYi3cYiM=.5d556e98-ccb3-4099-8542-02b6d8a77c05@github.com> References: <_QkE1j9qE56EBddhNFuaMjdRqNqZrEHt_NaBYi3cYiM=.5d556e98-ccb3-4099-8542-02b6d8a77c05@github.com> Message-ID: On Mon, 14 Dec 2020 12:07:33 GMT, Claes Redestad wrote: >> This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp >> >> Naming is hard, but I think the following scheme is reasonable: >> >> - log2i: any integral type. 0-hostile >> - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) >> - exact_log2i: any integral type. value must be a power of two >> >> I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. >> >> Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. >> >> To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: >> >> [ RUN ] power_of_2.log2_long_micro >> [ OK ] power_of_2.log2_long_micro (3581 ms) >> [ RUN ] power_of_2.log2_long_small_micro >> [ OK ] power_of_2.log2_long_small_micro (549 ms) >> [ RUN ] power_of_2.log2i_micro >> [ OK ] power_of_2.log2i_micro (259 ms) >> [ RUN ] power_of_2.log2i_small_micro >> [ OK ] power_of_2.log2i_small_micro (113 ms) >> >> I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W >> >> (Intending this for 17) > > Claes Redestad 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 26 additional commits since the last revision: > > - With JDK-8257985 fixed, use count_trailing_zeros to implement log2i_exact > - Merge branch 'master' into log2_template > - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template > - More review comments adressed > - Issue with using count_trailing_zeros with 64-bit values on 32-bit, revert and add TODO > - Merge branch 'master' into log2_template > - Renaming, adress review comments > - x->value > - Rename log2i ilogi and make it only accept value > 0, rename log2i_allow_zero log2i_graceful, accepting any value > - Rename exact_log2i exact_ilog2, make it stricter > - ... and 16 more: https://git.openjdk.java.net/jdk/compare/ea3a3570...42b75337 src/hotspot/share/utilities/powerOfTwo.hpp line 78: > 76: assert(is_power_of_2(value), > 77: "value must be a power of 2: " UINT64_FORMAT, > 78: (uint64_t)static_cast::type>(value)); This looks strange and complicated for something that ought to be straightforward. There was a comment in conversation suggesting this is working around some problem with some test. Please explain, because I'd really like this to go back to just a cast to uint64_t if at all possible. Sorry I didn't bring this up earlier. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From yzheng at openjdk.java.net Mon Dec 14 13:06:56 2020 From: yzheng at openjdk.java.net (Yudi Zheng) Date: Mon, 14 Dec 2020 13:06:56 GMT Subject: Withdrawn: 8257910: [JVMCI] Set exception_seen accordingly in the runtime. In-Reply-To: <-dC7EkSsxPpLvZE5I5ds2CAw1QJfDGNIAxLec7s8o2w=.d8c74ba5-45c4-4041-8674-6edad6dc49a6@github.com> References: <-dC7EkSsxPpLvZE5I5ds2CAw1QJfDGNIAxLec7s8o2w=.d8c74ba5-45c4-4041-8674-6edad6dc49a6@github.com> Message-ID: On Wed, 9 Dec 2020 10:03:48 GMT, Yudi Zheng wrote: > Update exception_seen flag in the MDO when no exception handler is found for caller during deoptimization, or when exception is thrown in the runtime. > > Plus, `-Xlog:exceptions=info` code and `AbortVMOnException` are adjusted in C1 runtime and jvmci runtime to be consistent with C2, i.e., before `JvmtiExport::can_post_on_exceptions` deoptimization and fast continuation when compiled handler is found. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1713 From redestad at openjdk.java.net Mon Dec 14 13:08:04 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 14 Dec 2020 13:08:04 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v10] In-Reply-To: References: <_QkE1j9qE56EBddhNFuaMjdRqNqZrEHt_NaBYi3cYiM=.5d556e98-ccb3-4099-8542-02b6d8a77c05@github.com> Message-ID: On Mon, 14 Dec 2020 12:54:09 GMT, Kim Barrett wrote: >> Claes Redestad 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 26 additional commits since the last revision: >> >> - With JDK-8257985 fixed, use count_trailing_zeros to implement log2i_exact >> - Merge branch 'master' into log2_template >> - Merge branch 'master' of https://github.com/openjdk/jdk into log2_template >> - More review comments adressed >> - Issue with using count_trailing_zeros with 64-bit values on 32-bit, revert and add TODO >> - Merge branch 'master' into log2_template >> - Renaming, adress review comments >> - x->value >> - Rename log2i ilogi and make it only accept value > 0, rename log2i_allow_zero log2i_graceful, accepting any value >> - Rename exact_log2i exact_ilog2, make it stricter >> - ... and 16 more: https://git.openjdk.java.net/jdk/compare/176978c5...42b75337 > > src/hotspot/share/utilities/powerOfTwo.hpp line 78: > >> 76: assert(is_power_of_2(value), >> 77: "value must be a power of 2: " UINT64_FORMAT, >> 78: (uint64_t)static_cast::type>(value)); > > This looks strange and complicated for something that ought to be straightforward. There was a comment in conversation suggesting this is working around some problem with some test. Please explain, because I'd really like this to go back to just a cast to uint64_t if at all possible. Sorry I didn't bring this up earlier. For signed int 0x80000000 casting to uint64_t will change the value to 0xFFFFFFFF80000000, which is avoided by making the value unsigned before casting (0x0000000080000000). After we changed the precondition to require value to be positive this is only an issue for what the assert prints in this edge case, so I agree we can simplify it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From redestad at openjdk.java.net Mon Dec 14 13:20:12 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 14 Dec 2020 13:20:12 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v11] In-Reply-To: References: Message-ID: > This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp > > Naming is hard, but I think the following scheme is reasonable: > > - log2i: any integral type. 0-hostile > - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) > - exact_log2i: any integral type. value must be a power of two > > I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. > > Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. > > To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: > > [ RUN ] power_of_2.log2_long_micro > [ OK ] power_of_2.log2_long_micro (3581 ms) > [ RUN ] power_of_2.log2_long_small_micro > [ OK ] power_of_2.log2_long_small_micro (549 ms) > [ RUN ] power_of_2.log2i_micro > [ OK ] power_of_2.log2i_micro (259 ms) > [ RUN ] power_of_2.log2i_small_micro > [ OK ] power_of_2.log2i_small_micro (113 ms) > > I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W > > (Intending this for 17) Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Remove use of make_unsigned, use UINT64_FORMAT_X to make sign extension stand out ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1663/files - new: https://git.openjdk.java.net/jdk/pull/1663/files/42b75337..e21e1b7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1663&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1663/head:pull/1663 PR: https://git.openjdk.java.net/jdk/pull/1663 From coleenp at openjdk.java.net Mon Dec 14 13:22:13 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 14 Dec 2020 13:22:13 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest [v5] In-Reply-To: References: Message-ID: > Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. > > Tested with tier1-3 with product and fastdebug builds. Built with optimized. > > This is for JDK 17. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Make temporary detail message stack allocated. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1723/files - new: https://git.openjdk.java.net/jdk/pull/1723/files/ca06a07e..8a5864eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1723&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1723&range=03-04 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1723.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1723/head:pull/1723 PR: https://git.openjdk.java.net/jdk/pull/1723 From coleenp at openjdk.java.net Mon Dec 14 13:22:13 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 14 Dec 2020 13:22:13 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest [v4] In-Reply-To: <4QCKlZp1zq8PtQSTAnfIOTa21TG93VQ9r4_ZBO3v7M8=.b7677eb5-902d-4c81-8ee2-cf675488e613@github.com> References: <4QCKlZp1zq8PtQSTAnfIOTa21TG93VQ9r4_ZBO3v7M8=.b7677eb5-902d-4c81-8ee2-cf675488e613@github.com> Message-ID: On Mon, 14 Dec 2020 05:59:10 GMT, Thomas Stuefe wrote: >> Marked as reviewed by iklam (Reviewer). > > Hi Coleen, > > sorry, found another issue. In `print_error_for_unit_test` multiple threads may race and overwrite each others _detail_fmt buffer. Later on we block all threads but the first to report an error. But not here yet. So, maybe just use a C-heap allocated buffer or a stack buffer. I also don't think it has to be 1024, I guess 128 or so would be enough. We can make it larger if needed. > > Cheers, Thomas Hi Thomas, thank you for finding the "last" bug in this. I made the buffer stack allocated and 256. That should be enough and it passes all the gtests. Thanks again. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From stuefe at openjdk.java.net Mon Dec 14 13:30:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 14 Dec 2020 13:30:57 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest [v4] In-Reply-To: References: <4QCKlZp1zq8PtQSTAnfIOTa21TG93VQ9r4_ZBO3v7M8=.b7677eb5-902d-4c81-8ee2-cf675488e613@github.com> Message-ID: <4YLRqlqNY99cjiUqxgqktnGEuGiQs3v1FCwt_OqVG64=.50961a9e-76e9-4619-a38d-7018335290a7@github.com> On Mon, 14 Dec 2020 13:19:41 GMT, Coleen Phillimore wrote: > Hi Thomas, thank you for finding the "last" bug in this. I made the buffer stack allocated and 256. That should be enough and it passes all the gtests. Thanks again. Thanks Coleen! Looks good now. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From mdoerr at openjdk.java.net Mon Dec 14 13:45:57 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 14 Dec 2020 13:45:57 GMT Subject: RFR: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack In-Reply-To: References: <3qdP98TKpomuXicHcyJhjpEFazYe9A4QfJBz-ku3lec=.e00b696a-fe7b-4e45-a6ca-da6805c0e3b2@github.com> <2puMIw9J1QtaMxcHkYId04ckZSUrydOelw0-CrqjtTo=.046a45bf-2ca0-4ed0-80b1-37b1e095134a@github.com> Message-ID: On Mon, 14 Dec 2020 10:47:01 GMT, Richard Reingruber wrote: >> Thanks for your proposal. I'll try it. >> >>> test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java failed in slowdebug on AIX. But that's no showstopper, is it? >> >> If it fails without this change, it'd be no regression and hence ok. >> >>> My attempt to build also release on AIX failed because of an internal compiler error raised building libharfbuzz. >> >> That's a known xlc bug. Workaround: >> --- a/make/modules/java.desktop/lib/Awt2dLibraries.gmk >> +++ b/make/modules/java.desktop/lib/Awt2dLibraries.gmk >> @@ -475,6 +475,9 @@ else >> # >> >> LIBHARFBUZZ_OPTIMIZATION := HIGH >> + ifeq ($(call isTargetOs, aix), true) >> + LIBHARFBUZZ_OPTIMIZATION := LOW >> + endif >> >> LIBHARFBUZZ_CFLAGS += $(X_CFLAGS) -DLE_STANDALONE -DHEADLESS > > Hi Martin > > we can even do without _NMT_NOINLINE_. > > diff --git a/src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp b/src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp > index 2eaf38d05cd..83f8af3b751 100644 > --- a/src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp > +++ b/src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp > @@ -159,13 +159,9 @@ frame os::get_sender_for_C_frame(frame* fr) { > > > frame os::current_frame() { > - intptr_t* csp = (intptr_t*) *((intptr_t*) os::current_stack_pointer()); > - // hack. > - frame topframe(csp, (address)0x8); > - // Return sender of sender of current topframe which hopefully > - // both have pc != NULL. > - frame tmp = os::get_sender_for_C_frame(&topframe); > - return os::get_sender_for_C_frame(&tmp); > + intptr_t* csp = *(intptr_t**) __builtin_frame_address(0); > + frame topframe(csp, CAST_FROM_FN_PTR(address, os::current_frame)); > + return os::get_sender_for_C_frame(&topframe); > } > > bool PosixSignals::pd_hotspot_signal_handler(int sig, siginfo_t* info, > diff --git a/src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp b/src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp > index 5d68c4b3407..8e0af2acecc 100644 > --- a/src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp > +++ b/src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp > @@ -179,13 +179,9 @@ frame os::get_sender_for_C_frame(frame* fr) { > > > frame os::current_frame() { > - intptr_t* csp = (intptr_t*) *((intptr_t*) os::current_stack_pointer()); > - // hack. > - frame topframe(csp, (address)0x8); > - // Return sender of sender of current topframe which hopefully > - // both have pc != NULL. > - frame tmp = os::get_sender_for_C_frame(&topframe); > - return os::get_sender_for_C_frame(&tmp); > + intptr_t* csp = *(intptr_t**) __builtin_frame_address(0); > + frame topframe(csp, CAST_FROM_FN_PTR(address, os::current_frame)); > + return os::get_sender_for_C_frame(&topframe); > } > > bool PosixSignals::pd_hotspot_signal_handler(int sig, siginfo_t* info, > diff --git a/src/hotspot/share/utilities/nativeCallStack.cpp b/src/hotspot/share/utilities/nativeCallStack.cpp > index 1093a13eaec..45a29424fd7 100644 > --- a/src/hotspot/share/utilities/nativeCallStack.cpp > +++ b/src/hotspot/share/utilities/nativeCallStack.cpp > @@ -36,7 +36,7 @@ NativeCallStack::NativeCallStack(int toSkip, bool fillStack) : > // to call os::get_native_stack. A tail call is used if _NMT_NOINLINE_ is not defined > // (which means this is not a slowdebug build), and we are on 64-bit (except Windows). > // This is not necessarily a rule, but what has been obvserved to date. > -#if (defined(_NMT_NOINLINE_) || defined(_WINDOWS) || !defined(_LP64)) > +#if (defined(_NMT_NOINLINE_) || defined(_WINDOWS) || !defined(_LP64) || defined(PPC64)) > // Not a tail call. > toSkip++; > #if (defined(_NMT_NOINLINE_) && defined(BSD) && defined(_LP64)) > diff --git a/test/hotspot/jtreg/runtime/logging/RedefineClasses.java b/test/hotspot/jtreg/runtime/logging/RedefineClasses.java > > My manual tests succeed with this on aix and linuxppc64le, except for the slowdebug build on aix where test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java fails with _and_ without the fix. > > Currently I don't understand why the result of __builtin_frame_address(0) has to > be dereferenced? Looking at the disassembly of the slowdebug build it returns > the sp of os::current_frame(). The head revision does the same though. > > (gdb) disass /s 0x7fffb71ed974,+64 > Dump of assembler code from 0x7fffb71ed974 to 0x7fffb71ed9b4: > > 181 frame os::current_frame() { > 0x00007fffb71ed974 : addis r2,r12,161 > 0x00007fffb71ed978 : addi r2,r2,-31604 > 0x00007fffb71ed97c : mflr r0 > 0x00007fffb71ed980 : std r0,16(r1) > 0x00007fffb71ed984 : std r31,-8(r1) > 0x00007fffb71ed988 : stdu r1,-128(r1) > 0x00007fffb71ed98c : mr r31,r1 > 0x00007fffb71ed990 : std r3,40(r31) > > 182 intptr_t* csp = *(intptr_t**) __builtin_frame_address(0); > 0x00007fffb71ed994 : mr r9,r31 > 0x00007fffb71ed998 : ld r9,0(r9) > 0x00007fffb71ed99c : std r9,56(r31) > > 183 // hack. > 184 frame topframe(csp, CAST_FROM_FN_PTR(address, os::current_frame)); > 0x00007fffb71ed9a0 : addi r9,r31,64 > 0x00007fffb71ed9a4 : addis r5,r2,-161 > 0x00007fffb71ed9a8 : addi r5,r5,31604 > 0x00007fffb71ed9ac : ld r4,56(r31) > 0x00007fffb71ed9b0 : mr r3,r9 Hi Richard, I was not aware of that __builtin_frame_address is available on all PPC64 platforms. Makes sense to use it and to get rid of the inline assembly. > Currently I don't understand why the result of __builtin_frame_address(0) has to be dereferenced? I don't understand that, either. Seems like it was implemented by trial and error. I think trying to predict the C++ compiler's inlining is a terrible design, but it's only used by non-critical code like NMT stack traces, so we can focus on more critical issues. We could use __builtin_frame_address(1) and remove the dereferencing. I think we should use that also in os::current_stack_pointer(). What do you think? Anyway, I like your proposal. Would you mind creating a PR for jdk16 as we need it there? I'm closing this one. ------------- PR: https://git.openjdk.java.net/jdk/pull/1724 From mdoerr at openjdk.java.net Mon Dec 14 13:45:58 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Mon, 14 Dec 2020 13:45:58 GMT Subject: Withdrawn: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 22:11:18 GMT, Martin Doerr wrote: > Method handle logging is broken in fastdebug builds. Problem is that os::current_frame() doesn't return the right frame in fastdebug builds. > Unfortunately, fixing os::current_frame() would break NMT stack traces (runtime/NMT/CheckForProperDetailStackTrace.java). This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1724 From coleenp at openjdk.java.net Mon Dec 14 14:14:09 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 14 Dec 2020 14:14:09 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest [v6] In-Reply-To: References: Message-ID: > Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. > > Tested with tier1-3 with product and fastdebug builds. Built with optimized. > > This is for JDK 17. Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into crashtest - Make temporary detail message stack allocated. - Removed the ".*" in unittest.hpp and moved to the tests instead. - add missing va_end() - Fixed va_copy problem, and added changes from pull request. - make crash test options develop options - 8252148: vmError::controlled_crash should be #ifdef ASSERT ------------- Changes: https://git.openjdk.java.net/jdk/pull/1723/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1723&range=05 Stats: 362 lines in 18 files changed: 148 ins; 171 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/1723.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1723/head:pull/1723 PR: https://git.openjdk.java.net/jdk/pull/1723 From coleenp at openjdk.java.net Mon Dec 14 14:14:10 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 14 Dec 2020 14:14:10 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest [v4] In-Reply-To: <4YLRqlqNY99cjiUqxgqktnGEuGiQs3v1FCwt_OqVG64=.50961a9e-76e9-4619-a38d-7018335290a7@github.com> References: <4QCKlZp1zq8PtQSTAnfIOTa21TG93VQ9r4_ZBO3v7M8=.b7677eb5-902d-4c81-8ee2-cf675488e613@github.com> <4YLRqlqNY99cjiUqxgqktnGEuGiQs3v1FCwt_OqVG64=.50961a9e-76e9-4619-a38d-7018335290a7@github.com> Message-ID: <-1VOWEsyDHSYipvoc-H2KiibQ5JYZLE1K7trswjY3kE=.fec88f11-ec23-4253-86b6-01aca41c0a7d@github.com> On Mon, 14 Dec 2020 13:28:23 GMT, Thomas Stuefe wrote: >> Hi Thomas, thank you for finding the "last" bug in this. I made the buffer stack allocated and 256. That should be enough and it passes all the gtests. Thanks again. > >> Hi Thomas, thank you for finding the "last" bug in this. I made the buffer stack allocated and 256. That should be enough and it passes all the gtests. Thanks again. > > Thanks Coleen! Looks good now. Thanks Thomas, Ioi and Gerard. I remerged with JDK-8257229: gtest death tests fail with unrecognized stderr output to make sure they still worked together. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From rrich at openjdk.java.net Mon Dec 14 14:16:55 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Mon, 14 Dec 2020 14:16:55 GMT Subject: RFR: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack In-Reply-To: References: <3qdP98TKpomuXicHcyJhjpEFazYe9A4QfJBz-ku3lec=.e00b696a-fe7b-4e45-a6ca-da6805c0e3b2@github.com> <2puMIw9J1QtaMxcHkYId04ckZSUrydOelw0-CrqjtTo=.046a45bf-2ca0-4ed0-80b1-37b1e095134a@github.com> Message-ID: <7fEghRQlNBrbhTLUxDL3pjZmkxDajmF8UeMYtdYx0oc=.f87279b3-bcf8-49bf-8b37-5fb581e506e0@github.com> On Mon, 14 Dec 2020 13:43:28 GMT, Martin Doerr wrote: > I was not aware of that __builtin_frame_address is available on all PPC64 platforms. Makes sense to use it and to get rid of the inline assembly. Me neither. I found it in the implementation for x86_64 and learned that xlC supports it as well. > > > Currently I don't understand why the result of __builtin_frame_address(0) has to be dereferenced? > > I don't understand that, either. Seems like it was implemented by trial and error. I think trying to predict the C++ compiler's inlining is a terrible design, but it's only used by non-critical code like NMT stack traces, so we can focus on more critical issues. > > We could use __builtin_frame_address(1) and remove the dereferencing. I think we should use that also in os::current_stack_pointer(). What do you think? According to the documentation (https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html) this is not really safe. Calling this function with a nonzero argument can have unpredictable effects, including crashing the calling program So I wouldn't do it. We could still use it in os::current_stack_pointer() _and_ in os::current_frame(). > > Anyway, I like your proposal. Would you mind creating a PR for jdk16 as we need it there? I'm closing this one. That's fine for me. Thanks, Richard. ------------- PR: https://git.openjdk.java.net/jdk/pull/1724 From kbarrett at openjdk.java.net Mon Dec 14 14:31:59 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 14 Dec 2020 14:31:59 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v11] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 13:20:12 GMT, Claes Redestad wrote: >> This patch replaces the log2 functions in globalDefinitions.hpp with more efficient counterparts in utilities/powerOfTwo.hpp >> >> Naming is hard, but I think the following scheme is reasonable: >> >> - log2i: any integral type. 0-hostile >> - log2i_allow_zero: any integral type. gracefully handles zero (adds a branch) >> - exact_log2i: any integral type. value must be a power of two >> >> I chose log2i rather than log2 to stand out from the log2 functions defined in various standard libraries. >> >> Going through all usage, quite a few uses of log2_long et.c. could be replaced by exact_log2i since they take something that has been checked to be a power of two. Most of the remaining usage seem to be able to use the 0-hostile variant, which avoids a branch. >> >> To sanity check that calculating log2 using count_leading_zeros gives better performance I added a couple of trivial and short-running microbenchmarks to test_powerOfTwo. For small values (<= 1025) the new impl is ~5x faster, with a larger speed-up for larger integer values: >> >> [ RUN ] power_of_2.log2_long_micro >> [ OK ] power_of_2.log2_long_micro (3581 ms) >> [ RUN ] power_of_2.log2_long_small_micro >> [ OK ] power_of_2.log2_long_small_micro (549 ms) >> [ RUN ] power_of_2.log2i_micro >> [ OK ] power_of_2.log2i_micro (259 ms) >> [ RUN ] power_of_2.log2i_small_micro >> [ OK ] power_of_2.log2i_small_micro (113 ms) >> >> I'm not sure if this naive microbenchmark carries its own weight, but it just adds a few seconds and can be useful for quickly checking this performance assumption on other H/W >> >> (Intending this for 17) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Remove use of make_unsigned, use UINT64_FORMAT_X to make sign extension stand out Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 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 stuefe at openjdk.java.net Mon Dec 14 15:28:08 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 14 Dec 2020 15:28:08 GMT Subject: RFR: JDK-8257959: Add gtest run with -XX:+UseLargePages Message-ID: Hi, may I please have reviews for this addition. To better test changes in large page handling, it makes sense to regularly run gtests with large pages enabled. Not the whole gtest suite needs to be run, but at least the os* part. Thanks, Thomas ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/1763/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1763&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257959 Stats: 64 lines in 2 files changed: 63 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1763.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1763/head:pull/1763 PR: https://git.openjdk.java.net/jdk/pull/1763 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 lfoltan at openjdk.java.net Mon Dec 14 15:58:05 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Mon, 14 Dec 2020 15:58:05 GMT Subject: RFR: JDK-8257959: Add gtest run with -XX:+UseLargePages In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 09:44:06 GMT, Thomas Stuefe wrote: > Hi, > > may I please have reviews for this addition. > > To better test changes in large page handling, it makes sense to regularly run gtests with large pages enabled. Not the whole gtest suite needs to be run, but at least the os* part. > > Thanks, Thomas Looks good. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1763 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 stuefe at openjdk.java.net Mon Dec 14 17:28:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 14 Dec 2020 17:28:55 GMT Subject: RFR: JDK-8257959: Add gtest run with -XX:+UseLargePages In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 15:55:26 GMT, Lois Foltan wrote: > Looks good. > Lois Thank you Lois! ------------- PR: https://git.openjdk.java.net/jdk/pull/1763 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 minqi at openjdk.java.net Mon Dec 14 18:23:57 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 14 Dec 2020 18:23:57 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v2] In-Reply-To: <5psc_1iEpzMF13HEci0Om_qEUjlijEWw0rAwymzWl3Q=.54975782-5d91-4bf6-882b-b0664fd40a25@github.com> References: <5psc_1iEpzMF13HEci0Om_qEUjlijEWw0rAwymzWl3Q=.54975782-5d91-4bf6-882b-b0664fd40a25@github.com> Message-ID: <1mKTxTpcO0e4Tvtls87h4kYeMJGS7VvF2JdKImpCn1U=.0a3a08f8-b637-4ea3-a341-bd74deeb7000@github.com> On Sat, 12 Dec 2020 00:45:23 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Use default timeout number (120) for the test > > test/hotspot/jtreg/runtime/cds/appcds/MismatchedPathTriggerMemoryRelease.java line 61: > >> 59: "-XX:NativeMemoryTracking=detail", >> 60: "-XX:SharedBaseAddress=0", >> 61: "Hello"); > > Instead of `TestCommon.exec`, you could use `TestCommon.execAuto` and no need to pass the `-Xshare:auto` argument. Changed to execAuto, remove "-Xshare:auto", it failed on "Error: Could not find or load main class non-exist.jar" so i will keep original version. ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From minqi at openjdk.java.net Mon Dec 14 18:24:01 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 14 Dec 2020 18:24:01 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v2] In-Reply-To: <3S1Bcf2NGiNVvb3krJvsliX_3zVp0Ac4t2lxOS3kDWY=.7c7ef18d-538e-4efd-bb04-8cd4c3c6fb9e@github.com> References: <3S1Bcf2NGiNVvb3krJvsliX_3zVp0Ac4t2lxOS3kDWY=.7c7ef18d-538e-4efd-bb04-8cd4c3c6fb9e@github.com> Message-ID: On Mon, 14 Dec 2020 06:57:54 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Use default timeout number (120) for the test > > src/hotspot/share/runtime/os.cpp line 1727: > >> 1725: } >> 1726: if (!res) { >> 1727: log_info(os)("os::release_memory(" PTR_FORMAT ", " SIZE_FORMAT ") failed", p2i(addr), bytes); > > I think it's better to use `"os::release_memory failed (" PTR_FORMAT ", " SIZE_FORMAT ")"`. That way it's easy to match the error message in the test case with a simple substring test of `"os::release_memory failed"`. Otherwise it's hard to see that the regexp in the test ` "os::release_memory\(0x[0-9a-fA-F]*,\\s[0-9]*\)\\sfailed"` indeed would match the error message. Thanks for the suggestion. Will make the check in test simple. (I have tested the pattern using online java pattern match and a local test program for it). Thanks Yumin ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From minqi at openjdk.java.net Mon Dec 14 18:29:13 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 14 Dec 2020 18:29:13 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3] In-Reply-To: References: Message-ID: > Hi, Please review > (This is redo for https://github.com/openjdk/jdk/pull/1657) > 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 spaces. To do so, we need release the whole first then do the reserve again on the split, 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, go to other way, but do not do the 'real' split for the whole reserved space, keep the whole region reserved and released as a whole. > Also fixed issues that when loading shared archive failed, bitmap region should be unmapped or it will cause mismatch in reserved/committed size calculation for NMT. > Fixed reserved region name for adding committed region for NMT, it should use the reserved region name not "Unknown" the default. > A test case added for testing the failed case which is caused by mismatch of class path. > > Tests:tier1-5,tier7 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fixed os::release message to make test simply check if output containing the message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1750/files - new: https://git.openjdk.java.net/jdk/pull/1750/files/e5323f51..ecca6b22 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1750&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1750&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1750.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1750/head:pull/1750 PR: https://git.openjdk.java.net/jdk/pull/1750 From iklam at openjdk.java.net Mon Dec 14 18:44:58 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 14 Dec 2020 18:44:58 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 18:29:13 GMT, Yumin Qi wrote: >> Hi, Please review >> (This is redo for https://github.com/openjdk/jdk/pull/1657) >> 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 spaces. To do so, we need release the whole first then do the reserve again on the split, 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, go to other way, but do not do the 'real' split for the whole reserved space, keep the whole region reserved and released as a whole. >> Also fixed issues that when loading shared archive failed, bitmap region should be unmapped or it will cause mismatch in reserved/committed size calculation for NMT. >> Fixed reserved region name for adding committed region for NMT, it should use the reserved region name not "Unknown" the default. >> A test case added for testing the failed case which is caused by mismatch of class path. >> >> Tests:tier1-5,tier7 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fixed os::release message to make test simply check if output containing the message LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1750 From github.com+7531824+dmitry-timofeev at openjdk.java.net Mon Dec 14 18:51:55 2020 From: github.com+7531824+dmitry-timofeev at openjdk.java.net (Dmitry Timofeev) Date: Mon, 14 Dec 2020 18:51:55 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> <6VZMqLpeMULXdYE_25YbmRYB0d6qmzMVJ4RVLpKMVTg=.1d893206-8004-4f57-aa5e-83fbe4f1f16a@github.com> Message-ID: On Sat, 12 Dec 2020 20:36:01 GMT, Dmitry Timofeev wrote: >> Hi David, >> >> Thanks for taking a look at the issue! I've investigated this issue with Mauro. >> >>> -Xcheck:jni issue because it is only in that case >> that any buffer copying every occurs and so freeing actually does >> something. Otherwise hotspot never copies and the release mode is >> irrelevant with regard to freeing anything. >> >> I might be missing something, but it seems it depends on which method is used: >> - In `GetCriticalArrayElements`, Hotspot never copies. >> - In `GetXArrayElements`, Hotspot [always copies](https://github.com/openjdk/jdk/blob/6bc493188b265b1f9776aa62f77c161d75fc591e/src/hotspot/share/prims/jni.cpp#L2579) a Java array (except the case of 0-length array), hence it is essential to call `Release...` with `0` to eventually release the JVM-allocated buffer (or `JNI_ABORT`). `ReleaseXArrayElements` in normal mode, with no extra checks, is consistent with the specification: [it does not free the array on commit](https://github.com/openjdk/jdk/blob/6bc493188b265b1f9776aa62f77c161d75fc591e/src/hotspot/share/prims/jni.cpp#L2631-L2635). For comparison, Android VM [sometimes](https://cs.android.com/android/platform/superproject/+/master:art/runtime/jni/jni_internal.cc;l=2660;drc=master) copies. >> >> --- >>> I'm more inclined today to think that the spec should have made it clear that multiple release calls are needed if you only COMMIT first. >> >> I agree that the spec could have made it clearer that a call to `Release...` with `JNI_COMMIT` must be followed by a `Release` with either `JNI_ABORT` or `0`. For example, JNI tips for Android say it explicitly in bold: https://developer.android.com/training/articles/perf-jni#primitive-arrays >> >>> Also note that the JNI_COMMIT flag does not release the array, and you will need to call Release again with a different flag eventually. >> >> To be fair, the JNI specification does say that most application shall use "0" mode, and other modes are for some advanced use-cases. I checked the usage of GetXArrayElements with JNI_COMMIT in Google code base, and all of the usages actually meant mode "0" and had to be patched. Also, we have a RAII wrapper similar to one in jni-rs with a separate `Commit()` method, and there are no usages of this method :) >> >>> But we can't revert JDK-8193234 without reintroducing the leak for anyone using only COMMIT mode - which we've implicitly endorsed now. >> >> It seems that for users of `GetXArrayElements` the leak is always there: any code that uses `JNI_COMMIT` _instead of_ `0` leaks on a VM that copies (e.g., on Hotspot and on Android VM). That doesn't seem to be true for the critical flavour, because it does not copy in normal mode, but such client code is still broken according to the spec. > > Also, searched for `JNI_COMMIT` on Github and sampled several results from non-toy projects ? all use `JNI_COMMIT` incorrectly instead of `0`. It would be lovely to add a clarification to the spec similar to one in Android JNI tips; and to raise awareness about `Xcheck:jni` mode, possibly, mention it prominently in the spec, so that more people use it to catch issues early in tests. Hi David, Thanks for submitting the issues! > This particular issue is only about the GetCritical API in relation to the change in JDK-8193234 which introduced the explicit free of the internally allocated buffer used only for Xcheck:jni. As [`check_wrapped_array_release`](https://github.com/openjdk/jdk/blob/976acddeb5a8df1e868269787c023306aad3fe4a/src/hotspot/share/prims/jniCheck.cpp#L422-L441), modified in JDK-8193234, is re-used in both [ReleaseCritical](https://github.com/openjdk/jdk/blob/976acddeb5a8df1e868269787c023306aad3fe4a/src/hotspot/share/prims/jniCheck.cpp#L1887) and [ReleaseScalar](https://github.com/openjdk/jdk/blob/976acddeb5a8df1e868269787c023306aad3fe4a/src/hotspot/share/prims/jniCheck.cpp#L1717) in checked mode, it is not just GetCritical API that is affected, but also GetXArrayElements methods. That is, a supposedly valid client code: var buf = env->GetByteArrayElements(jarray, ...); // Just commit, do not free env->ReleaseByteArrayElements(jarray, buf, JNI_COMMIT); // Commit and free env->ReleaseByteArrayElements(jarray, buf, 0); will result in an error with `check:jni` enabled. However, an incomplete usage, with a leak in client code: var buf = env->GetByteArrayElements(jarray, ...); // Just commit, do not free env->ReleaseByteArrayElements(jarray, buf, JNI_COMMIT); // buf is not freed will neither trigger an error, nor cause a `buf` leak with `check:jni` mode enabled (because of JDK-8193234), but will leak without JNI checks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From ccheung at openjdk.java.net Mon Dec 14 19:11:57 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 14 Dec 2020 19:11:57 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 18:29:13 GMT, Yumin Qi wrote: >> Hi, Please review >> (This is redo for https://github.com/openjdk/jdk/pull/1657) >> 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 spaces. To do so, we need release the whole first then do the reserve again on the split, 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, go to other way, but do not do the 'real' split for the whole reserved space, keep the whole region reserved and released as a whole. >> Also fixed issues that when loading shared archive failed, bitmap region should be unmapped or it will cause mismatch in reserved/committed size calculation for NMT. >> Fixed reserved region name for adding committed region for NMT, it should use the reserved region name not "Unknown" the default. >> A test case added for testing the failed case which is caused by mismatch of class path. >> >> Tests:tier1-5,tier7 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fixed os::release message to make test simply check if output containing the message Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1750 From ccheung at openjdk.java.net Mon Dec 14 19:11:59 2020 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 14 Dec 2020 19:11:59 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v2] In-Reply-To: <1mKTxTpcO0e4Tvtls87h4kYeMJGS7VvF2JdKImpCn1U=.0a3a08f8-b637-4ea3-a341-bd74deeb7000@github.com> References: <5psc_1iEpzMF13HEci0Om_qEUjlijEWw0rAwymzWl3Q=.54975782-5d91-4bf6-882b-b0664fd40a25@github.com> <1mKTxTpcO0e4Tvtls87h4kYeMJGS7VvF2JdKImpCn1U=.0a3a08f8-b637-4ea3-a341-bd74deeb7000@github.com> Message-ID: On Mon, 14 Dec 2020 18:18:46 GMT, Yumin Qi wrote: >> test/hotspot/jtreg/runtime/cds/appcds/MismatchedPathTriggerMemoryRelease.java line 61: >> >>> 59: "-XX:NativeMemoryTracking=detail", >>> 60: "-XX:SharedBaseAddress=0", >>> 61: "Hello"); >> >> Instead of `TestCommon.exec`, you could use `TestCommon.execAuto` and no need to pass the `-Xshare:auto` argument. > > Changed to execAuto, remove "-Xshare:auto", it failed on "Error: Could not find or load main class non-exist.jar" so i will keep original version. I think you'll need to add `"-cp"` before `"non-exist.jar"` for execAuto to work. I'm fine to leave it as is. ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From minqi at openjdk.java.net Mon Dec 14 19:16:56 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 14 Dec 2020 19:16:56 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 18:42:39 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed os::release message to make test simply check if output containing the message > > LGTM @iklam @calvinccheung Thanks for review. I will wait for @tstuefe input for integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From stuefe at openjdk.java.net Mon Dec 14 19:59:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 14 Dec 2020 19:59:55 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 19:14:32 GMT, Yumin Qi wrote: >> LGTM > > @iklam @calvinccheung Thanks for review. I will wait for @tstuefe input for integration. Hi Yumin, I don't understand the special handling in NMT. Unix: We reserve a region, split it, tell NMT about the split (see posix version of os::split_reserved_memory), then later release both parts separately. Windows: 1) use_archive_base_addr = true: we allocate the spaces separately, later release them separately 2) use_archive_base_addr = false: we allocate total space, leave it unsplit, then later release the total space. Where is this new NMT coding needed? Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From minqi at openjdk.java.net Mon Dec 14 20:14:55 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 14 Dec 2020 20:14:55 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 19:56:58 GMT, Thomas Stuefe wrote: >> @iklam @calvinccheung Thanks for review. I will wait for @tstuefe input for integration. > > Hi Yumin, > > I don't understand the special handling in NMT. > > Unix: We reserve a region, split it, tell NMT about the split (see posix version of os::split_reserved_memory), then later release both parts separately. > Windows: > 1) use_archive_base_addr = true: we allocate the spaces separately, later release them separately > 2) use_archive_base_addr = false: we allocate total space, leave it unsplit, then later release the total space. > > Where is this new NMT coding needed? > > Thanks, Thomas Hi, Thomas > I don't understand the special handling in NMT. > > Unix: We reserve a region, split it, tell NMT about the split (see posix version of os::split_reserved_memory), then later release both parts separately. There is no problem for Linux/Unix here since split does not do the split. > Windows: > > 1. use_archive_base_addr = true: we allocate the spaces separately, later release them separately Yes, the two spaces are released separately and NMT will find exact matched regions to remove. > 2. use_archive_base_addr = false: we allocate total space, leave it unsplit, then later release the total space. > The space reserved as a whole, and we did not do the 'split' on it. The release should be on whole too. When unmapping regions, the released on region in fact did not do anything in nmt since it is within the archive space. Since the new code is release on the whole space (there is no call to release on class_space_rs in this case), so it check if it is > archive_space_rs (with tag of mtClassShared) we know it is for releasing the whole space. The space which is bigger than archive_space_rs with tag of mtClassShared should be only the whole space. > Where is this new NMT coding needed? > The code is to make the bytes in snapshot correct. That, when all the spaces release, the bytes in the reserved slot should be 'zero'. Thanks for review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From kvn at openjdk.java.net Mon Dec 14 21:06:57 2020 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 14 Dec 2020 21:06:57 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v5] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 05:00:19 GMT, Jatin Bhateja wrote: >> A newly allocated memory is initialized either using user provided initialization values for various fields or setting the memory to zero as per java semantics (System initialization). >> >> C2 compiler creates ClearArray Node in order to perform system initialization. ClearArray accepts the number of Heap Words to be initialized, this number can be constant or a non-constant value. For constant number of heap words less than InitArrayShortSize (default value 64 bytes) currently compiler generates StoreL nodes which does the initialization at the granularity of 8 bytes. >> >> This patch vectorizes the initializing store operations for constant sized heap word less than InitArrayShortSize by emitting special instruction sequence for various tail sizes. >> >> In addition existing implementation for initialization under UseXMMForObjInit is extended to use masked operation to optimize tail initialization sequence. In case AVX3Threshold is set to 0 then new initialization sequence uses 64 byte ZMM registers. >> >> Following are the performance stats collected using micro-benchmark included with the patch. >> >> Testing : Tier1-Tier3 level tests are clean. >> >> System Configuration : Cascadelake, Intel Xeon Platinum 8280L @ 2.7 GHz, 2 socket, 28 cores per socket. >> >> ### Baseline: >> Benchmark Mode Cnt Score Error Units >> ClearMemory.testClearMemory16K thrpt 2 1427741.069 ops/s >> ClearMemory.testClearMemory1K thrpt 2 47628368.596 ops/s >> ClearMemory.testClearMemory1M thrpt 2 27388.979 ops/s >> ClearMemory.testClearMemory24B thrpt 2 167681010.419 ops/s >> ClearMemory.testClearMemory2K thrpt 2 22043948.290 ops/s >> ClearMemory.testClearMemory32B thrpt 2 168599498.817 ops/s >> ClearMemory.testClearMemory32K thrpt 2 775985.067 ops/s >> ClearMemory.testClearMemory40B thrpt 2 153375273.800 ops/s >> ClearMemory.testClearMemory48B thrpt 2 145328531.804 ops/s >> ClearMemory.testClearMemory4K thrpt 2 6492257.452 ops/s >> ClearMemory.testClearMemory56B thrpt 2 122376321.652 ops/s >> ClearMemory.testClearMemory8K thrpt 2 2857444.413 ops/s >> ClearMemory.testClearMemory8M thrpt 2 3461.674 ops/s >> ### With Optimization: >> Benchmark Mode Cnt Score Error Units >> ClearMemory.testClearMemory16K thrpt 2 2529701.368 ops/s >> ClearMemory.testClearMemory1K thrpt 2 50276682.550 ops/s >> ClearMemory.testClearMemory1M thrpt 2 27458.588 ops/s >> ClearMemory.testClearMemory24B thrpt 2 178751174.642 ops/s >> ClearMemory.testClearMemory2K thrpt 2 22574802.694 ops/s >> ClearMemory.testClearMemory32B thrpt 2 176630844.950 ops/s >> ClearMemory.testClearMemory32K thrpt 2 1297627.181 ops/s >> ClearMemory.testClearMemory40B thrpt 2 167469550.653 ops/s >> ClearMemory.testClearMemory48B thrpt 2 159391163.006 ops/s >> ClearMemory.testClearMemory4K thrpt 2 9045158.643 ops/s >> ClearMemory.testClearMemory56B thrpt 2 134550172.421 ops/s >> ClearMemory.testClearMemory8K thrpt 2 4581450.664 ops/s >> ClearMemory.testClearMemory8M thrpt 2 3446.834 ops/s > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolution. Passed my tier1-tier3 testing with UseAVX=3. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1631 From gkorland at gmail.com Mon Dec 14 23:08:27 2020 From: gkorland at gmail.com (Guy Korland) Date: Tue, 15 Dec 2020 01:08:27 +0200 Subject: Embedded JDK how to replace the default allocator In-Reply-To: References: Message-ID: I'm talking about replacing the malloc implementation, we're running on Linux. But, the tricky part is that my C application malloc should not be changed, only the libjvm.so when loaded embedded in my application. Regards, Guy Korland On Sun, Dec 13, 2020 at 12:15 PM Thomas St?fe wrote: > Hi Guy, > > What do you mean by default allocator? C-Heap? Mmap/shmat? And what OS are > you targeting? > > Cheers, Thomas > > On Fri, Dec 11, 2020 at 9:49 PM Guy Korland wrote: > >> Hi, >> >> I'm sorry if that is not the right mailing list for such questions, please >> point me to the right one if it's not. >> >> We're embedding the OpenJDK in a C application, we already managed to make >> it work and run Java bytecode, but we are still missing one last piece, we >> need a way to replace the default memory allocator to use our allocator. >> >> Is there a way to do it? >> >> Thanks, >> Guy Korland >> > From david.holmes at oracle.com Tue Dec 15 00:09:26 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2020 10:09:26 +1000 Subject: Embedded JDK how to replace the default allocator In-Reply-To: References: Message-ID: On 15/12/2020 9:08 am, Guy Korland wrote: > I'm talking about replacing the malloc implementation, we're running on > Linux. > But, the tricky part is that my C application malloc should not be changed, > only the libjvm.so when loaded embedded in my application. I don't know if this works, or you are able to do it, but statically linking your application with its desired malloc library, and using LD_PRELOAD for the JVMs might work. Cheers, David ----- > Regards, > Guy Korland > > > On Sun, Dec 13, 2020 at 12:15 PM Thomas St?fe > wrote: > >> Hi Guy, >> >> What do you mean by default allocator? C-Heap? Mmap/shmat? And what OS are >> you targeting? >> >> Cheers, Thomas >> >> On Fri, Dec 11, 2020 at 9:49 PM Guy Korland wrote: >> >>> Hi, >>> >>> I'm sorry if that is not the right mailing list for such questions, please >>> point me to the right one if it's not. >>> >>> We're embedding the OpenJDK in a C application, we already managed to make >>> it work and run Java bytecode, but we are still missing one last piece, we >>> need a way to replace the default memory allocator to use our allocator. >>> >>> Is there a way to do it? >>> >>> Thanks, >>> Guy Korland >>> >> 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 jbhateja at openjdk.java.net Tue Dec 15 04:23:57 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 15 Dec 2020 04:23:57 GMT Subject: RFR: 8257772: Vectorizing clear memory operation using AVX-512 masked operations [v5] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 21:03:52 GMT, Vladimir Kozlov wrote: > Passed my tier1-tier3 testing with UseAVX=3. Thanks @vnkozlov and @TobiHartmann ------------- PR: https://git.openjdk.java.net/jdk/pull/1631 From david.holmes at oracle.com Tue Dec 15 05:07:55 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2020 15:07:55 +1000 Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <6VZMqLpeMULXdYE_25YbmRYB0d6qmzMVJ4RVLpKMVTg=.1d893206-8004-4f57-aa5e-83fbe4f1f16a@github.com> Message-ID: <7cc88e07-4e65-dff5-ffa8-eb5db0c53b31@oracle.com> Hi Dmitry, On 15/12/2020 4:51 am, Dmitry Timofeev wrote: > Hi David, > > Thanks for submitting the issues! > >> This particular issue is only about the GetCritical API in relation to > the change in JDK-8193234 which introduced the explicit free of the > internally allocated buffer used only for Xcheck:jni. > > As [`check_wrapped_array_release`](https://github.com/openjdk/jdk/blob/976acddeb5a8df1e868269787c023306aad3fe4a/src/hotspot/share/prims/jniCheck.cpp#L422-L441), modified in JDK-8193234, is re-used in both [ReleaseCritical](https://github.com/openjdk/jdk/blob/976acddeb5a8df1e868269787c023306aad3fe4a/src/hotspot/share/prims/jniCheck.cpp#L1887) and [ReleaseScalar](https://github.com/openjdk/jdk/blob/976acddeb5a8df1e868269787c023306aad3fe4a/src/hotspot/share/prims/jniCheck.cpp#L1717) in checked mode, it is not just GetCritical API that is affected, but also GetXArrayElements methods. Thanks for the correction - I'm not sure if I realized at the time that this affected both API's. :( David ----- > That is, a supposedly valid client code: > > var buf = env->GetByteArrayElements(jarray, ...); > // Just commit, do not free > env->ReleaseByteArrayElements(jarray, buf, JNI_COMMIT); > // Commit and free > env->ReleaseByteArrayElements(jarray, buf, 0); > > will result in an error with `check:jni` enabled. However, an incomplete usage, with a leak in client code: > > > var buf = env->GetByteArrayElements(jarray, ...); > // Just commit, do not free > env->ReleaseByteArrayElements(jarray, buf, JNI_COMMIT); > // buf is not freed > > will neither trigger an error, nor cause a `buf` leak with `check:jni` mode enabled (because of JDK-8193234), but will leak without JNI checks. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1697 > From david.holmes at oracle.com Tue Dec 15 05:24:54 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2020 15:24:54 +1000 Subject: A solution to detect the footprint of Java thread stack In-Reply-To: <94dc25af-5a11-4414-bcba-45eca74014fc.qingfeng.yy@alibaba-inc.com> References: <94dc25af-5a11-4414-bcba-45eca74014fc.qingfeng.yy@alibaba-inc.com> Message-ID: <1e423c3c-fac3-268e-f4f6-8d9f1a2cea51@oracle.com> Hi Yang Yi, On 14/12/2020 3:03 pm, ??(??) wrote: > Hi all, > We occasionally get stack overflow errors if the application has too many deep callings. The usual solution is to increase -Xss, but there is no guiding opinion telling us in advance that the thread stack space is not enough. This patch attempts to address this issue. It introduces a new stack zone(warning_zone) for Hotspot VM, which can be used to detect whether the footprint ratio of the thread stack has reached the watermark set by the user. > > The current stack layout is as follows: > stack_base stack_end > --------------------------------------------------------------------------------------------------------------------------- > | | shadow zone | warning zone(added) | reserved zone | yellow zone | red zone | > --------------------------------------------------------------------------------------------------------------------------- > ^rsp |<-StackWarningRatio % of available stack-> > > Users can set the option -XX:StackWarningRatio=0 to turn off this feature(which is also the default value) and there will be no warning zone, the stack layout is the same as usual. > If the user sets -XX:StackWarningRatio to 50, the VM will protect 50% of the available stack space(let all = available+reserved+yellow+red;) as stack warning zone. When the footprint of available stack space reaches 50%, that is, when the application accesses the stack warning zone, the sigsegv signal will be triggered, and then the signal handler will warn this access in some ways(e.g. send the JFR event, logging) and resume current execution. As a prototype, this feature is only implemented on x86_posix, it can be implemented on more platforms as needed. > > Could anyone give some suggestions? If you think this is a useful feature, I will file an issue and support it on all platforms. Looking forward to your comments. How do you actually envisage people using this? This seems more of a tuning option, but you can tune just as readily by adjusting -Xss in the same manner you would set the warning ratio. I.e. you'd like to shrink your stack usage but are not sure how small you can make it safely so you can either just reduce -Xss and see if it works, or you can set the warning ratio to give the same effective -Xss and see if you get a warning. The flag would need to be diagnostic rather than full product. Cheers, David > Patch: https://github.com/kelthuzadx/jdk/commit/a145b2ebb4ac568e3bb090cbe3e7f091e1dc69ea > Diff: https://github.com/kelthuzadx/jdk/compare/37dc675..a145b2e > > Best, > Yang Yi > From kbarrett at openjdk.java.net Tue Dec 15 06:09:03 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 15 Dec 2020 06:09:03 GMT Subject: RFR: 8258252: Move PtrQueue enqueue to PtrQueueSet subclasses Message-ID: Please review this refactoring in the PtrQueue/PtrQueueSet hierarchy. The functions PtrQueue::enqueue and PtrQueue::enqueue_known_active are removed, along with the helper virtual function PtrQueue::handle_completed_buffer. Instead we now have G1{Dirty,Redirty}CardQueueSet::enqueue and SATBMarkQueueSet::enqueue/enqueue_known_active, each tailored to the corresponding specific behavior. They use some shared helper routines from PtrQueueSet, and the PtrQueue buffer and index have been made accessible to clients. Testing: mach5 tier1-3, 5 (stress tests) Local (linux-x64) tier1 with -XX:+UseShenandoahGC ------------- Commit messages: - shenandoah support - move enqueue to qsets Changes: https://git.openjdk.java.net/jdk/pull/1776/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1776&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258252 Stats: 364 lines in 22 files changed: 181 ins; 113 del; 70 mod Patch: https://git.openjdk.java.net/jdk/pull/1776.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1776/head:pull/1776 PR: https://git.openjdk.java.net/jdk/pull/1776 From thomas.stuefe at gmail.com Tue Dec 15 06:54:01 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 15 Dec 2020 07:54:01 +0100 Subject: Embedded JDK how to replace the default allocator In-Reply-To: References: Message-ID: Hi, you are still not very forthcoming with information, so we don't know what your goal is. Total isolation of all allocations? Or just monitoring? Is partial isolation okay? Since I do not know what you need, here are some hints: - majority of allocations of a VM are not done via C-Heap but via virtual memory APIs like mmap() or SystemV shm(). - C Heap allocations from the hotspot itself could be redirected, since they go through the os::malloc... layer. I believe this also takes care of C++ allocations - However, that is only a small part of all allocations, since any library loaded via JNI (including both the JDK libraries themselves as well as any third party JNI libraries we don't have control over) rolls their own memory management by calling malloc or C++ new or mmap or... directly. - Also note that there may be places in the hotspot where C heap allocated pointers are kept in a hashmap, and radically changing how the pointers look like (different allocator) may mess with the efficiency of those hash functions. So if you need total isolation, the only realistic way is as David described: use LD_PRELOAD and provide redirections for all system level APIs which allocate memory. The problem with redirecting C-Heap allocations at that level however is that if you override free() you need to have perfect coverage of all allocating APIs. These are not limited to malloc/calloc/free etc but there are a number of other APIs which return their results in C-Heap allocated buffers. And I have no idea honestly how to redirect C++ allocations via LD_PRELOAD. Cheers, Thomas On Tue, Dec 15, 2020 at 12:08 AM Guy Korland wrote: > > I'm talking about replacing the malloc implementation, we're running on > Linux. > But, the tricky part is that my C application malloc should not be > changed, only the libjvm.so when loaded embedded in my application. > > Regards, > Guy Korland > > > On Sun, Dec 13, 2020 at 12:15 PM Thomas St?fe > wrote: > >> Hi Guy, >> >> What do you mean by default allocator? C-Heap? Mmap/shmat? And what OS >> are you targeting? >> >> Cheers, Thomas >> >> On Fri, Dec 11, 2020 at 9:49 PM Guy Korland wrote: >> >>> Hi, >>> >>> I'm sorry if that is not the right mailing list for such questions, >>> please >>> point me to the right one if it's not. >>> >>> We're embedding the OpenJDK in a C application, we already managed to >>> make >>> it work and run Java bytecode, but we are still missing one last piece, >>> we >>> need a way to replace the default memory allocator to use our allocator. >>> >>> Is there a way to do it? >>> >>> Thanks, >>> Guy Korland >>> >> From qingfeng.yy at alibaba-inc.com Tue Dec 15 07:02:21 2020 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Tue, 15 Dec 2020 15:02:21 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaUmU6IEEgc29sdXRpb24gdG8gZGV0ZWN0IHRoZSBmb290cHJpbnQgb2YgSmF2?= =?UTF-8?B?YSB0aHJlYWQgc3RhY2s=?= In-Reply-To: <1e423c3c-fac3-268e-f4f6-8d9f1a2cea51@oracle.com> References: <94dc25af-5a11-4414-bcba-45eca74014fc.qingfeng.yy@alibaba-inc.com>, <1e423c3c-fac3-268e-f4f6-8d9f1a2cea51@oracle.com> Message-ID: Hi David, Thank you for your comments. > How do you actually envisage people using this? This seems more of a > tuning option, but you can tune just as readily by adjusting -Xss in the > same manner you would set the warning ratio. I.e. you'd like to shrink > your stack usage but are not sure how small you can make it safely so > you can either just reduce -Xss and see if it works, or you can set the > warning ratio to give the same effective -Xss and see if you get a warning. Yes, we can indeed achieve similar goals by constantly adjusting -Xss, but adjusting -Xss is generally a way to make the application work again after StackOverflowError occurs. The purpose of -XX:StackWarningRatio is to warn early before StackOverflowError occurs. Based on my experience and observation, many developers use the default value of ThreadStackSize(the default value of is 1M on linux_x86), they will not adjust the value of this option unless a stack overflow occurs. With the iterative development of the application, the size of the stack may no longer meet the demand. It's helpful to warn about insufficient stack space earlier in case of hurriedly troubleshooting and adjusting the -Xss when the application throws StackOverflowError in the production environment. > The flag would need to be diagnostic rather than full product. Accept. Best, Yang Yi ------------------------------------------------------------------ ????David Holmes ????2020?12?15? 13:24:54 ????Yang Yi; HotSpot Open Source Developers; hotspot-jfr-dev ????Re: A solution to detect the footprint of Java thread stack Hi Yang Yi, On 14/12/2020 3:03 pm, ??(??) wrote: > Hi all, > We occasionally get stack overflow errors if the application has too many deep callings. The usual solution is to increase -Xss, but there is no guiding opinion telling us in advance that the thread stack space is not enough. This patch attempts to address this issue. It introduces a new stack zone(warning_zone) for Hotspot VM, which can be used to detect whether the footprint ratio of the thread stack has reached the watermark set by the user. > > The current stack layout is as follows: > stack_base stack_end > --------------------------------------------------------------------------------------------------------------------------- > | | shadow zone | warning zone(added) | reserved zone | yellow zone | red zone | > --------------------------------------------------------------------------------------------------------------------------- > ^rsp |<-StackWarningRatio % of available stack-> > > Users can set the option -XX:StackWarningRatio=0 to turn off this feature(which is also the default value) and there will be no warning zone, the stack layout is the same as usual. > If the user sets -XX:StackWarningRatio to 50, the VM will protect 50% of the available stack space(let all = available+reserved+yellow+red;) as stack warning zone. When the footprint of available stack space reaches 50%, that is, when the application accesses the stack warning zone, the sigsegv signal will be triggered, and then the signal handler will warn this access in some ways(e.g. send the JFR event, logging) and resume current execution. As a prototype, this feature is only implemented on x86_posix, it can be implemented on more platforms as needed. > > Could anyone give some suggestions? If you think this is a useful feature, I will file an issue and support it on all platforms. Looking forward to your comments. How do you actually envisage people using this? This seems more of a tuning option, but you can tune just as readily by adjusting -Xss in the same manner you would set the warning ratio. I.e. you'd like to shrink your stack usage but are not sure how small you can make it safely so you can either just reduce -Xss and see if it works, or you can set the warning ratio to give the same effective -Xss and see if you get a warning. The flag would need to be diagnostic rather than full product. Cheers, David > Patch: https://github.com/kelthuzadx/jdk/commit/a145b2ebb4ac568e3bb090cbe3e7f091e1dc69ea > Diff: https://github.com/kelthuzadx/jdk/compare/37dc675..a145b2e > > Best, > Yang Yi > From thomas.stuefe at gmail.com Tue Dec 15 07:24:49 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 15 Dec 2020 08:24:49 +0100 Subject: A solution to detect the footprint of Java thread stack In-Reply-To: <94dc25af-5a11-4414-bcba-45eca74014fc.qingfeng.yy@alibaba-inc.com> References: <94dc25af-5a11-4414-bcba-45eca74014fc.qingfeng.yy@alibaba-inc.com> Message-ID: Hi Yang Yi, it sounds interesting, but I am not yet sure how useful this will be in the proposed form. I may misunderstand the proposal, but is this a one-shot solution? So the first time we reach the warning zone we get a warning, zone gets disabled, never gets enabled again? We have that warning in UL and JFR, but we do not have any context. Looking from outside at all threads, some will have their warning zone disabled, some not. We have the information that a thread reached the warning level, but not when and what it did then, no? It could have been a short spike in the deep past, never to reoccur, or it could be a permanent high stack usage. I think especially for long-running worker threads which have many different workloads this may limit its usefulness. If it is only to measure stack sizes, would a solution in JFR which iterates the stacks of threads periodically and measures the real used stack (as NMT does it, using mincore()) not better? That would be somewhat simpler to implement, would not be a one-shot solution, would not be bound to one warning level, would get more precise information, and would not rely on page granularity. About that, the warning zone may increase the stack size for platforms with larger base page sizes (eg PPC) where we have 64K pages. Cheers, Thomas On Mon, Dec 14, 2020 at 6:03 AM ??(??) wrote: > Hi all, > We occasionally get stack overflow errors if the application has too many > deep callings. The usual solution is to increase -Xss, but there is no > guiding opinion telling us in advance that the thread stack space is not > enough. This patch attempts to address this issue. It introduces a new > stack zone(warning_zone) for Hotspot VM, which can be used to detect > whether the footprint ratio of the thread stack has reached the watermark > set by the user. > > The current stack layout is as follows: > stack_base > stack_end > > --------------------------------------------------------------------------------------------------------------------------- > | | shadow zone | warning zone(added) > | reserved zone | yellow zone | red zone | > > --------------------------------------------------------------------------------------------------------------------------- > ^rsp |<-StackWarningRatio % of available stack-> > > Users can set the option -XX:StackWarningRatio=0 to turn off this > feature(which is also the default value) and there will be no warning zone, > the stack layout is the same as usual. > If the user sets -XX:StackWarningRatio to 50, the VM will protect 50% of > the available stack space(let all = available+reserved+yellow+red;) as > stack warning zone. When the footprint of available stack space reaches > 50%, that is, when the application accesses the stack warning zone, the > sigsegv signal will be triggered, and then the signal handler will warn > this access in some ways(e.g. send the JFR event, logging) and resume > current execution. As a prototype, this feature is only implemented on > x86_posix, it can be implemented on more platforms as needed. > > Could anyone give some suggestions? If you think this is a useful feature, > I will file an issue and support it on all platforms. Looking forward to > your comments. > > Patch: > https://github.com/kelthuzadx/jdk/commit/a145b2ebb4ac568e3bb090cbe3e7f091e1dc69ea > Diff: https://github.com/kelthuzadx/jdk/compare/37dc675..a145b2e > > Best, > Yang Yi > From david.holmes at oracle.com Tue Dec 15 07:26:56 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Dec 2020 17:26:56 +1000 Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJlOiBBIHNvbHV0aW9uIHRvIGRldGVjdCB0aGUg?= =?UTF-8?Q?footprint_of_Java_thread_stack?= In-Reply-To: References: <94dc25af-5a11-4414-bcba-45eca74014fc.qingfeng.yy@alibaba-inc.com> <1e423c3c-fac3-268e-f4f6-8d9f1a2cea51@oracle.com> Message-ID: <84812ffc-7947-da4c-15b0-9f38ed2c6615@oracle.com> Hi, On 15/12/2020 5:02 pm, Yang Yi wrote: > Hi?David, > > Thank?you?for?your?comments. > > >?How?do?you?actually?envisage?people?using?this??This?seems?more?of?a > >?tuning?option,?but?you?can?tune?just?as?readily?by?adjusting?-Xss?in?the > >?same?manner?you?would?set?the?warning?ratio.?I.e.?you'd?like?to?shrink > >?your?stack?usage?but?are?not?sure?how?small?you?can?make?it?safely?so > >?you?can?either?just?reduce?-Xss?and?see?if?it?works,?or?you?can?set?the > >?warning?ratio?to?give?the?same?effective?-Xss?and?see?if?you?get?a?warning. > > Yes, we can indeed achieve similar goals by constantly adjusting > -Xss, but adjusting -Xss is generally a way to make the application work > again after StackOverflowError occurs. The purpose of > -XX:StackWarningRatio is to warn early before StackOverflowError occurs. But the problem there is that triggering the warning does not indicate that a stackoverflow will in fact occur. It will only tell whether you used a given percentage of your stack, not how much you have actually used. So how does this help you avoid stackoverflow? If you used the warning to increase -Xss without ever encountering stackoverflow then you are just wasting memory and potentially reducing the number of threads you can support. Cheers, David > Based on my experience and observation, many developers use the default > value of ThreadStackSize(the default value of is 1M on linux_x86), they > will not adjust the value of this option unless a stack overflow occurs. > With the iterative development of the application, the size of the stack > may no longer meet the demand. It's helpful to warn about insufficient > stack space earlier in case of hurriedly troubleshooting and adjusting > the -Xss when the application throws StackOverflowError in the > production environment. > > > >?The?flag?would?need?to?be?diagnostic?rather?than?full?product. > > Accept. > > Best, > Yang?Yi > > ------------------------------------------------------------------ > ????David Holmes > ????2020?12?15? 13:24:54 > ????Yang Yi; HotSpot Open Source > Developers; > hotspot-jfr-dev > ????Re: A solution to detect the footprint of Java thread stack > > Hi?Yang?Yi, > > On?14/12/2020?3:03?pm,???(??)?wrote: > >?Hi?all, > >?We?occasionally?get?stack?overflow?errors?if?the?application?has?too?many?deep?callings.?The?usual?solution?is?to?increase?-Xss,?but?there?is?no?guiding?opinion?telling?us?in?advance?that?the?thread?stack?space?is?not?enough.?This?patch?attempts?to?address?this?issue.?It?introduces?a?new?stack?zone(warning_zone)?for?Hotspot?VM,?which?can?be?used?to?detect?whether?the?footprint?ratio?of?the?thread?stack?has?reached?the?watermark?set?by?the?user. > > > >?The?current?stack?layout?is?as?follows: > >?stack_base????????????????????????????????????????????????????????????????????????????????????stack_end > >?--------------------------------------------------------------------------------------------------------------------------- > >?|????????|???shadow?zone?|???????????????????warning?zone(added)???????????????????|?reserved?zone?|?yellow?zone?|?red?zone?| > >?--------------------------------------------------------------------------------------------------------------------------- > >???????????^rsp???????????????????|<-StackWarningRatio?%?of?available?stack-> > > > >?Users?can?set?the?option?-XX:StackWarningRatio=0?to?turn?off?this?feature(which?is?also?the?default?value)?and?there?will?be?no?warning?zone,?the?stack?layout?is?the?same?as?usual. > >?If?the?user?sets?-XX:StackWarningRatio?to?50,?the?VM?will?protect?50%?of?the?available?stack?space(let?all?=?available+reserved+yellow+red;)?as?stack?warning?zone.?When?the?footprint?of?available?stack?space?reaches?50%,?that?is,?when?the?application?accesses?the?stack?warning?zone,?the?sigsegv?signal?will?be?triggered,?and?then?the?signal?handler?will?warn?this?access?in?some?ways(e.g.?send?the?JFR?event,?logging)?and?resume?current?execution.?As?a?prototype,?this?feature?is?only?implemented?on?x86_posix,?it?can?be?implemented?on?more?platforms?as?needed. > > > >?Could?anyone?give?some?suggestions??If?you?think?this?is?a?useful?feature,?I?will?file?an?issue?and?support?it?on?all?platforms.?Looking?forward?to?your?comments. > > How?do?you?actually?envisage?people?using?this??This?seems?more?of?a > tuning?option,?but?you?can?tune?just?as?readily?by?adjusting?-Xss?in?the > > same?manner?you?would?set?the?warning?ratio.?I.e.?you'd?like?to?shrink > your?stack?usage?but?are?not?sure?how?small?you?can?make?it?safely?so > you?can?either?just?reduce?-Xss?and?see?if?it?works,?or?you?can?set?the > warning?ratio?to?give?the?same?effective?-Xss?and?see?if?you?get?a?warning. > > The?flag?would?need?to?be?diagnostic?rather?than?full?product. > > Cheers, > David > > >?Patch:?https://github.com/kelthuzadx/jdk/commit/a145b2ebb4ac568e3bb090cbe3e7f091e1dc69ea > >?Diff:?https://github.com/kelthuzadx/jdk/compare/37dc675..a145b2e > > > >?Best, > >?Yang?Yi > > > From github.com+11656534+maurolacy at openjdk.java.net Tue Dec 15 08:21:56 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Tue, 15 Dec 2020 08:21:56 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: On Fri, 11 Dec 2020 08:39:58 GMT, Mauro Lacy wrote: > Besides, I don't think the same is true of the other `Release` methods. This happens only with the `Critical` variant. Sorry for the confusion. The reported double free error always mentions `ReleasePrimitiveArrayCritical`, but as Dmitry says, this ends up affecting both APIs. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From stuefe at openjdk.java.net Tue Dec 15 09:46:58 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 15 Dec 2020 09:46:58 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 18:29:13 GMT, Yumin Qi wrote: >> Hi, Please review >> (This is redo for https://github.com/openjdk/jdk/pull/1657) >> 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 spaces. To do so, we need release the whole first then do the reserve again on the split, 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, go to other way, but do not do the 'real' split for the whole reserved space, keep the whole region reserved and released as a whole. >> Also fixed issues that when loading shared archive failed, bitmap region should be unmapped or it will cause mismatch in reserved/committed size calculation for NMT. >> Fixed reserved region name for adding committed region for NMT, it should use the reserved region name not "Unknown" the default. >> A test case added for testing the failed case which is caused by mismatch of class path. >> >> Tests:tier1-5,tier7 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fixed os::release message to make test simply check if output containing the message LGTM ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1750 From stuefe at openjdk.java.net Tue Dec 15 09:46:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 15 Dec 2020 09:46:59 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 20:12:06 GMT, Yumin Qi wrote: > Hi, Thomas > > > I don't understand the special handling in NMT. > > Unix: We reserve a region, split it, tell NMT about the split (see posix version of os::split_reserved_memory), then later release both parts separately. > > There is no problem for Linux/Unix here since split does not do the split. > > Windows: > > > > 1. use_archive_base_addr = true: we allocate the spaces separately, later release them separately > > Yes, the two spaces are released separately and NMT will find exact matched regions to remove. > > 2. use_archive_base_addr = false: we allocate total space, leave it unsplit, then later release the total space. > > The space reserved as a whole, and we did not do the 'split' on it. The release should be on whole too. When unmapping regions, the released on region in fact did not do anything in nmt since it is within the archive space. Since the new code is release on the whole space (there is no call to release on class_space_rs in this case), so it check if it is > archive_space_rs (with tag of mtClassShared) we know it is for releasing the whole space. The space which is bigger than archive_space_rs with tag of mtClassShared should be only the whole space. Okay. Lets see if I understand: For (2) and for Unix, we reserve the total area. Then we tell NMT to semantically split it up in two regions (`MemTracker::record_virtual_memory_split_reserved...`) - later we tag the first one with "mtClassShared", the second with "mtClass". Then, if initializing the archive fails, we release now the total area. Since NMT has only the split view, it finds the mtClassShared entry at base address which is of smaller size. We run into the `if (size > reserved_rgn->size()) {` case in `virtualMemoryTracker.cpp:517`. We release both separately. Right? Also: the section at `virtualMemoryTracker.cpp:509` `if (reserved_rgn->contain_region(addr, size)) {` should only be needed for Posix, right? We never should run into the problem that we unmap a section within another section on Windows? So, in theory, we should be able to make this a `WINDOWS_ONLY(ShouldNotReachHere())` ? -- Going forward, I wonder whether NMT should have general support for releasing multiple mappings in one go. Since we introduced the concept of "artificial split" with `MemTracker::record_virtual_memory_split_reserved...` we may want to have now a corresponding "multi-release". Or, Idk, maybe just remove the `MemTracker::record_virtual_memory_split_reserved` and the corresponding code in NMT release? and just live with the fact that for a "shallow split" the numbers in NMT are accounted to the wrong tag (mtClassShared gets mtClass). > > > Where is this new NMT coding needed? > > The code is to make the bytes in snapshot correct. That, when all the spaces release, the bytes in the reserved slot should be 'zero'. > > Thanks for review. The rest looks good AFAICS. For JDK17, I really hope we can simplify and streamline this coding. Maybe if we consider one or two things: - just do File IO always on Windows? I did make a test and I may be wrong but I could not measure any startup performance loss compared to the multiple mappings. - instead of many little mmap calls, just mmap the whole archive right at reservation time alongside the class space reservation. That would increase the chance that everything goes well, and reduce the complexity of the cleanup if it doesn't. What do you think, does that make sense? Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From tschatzl at openjdk.java.net Tue Dec 15 09:57:58 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 15 Dec 2020 09:57:58 GMT Subject: RFR: 8258252: Move PtrQueue enqueue to PtrQueueSet subclasses In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 05:32:07 GMT, Kim Barrett wrote: > Please review this refactoring in the PtrQueue/PtrQueueSet hierarchy. > > The functions PtrQueue::enqueue and PtrQueue::enqueue_known_active are > removed, along with the helper virtual function PtrQueue::handle_completed_buffer. > > Instead we now have G1{Dirty,Redirty}CardQueueSet::enqueue and SATBMarkQueueSet::enqueue/enqueue_known_active, each tailored to the corresponding specific behavior. They use some shared helper routines from PtrQueueSet, and the PtrQueue buffer and index have been made accessible to clients. > > Testing: > mach5 tier1-3, 5 (stress tests) > Local (linux-x64) tier1 with -XX:+UseShenandoahGC Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1776 From aph at redhat.com Tue Dec 15 10:47:33 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Dec 2020 10:47:33 +0000 Subject: RFR: 8256820: AArch64: Optimize vector rotate (immediate) with shift and insert instructions [v2] In-Reply-To: References: Message-ID: <1997e658-c286-32cb-1f87-0907d0248117@redhat.com> On 14/12/2020 11:48, Dong Bo wrote: > We tested this on the two servers we have by hand now. It is a pity > for us that we didn't see performance improvements on `Cortex-A72`. > Because we have detected microarchitecture in the code already, I > thought we could make full use of the flexibility it provided. > > We find the shift and insert instructions are used in Linux OS for > serveral crypto algorithms for all CPUs [1, 2, 3]. I don't want to be unfair to you. There are many small optimizations that we have made for which we don't require large-scale benchmarks. I'm not going to start insisting that every small change shows a gain on such benchmarks. But this patch seems to be very marginal: not only does it offer a modest gain one one machine, it also shows a modest loss on another. Not only that, but we do not know if auto-vectorization is at all effective on these OpenJDK's algorithms. My reason for pushing back here is that I want HotSpot to generate "good" code for all AArch64 platforms, rather than containing special patterns for microarchitectures. There are risks if we allow that. For example, mistakes which affect only one machine might be made by accident, and they cannot be tested by anyone who does not have that machine. Also, the AArch64 back end becomes complex and hard to maintain. For example, a simple mistake made during a critical patch update might break Kunpeng920, and unless everybody tests on all machines, we might not know until it's too late to fix it. So, any change which causes divergence between microarchitectures must be needed, or it isn't worth the risk. It's not in your interest for that to happen, either. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Dec 15 10:50:42 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Dec 2020 10:50:42 +0000 Subject: Embedded JDK how to replace the default allocator In-Reply-To: References: Message-ID: <3e66f47d-0dc2-1fd2-8382-bff007cf5b28@redhat.com> On 14/12/2020 23:08, Guy Korland wrote: > I'm talking about replacing the malloc implementation, we're running on > Linux. > But, the tricky part is that my C application malloc should not be changed, > only the libjvm.so when loaded embedded in my application. Surely that's trivial: you just replace malloc() and its friends with your replacement, and recompile. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at openjdk.java.net Tue Dec 15 11:57:00 2020 From: rkennke at openjdk.java.net (Roman Kennke) Date: Tue, 15 Dec 2020 11:57:00 GMT Subject: RFR: 8258252: Move PtrQueue enqueue to PtrQueueSet subclasses In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 05:32:07 GMT, Kim Barrett wrote: > Please review this refactoring in the PtrQueue/PtrQueueSet hierarchy. > > The functions PtrQueue::enqueue and PtrQueue::enqueue_known_active are > removed, along with the helper virtual function PtrQueue::handle_completed_buffer. > > Instead we now have G1{Dirty,Redirty}CardQueueSet::enqueue and SATBMarkQueueSet::enqueue/enqueue_known_active, each tailored to the corresponding specific behavior. They use some shared helper routines from PtrQueueSet, and the PtrQueue buffer and index have been made accessible to clients. > > Testing: > mach5 tier1-3, 5 (stress tests) > Local (linux-x64) tier1 with -XX:+UseShenandoahGC Looks good to me, and I ran some more Shenandoah tests which also look good. ------------- Marked as reviewed by rkennke (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1776 From coleenp at openjdk.java.net Tue Dec 15 13:06:10 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 13:06:10 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest [v7] In-Reply-To: References: Message-ID: > Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. > > Tested with tier1-3 with product and fastdebug builds. Built with optimized. > > This is for JDK 17. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix tests for windows and macosx pattern matching. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1723/files - new: https://git.openjdk.java.net/jdk/pull/1723/files/95f66587..8d326e9f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1723&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1723&range=05-06 Stats: 10 lines in 3 files changed: 0 ins; 3 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1723.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1723/head:pull/1723 PR: https://git.openjdk.java.net/jdk/pull/1723 From coleenp at openjdk.java.net Tue Dec 15 13:09:55 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 13:09:55 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest [v4] In-Reply-To: <-1VOWEsyDHSYipvoc-H2KiibQ5JYZLE1K7trswjY3kE=.fec88f11-ec23-4253-86b6-01aca41c0a7d@github.com> References: <4QCKlZp1zq8PtQSTAnfIOTa21TG93VQ9r4_ZBO3v7M8=.b7677eb5-902d-4c81-8ee2-cf675488e613@github.com> <4YLRqlqNY99cjiUqxgqktnGEuGiQs3v1FCwt_OqVG64=.50961a9e-76e9-4619-a38d-7018335290a7@github.com> <-1VOWEsyDHSYipvoc-H2KiibQ5JYZLE1K7trswjY3kE=.fec88f11-ec23-4253-86b6-01aca41c0a7d@github.com> Message-ID: On Mon, 14 Dec 2020 14:11:10 GMT, Coleen Phillimore wrote: >>> Hi Thomas, thank you for finding the "last" bug in this. I made the buffer stack allocated and 256. That should be enough and it passes all the gtests. Thanks again. >> >> Thanks Coleen! Looks good now. > > Thanks Thomas, Ioi and Gerard. I remerged with JDK-8257229: gtest death tests fail with unrecognized stderr output to make sure they still worked together. So it turns out that I only tested with linux-x64-debug and not windows and macosx which have slightly different rules for pattern matching. Some of the patterns in the assert(some expression) failed: message didn't match, so I just added .* to the expected message and that worked better. Now I've tested them everywhere. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 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 shade at openjdk.java.net Tue Dec 15 13:55:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Tue, 15 Dec 2020 13:55:58 GMT Subject: Withdrawn: 8253611: AArch64: Concurrency problems in JavaFrameAnchor In-Reply-To: References: Message-ID: On Fri, 25 Sep 2020 07:00:16 GMT, Aleksey Shipilev wrote: > It looks that `_last_Java_sp` is additionally used as acquire/release flag that guards the rest of the state. Yet, the coding in `javaFrameAnchor_aarch64.hpp` is incorrect at least in one place: > > _last_Java_fp = src->_last_Java_fp; > _last_Java_pc = src->_last_Java_pc; > // Must be last so profiler will always see valid frame if has_last_frame() is true > _last_Java_sp = src->_last_Java_sp; > > There should be `OrderAccess::release()` where the comment suggesting the ordering constraint actually is -- I believe that is a copy-paste error from x86. Other platforms have `release` thre. Additionally, it has to be matched with `OrderAccess::acquire()` before `_last_Java_sp` reads, which requires the shared code to use the platform-specific getter. > > Testing: > - [x] Linux x86_64 tier1 > - [x] Linux AArch64 tier1 > - [x] Linux AArch64 tier2 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/352 From github.com+4676506+javeleon at openjdk.java.net Tue Dec 15 13:57:59 2020 From: github.com+4676506+javeleon at openjdk.java.net (Allan Gregersen) Date: Tue, 15 Dec 2020 13:57:59 GMT Subject: Withdrawn: JDK-8253001: [JVMCI] Add API for getting stacktraces independently of current thread In-Reply-To: References: Message-ID: On Thu, 10 Sep 2020 11:52:34 GMT, Allan Gregersen wrote: > The idea is to add a more powerful API for cases where the current iterateFrames API cannot be used. > > For example, a debugger needs access to the content of stack frames such as local variables or monitors. In cases where threads execute in the runtime or in native code, it's not possible to obtain a thread suspension hook, for which iterateFrames can be used on the suspended thread. The getStackFrames method enables an immediate stack frames lookup regardless of the status of the underlying thread. > Another use case would be for lookup of backtraces for non-current threads. > > The implementation is done by means of a VM operation that collects vframe data for each thread during a safepoint, whereafter required object reallocation/reassign fields is performed based on the collected snapshot. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/110 From akozlov at openjdk.java.net Tue Dec 15 14:35:17 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 15 Dec 2020 14:35:17 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v9] In-Reply-To: References: Message-ID: <95S7DbygBemN4yE6wxka4-ETsFJEm4XES-9o6P8Kl78=.3a804e4f-8cbb-4c0e-b58d-6e95c71e511b@github.com> > Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html > > On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, PROT_NONE), the function was made aware of exec permissions. > > For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference compared with old code. > > For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not shrink (if I haven't missed anything, by the implementation and in principle). > > Tested: > * local tier1 > * jdk-submit > * codesign[2] with hardened runtime and allow-jit but without > allow-unsigned-executable-memory entitlements[3] produce a working bundle. > > (adding GC group as suggested by @dholmes-ora) > > > [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 > [2] > > codesign \ > --sign - \ > --options runtime \ > --entitlements ents.plist \ > --timestamp \ > $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib > [3] > > > > > com.apple.security.cs.allow-jit > > com.apple.security.cs.disable-library-validation > > com.apple.security.cs.allow-dyld-environment-variables > > > Anton Kozlov has updated the pull request incrementally with four additional commits since the last revision: - Use exec in os for consistency - Simplify virtualspace - Add exec to attempt_reserve_at - Add default value for uncommit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/294/files - new: https://git.openjdk.java.net/jdk/pull/294/files/31fe1fb0..ec32e144 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=07-08 Stats: 109 lines in 16 files changed: 17 ins; 23 del; 69 mod Patch: https://git.openjdk.java.net/jdk/pull/294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/294/head:pull/294 PR: https://git.openjdk.java.net/jdk/pull/294 From akozlov at openjdk.java.net Tue Dec 15 14:53:11 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 15 Dec 2020 14:53:11 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v10] In-Reply-To: References: Message-ID: > Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html > > On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, PROT_NONE), the function was made aware of exec permissions. > > For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference compared with old code. > > For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not shrink (if I haven't missed anything, by the implementation and in principle). > > Tested: > * local tier1 > * jdk-submit > * codesign[2] with hardened runtime and allow-jit but without > allow-unsigned-executable-memory entitlements[3] produce a working bundle. > > (adding GC group as suggested by @dholmes-ora) > > > [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 > [2] > > codesign \ > --sign - \ > --options runtime \ > --entitlements ents.plist \ > --timestamp \ > $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib > [3] > > > > > com.apple.security.cs.allow-jit > > com.apple.security.cs.disable-library-validation > > com.apple.security.cs.allow-dyld-environment-variables > > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: Update pd_commit_memory on bsd ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/294/files - new: https://git.openjdk.java.net/jdk/pull/294/files/ec32e144..e40337e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=08-09 Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/294/head:pull/294 PR: https://git.openjdk.java.net/jdk/pull/294 From akozlov at openjdk.java.net Tue Dec 15 15:31:58 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 15 Dec 2020 15:31:58 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v8] In-Reply-To: References: Message-ID: On Sat, 12 Dec 2020 09:29:08 GMT, Thomas Stuefe wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update style > > Hi Anton, > > 1) can you please make the executable parameter on os::uncommit() default false? Lets minimize the impact for the vast majority of callers which do not need protected memory. The only caller needing this is ReservedSpace. Would also be more in sync with the default false for executable on os::reserve(). > > 2) Personal nit, I really find this `ExecMem` jarring. We don't do this (pass named aliases for boolean flags) for any other arguments AFAICS. The usual way to emphasize arg names is with comments: > bool result = os::commit_memory(base, size, /*exec*/ false); > If you still prefer to use it, could you leave at least those places unchanged which are unaffected by your patch? > > 3) There is some code explicitly dealing with the supposed inability of attempt_reserve_memory_at() using MAP_JIT. I don't understand. I thought the problem was thjat MAP_JIT and MAP_FIXED don't mix. But attempt_reserve_memory_at() does explicitely not use MAP_FIXED, it just attempts to map at a non-null wish address. Does that also not work with MAP_JIT? > > 4) For my taste there are too many unrelated changes, especially in ReservedSpace. Making all those file scope static helpers members of ReservedSpace causes a lot of diffs. Makes sense cleanup-wise but will make backporting your patch more difficult later (I expect this will be a strong candidate for backporting). Please tone down the patch a bit. I pointed some parts out directly below. Beyond those, I leave it up to you how far you minimize the patch. > > Thanks, Thomas Hi Thomas, Thank you for review! > 1. can you please make the executable parameter on os::uncommit() default false? Ok, fixed. > 2. Personal nit, I really find this `ExecMem` jarring. > If you still prefer to use it, could you leave at least those places unchanged which are unaffected by your patch? The only two places where I had to replace false with !ExecMem are https://github.com/openjdk/jdk/pull/294/files#diff-80d6a105c4da7337cbc8c4602c8a1582c6a1beb771797e1a84928bd864afe563R105 It would be really inconsistent to maintain them as char* base = os::reserve_memory(size, !ExecMem, mtThreadStack); bool result = os::commit_memory(base, size, false); (Please note that the false without comment didn't obey any style, so I had to fix these anyway) > 3. There is some code explicitly dealing with the supposed inability of attempt_reserve_memory_at() using MAP_JIT. I don't understand. I thought the problem was thjat MAP_JIT and MAP_FIXED don't mix. But attempt_reserve_memory_at() does explicitely not use MAP_FIXED, it just attempts to map at a non-null wish address. Does that also not work with MAP_JIT? Interesting and funny, it does work. I would expected it does not (due to security reasons I could image behind forbidding MAP_JIT|MAP_FIXED). But since it works for now, I've added the executable parameter to attemp_reserve_memory_at as well. > 2. For my taste there are too many unrelated changes, especially in ReservedSpace. Making all those file scope static helpers members of ReservedSpace causes a lot of diffs. Makes sense cleanup-wise but will make backporting your patch more difficult later (I expect this will be a strong candidate for backporting). Please tone down the patch a bit. I pointed some parts out directly below. Beyond those, I leave it up to you how far you minimize the patch. Ok, it is possible to do the clean up after. Thanks for your comment, I'll account them in the future clean-up RFR. Thanks, Anton ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From akozlov at openjdk.java.net Tue Dec 15 15:36:57 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 15 Dec 2020 15:36:57 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v8] In-Reply-To: References: Message-ID: On Sat, 12 Dec 2020 07:52:45 GMT, Thomas Stuefe wrote: >> src/hotspot/os/bsd/os_bsd.cpp line 1690: >> >>> 1688: if (::mprotect(addr, size, prot) == 0) { >>> 1689: return true; >>> 1690: } >> >> You need to handle mprotect failure here too. Probably just by returning false. There is no point in doing the mmap below as fallback. The same applies for the OpenBSD path too. >> >> mprotect may, at least on Linux, fail if the new mapping introduced by changing the protection would bring the process above the system limit for numbrer of mappings. I strongly believe there must be a similar error scenario on Mac. At least on BSD there is (https://man.openbsd.org/mprotect.2), see ENOMEM. > > Also, this is asymetric to uncommit now for the !exec case. There, we mmap(MAP_NORESERVE, PROT_NONE). We have established that MAP_NORESERVE is a noop, so this would be probably fine. Still, I'd do the mmap(PROT_RW) for commit instead for !exec: > > if (exec) > // Do not replace MAP_JIT mappings, see JDK-8234930 > return mprotect() == 0; > } else { > mmap ... > } > If not, I would remove MAP_NORESERVE from this code. > You need to handle mprotect failure here too. They are handled later https://github.com/openjdk/jdk/pull/294/files#diff-1f93205c2e57bee432f8fb7a0725ba1dfdbe5b901ac63010ea0b43922e34ac12R1708 > Also, this is asymetric to uncommit now for the !exec case. Still, I'd do the mmap(PROT_RW) for commit instead for !exec: Thanks, this looks good, I've applied the suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From minqi at openjdk.java.net Tue Dec 15 15:48:57 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 15 Dec 2020 15:48:57 GMT Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" [v3] In-Reply-To: References: Message-ID: <8AtNwG4CzF7sU284kAF3iR8vf97NizG43RTkDeSQOb8=.e9077bc7-d1a3-4384-9395-d5cd9656e286@github.com> On Tue, 15 Dec 2020 09:44:00 GMT, Thomas Stuefe wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed os::release message to make test simply check if output containing the message > > LGTM @tstuefe Thanks for review, next os::split_reserved_memory will be removed (https://bugs.openjdk.java.net/browse/JDK-8256213). ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From hseigel at openjdk.java.net Tue Dec 15 15:50:04 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 15 Dec 2020 15:50:04 GMT Subject: RFR: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses Message-ID: Please review this small fix for JDK-8257700 to add logging to JVM_GetPermittedSubclasses(). The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS, and WIndows, tiers 3-5 on Linux x64, and by running the hotspot runtime sealed tests with -Xlog:class+sealed=trace and looking at the output. Thanks, Harold ------------- Commit messages: - 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses Changes: https://git.openjdk.java.net/jdk/pull/1780/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1780&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257700 Stats: 19 lines in 1 file changed: 18 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1780.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1780/head:pull/1780 PR: https://git.openjdk.java.net/jdk/pull/1780 From stuefe at openjdk.java.net Tue Dec 15 16:09:00 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 15 Dec 2020 16:09:00 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v10] In-Reply-To: References: Message-ID: <2i6S1b7ul-EJ9WyiCHGIAAiwPcnybhFQ1cAYhd52EQU=.fd1905d3-af3d-451d-885d-2f5758603a5f@github.com> On Tue, 15 Dec 2020 14:53:11 GMT, Anton Kozlov wrote: >> Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html >> >> On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, PROT_NONE), the function was made aware of exec permissions. >> >> For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference compared with old code. >> >> For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not shrink (if I haven't missed anything, by the implementation and in principle). >> >> Tested: >> * local tier1 >> * jdk-submit >> * codesign[2] with hardened runtime and allow-jit but without >> allow-unsigned-executable-memory entitlements[3] produce a working bundle. >> >> (adding GC group as suggested by @dholmes-ora) >> >> >> [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 >> [2] >> >> codesign \ >> --sign - \ >> --options runtime \ >> --entitlements ents.plist \ >> --timestamp \ >> $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib >> [3] >> >> >> >> >> com.apple.security.cs.allow-jit >> >> com.apple.security.cs.disable-library-validation >> >> com.apple.security.cs.allow-dyld-environment-variables >> >> >> > > Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Update pd_commit_memory on bsd > Hi Thomas, > > Thank you for review! > > > 1. can you please make the executable parameter on os::uncommit() default false? > > Ok, fixed. Thanks! > > > 1. Personal nit, I really find this `ExecMem` jarring. > > If you still prefer to use it, could you leave at least those places unchanged which are unaffected by your patch? > > The only two places where I had to replace false with !ExecMem are https://github.com/openjdk/jdk/pull/294/files#diff-80d6a105c4da7337cbc8c4602c8a1582c6a1beb771797e1a84928bd864afe563R105 > > It would be really inconsistent to maintain them as > > ``` > char* base = os::reserve_memory(size, !ExecMem, mtThreadStack); > bool result = os::commit_memory(base, size, false); > ``` > > (Please note that the false without comment didn't obey any style, so I had to fix these anyway) Okay. > > > 1. There is some code explicitly dealing with the supposed inability of attempt_reserve_memory_at() using MAP_JIT. I don't understand. I thought the problem was thjat MAP_JIT and MAP_FIXED don't mix. But attempt_reserve_memory_at() does explicitely not use MAP_FIXED, it just attempts to map at a non-null wish address. Does that also not work with MAP_JIT? > > Interesting and funny, it does work. I would expected it does not (due to security reasons I could image behind forbidding MAP_JIT|MAP_FIXED). But since it works for now, I've added the executable parameter to attemp_reserve_memory_at as well. I am not that surprised. Wish address != NULL with MAP_FIXED=0 just establishes a brand new mapping, does not change an existing mapping. I think they just forbid to modify existing mappings with MAP_JIT once established. > > > 1. For my taste there are too many unrelated changes, especially in ReservedSpace. Making all those file scope static helpers members of ReservedSpace causes a lot of diffs. Makes sense cleanup-wise but will make backporting your patch more difficult later (I expect this will be a strong candidate for backporting). Please tone down the patch a bit. I pointed some parts out directly below. Beyond those, I leave it up to you how far you minimize the patch. > > Ok, it is possible to do the clean up after. Thanks for your comment, I'll account them in the future clean-up RFR. > Great, thanks, the change looks much cleaner now. > Thanks, > Anton There are two remaining very minor nits, I leave it up to you if you fix them. From my eyes this is fine. ----- I think we should shake up that coding at some point and improve the API. I imagine something along the line of struct mappinginfo_t { pagesize, // may be dynamically chosen by the OS layer but caller wants to know exec, base, size, ... // maybe + maybe opaque OS specific information }; address os::reserve_xxxx(size, ..., reservation_info_t* p_info = NULL); bool os::commit_memory(addr, size, const reservation_info_t* info); bool os::commit_memory(addr, size, const reservation_info_t* info); The concrete form can be shaped however, but the base idea is to return more information than just the reservation pointer: - some attributes may be chosen or adapted by os::reserve_... (eg PageSize), but caller could just be told to spare him having to second-guess os::reserve_memory_special(). - some attributes may be only interesting to the os layer, so they can be opaque for the caller - but caller could hold onto that information until commit/uncommit. Examples for that are AIX: mmap-or-shmat , or Windows: NUMA-striped-allocation or not. - some information may be caller specified (eg exec) but returning this in a handle-like structure relieves the caller from holding on to that particular information, and having to pass each argument separately- I know this is crossing territory into what ReservedSpace does today, but that class is quite polluted with VM specific stuff, eg that noaccess zone. Well, lets see how this goes. Thanks alot for your perseverance! Cheers, Thomas test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp line 172: > 170: const size_t num_pages = 4; > 171: const size_t size = num_pages * page_sz; > 172: char* base = os::reserve_memory(size, !ExecMem, mtTest); This test function seems to leak this reservation. I leave it up to you if you want to fix it, has nothing to do with your test. If you don't could you please open a issue for this? (Took me some minutes to figure out that all these tests are NMT related) src/hotspot/os/windows/os_windows.cpp line 3271: > 3269: > 3270: char* os::reserve_memory_aligned(size_t size, size_t alignment, bool exec) { > 3271: // exec can be ignored Change to "Support for exec not implemented" ? (Maybe even with an assert) (Or - leave that up to you - leave this parameter out of os::reserve_memory_aligned completely.) ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/294 From minqi at openjdk.java.net Tue Dec 15 16:55:58 2020 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 15 Dec 2020 16:55:58 GMT Subject: Integrated: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 20:06:34 GMT, Yumin Qi wrote: > Hi, Please review > (This is redo for https://github.com/openjdk/jdk/pull/1657) > 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 spaces. To do so, we need release the whole first then do the reserve again on the split, 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, go to other way, but do not do the 'real' split for the whole reserved space, keep the whole region reserved and released as a whole. > Also fixed issues that when loading shared archive failed, bitmap region should be unmapped or it will cause mismatch in reserved/committed size calculation for NMT. > Fixed reserved region name for adding committed region for NMT, it should use the reserved region name not "Unknown" the default. > A test case added for testing the failed case which is caused by mismatch of class path. > > Tests:tier1-5,tier7 This pull request has now been integrated. Changeset: 36e20974 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/36e20974 Stats: 190 lines in 8 files changed: 143 ins; 10 del; 37 mod 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region" Reviewed-by: ccheung, iklam, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1750 From akozlov at openjdk.java.net Tue Dec 15 17:32:01 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 15 Dec 2020 17:32:01 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v10] In-Reply-To: <2i6S1b7ul-EJ9WyiCHGIAAiwPcnybhFQ1cAYhd52EQU=.fd1905d3-af3d-451d-885d-2f5758603a5f@github.com> References: <2i6S1b7ul-EJ9WyiCHGIAAiwPcnybhFQ1cAYhd52EQU=.fd1905d3-af3d-451d-885d-2f5758603a5f@github.com> Message-ID: On Tue, 15 Dec 2020 15:41:43 GMT, Thomas Stuefe wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update pd_commit_memory on bsd > > test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp line 172: > >> 170: const size_t num_pages = 4; >> 171: const size_t size = num_pages * page_sz; >> 172: char* base = os::reserve_memory(size, !ExecMem, mtTest); > > This test function seems to leak this reservation. I leave it up to you if you want to fix it, has nothing to do with your test. If you don't could you please open a issue for this? > > (Took me some minutes to figure out that all these tests are NMT related) Right. Tracked in https://bugs.openjdk.java.net/browse/JDK-8258415, probably it's worth review tests for similar issues ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From lfoltan at openjdk.java.net Tue Dec 15 17:36:00 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Tue, 15 Dec 2020 17:36:00 GMT Subject: RFR: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses In-Reply-To: References: Message-ID: <_8XvbFc-FhZKiHvJeolfp8MmijIwRLk3Z-f7f2lOIB8=.1f1bbda5-7005-46ac-acef-501593b1dc94@github.com> On Tue, 15 Dec 2020 15:45:25 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8257700 to add logging to JVM_GetPermittedSubclasses(). The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS, and WIndows, tiers 3-5 on Linux x64, and by running the hotspot runtime sealed tests with -Xlog:class+sealed=trace and looking at the output. > > Thanks, Harold Looks good, one minor comment. Lois src/hotspot/share/prims/jvm.cpp line 2179: > 2177: return (jobjectArray)JNIHandles::make_local(THREAD, result()); > 2178: } else { > 2179: log_trace(class, sealed)("Type %s is not sealed", ik->external_name()); I would remove this line in favor of adding adding an indication of sealed or not sealed to line #2129. See my suggested change above. src/hotspot/share/prims/jvm.cpp line 2129: > 2127: assert(c->is_instance_klass(), "must be"); > 2128: InstanceKlass* ik = InstanceKlass::cast(c); > 2129: log_trace(class, sealed)("Calling GetPermittedSubclasses for type %s", ik->external_name()); Consider adding a sealed indication to this log_trace which would allow you to delete line #2179. Something like: ("Calling GetPermittedSubclasses for %s type %s", ik->external_name(), (ik->is_sealed() ? "sealed" : "non-sealed")) ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1780 From akozlov at openjdk.java.net Tue Dec 15 17:43:02 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 15 Dec 2020 17:43:02 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v10] In-Reply-To: <2i6S1b7ul-EJ9WyiCHGIAAiwPcnybhFQ1cAYhd52EQU=.fd1905d3-af3d-451d-885d-2f5758603a5f@github.com> References: <2i6S1b7ul-EJ9WyiCHGIAAiwPcnybhFQ1cAYhd52EQU=.fd1905d3-af3d-451d-885d-2f5758603a5f@github.com> Message-ID: On Tue, 15 Dec 2020 15:44:26 GMT, Thomas Stuefe wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update pd_commit_memory on bsd > > src/hotspot/os/windows/os_windows.cpp line 3271: > >> 3269: >> 3270: char* os::reserve_memory_aligned(size_t size, size_t alignment, bool exec) { >> 3271: // exec can be ignored > > Change to "Support for exec not implemented" ? (Maybe even with an assert) (Or - leave that up to you - leave this parameter out of os::reserve_memory_aligned completely.) Actually, since exec and non-exec reservations are equal on windows, ignoring exec is a correct implementation. Assert would not fit here. Please let me know if the comment fails to deliver this message. Also, I have a prototype implementation of CDS support for macOS/AArch64 and it needs executable aligned mapping, I think we'll need this parameter anyway. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From stuefe at openjdk.java.net Tue Dec 15 17:49:59 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 15 Dec 2020 17:49:59 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v10] In-Reply-To: References: <2i6S1b7ul-EJ9WyiCHGIAAiwPcnybhFQ1cAYhd52EQU=.fd1905d3-af3d-451d-885d-2f5758603a5f@github.com> Message-ID: On Tue, 15 Dec 2020 17:40:39 GMT, Anton Kozlov wrote: >> src/hotspot/os/windows/os_windows.cpp line 3271: >> >>> 3269: >>> 3270: char* os::reserve_memory_aligned(size_t size, size_t alignment, bool exec) { >>> 3271: // exec can be ignored >> >> Change to "Support for exec not implemented" ? (Maybe even with an assert) (Or - leave that up to you - leave this parameter out of os::reserve_memory_aligned completely.) > > Actually, since exec and non-exec reservations are equal on windows, ignoring exec is a correct implementation. Assert would not fit here. Please let me know if the comment fails to deliver this message. Also, I have a prototype implementation of CDS support for macOS/AArch64 and it needs executable aligned mapping, I think we'll need this parameter anyway. Okay, leave it as it is. ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From iklam at openjdk.java.net Tue Dec 15 17:51:00 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 15 Dec 2020 17:51:00 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest [v7] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 13:06:10 GMT, Coleen Phillimore wrote: >> Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. >> >> Tested with tier1-3 with product and fastdebug builds. Built with optimized. >> >> This is for JDK 17. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests for windows and macosx pattern matching. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1723 From stuefe at openjdk.java.net Tue Dec 15 17:58:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 15 Dec 2020 17:58:56 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest [v7] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 13:06:10 GMT, Coleen Phillimore wrote: >> Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. >> >> Tested with tier1-3 with product and fastdebug builds. Built with optimized. >> >> This is for JDK 17. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix tests for windows and macosx pattern matching. Looks good! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1723 From akozlov at openjdk.java.net Tue Dec 15 18:03:00 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 15 Dec 2020 18:03:00 GMT Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v10] In-Reply-To: <2i6S1b7ul-EJ9WyiCHGIAAiwPcnybhFQ1cAYhd52EQU=.fd1905d3-af3d-451d-885d-2f5758603a5f@github.com> References: <2i6S1b7ul-EJ9WyiCHGIAAiwPcnybhFQ1cAYhd52EQU=.fd1905d3-af3d-451d-885d-2f5758603a5f@github.com> Message-ID: <2aPTSZ_1FPGC9oQPQ-CSfxm7C6QfE6PcgF_zOxdwSjU=.b3767b8c-8e27-4317-9b7c-35ed85df58fc@github.com> On Tue, 15 Dec 2020 16:06:23 GMT, Thomas Stuefe wrote: >> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Update pd_commit_memory on bsd > >> Hi Thomas, >> >> Thank you for review! >> >> > 1. can you please make the executable parameter on os::uncommit() default false? >> >> Ok, fixed. > > Thanks! > >> >> > 1. Personal nit, I really find this `ExecMem` jarring. >> > If you still prefer to use it, could you leave at least those places unchanged which are unaffected by your patch? >> >> The only two places where I had to replace false with !ExecMem are https://github.com/openjdk/jdk/pull/294/files#diff-80d6a105c4da7337cbc8c4602c8a1582c6a1beb771797e1a84928bd864afe563R105 >> >> It would be really inconsistent to maintain them as >> >> ``` >> char* base = os::reserve_memory(size, !ExecMem, mtThreadStack); >> bool result = os::commit_memory(base, size, false); >> ``` >> >> (Please note that the false without comment didn't obey any style, so I had to fix these anyway) > > Okay. > >> >> > 1. There is some code explicitly dealing with the supposed inability of attempt_reserve_memory_at() using MAP_JIT. I don't understand. I thought the problem was thjat MAP_JIT and MAP_FIXED don't mix. But attempt_reserve_memory_at() does explicitely not use MAP_FIXED, it just attempts to map at a non-null wish address. Does that also not work with MAP_JIT? >> >> Interesting and funny, it does work. I would expected it does not (due to security reasons I could image behind forbidding MAP_JIT|MAP_FIXED). But since it works for now, I've added the executable parameter to attemp_reserve_memory_at as well. > > I am not that surprised. Wish address != NULL with MAP_FIXED=0 just establishes a brand new mapping, does not change an existing mapping. I think they just forbid to modify existing mappings with MAP_JIT once established. > >> >> > 1. For my taste there are too many unrelated changes, especially in ReservedSpace. Making all those file scope static helpers members of ReservedSpace causes a lot of diffs. Makes sense cleanup-wise but will make backporting your patch more difficult later (I expect this will be a strong candidate for backporting). Please tone down the patch a bit. I pointed some parts out directly below. Beyond those, I leave it up to you how far you minimize the patch. >> >> Ok, it is possible to do the clean up after. Thanks for your comment, I'll account them in the future clean-up RFR. >> > > Great, thanks, the change looks much cleaner now. > >> Thanks, >> Anton > > There are two remaining very minor nits, I leave it up to you if you fix them. From my eyes this is fine. > > ----- > > I think we should shake up that coding at some point and improve the API. I imagine something along the line of > > struct mappinginfo_t { > pagesize, // may be dynamically chosen by the OS layer but caller wants to know > exec, > base, size, ... // maybe > + maybe opaque OS specific information > }; > address os::reserve_xxxx(size, ..., reservation_info_t* p_info = NULL); > bool os::commit_memory(addr, size, const reservation_info_t* info); > bool os::commit_memory(addr, size, const reservation_info_t* info); > > The concrete form can be shaped however, but the base idea is to return more information than just the reservation pointer: > - some attributes may be chosen or adapted by os::reserve_... (eg PageSize), but caller could just be told to spare him having to second-guess os::reserve_memory_special(). > - some attributes may be only interesting to the os layer, so they can be opaque for the caller - but caller could hold onto that information until commit/uncommit. Examples for that are AIX: mmap-or-shmat , or Windows: NUMA-striped-allocation or not. > - some information may be caller specified (eg exec) but returning this in a handle-like structure relieves the caller from holding on to that particular information, and having to pass each argument separately- > > I know this is crossing territory into what ReservedSpace does today, but that class is quite polluted with VM specific stuff, eg that noaccess zone. Well, lets see how this goes. > > Thanks alot for your perseverance! > > Cheers, Thomas Thomas, thank you very much for all the comments, insights, and all of your time. I think a have a good queue of future enhancements from various approaches we've discussed and tried, small and big ones :) ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From gkorland at gmail.com Tue Dec 15 18:24:48 2020 From: gkorland at gmail.com (Guy Korland) Date: Tue, 15 Dec 2020 20:24:48 +0200 Subject: Embedded JDK how to replace the default allocator In-Reply-To: References: Message-ID: > you are still not very forthcoming with information, so we don't know what your goal is. Total isolation of all allocations? Or just monitoring? Is partial isolation okay? Sorry for not being clear, we are trying to build an extension to Redis that will run an embedded JVM. In order to allow Redis monitor all the memory allocated by the JVM we need to make sure all the allocation are going through Redis allocation commands. We already managed to do it in the past with other VMs like CPython, WSAM & Lua, but didn't find an easy way to set it in OpenJDK. Regards, Guy Korland On Tue, Dec 15, 2020 at 8:54 AM Thomas St?fe wrote: > Hi, > > you are still not very forthcoming with information, so we don't know what > your goal is. Total isolation of all allocations? Or just monitoring? Is > partial isolation okay? > > Since I do not know what you need, here are some hints: > > - majority of allocations of a VM are not done via C-Heap but via virtual > memory APIs like mmap() or SystemV shm(). > > - C Heap allocations from the hotspot itself could be redirected, since > they go through the os::malloc... layer. I believe this also takes care of > C++ allocations > > - However, that is only a small part of all allocations, since any library > loaded via JNI (including both the JDK libraries themselves as well as any > third party JNI libraries we don't have control over) rolls their own > memory management by calling malloc or C++ new or mmap or... directly. > > - Also note that there may be places in the hotspot where C heap allocated > pointers are kept in a hashmap, and radically changing how the pointers > look like (different allocator) may mess with the efficiency of those hash > functions. > > So if you need total isolation, the only realistic way is as David > described: use LD_PRELOAD and provide redirections for all system level > APIs which allocate memory. > > The problem with redirecting C-Heap allocations at that level however is > that if you override free() you need to have perfect coverage of all > allocating APIs. These are not limited to malloc/calloc/free etc but there > are a number of other APIs which return their results in C-Heap allocated > buffers. And I have no idea honestly how to redirect C++ allocations via > LD_PRELOAD. > > Cheers, Thomas > > > On Tue, Dec 15, 2020 at 12:08 AM Guy Korland wrote: > >> >> I'm talking about replacing the malloc implementation, we're running on >> Linux. >> But, the tricky part is that my C application malloc should not be >> changed, only the libjvm.so when loaded embedded in my application. >> >> Regards, >> Guy Korland >> >> >> On Sun, Dec 13, 2020 at 12:15 PM Thomas St?fe >> wrote: >> >>> Hi Guy, >>> >>> What do you mean by default allocator? C-Heap? Mmap/shmat? And what OS >>> are you targeting? >>> >>> Cheers, Thomas >>> >>> On Fri, Dec 11, 2020 at 9:49 PM Guy Korland wrote: >>> >>>> Hi, >>>> >>>> I'm sorry if that is not the right mailing list for such questions, >>>> please >>>> point me to the right one if it's not. >>>> >>>> We're embedding the OpenJDK in a C application, we already managed to >>>> make >>>> it work and run Java bytecode, but we are still missing one last piece, >>>> we >>>> need a way to replace the default memory allocator to use our allocator. >>>> >>>> Is there a way to do it? >>>> >>>> Thanks, >>>> Guy Korland >>>> >>> From thomas.stuefe at gmail.com Tue Dec 15 18:36:54 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 15 Dec 2020 19:36:54 +0100 Subject: Embedded JDK how to replace the default allocator In-Reply-To: References: Message-ID: Yes, that is not so easy, as I wrote. If you only care for C heap, an approximation would be to hook into os::malloc/os::free etc and do your counting there. See hotspot/share/runtime/os.hpp/cpp. This only gives you C-heap usage from the hotspot, but leaves out memory managed via mmap, and thread stacks, and memory allocated from JDK libraries. Another way would be to somehow use NMT (Native Memory Tracking). Look it up, or play around with -XX:NativeMemoryTracking. NMT tracks native memory usage from the hotspot quite completely, including mmap (which includes the java heap too) and thread stacks, depending on JDK version. You'd be still in the dark about usage from JDK libraries, but it's a start. You could print the NMT report into memory and parse that for your information. Cheers, Thomas On Tue, Dec 15, 2020 at 7:25 PM Guy Korland wrote: > > you are still not very forthcoming with information, so we don't know > what your goal is. Total isolation of all allocations? Or just monitoring? > Is partial isolation okay? > > Sorry for not being clear, we are trying to build an extension to Redis > that will run an embedded JVM. In order to allow Redis monitor all the > memory allocated by the JVM we need to make sure all the allocation are > going through Redis allocation commands. > We already managed to do it in the past with other VMs like CPython, WSAM > & Lua, but didn't find an easy way to set it in OpenJDK. > > > Regards, > Guy Korland > > > On Tue, Dec 15, 2020 at 8:54 AM Thomas St?fe > wrote: > >> Hi, >> >> you are still not very forthcoming with information, so we don't know >> what your goal is. Total isolation of all allocations? Or just monitoring? >> Is partial isolation okay? >> >> Since I do not know what you need, here are some hints: >> >> - majority of allocations of a VM are not done via C-Heap but via virtual >> memory APIs like mmap() or SystemV shm(). >> >> - C Heap allocations from the hotspot itself could be redirected, since >> they go through the os::malloc... layer. I believe this also takes care of >> C++ allocations >> >> - However, that is only a small part of all allocations, since any >> library loaded via JNI (including both the JDK libraries themselves as well >> as any third party JNI libraries we don't have control over) rolls their >> own memory management by calling malloc or C++ new or mmap or... directly. >> >> - Also note that there may be places in the hotspot where C heap >> allocated pointers are kept in a hashmap, and radically changing how the >> pointers look like (different allocator) may mess with the efficiency of >> those hash functions. >> >> So if you need total isolation, the only realistic way is as David >> described: use LD_PRELOAD and provide redirections for all system level >> APIs which allocate memory. >> >> The problem with redirecting C-Heap allocations at that level however is >> that if you override free() you need to have perfect coverage of all >> allocating APIs. These are not limited to malloc/calloc/free etc but there >> are a number of other APIs which return their results in C-Heap allocated >> buffers. And I have no idea honestly how to redirect C++ allocations via >> LD_PRELOAD. >> >> Cheers, Thomas >> >> >> On Tue, Dec 15, 2020 at 12:08 AM Guy Korland wrote: >> >>> >>> I'm talking about replacing the malloc implementation, we're running on >>> Linux. >>> But, the tricky part is that my C application malloc should not be >>> changed, only the libjvm.so when loaded embedded in my application. >>> >>> Regards, >>> Guy Korland >>> >>> >>> On Sun, Dec 13, 2020 at 12:15 PM Thomas St?fe >>> wrote: >>> >>>> Hi Guy, >>>> >>>> What do you mean by default allocator? C-Heap? Mmap/shmat? And what OS >>>> are you targeting? >>>> >>>> Cheers, Thomas >>>> >>>> On Fri, Dec 11, 2020 at 9:49 PM Guy Korland wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm sorry if that is not the right mailing list for such questions, >>>>> please >>>>> point me to the right one if it's not. >>>>> >>>>> We're embedding the OpenJDK in a C application, we already managed to >>>>> make >>>>> it work and run Java bytecode, but we are still missing one last >>>>> piece, we >>>>> need a way to replace the default memory allocator to use our >>>>> allocator. >>>>> >>>>> Is there a way to do it? >>>>> >>>>> Thanks, >>>>> Guy Korland >>>>> >>>> From akozlov at openjdk.java.net Tue Dec 15 18:46:57 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 15 Dec 2020 18:46:57 GMT Subject: Integrated: 8234930: Use MAP_JIT when allocating pages for code cache on macOS In-Reply-To: References: Message-ID: On Tue, 22 Sep 2020 07:08:35 GMT, Anton Kozlov wrote: > Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html > > On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL, PROT_NONE), the function was made aware of exec permissions. > > For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference compared with old code. > > For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and immediately reflects this in diagnostic tools like ps. For executable regions it would require MAP_FIXED|MAP_JIT, so instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not shrink (if I haven't missed anything, by the implementation and in principle). > > Tested: > * local tier1 > * jdk-submit > * codesign[2] with hardened runtime and allow-jit but without > allow-unsigned-executable-memory entitlements[3] produce a working bundle. > > (adding GC group as suggested by @dholmes-ora) > > > [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227 > [2] > > codesign \ > --sign - \ > --options runtime \ > --entitlements ents.plist \ > --timestamp \ > $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib > [3] > > > > > com.apple.security.cs.allow-jit > > com.apple.security.cs.disable-library-validation > > com.apple.security.cs.allow-dyld-environment-variables > > > This pull request has now been integrated. Changeset: 2273f955 Author: Anton Kozlov Committer: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/2273f955 Stats: 85 lines in 11 files changed: 26 ins; 0 del; 59 mod 8234930: Use MAP_JIT when allocating pages for code cache on macOS Reviewed-by: stuefe, iklam, burban ------------- PR: https://git.openjdk.java.net/jdk/pull/294 From github.com+168222+mgkwill at openjdk.java.net Tue Dec 15 18:48:05 2020 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 15 Dec 2020 18:48:05 GMT Subject: RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v15] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Merge branch 'master' into update_hlp - Merge branch 'master' into update_hlp - Remove extraneous ' from warning Signed-off-by: Marcus G K Williams - Merge branch 'master' into update_hlp - Merge branch 'master' into update_hlp - Merge branch 'master' into update_hlp - Fix os::large_page_size() in last update Signed-off-by: Marcus G K Williams - Ivan W. Requested Changes Removed os::Linux::select_large_page_size and use os::page_size_for_region instead Removed Linux::find_large_page_size and use register_large_page_sizes. Streamlined Linux::setup_large_page_size Signed-off-by: Marcus G K Williams - Fix space format, use Linux:: for local func. Signed-off-by: Marcus G K Williams - Merge branch 'update_hlp' of github.com:mgkwill/jdk into update_hlp - ... and 13 more: https://git.openjdk.java.net/jdk/compare/da2415fe...d73e7a4c ------------- Changes: https://git.openjdk.java.net/jdk/pull/1153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=14 Stats: 63 lines in 2 files changed: 24 ins; 11 del; 28 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From coleenp at openjdk.java.net Tue Dec 15 20:51:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 20:51:58 GMT Subject: RFR: 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest [v7] In-Reply-To: References: Message-ID: <82k9KwnQFj6SX_XRI3ldDA0D9w6QxtrKxv9ezXthGdQ=.2c4c1110-f49b-4b18-8685-dcec2165acd8@github.com> On Tue, 15 Dec 2020 17:56:40 GMT, Thomas Stuefe wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix tests for windows and macosx pattern matching. > > Looks good! Thanks for re-reviewing Ioi and Thomas. ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From coleenp at openjdk.java.net Tue Dec 15 20:52:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 20:52:01 GMT Subject: Integrated: 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest In-Reply-To: References: Message-ID: On Wed, 9 Dec 2020 21:47:31 GMT, Coleen Phillimore wrote: > Moved some unit tests from vmError into a gtest and moved controlled_crash code under #ifdef ASSERT rather than #ifndef PRODUCT since the tests that use this are @requires = vm.debug. This change keeps the ErrorHandlerTest=n option and other handler test options, because there are some tests that use this more but moves them to develop options (they were notproduct). There are some ErrorHandlerTest=n tests that do more thorough hs_err_pid.log file verification that remain. > > Tested with tier1-3 with product and fastdebug builds. Built with optimized. > > This is for JDK 17. This pull request has now been integrated. Changeset: c37eabe7 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/c37eabe7 Stats: 361 lines in 18 files changed: 145 ins; 171 del; 45 mod 8252148: vmError::controlled_crash should be #ifdef ASSERT and move tests to gtest Reviewed-by: iklam, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/1723 From hseigel at openjdk.java.net Tue Dec 15 21:58:09 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 15 Dec 2020 21:58:09 GMT Subject: RFR: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses [v2] In-Reply-To: References: Message-ID: > Please review this small fix for JDK-8257700 to add logging to JVM_GetPermittedSubclasses(). The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS, and WIndows, tiers 3-5 on Linux x64, and by running the hotspot runtime sealed tests with -Xlog:class+sealed=trace and looking at the output. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1780/files - new: https://git.openjdk.java.net/jdk/pull/1780/files/6c8d830c..4cb2719d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1780&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1780&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1780.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1780/head:pull/1780 PR: https://git.openjdk.java.net/jdk/pull/1780 From hseigel at openjdk.java.net Tue Dec 15 22:01:56 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Tue, 15 Dec 2020 22:01:56 GMT Subject: RFR: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses [v2] In-Reply-To: <_8XvbFc-FhZKiHvJeolfp8MmijIwRLk3Z-f7f2lOIB8=.1f1bbda5-7005-46ac-acef-501593b1dc94@github.com> References: <_8XvbFc-FhZKiHvJeolfp8MmijIwRLk3Z-f7f2lOIB8=.1f1bbda5-7005-46ac-acef-501593b1dc94@github.com> Message-ID: On Tue, 15 Dec 2020 17:33:33 GMT, Lois Foltan wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses > > Looks good, one minor comment. > Lois Please review this updated webrev. It contains the change suggested by Lois. Here's sample output from the added logging: [0.355s][trace][class,sealed] Calling GetPermittedSubclasses for sealed type NoLoadSubclasses [0.355s][trace][class,sealed] - sealed class has 2 permitted subclasses [0.355s][trace][class,sealed] - [1] = ExistingClassFile [0.355s][trace][class,sealed] - resolution of permitted subclass I/Dont/Exist/Either failed: java.lang.NoClassDefFoundError: I/Dont/Exist/Either [0.355s][trace][class,sealed] - compacting array from length 2 to 1 Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1780 From lfoltan at openjdk.java.net Tue Dec 15 22:10:00 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Tue, 15 Dec 2020 22:10:00 GMT Subject: RFR: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses [v2] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 21:58:09 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8257700 to add logging to JVM_GetPermittedSubclasses(). The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS, and WIndows, tiers 3-5 on Linux x64, and by running the hotspot runtime sealed tests with -Xlog:class+sealed=trace and looking at the output. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses Marked as reviewed by lfoltan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1780 From lfoltan at openjdk.java.net Tue Dec 15 22:10:01 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Tue, 15 Dec 2020 22:10:01 GMT Subject: RFR: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses [v2] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:04:42 GMT, Lois Foltan wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses > > Marked as reviewed by lfoltan (Reviewer). Looks good. Thanks for making the change I suggested! ------------- PR: https://git.openjdk.java.net/jdk/pull/1780 From coleenp at openjdk.java.net Tue Dec 15 22:20:59 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 22:20:59 GMT Subject: RFR: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses [v2] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 21:58:09 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8257700 to add logging to JVM_GetPermittedSubclasses(). The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS, and WIndows, tiers 3-5 on Linux x64, and by running the hotspot runtime sealed tests with -Xlog:class+sealed=trace and looking at the output. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses Changes requested by coleenp (Reviewer). src/hotspot/share/prims/jvm.cpp line 2129: > 2127: assert(c->is_instance_klass(), "must be"); > 2128: InstanceKlass* ik = InstanceKlass::cast(c); > 2129: log_trace(class, sealed)("Calling GetPermittedSubclasses for %s type %s", I don't know why this didn't complain about a missing ResourceMark, but can you add one just before line 2129 and it'll clean up any potential resource area uses for any external_name() calls. They're not that expensive so one would do without conditionalization. ------------- PR: https://git.openjdk.java.net/jdk/pull/1780 From coleenp at openjdk.java.net Tue Dec 15 23:08:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 15 Dec 2020 23:08:58 GMT Subject: RFR: 8258074: Move some flags related to compiler to compiler_globals.hpp [v2] In-Reply-To: <9nBHyQNqGlItycVc3uY9HXZmq3nw_1bzXmz95c9mq6w=.9b5c24cb-7ec0-4b20-939c-086245d39879@github.com> References: <9nBHyQNqGlItycVc3uY9HXZmq3nw_1bzXmz95c9mq6w=.9b5c24cb-7ec0-4b20-939c-086245d39879@github.com> Message-ID: On Fri, 11 Dec 2020 07:22:19 GMT, Ioi Lam wrote: >> Many flags in globals.hpp are related to the compiler, and are mostly used only by the compiler source files. These flags should be moved to compiler_globals.hpp >> >> Examples: >> >> - CompileCommandFile >> - Tier2CompileThreshold >> - HugeMethodLimit >> >> This speeds up HotSpot build time, and improves modularity. >> >> This RFE is the first step -- it moves a few dozen flags that are straight-forward to move. Other flags may be moved by follow-up RFEs. >> >> Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > fixed gtest Very nice! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1746 From xliu at openjdk.java.net Tue Dec 15 23:34:01 2020 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 15 Dec 2020 23:34:01 GMT Subject: RFR: 8258058: improve description of OutOfMemoryError relevant flags Message-ID: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> 8258058: improve description of OutOfMemoryError relevant flags ------------- Commit messages: - 8258058: improve description of OutOfMemoryError relevant flags Changes: https://git.openjdk.java.net/jdk/pull/1792/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1792&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258058 Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1792.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1792/head:pull/1792 PR: https://git.openjdk.java.net/jdk/pull/1792 From ihse at openjdk.java.net Wed Dec 16 00:17:02 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 16 Dec 2020 00:17:02 GMT Subject: RFR: 8258447: Move make/hotspot/hotspot.script to make/scripts In-Reply-To: References: Message-ID: <5eItiU_W66u3rfiyNFuu18Oiq3Qu55gN7ZMQlmiU-gs=.8a98404d-12a2-4765-bd09-eacdb7fb8616@github.com> On Tue, 15 Dec 2020 23:28:25 GMT, Magnus Ihse Bursie wrote: > The hotspot launcher script is misplaced among the hotspot make files. It should move to make/scripts (and get a proper extension). Can someone from hotspot please confirm if this script is still needed/used? ------------- PR: https://git.openjdk.java.net/jdk/pull/1791 From dholmes at openjdk.java.net Wed Dec 16 00:48:02 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 16 Dec 2020 00:48:02 GMT Subject: RFR: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses [v2] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 21:58:09 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8257700 to add logging to JVM_GetPermittedSubclasses(). The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS, and WIndows, tiers 3-5 on Linux x64, and by running the hotspot runtime sealed tests with -Xlog:class+sealed=trace and looking at the output. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses Hi Harold, Looks good. One minor comment below. Thanks, David src/hotspot/share/prims/jvm.cpp line 2168: > 2166: // we had invalid entries so we need to compact the array > 2167: log_trace(class, sealed)(" - compacting array from length %d to %d", > 2168: length, count); Not sure this really adds any useful information, but your call. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1780 From dholmes at openjdk.java.net Wed Dec 16 01:31:00 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 16 Dec 2020 01:31:00 GMT Subject: RFR: 8258058: improve description of OutOfMemoryError relevant flags In-Reply-To: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> References: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> Message-ID: On Tue, 15 Dec 2020 23:29:22 GMT, Xin Liu wrote: > 8258058: improve description of OutOfMemoryError relevant flags Seems fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1792 From jiefu at openjdk.java.net Wed Dec 16 01:42:56 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 16 Dec 2020 01:42:56 GMT Subject: RFR: 8258058: improve description of OutOfMemoryError relevant flags In-Reply-To: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> References: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> Message-ID: On Tue, 15 Dec 2020 23:29:22 GMT, Xin Liu wrote: > 8258058: improve description of OutOfMemoryError relevant flags src/hotspot/share/runtime/globals.hpp line 555: > 553: product(bool, HeapDumpOnOutOfMemoryError, false, MANAGEABLE, \ > 554: "Dump heap to file when java.lang.OutOfMemoryError is thrown " \ > 555: "from JVM") \ It would be better to align `` to the right. ------------- PR: https://git.openjdk.java.net/jdk/pull/1792 From dongbo at openjdk.java.net Wed Dec 16 02:02:55 2020 From: dongbo at openjdk.java.net (Dong Bo) Date: Wed, 16 Dec 2020 02:02:55 GMT Subject: RFR: 8256820: AArch64: Optimize vector rotate (immediate) with shift and insert instructions [v2] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 11:45:05 GMT, Dong Bo wrote: >> This patch is very hard to review because much of it is just moving things around. Please do this as two PRs, one which does all the moves and one with the substantive changes. Thanks. > > Thanks for the quick reply. Deleted all the moves in the updated version. > > We tested this on the two servers we have by hand now. It is a pity for us that we didn't see performance improvements on `Cortex-A72`. > Because we have detected microarchitecture in the code already, I thought we could make full use of the flexibility it provided. > > We find the shift and insert instructions are used in Linux OS for serveral crypto algorithms for all CPUs [1, 2, 3]. > But as of now, we only have the micro benchmarks for JDK as shown before. > I'll try to investigate to see if there is any workload can benifit from this. > > Maybe someone from the community can help test this on other CPUs, like `ThunderX`, `Cortex-A73`? Thanks. :) > > [1] https://github.com/torvalds/linux/blob/master/arch/arm64/crypto/chacha-neon-core.S > [2] https://github.com/torvalds/linux/blob/master/arch/arm64/crypto/crct10dif-ce-core.S > [3] https://github.com/torvalds/linux/blob/master/arch/arm64/crypto/sha512-armv8.pl > _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):_ > > On 14/12/2020 11:48, Dong Bo wrote: > > > We tested this on the two servers we have by hand now. It is a pity > > for us that we didn't see performance improvements on `Cortex-A72`. > > Because we have detected microarchitecture in the code already, I > > thought we could make full use of the flexibility it provided. > > We find the shift and insert instructions are used in Linux OS for > > serveral crypto algorithms for all CPUs [1, 2, 3]. > > I don't want to be unfair to you. There are many small optimizations > that we have made for which we don't require large-scale benchmarks. > I'm not going to start insisting that every small change shows a > gain on such benchmarks. > > But this patch seems to be very marginal: not only does it offer a > modest gain one one machine, it also shows a modest loss on another. > Not only that, but we do not know if auto-vectorization is at all > effective on these OpenJDK's algorithms. > Agree. It's marginal. These crypto algorithms in JDK are not vectorized. I checked some other Java code in core-libs, didn't find any candidate of this optimization. The rotate instructions are also negligible or inexistent in applications we investigated, like Spark, Flink, Tomcat. > My reason for pushing back here is that I want HotSpot to generate "good" > code for all AArch64 platforms, rather than containing special patterns > for microarchitectures. There are risks if we allow that. For example, > mistakes which affect only one machine might be made by accident, and > they cannot be tested by anyone who does not have that machine. Also, > the AArch64 back end becomes complex and hard to maintain. > > For example, a simple mistake made during a critical patch update > might break Kunpeng920, and unless everybody tests on all machines, we > might not know until it's too late to fix it. > > So, any change which causes divergence between microarchitectures must > be needed, or it isn't worth the risk. It's not in your interest for > that to happen, either. > OKAY, this does make sense to us, we don't want to take the possible risk neither. By far, I think it's not worthy, unless we see a profitable workload one day. As of now, I am going to withdraw this. Thanks for the comments. Best Regards. ------------- PR: https://git.openjdk.java.net/jdk/pull/1761 From dongbo at openjdk.java.net Wed Dec 16 02:02:56 2020 From: dongbo at openjdk.java.net (Dong Bo) Date: Wed, 16 Dec 2020 02:02:56 GMT Subject: Withdrawn: 8256820: AArch64: Optimize vector rotate (immediate) with shift and insert instructions In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 05:57:36 GMT, Dong Bo wrote: > 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`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1761 From david.holmes at oracle.com Wed Dec 16 02:09:06 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Dec 2020 12:09:06 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> Message-ID: <82684a2f-5231-d64b-5175-8aa6c8e428e9@oracle.com> Hi Yasumasa, Sorry for the delay getting back to this. On 1/12/2020 4:41 pm, Yasumasa Suenaga wrote: > Hi David, > > On 2020/12/01 14:59, David Holmes wrote: >> Looking at the original webrev from September: >> >> https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html >> >> >> The suggestion to unload the library if Agent_OnAttach fails seems >> quite reasonable - it is what happens if no Agent_OnAttach function >> can be found in the agent. >> >> But the specification is lacking because it simply states any such >> error is "ignored" - which is an oversimplification and I think was >> really intended to contrast with the abort behaviour if Agent_OnLoad >> fails. In addition the specification indicates that Agent_OnUnload is >> called any time the agent library is unloaded, except for >> "uncontrolled shutdown". This unfortunately suggests that before >> unloading the library after OnAttach fails, we also call OnUnload. >> That seems wrong and in fact the VM does not do that - and noone seems >> to have complained. >> >> Also note the specification states an agent "must export a start-up >> function ..." but doesn't say what happens if it doesn't do so. >> >> My gut feeling for what the specification should say here is that if >> the start-up function does not exist, or the call to Agent_OnAttach >> reports an error, then the agent library is immediately unloaded with >> no attempt to call the agent shutdown function (Agent_OnUnload). > > That's what I wanted to suggest! > I understand we need to consider following case in this issue, is it right? > > Agent_OnLoad / Agent_OnLoad_L does not exist: > ??? - Agent_OnUnload is not called > ??? - DLL is not unloaded (JVM will abort) > > Agent_OnLoad / Agent_OnLoad_L failed: > ??? - Agent_OnUnload is not called > ??? - DLL is not unloaded (JVM will abort) These cases are already well covered. > Agent_OnAttach does not exist: > ??? - Agent_OnUnload is not called > ??? - DLL is unloaded > > Agent_OnAttach_L does not exist: > ??? - Agent_OnUnload is not called > ??? - DLL is not unloaded (static link) These cases are kind of implicitly covered, but could be clarified. > Agent_OnAttach failed: > ??? - Agent_OnUnload is not called > ??? - DLL is unloaded > > Agent_OnAttach_L faled: > ??? - Agent_OnUnload is not called > ??? - DLL is not unloaded (static link) These are the problematic cases. > >> But with my "compatibility glasses" on this may be too strong to >> retrofit to the specification as other VMs may behave differently. So >> as I stated in the CSR request we probably want to allow the current >> hotspot behaviour but not mandate it (unless we check with all the >> other VM implementations that such a specification is okay with them). > > Ok, for example, can we change the spec as following? > (Of course, this is not all) > > ``` > diff --git a/src/hotspot/share/prims/jvmti.xml > b/src/hotspot/share/prims/jvmti.xml > index 44553b8065f..57c87b1a71b 100644 > --- a/src/hotspot/share/prims/jvmti.xml > +++ b/src/hotspot/share/prims/jvmti.xml > @@ -688,7 +688,8 @@ Agent_OnUnload_L(JavaVM *vm) > ???? mechanism causes the unload (an unload mechanism is not specified > in this document) > ???? or the library is (in effect) unloaded by the termination of the > VM whether through > ???? normal termination or VM failure, including start-up failure. > -??? Uncontrolled shutdown is, of course, an exception to this rule. > +??? Uncontrolled shutdown is, of course, an exception to this rule, and > also it might not be called > +??? when start-up function does not exist or fails (returns non-zero > value). I think this is what was originally proposed and as I said then I don't like burying this detail inside the reference to uncontrolled shutdown. We should make this much more explicit which requires some reworking of the existing far-too-long sentence. "This function will be called by the VM when the library is about to be unloaded. The library will be unloaded (unless it is statically linked into the executable) and this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document) or the library is (in effect) unloaded by the termination of the VM. VM termination includes normal termination and VM failure, including start-up failure, but not, of course, uncontrolled shutdown. An implementation may also choose to not call this function if the Agent_OnAttach/Agent_OnAttach_L function reported an error (returned a non-zero value)." Cheers, David ----- > ???? Note the distinction between this function and the > ???? VM Death event: for the VM > Death event > ???? to be sent, the VM must have run at least to the point of > initialization and a valid > ``` > >> I agree that the more general issue of re-loading an agent is a >> separate issue. > > Thanks! > > > Yasumasa > > >> David >> ----- >> >> On 1/12/2020 3:21 pm, David Holmes wrote: >>> On 1/12/2020 3:19 pm, David Holmes wrote: >>>> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>>>> Hi Chris, David, >>>>> >>>>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is >>>>> failed - JVM will abort. >>>>> Should we re-think this behavior? >>>> >>>> We should we rethink that? It is probably one of the clearest parts >>>> of the spec. If Agent_Onload fails that is considered a fatal error >>>> - end of story. >>> >>> I meant, of course, "Why should we rethink that?". >>> >>> David >>> >>>> The issue is with Agent_onAttach and how its failure should, or >>>> should not, impact Agent_OnUnload. >>>> >>>> David >>>> ----- >>>> >>>>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>>>> >>>>> ``` >>>>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>>>> Hello World from Agent_OnLoad() >>>>> ?? options = error >>>>> Error occurred during initialization of VM >>>>> agent library failed to init: /path/to/libhelloworld.so >>>>> ``` >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2020/12/01 11:44, David Holmes wrote: >>>>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga >>>>>>> wrote: >>>>>>> >>>>>>>>> * Q3: What has to be done for statically linked agent? >>>>>>>> >>>>>>>> JVMTI spec says "unless it is statically linked into the >>>>>>>> executable", so I think we can ignore about Agent_OnUnload_L() >>>>>>>> in this PR. >>>>>>> >>>>>>> I don't think that makes sense. If you call it for dynamically >>>>>>> linked then you need to call it for statically linked also. >>>>>> >>>>>> Agreed. Even though you can't physically unload the statically >>>>>> linked library, if it is logically unloaded by some mechanism, >>>>>> then Agent_OnUnload_L is supposed to be called. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> ------------- >>>>>>> >>>>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>>>> From qingfeng.yy at alibaba-inc.com Wed Dec 16 03:30:54 2020 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Wed, 16 Dec 2020 11:30:54 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaUmU6IEEgc29sdXRpb24gdG8gZGV0ZWN0IHRoZSBmb290cHJpbnQgb2YgSmF2?= =?UTF-8?B?YSB0aHJlYWQgc3RhY2s=?= In-Reply-To: References: <94dc25af-5a11-4414-bcba-45eca74014fc.qingfeng.yy@alibaba-inc.com>, Message-ID: <8c85fefa-f4ef-434a-813f-4a67273db286.qingfeng.yy@alibaba-inc.com> Hi Tomas, Thank you for your comment. > I may misunderstand the proposal, but is this a one-shot solution? So the first time we reach the warning zone we get a warning, zone gets disabled, never gets enabled again? We will disable the pages between the accessing address and the warning zone base, not the whole warning zone, this disabled zone will not become enabled again. > Looking from outside at all threads, some will have their warning zone disabled, some not. We have the information that a thread reached the warning level, but not when and what it did then, no? It could have been a short spike in the deep past, never to reoccur, or it could be a permanent high stack usage. I think especially for long-running worker threads which have many different workloads this may limit its usefulness. You inspire me. Warning messages should not only contain thread id, current footprint, and stack size but also contain thread stack, this is necessary since users would have more information. As for a temporary short spike, this is indeed possible. In my original intention, the user observes warning messages in recent iterations of the application, and then judge whether to adjust -Xss in the next iteration. Thanks, Yang Yi ------------------------------------------------------------------ ????Thomas St?fe ????2020?12?15? 15:24:49 ????Yang Yi ????HotSpot Open Source Developers; hotspot-jfr-dev ????Re: A solution to detect the footprint of Java thread stack Hi Yang Yi, it sounds interesting, but I am not yet sure how useful this will be in the proposed form. I may misunderstand the proposal, but is this a one-shot solution? So the first time we reach the warning zone we get a warning, zone gets disabled, never gets enabled again? We have that warning in UL and JFR, but we do not have any context. Looking from outside at all threads, some will have their warning zone disabled, some not. We have the information that a thread reached the warning level, but not when and what it did then, no? It could have been a short spike in the deep past, never to reoccur, or it could be a permanent high stack usage. I think especially for long-running worker threads which have many different workloads this may limit its usefulness. If it is only to measure stack sizes, would a solution in JFR which iterates the stacks of threads periodically and measures the real used stack (as NMT does it, using mincore()) not better? That would be somewhat simpler to implement, would not be a one-shot solution, would not be bound to one warning level, would get more precise information, and would not rely on page granularity. About that, the warning zone may increase the stack size for platforms with larger base page sizes (eg PPC) where we have 64K pages. Cheers, Thomas On Mon, Dec 14, 2020 at 6:03 AM ??(??) wrote: Hi all, We occasionally get stack overflow errors if the application has too many deep callings. The usual solution is to increase -Xss, but there is no guiding opinion telling us in advance that the thread stack space is not enough. This patch attempts to address this issue. It introduces a new stack zone(warning_zone) for Hotspot VM, which can be used to detect whether the footprint ratio of the thread stack has reached the watermark set by the user. The current stack layout is as follows: stack_base stack_end --------------------------------------------------------------------------------------------------------------------------- | | shadow zone | warning zone(added) | reserved zone | yellow zone | red zone | --------------------------------------------------------------------------------------------------------------------------- ^rsp |<-StackWarningRatio % of available stack-> Users can set the option -XX:StackWarningRatio=0 to turn off this feature(which is also the default value) and there will be no warning zone, the stack layout is the same as usual. If the user sets -XX:StackWarningRatio to 50, the VM will protect 50% of the available stack space(let all = available+reserved+yellow+red;) as stack warning zone. When the footprint of available stack space reaches 50%, that is, when the application accesses the stack warning zone, the sigsegv signal will be triggered, and then the signal handler will warn this access in some ways(e.g. send the JFR event, logging) and resume current execution. As a prototype, this feature is only implemented on x86_posix, it can be implemented on more platforms as needed. Could anyone give some suggestions? If you think this is a useful feature, I will file an issue and support it on all platforms. Looking forward to your comments. Patch: https://github.com/kelthuzadx/jdk/commit/a145b2ebb4ac568e3bb090cbe3e7f091e1dc69ea Diff: https://github.com/kelthuzadx/jdk/compare/37dc675..a145b2e Best, Yang Yi From iklam at openjdk.java.net Wed Dec 16 04:41:13 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 16 Dec 2020 04:41:13 GMT Subject: RFR: 8258074: Move some flags related to compiler to compiler_globals.hpp [v3] In-Reply-To: References: Message-ID: > Many flags in globals.hpp are related to the compiler, and are mostly used only by the compiler source files. These flags should be moved to compiler_globals.hpp > > Examples: > > - CompileCommandFile > - Tier2CompileThreshold > - HugeMethodLimit > > This speeds up HotSpot build time, and improves modularity. > > This RFE is the first step -- it moves a few dozen flags that are straight-forward to move. Other flags may be moved by follow-up RFEs. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. Ioi Lam 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 8258074-move-compiler-globals - fixed gtest - 8258074: Move some flags related to compiler to compiler_globals.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1746/files - new: https://git.openjdk.java.net/jdk/pull/1746/files/c218bd66..fc9c673f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1746&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1746&range=01-02 Stats: 6071 lines in 178 files changed: 4168 ins; 1363 del; 540 mod Patch: https://git.openjdk.java.net/jdk/pull/1746.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1746/head:pull/1746 PR: https://git.openjdk.java.net/jdk/pull/1746 From iklam at openjdk.java.net Wed Dec 16 04:41:14 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 16 Dec 2020 04:41:14 GMT Subject: RFR: 8258074: Move some flags related to compiler to compiler_globals.hpp [v2] In-Reply-To: <5oH23oAJR4obLniV9p4FSrrECuog6TCKHR6EQ0sX_5Y=.e5f92055-1845-411e-bebc-18961aac051b@github.com> References: <9nBHyQNqGlItycVc3uY9HXZmq3nw_1bzXmz95c9mq6w=.9b5c24cb-7ec0-4b20-939c-086245d39879@github.com> <5oH23oAJR4obLniV9p4FSrrECuog6TCKHR6EQ0sX_5Y=.e5f92055-1845-411e-bebc-18961aac051b@github.com> Message-ID: On Fri, 11 Dec 2020 18:30:34 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed gtest > > Good. Thanks @vnkozlov and @coleenp for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1746 From iklam at openjdk.java.net Wed Dec 16 04:41:15 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 16 Dec 2020 04:41:15 GMT Subject: Integrated: 8258074: Move some flags related to compiler to compiler_globals.hpp In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 05:07:51 GMT, Ioi Lam wrote: > Many flags in globals.hpp are related to the compiler, and are mostly used only by the compiler source files. These flags should be moved to compiler_globals.hpp > > Examples: > > - CompileCommandFile > - Tier2CompileThreshold > - HugeMethodLimit > > This speeds up HotSpot build time, and improves modularity. > > This RFE is the first step -- it moves a few dozen flags that are straight-forward to move. Other flags may be moved by follow-up RFEs. > > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5 on mach5, plus locally building arm, aarch64, s390, ppc64, and zero. This pull request has now been integrated. Changeset: 17ace833 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/17ace833 Stats: 910 lines in 12 files changed: 470 ins; 429 del; 11 mod 8258074: Move some flags related to compiler to compiler_globals.hpp Reviewed-by: kvn, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1746 From david.holmes at oracle.com Wed Dec 16 05:03:09 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Dec 2020 15:03:09 +1000 Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJlOiDlm57lpI3vvJpSZTogQSBzb2x1dGlvbiB0?= =?UTF-8?Q?o_detect_the_footprint_of_Java_thread_stack?= In-Reply-To: <6f1a7c7e-13bf-49a2-a7d2-8596793cb2d6.qingfeng.yy@alibaba-inc.com> References: <94dc25af-5a11-4414-bcba-45eca74014fc.qingfeng.yy@alibaba-inc.com> <1e423c3c-fac3-268e-f4f6-8d9f1a2cea51@oracle.com> <84812ffc-7947-da4c-15b0-9f38ed2c6615@oracle.com> <6f1a7c7e-13bf-49a2-a7d2-8596793cb2d6.qingfeng.yy@alibaba-inc.com> Message-ID: <81665307-6b0b-3299-2cda-06b72968d360@oracle.com> Adding back the mailing lists ... Hi, On 16/12/2020 1:00 pm, Yang Yi wrote: > ?Hi David, > > The purpose of this option is to warn rather than avoiding stack > overflow. It would tell users how much stack space they have been used > and what is the percentage of the stack footprint in the total. If the > ratio of stack footprint reaches - XX:StackWarningRatio=90 in many > iterations of the application, the user can make a judgment, whether to > increase the stack space to reduce the risk of StackOverflowError or > keep the current stack size to save memory as much as possible. My concern is the cost:benefit ratio for this feature. It's code that has to be added and maintained and may interact in unintended ways with other features - like ReservedStackAccess. So to me I see the cost here as moderate. The benefit seems very small to me. I don't recall ever seeing a feature request for this, and I just searched for it. If people were trying to size their applications in the way you suggest, or if they wanted to do so, then I would have expected to see requests for such functionality. At the moment this seems a solution in search of a problem. Just my opinion of course. Cheers, David ----- > > Best, > Yang YI > > ------------------------------------------------------------------ > ????David Holmes > ????2020?12?15? 15:26:56 > ????Yang Yi; HotSpot Open Source > Developers; > hotspot-jfr-dev > ????Re: ???Re: A solution to detect the footprint of Java > thread stack > > Hi, > > On 15/12/2020 5:02 pm, Yang Yi wrote: > > Hi?David, > > > > Thank?you?for?your?comments. > > > > > >?How?do?you?actually?envisage?people?using?this??This?seems?more?of?a > > > >?tuning?option,?but?you?can?tune?just?as?readily?by?adjusting?-Xss?in?the > > > >?same?manner?you?would?set?the?warning?ratio.?I.e.?you'd?like?to?shrink > > > >?your?stack?usage?but?are?not?sure?how?small?you?can?make?it?safely?so > > > >?you?can?either?just?reduce?-Xss?and?see?if?it?works,?or?you?can?set?the > > > >?warning?ratio?to?give?the?same?effective?-Xss?and?see?if?you?get?a?warning. > > > > Yes, we can indeed achieve similar goals by constantly adjusting > > -Xss, but adjusting -Xss is generally a way to make the > application work > > again after StackOverflowError occurs. The purpose of > > -XX:StackWarningRatio is to warn early before StackOverflowError > occurs. > > But the problem there is that triggering the warning does not indicate > that a stackoverflow will in fact occur. It will only tell whether you > used a given percentage of your stack, not how much you have actually > used. So how does this help you avoid stackoverflow? If you used the > warning to increase -Xss without ever encountering stackoverflow then > you are just wasting memory and potentially reducing the number of > threads you can support. > > Cheers, > David > > > > Based on my experience and observation, many developers use the > default > > value of ThreadStackSize(the default value of is 1M on > linux_x86), they > > will not adjust the value of this option unless a stack overflow > occurs. > > With the iterative development of the application, the size of > the stack > > may no longer meet the demand. It's helpful to warn about > insufficient > > stack space earlier in case of hurriedly troubleshooting and > adjusting > > the -Xss when the application throws StackOverflowError in the > > production environment. > > > > > > > > >?The?flag?would?need?to?be?diagnostic?rather?than?full?product. > > > > Accept. > > > > Best, > > Yang?Yi > > > > ------------------------------------------------------------------ > > ????David Holmes > > ????2020?12?15? 13:24:54 > > ????Yang Yi; HotSpot Open Source > > Developers; > > hotspot-jfr-dev > > ????Re: A solution to detect the footprint of Java thread stack > > > > Hi?Yang?Yi, > > > > On?14/12/2020?3:03?pm,???(??)?wrote: > > >?Hi?all, > > > >?We?occasionally?get?stack?overflow?errors?if?the?application?has?too?many?deep?callings.?The?usual?solution?is?to?increase?-Xss,?but?there?is?no?guiding?opinion?telling?us?in?advance?that?the?thread?stack?space?is?not?enough.?This?patch?attempts?to?address?this?issue.?It?introduces?a?new?stack?zone(warning_zone)?for?Hotspot?VM,?which?can?be?used?to?detect?whether?the?footprint?ratio?of?the?thread?stack?has?reached?the?watermark?set?by?the?user. > > > > > >?The?current?stack?layout?is?as?follows: > > > >?stack_base????????????????????????????????????????????????????????????????????????????????????stack_end > > > >?--------------------------------------------------------------------------------------------------------------------------- > > > >?|????????|???shadow?zone?|???????????????????warning?zone(added)???????????????????|?reserved?zone?|?yellow?zone?|?red?zone?| > > > >?--------------------------------------------------------------------------------------------------------------------------- > > > >???????????^rsp???????????????????|<-StackWarningRatio?%?of?available?stack-> > > > > > > >?Users?can?set?the?option?-XX:StackWarningRatio=0?to?turn?off?this?feature(which?is?also?the?default?value)?and?there?will?be?no?warning?zone,?the?stack?layout?is?the?same?as?usual. > > > >?If?the?user?sets?-XX:StackWarningRatio?to?50,?the?VM?will?protect?50%?of?the?available?stack?space(let?all?=?available+reserved+yellow+red;)?as?stack?warning?zone.?When?the?footprint?of?available?stack?space?reaches?50%,?that?is,?when?the?application?accesses?the?stack?warning?zone,?the?sigsegv?signal?will?be?triggered,?and?then?the?signal?handler?will?warn?this?access?in?some?ways(e.g.?send?the?JFR?event,?logging)?and?resume?current?execution.?As?a?prototype,?this?feature?is?only?implemented?on?x86_posix,?it?can?be?implemented?on?more?platforms?as?needed. > > > > > > >?Could?anyone?give?some?suggestions??If?you?think?this?is?a?useful?feature,?I?will?file?an?issue?and?support?it?on?all?platforms.?Looking?forward?to?your?comments. > > > > How?do?you?actually?envisage?people?using?this??This?seems?more?of?a > > > tuning?option,?but?you?can?tune?just?as?readily?by?adjusting?-Xss?in?the > > > > > same?manner?you?would?set?the?warning?ratio.?I.e.?you'd?like?to?shrink > > your?stack?usage?but?are?not?sure?how?small?you?can?make?it?safely?so > > > you?can?either?just?reduce?-Xss?and?see?if?it?works,?or?you?can?set?the > > > warning?ratio?to?give?the?same?effective?-Xss?and?see?if?you?get?a?warning. > > > > The?flag?would?need?to?be?diagnostic?rather?than?full?product. > > > > Cheers, > > David > > > > > >?Patch:?https://github.com/kelthuzadx/jdk/commit/a145b2ebb4ac568e3bb090cbe3e7f091e1dc69ea > > >?Diff:?https://github.com/kelthuzadx/jdk/compare/37dc675..a145b2e > > > > > >?Best, > > >?Yang?Yi > > > > > > From xliu at openjdk.java.net Wed Dec 16 05:54:57 2020 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 16 Dec 2020 05:54:57 GMT Subject: RFR: 8258058: improve description of OutOfMemoryError relevant flags In-Reply-To: References: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> Message-ID: On Wed, 16 Dec 2020 01:39:46 GMT, Jie Fu wrote: >> 8258058: improve description of OutOfMemoryError relevant flags > > src/hotspot/share/runtime/globals.hpp line 555: > >> 553: product(bool, HeapDumpOnOutOfMemoryError, false, MANAGEABLE, \ >> 554: "Dump heap to file when java.lang.OutOfMemoryError is thrown " \ >> 555: "from JVM") \ > > It would be better to align `` to the right. yes, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1792 From xliu at openjdk.java.net Wed Dec 16 06:04:07 2020 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 16 Dec 2020 06:04:07 GMT Subject: RFR: 8258058: improve description of OutOfMemoryError relevant flags [v2] In-Reply-To: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> References: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> Message-ID: > 8258058: improve description of OutOfMemoryError relevant flags Xin Liu has updated the pull request incrementally with one additional commit since the last revision: fix the format issue ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1792/files - new: https://git.openjdk.java.net/jdk/pull/1792/files/f8c225dd..599bea8a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1792&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1792&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1792.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1792/head:pull/1792 PR: https://git.openjdk.java.net/jdk/pull/1792 From jiefu at openjdk.java.net Wed Dec 16 06:09:55 2020 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 16 Dec 2020 06:09:55 GMT Subject: RFR: 8258058: improve description of OutOfMemoryError relevant flags [v2] In-Reply-To: References: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> Message-ID: On Wed, 16 Dec 2020 06:04:07 GMT, Xin Liu wrote: >> 8258058: improve description of OutOfMemoryError relevant flags > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > fix the format issue Thanks for the change. LGTM ------------- Marked as reviewed by jiefu (Committer). PR: https://git.openjdk.java.net/jdk/pull/1792 From suenaga at oss.nttdata.com Wed Dec 16 06:33:16 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 16 Dec 2020 15:33:16 +0900 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <82684a2f-5231-d64b-5175-8aa6c8e428e9@oracle.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> <82684a2f-5231-d64b-5175-8aa6c8e428e9@oracle.com> Message-ID: <93e65fc1-3052-706e-cabf-fb1ff4f7f895@oss.nttdata.com> Hi David, > "This function will be called by the VM when the library is about to be unloaded. The library will be unloaded (unless it is statically linked into the executable) and this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document) or the library is (in effect) unloaded by the termination of the VM. VM termination includes normal termination and VM failure, including start-up failure, but not, of course, uncontrolled shutdown. An implementation may also choose to not call this function if the Agent_OnAttach/Agent_OnAttach_L function reported an error (returned a non-zero value)." Thank you so much! According to this, we can fix this bug simply. (We can unload agent library without `Agent_OnUnload()` call) However I think following sentence should be removed because DLL unloading mechanism is not hooked, and also `Agent_OnUnload()` wouldn't be called by dll unloading - it depends on VM termination / failure / non-zero value from entry points. "this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document)" If you are OK, I will update CSR. Cheers, Yasumasa On 2020/12/16 11:09, David Holmes wrote: > Hi Yasumasa, > > Sorry for the delay getting back to this. > > On 1/12/2020 4:41 pm, Yasumasa Suenaga wrote: >> Hi David, >> >> On 2020/12/01 14:59, David Holmes wrote: >>> Looking at the original webrev from September: >>> >>> https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html >>> >>> The suggestion to unload the library if Agent_OnAttach fails seems quite reasonable - it is what happens if no Agent_OnAttach function can be found in the agent. >>> >>> But the specification is lacking because it simply states any such error is "ignored" - which is an oversimplification and I think was really intended to contrast with the abort behaviour if Agent_OnLoad fails. In addition the specification indicates that Agent_OnUnload is called any time the agent library is unloaded, except for "uncontrolled shutdown". This unfortunately suggests that before unloading the library after OnAttach fails, we also call OnUnload. That seems wrong and in fact the VM does not do that - and noone seems to have complained. >>> >>> Also note the specification states an agent "must export a start-up function ..." but doesn't say what happens if it doesn't do so. >>> >>> My gut feeling for what the specification should say here is that if the start-up function does not exist, or the call to Agent_OnAttach reports an error, then the agent library is immediately unloaded with no attempt to call the agent shutdown function (Agent_OnUnload). >> >> That's what I wanted to suggest! >> I understand we need to consider following case in this issue, is it right? >> >> Agent_OnLoad / Agent_OnLoad_L does not exist: >> ???? - Agent_OnUnload is not called >> ???? - DLL is not unloaded (JVM will abort) >> >> Agent_OnLoad / Agent_OnLoad_L failed: >> ???? - Agent_OnUnload is not called >> ???? - DLL is not unloaded (JVM will abort) > > These cases are already well covered. > >> Agent_OnAttach does not exist: >> ???? - Agent_OnUnload is not called >> ???? - DLL is unloaded >> >> Agent_OnAttach_L does not exist: >> ???? - Agent_OnUnload is not called >> ???? - DLL is not unloaded (static link) > > These cases are kind of implicitly covered, but could be clarified. > >> Agent_OnAttach failed: >> ???? - Agent_OnUnload is not called >> ???? - DLL is unloaded >> >> Agent_OnAttach_L faled: >> ???? - Agent_OnUnload is not called >> ???? - DLL is not unloaded (static link) > > These are the problematic cases. > >> >>> But with my "compatibility glasses" on this may be too strong to retrofit to the specification as other VMs may behave differently. So as I stated in the CSR request we probably want to allow the current hotspot behaviour but not mandate it (unless we check with all the other VM implementations that such a specification is okay with them). >> >> Ok, for example, can we change the spec as following? >> (Of course, this is not all) >> >> ``` >> diff --git a/src/hotspot/share/prims/jvmti.xml b/src/hotspot/share/prims/jvmti.xml >> index 44553b8065f..57c87b1a71b 100644 >> --- a/src/hotspot/share/prims/jvmti.xml >> +++ b/src/hotspot/share/prims/jvmti.xml >> @@ -688,7 +688,8 @@ Agent_OnUnload_L(JavaVM *vm) >> ????? mechanism causes the unload (an unload mechanism is not specified in this document) >> ????? or the library is (in effect) unloaded by the termination of the VM whether through >> ????? normal termination or VM failure, including start-up failure. >> -??? Uncontrolled shutdown is, of course, an exception to this rule. >> +??? Uncontrolled shutdown is, of course, an exception to this rule, and also it might not be called >> +??? when start-up function does not exist or fails (returns non-zero value). > > I think this is what was originally proposed and as I said then I don't like burying this detail inside the reference to uncontrolled shutdown. We should make this much more explicit which requires some reworking of the existing far-too-long sentence. > > "This function will be called by the VM when the library is about to be unloaded. The library will be unloaded (unless it is statically linked into the executable) and this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document) or the library is (in effect) unloaded by the termination of the VM. VM termination includes normal termination and VM failure, including start-up failure, but not, of course, uncontrolled shutdown. An implementation may also choose to not call this function if the Agent_OnAttach/Agent_OnAttach_L function reported an error (returned a non-zero value)." > > Cheers, > David > ----- > >> ????? Note the distinction between this function and the >> ????? VM Death event: for the VM Death event >> ????? to be sent, the VM must have run at least to the point of initialization and a valid >> ``` >> >>> I agree that the more general issue of re-loading an agent is a separate issue. >> >> Thanks! >> >> >> Yasumasa >> >> >>> David >>> ----- >>> >>> On 1/12/2020 3:21 pm, David Holmes wrote: >>>> On 1/12/2020 3:19 pm, David Holmes wrote: >>>>> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>>>>> Hi Chris, David, >>>>>> >>>>>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is failed - JVM will abort. >>>>>> Should we re-think this behavior? >>>>> >>>>> We should we rethink that? It is probably one of the clearest parts of the spec. If Agent_Onload fails that is considered a fatal error - end of story. >>>> >>>> I meant, of course, "Why should we rethink that?". >>>> >>>> David >>>> >>>>> The issue is with Agent_onAttach and how its failure should, or should not, impact Agent_OnUnload. >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>>>>> >>>>>> ``` >>>>>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>>>>> Hello World from Agent_OnLoad() >>>>>> ?? options = error >>>>>> Error occurred during initialization of VM >>>>>> agent library failed to init: /path/to/libhelloworld.so >>>>>> ``` >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2020/12/01 11:44, David Holmes wrote: >>>>>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: >>>>>>>> >>>>>>>>>> * Q3: What has to be done for statically linked agent? >>>>>>>>> >>>>>>>>> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. >>>>>>>> >>>>>>>> I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. >>>>>>> >>>>>>> Agreed. Even though you can't physically unload the statically linked library, if it is logically unloaded by some mechanism, then Agent_OnUnload_L is supposed to be called. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> ------------- >>>>>>>> >>>>>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>>>>> From iklam at openjdk.java.net Wed Dec 16 06:37:09 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 16 Dec 2020 06:37:09 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp Message-ID: Currently, [globals.hpp](https://github.com/openjdk/jdk/blob/17ace8339dd8235f3811e3975d9ccc77910b0c77/src/hotspot/share/runtime/globals.hpp#L29) is including gc_globals.hpp. This exposes all the GC command-line flags to almost all cpp files. However, only about 1/3 of the cpp files would require gc_globals.hpp. This RFE improves modularity and HotSpot build time. **Review notes:** - Please start with globals.hpp, gc_globals.hpp. - Flags related to TLAB are frequently used by other header files. I moved these flags to a new header tlab_globals.hpp. - Some tweaking of oop.hpp to avoid including gc_globals.hpp in this popular header file. (Otherwise gc_globals.hpp would be included by everyone). - The other changes are just files that use GC flags. They should have included gc_globals.hpp but didn't. **Testing:** Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- Commit messages: - fixed copyright year - 8258459: Decouple gc_globals.hpp from globals.hpp Changes: https://git.openjdk.java.net/jdk/pull/1797/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1797&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258459 Stats: 321 lines in 99 files changed: 221 ins; 63 del; 37 mod Patch: https://git.openjdk.java.net/jdk/pull/1797.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1797/head:pull/1797 PR: https://git.openjdk.java.net/jdk/pull/1797 From dholmes at openjdk.java.net Wed Dec 16 06:47:57 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 16 Dec 2020 06:47:57 GMT Subject: RFR: 8258058: improve description of OutOfMemoryError relevant flags [v2] In-Reply-To: References: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> Message-ID: <1FtFauwgIE_CHr-pbYr1MHaye98aPeY6_NV9HKK_-Rc=.eb856b91-2012-400d-a833-ac09f6280bdf@github.com> On Wed, 16 Dec 2020 06:04:07 GMT, Xin Liu wrote: >> 8258058: improve description of OutOfMemoryError relevant flags > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > fix the format issue Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1792 From david.holmes at oracle.com Wed Dec 16 06:48:49 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Dec 2020 16:48:49 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <93e65fc1-3052-706e-cabf-fb1ff4f7f895@oss.nttdata.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> <82684a2f-5231-d64b-5175-8aa6c8e428e9@oracle.com> <93e65fc1-3052-706e-cabf-fb1ff4f7f895@oss.nttdata.com> Message-ID: <6e375192-bb36-3888-58b1-5cdc52688b08@oracle.com> On 16/12/2020 4:33 pm, Yasumasa Suenaga wrote: > Hi David, > >> "This function will be called by the VM when the library is about to >> be unloaded. The library will be unloaded (unless it is statically >> linked into the executable) and this function will be called if some >> platform specific mechanism causes the unload (an unload mechanism is >> not specified in this document) or the library is (in effect) unloaded >> by the termination of the VM. VM termination includes normal >> termination and VM failure, including start-up failure, but not, of >> course, uncontrolled shutdown. An implementation may also choose to >> not call this function if the Agent_OnAttach/Agent_OnAttach_L function >> reported an error (returned a non-zero value)." > > Thank you so much! > According to this, we can fix this bug simply. (We can unload agent > library without `Agent_OnUnload()` call) Yes I think it is reasonable to allow this. But of course there must be a general consensus. > However I think following sentence should be removed because DLL > unloading mechanism is not hooked, and also `Agent_OnUnload()` wouldn't > be called by dll unloading - it depends on VM termination / failure / > non-zero value from entry points. > > "this function will be called if some platform specific mechanism causes > the unload (an unload mechanism is not specified in this document)" I'm not sure you mean exactly by DLL unloading mechanism is not hooked. But that sentence has to remain because it makes it clear that the decision as to when unloading occurs is up to an implementation and is not defined by the specification. Cheers, David ----- > > If you are OK, I will update CSR. > > > Cheers, > > Yasumasa > > > On 2020/12/16 11:09, David Holmes wrote: >> Hi Yasumasa, >> >> Sorry for the delay getting back to this. >> >> On 1/12/2020 4:41 pm, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> On 2020/12/01 14:59, David Holmes wrote: >>>> Looking at the original webrev from September: >>>> >>>> https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html >>>> >>>> >>>> The suggestion to unload the library if Agent_OnAttach fails seems >>>> quite reasonable - it is what happens if no Agent_OnAttach function >>>> can be found in the agent. >>>> >>>> But the specification is lacking because it simply states any such >>>> error is "ignored" - which is an oversimplification and I think was >>>> really intended to contrast with the abort behaviour if Agent_OnLoad >>>> fails. In addition the specification indicates that Agent_OnUnload >>>> is called any time the agent library is unloaded, except for >>>> "uncontrolled shutdown". This unfortunately suggests that before >>>> unloading the library after OnAttach fails, we also call OnUnload. >>>> That seems wrong and in fact the VM does not do that - and noone >>>> seems to have complained. >>>> >>>> Also note the specification states an agent "must export a start-up >>>> function ..." but doesn't say what happens if it doesn't do so. >>>> >>>> My gut feeling for what the specification should say here is that if >>>> the start-up function does not exist, or the call to Agent_OnAttach >>>> reports an error, then the agent library is immediately unloaded >>>> with no attempt to call the agent shutdown function (Agent_OnUnload). >>> >>> That's what I wanted to suggest! >>> I understand we need to consider following case in this issue, is it >>> right? >>> >>> Agent_OnLoad / Agent_OnLoad_L does not exist: >>> ???? - Agent_OnUnload is not called >>> ???? - DLL is not unloaded (JVM will abort) >>> >>> Agent_OnLoad / Agent_OnLoad_L failed: >>> ???? - Agent_OnUnload is not called >>> ???? - DLL is not unloaded (JVM will abort) >> >> These cases are already well covered. >> >>> Agent_OnAttach does not exist: >>> ???? - Agent_OnUnload is not called >>> ???? - DLL is unloaded >>> >>> Agent_OnAttach_L does not exist: >>> ???? - Agent_OnUnload is not called >>> ???? - DLL is not unloaded (static link) >> >> These cases are kind of implicitly covered, but could be clarified. >> >>> Agent_OnAttach failed: >>> ???? - Agent_OnUnload is not called >>> ???? - DLL is unloaded >>> >>> Agent_OnAttach_L faled: >>> ???? - Agent_OnUnload is not called >>> ???? - DLL is not unloaded (static link) >> >> These are the problematic cases. >> >>> >>>> But with my "compatibility glasses" on this may be too strong to >>>> retrofit to the specification as other VMs may behave differently. >>>> So as I stated in the CSR request we probably want to allow the >>>> current hotspot behaviour but not mandate it (unless we check with >>>> all the other VM implementations that such a specification is okay >>>> with them). >>> >>> Ok, for example, can we change the spec as following? >>> (Of course, this is not all) >>> >>> ``` >>> diff --git a/src/hotspot/share/prims/jvmti.xml >>> b/src/hotspot/share/prims/jvmti.xml >>> index 44553b8065f..57c87b1a71b 100644 >>> --- a/src/hotspot/share/prims/jvmti.xml >>> +++ b/src/hotspot/share/prims/jvmti.xml >>> @@ -688,7 +688,8 @@ Agent_OnUnload_L(JavaVM *vm) >>> ????? mechanism causes the unload (an unload mechanism is not >>> specified in this document) >>> ????? or the library is (in effect) unloaded by the termination of >>> the VM whether through >>> ????? normal termination or VM failure, including start-up failure. >>> -??? Uncontrolled shutdown is, of course, an exception to this rule. >>> +??? Uncontrolled shutdown is, of course, an exception to this rule, >>> and also it might not be called >>> +??? when start-up function does not exist or fails (returns non-zero >>> value). >> >> I think this is what was originally proposed and as I said then I >> don't like burying this detail inside the reference to uncontrolled >> shutdown. We should make this much more explicit which requires some >> reworking of the existing far-too-long sentence. >> >> "This function will be called by the VM when the library is about to >> be unloaded. The library will be unloaded (unless it is statically >> linked into the executable) and this function will be called if some >> platform specific mechanism causes the unload (an unload mechanism is >> not specified in this document) or the library is (in effect) unloaded >> by the termination of the VM. VM termination includes normal >> termination and VM failure, including start-up failure, but not, of >> course, uncontrolled shutdown. An implementation may also choose to >> not call this function if the Agent_OnAttach/Agent_OnAttach_L function >> reported an error (returned a non-zero value)." >> >> Cheers, >> David >> ----- >> >>> ????? Note the distinction between this function and the >>> ????? VM Death event: for the VM >>> Death event >>> ????? to be sent, the VM must have run at least to the point of >>> initialization and a valid >>> ``` >>> >>>> I agree that the more general issue of re-loading an agent is a >>>> separate issue. >>> >>> Thanks! >>> >>> >>> Yasumasa >>> >>> >>>> David >>>> ----- >>>> >>>> On 1/12/2020 3:21 pm, David Holmes wrote: >>>>> On 1/12/2020 3:19 pm, David Holmes wrote: >>>>>> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>>>>>> Hi Chris, David, >>>>>>> >>>>>>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is >>>>>>> failed - JVM will abort. >>>>>>> Should we re-think this behavior? >>>>>> >>>>>> We should we rethink that? It is probably one of the clearest >>>>>> parts of the spec. If Agent_Onload fails that is considered a >>>>>> fatal error - end of story. >>>>> >>>>> I meant, of course, "Why should we rethink that?". >>>>> >>>>> David >>>>> >>>>>> The issue is with Agent_onAttach and how its failure should, or >>>>>> should not, impact Agent_OnUnload. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>>>>>> >>>>>>> ``` >>>>>>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>>>>>> Hello World from Agent_OnLoad() >>>>>>> ?? options = error >>>>>>> Error occurred during initialization of VM >>>>>>> agent library failed to init: /path/to/libhelloworld.so >>>>>>> ``` >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2020/12/01 11:44, David Holmes wrote: >>>>>>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>>>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>>> * Q3: What has to be done for statically linked agent? >>>>>>>>>> >>>>>>>>>> JVMTI spec says "unless it is statically linked into the >>>>>>>>>> executable", so I think we can ignore about Agent_OnUnload_L() >>>>>>>>>> in this PR. >>>>>>>>> >>>>>>>>> I don't think that makes sense. If you call it for dynamically >>>>>>>>> linked then you need to call it for statically linked also. >>>>>>>> >>>>>>>> Agreed. Even though you can't physically unload the statically >>>>>>>> linked library, if it is logically unloaded by some mechanism, >>>>>>>> then Agent_OnUnload_L is supposed to be called. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> ------------- >>>>>>>>> >>>>>>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>>>>>> From stuefe at openjdk.java.net Wed Dec 16 07:22:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 16 Dec 2020 07:22:56 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v11] In-Reply-To: References: Message-ID: On Mon, 14 Dec 2020 14:29:22 GMT, Kim Barrett wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove use of make_unsigned, use UINT64_FORMAT_X to make sign extension stand out > > Marked as reviewed by kbarrett (Reviewer). > @kimbarrett @stefank - thank you for reviews! > > @tstuefe - re-testing latest on BE (ppc and s390?) would be much appreciated. I'm going to hold off on pushing this until some time after 16 forks off, so there's no rush. Hi Claes, sorry, I won't get to this before the holidays. @TheRealMDoerr maybe? ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From suenaga at oss.nttdata.com Wed Dec 16 07:36:30 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 16 Dec 2020 16:36:30 +0900 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <6e375192-bb36-3888-58b1-5cdc52688b08@oracle.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> <82684a2f-5231-d64b-5175-8aa6c8e428e9@oracle.com> <93e65fc1-3052-706e-cabf-fb1ff4f7f895@oss.nttdata.com> <6e375192-bb36-3888-58b1-5cdc52688b08@oracle.com> Message-ID: <2f67d06f-4345-0d10-89a8-906beadcd737@oss.nttdata.com> Hi David, > I'm not sure you mean exactly by DLL unloading mechanism is not hooked. I want to say we do not hook `FreeLibrary()` on Windows and `dlclose()` on Linux. Can we describe ""this function may be called - " at here? Cheers, Yasumasa On 2020/12/16 15:48, David Holmes wrote: > On 16/12/2020 4:33 pm, Yasumasa Suenaga wrote: >> Hi David, >> >>> "This function will be called by the VM when the library is about to be unloaded. The library will be unloaded (unless it is statically linked into the executable) and this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document) or the library is (in effect) unloaded by the termination of the VM. VM termination includes normal termination and VM failure, including start-up failure, but not, of course, uncontrolled shutdown. An implementation may also choose to not call this function if the Agent_OnAttach/Agent_OnAttach_L function reported an error (returned a non-zero value)." >> >> Thank you so much! >> According to this, we can fix this bug simply. (We can unload agent library without `Agent_OnUnload()` call) > > Yes I think it is reasonable to allow this. But of course there must be a general consensus. > >> However I think following sentence should be removed because DLL unloading mechanism is not hooked, and also `Agent_OnUnload()` wouldn't be called by dll unloading - it depends on VM termination / failure / non-zero value from entry points. >> >> "this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document)" > > I'm not sure you mean exactly by DLL unloading mechanism is not hooked. But that sentence has to remain because it makes it clear that the decision as to when unloading occurs is up to an implementation and is not defined by the specification. > > Cheers, > David > ----- > >> >> If you are OK, I will update CSR. >> >> >> Cheers, >> >> Yasumasa >> >> >> On 2020/12/16 11:09, David Holmes wrote: >>> Hi Yasumasa, >>> >>> Sorry for the delay getting back to this. >>> >>> On 1/12/2020 4:41 pm, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> On 2020/12/01 14:59, David Holmes wrote: >>>>> Looking at the original webrev from September: >>>>> >>>>> https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html >>>>> >>>>> The suggestion to unload the library if Agent_OnAttach fails seems quite reasonable - it is what happens if no Agent_OnAttach function can be found in the agent. >>>>> >>>>> But the specification is lacking because it simply states any such error is "ignored" - which is an oversimplification and I think was really intended to contrast with the abort behaviour if Agent_OnLoad fails. In addition the specification indicates that Agent_OnUnload is called any time the agent library is unloaded, except for "uncontrolled shutdown". This unfortunately suggests that before unloading the library after OnAttach fails, we also call OnUnload. That seems wrong and in fact the VM does not do that - and noone seems to have complained. >>>>> >>>>> Also note the specification states an agent "must export a start-up function ..." but doesn't say what happens if it doesn't do so. >>>>> >>>>> My gut feeling for what the specification should say here is that if the start-up function does not exist, or the call to Agent_OnAttach reports an error, then the agent library is immediately unloaded with no attempt to call the agent shutdown function (Agent_OnUnload). >>>> >>>> That's what I wanted to suggest! >>>> I understand we need to consider following case in this issue, is it right? >>>> >>>> Agent_OnLoad / Agent_OnLoad_L does not exist: >>>> ???? - Agent_OnUnload is not called >>>> ???? - DLL is not unloaded (JVM will abort) >>>> >>>> Agent_OnLoad / Agent_OnLoad_L failed: >>>> ???? - Agent_OnUnload is not called >>>> ???? - DLL is not unloaded (JVM will abort) >>> >>> These cases are already well covered. >>> >>>> Agent_OnAttach does not exist: >>>> ???? - Agent_OnUnload is not called >>>> ???? - DLL is unloaded >>>> >>>> Agent_OnAttach_L does not exist: >>>> ???? - Agent_OnUnload is not called >>>> ???? - DLL is not unloaded (static link) >>> >>> These cases are kind of implicitly covered, but could be clarified. >>> >>>> Agent_OnAttach failed: >>>> ???? - Agent_OnUnload is not called >>>> ???? - DLL is unloaded >>>> >>>> Agent_OnAttach_L faled: >>>> ???? - Agent_OnUnload is not called >>>> ???? - DLL is not unloaded (static link) >>> >>> These are the problematic cases. >>> >>>> >>>>> But with my "compatibility glasses" on this may be too strong to retrofit to the specification as other VMs may behave differently. So as I stated in the CSR request we probably want to allow the current hotspot behaviour but not mandate it (unless we check with all the other VM implementations that such a specification is okay with them). >>>> >>>> Ok, for example, can we change the spec as following? >>>> (Of course, this is not all) >>>> >>>> ``` >>>> diff --git a/src/hotspot/share/prims/jvmti.xml b/src/hotspot/share/prims/jvmti.xml >>>> index 44553b8065f..57c87b1a71b 100644 >>>> --- a/src/hotspot/share/prims/jvmti.xml >>>> +++ b/src/hotspot/share/prims/jvmti.xml >>>> @@ -688,7 +688,8 @@ Agent_OnUnload_L(JavaVM *vm) >>>> ????? mechanism causes the unload (an unload mechanism is not specified in this document) >>>> ????? or the library is (in effect) unloaded by the termination of the VM whether through >>>> ????? normal termination or VM failure, including start-up failure. >>>> -??? Uncontrolled shutdown is, of course, an exception to this rule. >>>> +??? Uncontrolled shutdown is, of course, an exception to this rule, and also it might not be called >>>> +??? when start-up function does not exist or fails (returns non-zero value). >>> >>> I think this is what was originally proposed and as I said then I don't like burying this detail inside the reference to uncontrolled shutdown. We should make this much more explicit which requires some reworking of the existing far-too-long sentence. >>> >>> "This function will be called by the VM when the library is about to be unloaded. The library will be unloaded (unless it is statically linked into the executable) and this function will be called if some platform specific mechanism causes the unload (an unload mechanism is not specified in this document) or the library is (in effect) unloaded by the termination of the VM. VM termination includes normal termination and VM failure, including start-up failure, but not, of course, uncontrolled shutdown. An implementation may also choose to not call this function if the Agent_OnAttach/Agent_OnAttach_L function reported an error (returned a non-zero value)." >>> >>> Cheers, >>> David >>> ----- >>> >>>> ????? Note the distinction between this function and the >>>> ????? VM Death event: for the VM Death event >>>> ????? to be sent, the VM must have run at least to the point of initialization and a valid >>>> ``` >>>> >>>>> I agree that the more general issue of re-loading an agent is a separate issue. >>>> >>>> Thanks! >>>> >>>> >>>> Yasumasa >>>> >>>> >>>>> David >>>>> ----- >>>>> >>>>> On 1/12/2020 3:21 pm, David Holmes wrote: >>>>>> On 1/12/2020 3:19 pm, David Holmes wrote: >>>>>>> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>>>>>>> Hi Chris, David, >>>>>>>> >>>>>>>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is failed - JVM will abort. >>>>>>>> Should we re-think this behavior? >>>>>>> >>>>>>> We should we rethink that? It is probably one of the clearest parts of the spec. If Agent_Onload fails that is considered a fatal error - end of story. >>>>>> >>>>>> I meant, of course, "Why should we rethink that?". >>>>>> >>>>>> David >>>>>> >>>>>>> The issue is with Agent_onAttach and how its failure should, or should not, impact Agent_OnUnload. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>>>>>>> >>>>>>>> ``` >>>>>>>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>>>>>>> Hello World from Agent_OnLoad() >>>>>>>> ?? options = error >>>>>>>> Error occurred during initialization of VM >>>>>>>> agent library failed to init: /path/to/libhelloworld.so >>>>>>>> ``` >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2020/12/01 11:44, David Holmes wrote: >>>>>>>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>>>>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga wrote: >>>>>>>>>> >>>>>>>>>>>> * Q3: What has to be done for statically linked agent? >>>>>>>>>>> >>>>>>>>>>> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. >>>>>>>>>> >>>>>>>>>> I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. >>>>>>>>> >>>>>>>>> Agreed. Even though you can't physically unload the statically linked library, if it is logically unloaded by some mechanism, then Agent_OnUnload_L is supposed to be called. >>>>>>>>> >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> ------------- >>>>>>>>>> >>>>>>>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>>>>>>> From kbarrett at openjdk.java.net Wed Dec 16 07:44:56 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 16 Dec 2020 07:44:56 GMT Subject: RFR: 8258252: Move PtrQueue enqueue to PtrQueueSet subclasses In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 09:55:14 GMT, Thomas Schatzl wrote: >> Please review this refactoring in the PtrQueue/PtrQueueSet hierarchy. >> >> The functions PtrQueue::enqueue and PtrQueue::enqueue_known_active are >> removed, along with the helper virtual function PtrQueue::handle_completed_buffer. >> >> Instead we now have G1{Dirty,Redirty}CardQueueSet::enqueue and SATBMarkQueueSet::enqueue/enqueue_known_active, each tailored to the corresponding specific behavior. They use some shared helper routines from PtrQueueSet, and the PtrQueue buffer and index have been made accessible to clients. >> >> Testing: >> mach5 tier1-3, 5 (stress tests) >> Local (linux-x64) tier1 with -XX:+UseShenandoahGC > > Lgtm. Thanks @tschatzl and @rkennke for reviews, and @rkennke for additional Shenandoah testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1776 From kbarrett at openjdk.java.net Wed Dec 16 07:58:13 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 16 Dec 2020 07:58:13 GMT Subject: RFR: 8258252: Move PtrQueue enqueue to PtrQueueSet subclasses [v2] In-Reply-To: References: Message-ID: <_ybPZVnQjZpAVuNyHl4ZK9K8eaezwtJAlV0vaulkpRo=.826b8506-967f-4485-8578-6ea55bfa9710@github.com> > Please review this refactoring in the PtrQueue/PtrQueueSet hierarchy. > > The functions PtrQueue::enqueue and PtrQueue::enqueue_known_active are > removed, along with the helper virtual function PtrQueue::handle_completed_buffer. > > Instead we now have G1{Dirty,Redirty}CardQueueSet::enqueue and SATBMarkQueueSet::enqueue/enqueue_known_active, each tailored to the corresponding specific behavior. They use some shared helper routines from PtrQueueSet, and the PtrQueue buffer and index have been made accessible to clients. > > Testing: > mach5 tier1-3, 5 (stress tests) > Local (linux-x64) tier1 with -XX:+UseShenandoahGC 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 three additional commits since the last revision: - Merge branch 'master' into move_enqueue - shenandoah support - move enqueue to qsets ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1776/files - new: https://git.openjdk.java.net/jdk/pull/1776/files/9dc2a4e5..6cfd4bea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1776&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1776&range=00-01 Stats: 5048 lines in 107 files changed: 3421 ins; 1280 del; 347 mod Patch: https://git.openjdk.java.net/jdk/pull/1776.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1776/head:pull/1776 PR: https://git.openjdk.java.net/jdk/pull/1776 From kbarrett at openjdk.java.net Wed Dec 16 07:58:14 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 16 Dec 2020 07:58:14 GMT Subject: Integrated: 8258252: Move PtrQueue enqueue to PtrQueueSet subclasses In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 05:32:07 GMT, Kim Barrett wrote: > Please review this refactoring in the PtrQueue/PtrQueueSet hierarchy. > > The functions PtrQueue::enqueue and PtrQueue::enqueue_known_active are > removed, along with the helper virtual function PtrQueue::handle_completed_buffer. > > Instead we now have G1{Dirty,Redirty}CardQueueSet::enqueue and SATBMarkQueueSet::enqueue/enqueue_known_active, each tailored to the corresponding specific behavior. They use some shared helper routines from PtrQueueSet, and the PtrQueue buffer and index have been made accessible to clients. > > Testing: > mach5 tier1-3, 5 (stress tests) > Local (linux-x64) tier1 with -XX:+UseShenandoahGC This pull request has now been integrated. Changeset: cdb53422 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/cdb53422 Stats: 364 lines in 22 files changed: 181 ins; 113 del; 70 mod 8258252: Move PtrQueue enqueue to PtrQueueSet subclasses Reviewed-by: tschatzl, rkennke ------------- PR: https://git.openjdk.java.net/jdk/pull/1776 From mikael at openjdk.java.net Wed Dec 16 08:28:01 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Wed, 16 Dec 2020 08:28:01 GMT Subject: RFR: 8253881: Hotspot/Serviceability 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 hotspot code and tests. Terms were changed as follows: 1. whitelist -> removed or changed to allow-list/allowed 2. blacklist -> removed 3. chop-chop -> removed ------------- Commit messages: - 8253881: Hotspot/Serviceability Terminology Refresh Changes: https://git.openjdk.java.net/jdk/pull/1798/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1798&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253881 Stats: 13 lines in 5 files changed: 0 ins; 7 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/1798.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1798/head:pull/1798 PR: https://git.openjdk.java.net/jdk/pull/1798 From rrich at openjdk.java.net Wed Dec 16 08:56:12 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 16 Dec 2020 08:56:12 GMT Subject: [jdk16] RFR: 8256843: [PPC64] test RedefineClasses.java fails with assert: registers not saved on stack Message-ID: // Continuation of https://github.com/openjdk/jdk/pull/1724 // I'm taking over from @TheRealMDoerr who's busy with 11u downports Please help review this small PPC64 fix. It replaces the call os::current_stack_pointer() in os::current_frame() with __builtin_frame_address(0) which is available also with xlC used by the AIX build. With this os::current_frame() is agnostic to C++ compiler inlining. Furthermore the fix changes os::current_frame() to return the correct frame. Without the fix the returned frame is one frame to high which triggered the assertion in trace_method_handle_stub(). This change uncovers an issue with NativeCallStack::NativeCallStack(int toSkip, bool fillStack) on PPC64. There the call os::get_native_stack() is not compiled to a tail call therefore the frame of the NativeCallStack constructor needs to be skipped on PPC64 too as on other platforms. Without this make run-test TEST=test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java fails. Furthermore the inline assembler from os::current_stack_pointer() is removed. Instead __builtin_frame_address(0) is used again. The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms ------------- Commit messages: - 8256843: [PPC64] test RedefineClasses.java fails with assert: registers not saved on stack Changes: https://git.openjdk.java.net/jdk16/pull/24/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=24&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256843 Stats: 31 lines in 3 files changed: 0 ins; 22 del; 9 mod Patch: https://git.openjdk.java.net/jdk16/pull/24.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/24/head:pull/24 PR: https://git.openjdk.java.net/jdk16/pull/24 From xliu at openjdk.java.net Wed Dec 16 09:03:56 2020 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 16 Dec 2020 09:03:56 GMT Subject: Integrated: 8258058: improve description of OutOfMemoryError relevant flags In-Reply-To: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> References: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> Message-ID: On Tue, 15 Dec 2020 23:29:22 GMT, Xin Liu wrote: > 8258058: improve description of OutOfMemoryError relevant flags This pull request has now been integrated. Changeset: 0c8cc2cd Author: Xin Liu Committer: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/0c8cc2cd Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod 8258058: improve description of OutOfMemoryError relevant flags OutOfMemoryError thrown out of JVM doesn't notify hotspot, so debug.cpp::report_java_out_out_memory does not handle it. ie. Some options don't respect OOMEs from Java libraries. We need to make the description more clear to users. Reviewed-by: dholmes, jiefu ------------- PR: https://git.openjdk.java.net/jdk/pull/1792 From xliu at openjdk.java.net Wed Dec 16 09:17:56 2020 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 16 Dec 2020 09:17:56 GMT Subject: RFR: 8258058: improve description of OutOfMemoryError relevant flags [v2] In-Reply-To: References: <1h5Cxw1J1tXga_fzLck5IYtlSNy6JEc9l2P6bs2sE80=.6bbe1dae-1ed0-4d2c-b130-119809537c40@github.com> Message-ID: On Wed, 16 Dec 2020 06:06:42 GMT, Jie Fu wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> fix the format issue > > Thanks for the change. > > LGTM Thanks! @DamonFool and @dholmes-ora ------------- PR: https://git.openjdk.java.net/jdk/pull/1792 From kbarrett at openjdk.java.net Wed Dec 16 09:39:58 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 16 Dec 2020 09:39:58 GMT Subject: RFR: 8253881: Hotspot/Serviceability Terminology Refresh In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 08:24:01 GMT, Mikael Vidstedt 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 hotspot code and tests. Terms were changed as follows: > > 1. whitelist -> removed or changed to allow-list/allowed > 2. blacklist -> removed > 3. chop-chop -> removed Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1798 From tschatzl at openjdk.java.net Wed Dec 16 09:56:56 2020 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Wed, 16 Dec 2020 09:56:56 GMT Subject: RFR: 8253881: Hotspot/Serviceability Terminology Refresh In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 08:24:01 GMT, Mikael Vidstedt 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 hotspot code and tests. Terms were changed as follows: > > 1. whitelist -> removed or changed to allow-list/allowed > 2. blacklist -> removed > 3. chop-chop -> removed Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1798 From mdoerr at openjdk.java.net Wed Dec 16 09:57:02 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 16 Dec 2020 09:57:02 GMT Subject: [jdk16] RFR: 8256843: [PPC64] test RedefineClasses.java fails with assert: registers not saved on stack In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 15:34:33 GMT, Richard Reingruber wrote: > // Continuation of https://github.com/openjdk/jdk/pull/1724 > // I'm taking over from @TheRealMDoerr who's busy with 11u downports > > Please help review this small PPC64 fix. > It replaces the call os::current_stack_pointer() in os::current_frame() > with __builtin_frame_address(0) which is available also with xlC used by the AIX > build. With this os::current_frame() is agnostic to C++ compiler inlining. > > Furthermore the fix changes os::current_frame() to return the correct > frame. Without the fix the returned frame is one frame to high which triggered > the assertion in trace_method_handle_stub(). > This change uncovers an issue with NativeCallStack::NativeCallStack(int toSkip, bool fillStack) > on PPC64. There the call os::get_native_stack() is not compiled > to a tail call therefore the frame of the NativeCallStack constructor needs to > be skipped on PPC64 too as on other platforms. > > Without this > > make run-test TEST=test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java > > fails. > > Furthermore the inline assembler from os::current_stack_pointer() is > removed. Instead __builtin_frame_address(0) is used again. > > The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms Thank you for fixing it in jdk16 as discussed in the jdk PR! Note that PR and JBS title must match, otherwise integration is blocked. ------------- Marked as reviewed by mdoerr (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/24 From dholmes at openjdk.java.net Wed Dec 16 10:02:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 16 Dec 2020 10:02:56 GMT Subject: RFR: 8253881: Hotspot/Serviceability Terminology Refresh In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 08:24:01 GMT, Mikael Vidstedt 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 hotspot code and tests. Terms were changed as follows: > > 1. whitelist -> removed or changed to allow-list/allowed > 2. blacklist -> removed > 3. chop-chop -> removed LGTM. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1798 From mdoerr at openjdk.java.net Wed Dec 16 10:09:55 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 16 Dec 2020 10:09:55 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v11] In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 07:19:53 GMT, Thomas Stuefe wrote: > Hi Claes, sorry, I won't get to this before the holidays. @TheRealMDoerr maybe? I've put it into our nightly testing again. We should see results tomorrow if everything works. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From stuefe at openjdk.java.net Wed Dec 16 10:11:06 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 16 Dec 2020 10:11:06 GMT Subject: RFR: JDK-8258469: Cleanup remaining safefetch test coding Message-ID: <6HkHFmD3f1TOVLB1zyP78S2gKIIySLMTlZN7N-g-Q4I=.9b9759be-06e5-4b6a-aa1f-53d0bbc8a387@github.com> JDK-8257828 fixed SafeFetch for non-java-thread situations on all platforms. It also introduced gtests. JDK-8185734 fixed the problem that gtests were running without SEH catcher on Windows, preventing us from testing Windows x86 at least. Since these are fixed, we can remove the related test coding in stubRoutines.cpp. ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/1799/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1799&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258469 Stats: 70 lines in 4 files changed: 8 ins; 55 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/1799.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1799/head:pull/1799 PR: https://git.openjdk.java.net/jdk/pull/1799 From rrich at openjdk.java.net Wed Dec 16 10:19:59 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Wed, 16 Dec 2020 10:19:59 GMT Subject: [jdk16] RFR: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 09:53:46 GMT, Martin Doerr wrote: > Thank you for fixing it in jdk16 as discussed in the jdk PR! Thanks for the review! > Note that PR and JBS title must match, otherwise integration is blocked. Mon dieu! I corrected the PR title :) ------------- PR: https://git.openjdk.java.net/jdk16/pull/24 From redestad at openjdk.java.net Wed Dec 16 11:12:55 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 16 Dec 2020 11:12:55 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v11] In-Reply-To: References: Message-ID: <69k8Moh5KhGkjiymiWIupvM_BgMfCE5Vz6sNSMz6Mb0=.b17954a6-0130-4e3e-bccb-ceff35213867@github.com> On Wed, 16 Dec 2020 10:06:59 GMT, Martin Doerr wrote: > I've put it into our nightly testing again. We should see results tomorrow if everything works. Perfect, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From aph at redhat.com Wed Dec 16 11:35:20 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 16 Dec 2020 11:35:20 +0000 Subject: RFR: 8256820: AArch64: Optimize vector rotate (immediate) with shift and insert instructions [v2] In-Reply-To: References: Message-ID: On 16/12/2020 02:02, Dong Bo wrote: > aph wrote: >> So, any change which causes divergence between microarchitectures must >> be needed, or it isn't worth the risk. It's not in your interest for >> that to happen, either. >> > OKAY, this does make sense to us, we don't want to take the possible risk neither. > By far, I think it's not worthy, unless we see a profitable workload one day. > As of now, I am going to withdraw this. Thank you for your understanding and co-operation. I know that it's hard to throw work away, but we'll never know if changes are worthwhile unless we try them. It wasn't a waste of time. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuefe at openjdk.java.net Wed Dec 16 12:45:01 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 16 Dec 2020 12:45:01 GMT Subject: RFR: JDK-8258479: Minor cleanups in VMError Message-ID: <7S7GO7A5oBUSvXbSpbE_7W_TfWGXCFLwHGgwzLGxv_o=.d4d7322d-d212-4cb8-a970-1e3312323c33@github.com> A list of smaller cleanups, each one too small to justify an own issue: 1) VMError exposes is_error_reported(), fatal_error_in_progress() and get_first_error_tid(). These functions are used from outside to check on the state of error handling. They can be combined and duplicate coding removed. Also, VMError::_error_reported can be removed, since its redundant with VMError::_first_error_tid != -1) 2) A lot of methods are unnecessarily public 3) the `env_var` array in vmError.cpp can be limited to file scope 4) definition of VMError static members should be combined to the start of the cpp file 5) the comment describing VMError::report() is misplaced 6) VMError::reset_signal_handlers() is badly named; nothing is reset here, the secondary signal handler is installed. ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/1802/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1802&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258479 Stats: 132 lines in 7 files changed: 45 ins; 62 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/1802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1802/head:pull/1802 PR: https://git.openjdk.java.net/jdk/pull/1802 From zgu at redhat.com Wed Dec 16 12:54:18 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 16 Dec 2020 07:54:18 -0500 Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJlOiDlm57lpI3vvJpSZTogQSBzb2x1dGlvbiB0?= =?UTF-8?Q?o_detect_the_footprint_of_Java_thread_stack?= In-Reply-To: <81665307-6b0b-3299-2cda-06b72968d360@oracle.com> References: <94dc25af-5a11-4414-bcba-45eca74014fc.qingfeng.yy@alibaba-inc.com> <1e423c3c-fac3-268e-f4f6-8d9f1a2cea51@oracle.com> <84812ffc-7947-da4c-15b0-9f38ed2c6615@oracle.com> <6f1a7c7e-13bf-49a2-a7d2-8596793cb2d6.qingfeng.yy@alibaba-inc.com> <81665307-6b0b-3299-2cda-06b72968d360@oracle.com> Message-ID: Hi, I agree with David, I don't see a lot of benefits for adding warning zone. I believe the feature can be achieved by utilizing existing NMT functionality as Thomas pointed out, either vs. JFR or jcmd, to report thread stack physical sizes (committed size), since they do not shrink, you get the idea the maximum space a thread used. -Zhengyu On 12/16/20 12:03 AM, David Holmes wrote: > Adding back the mailing lists ... > > Hi, > > On 16/12/2020 1:00 pm, Yang Yi wrote: >> ?Hi David, >> >> The purpose of this option is to warn rather than avoiding stack >> overflow. It would tell users how much stack space they have been used >> and what is the percentage of the stack footprint in the total. If the >> ratio of stack footprint reaches - XX:StackWarningRatio=90 in many >> iterations of the application, the user can make a judgment, whether to >> increase the stack space to reduce the risk of StackOverflowError or >> keep the current stack size to save memory as much as possible. > > My concern is the cost:benefit ratio for this feature. It's code that > has to be added and maintained and may interact in unintended ways with > other features - like ReservedStackAccess. So to me I see the cost here > as moderate. The benefit seems very small to me. I don't recall ever > seeing a feature request for this, and I just searched for it. If people > were trying to size their applications in the way you suggest, or if > they wanted to do so, then I would have expected to see requests for > such functionality. At the moment this seems a solution in search of a > problem. > > Just my opinion of course. > > Cheers, > David > ----- > >> >> Best, >> Yang YI >> >> ??? ------------------------------------------------------------------ >> ??? ????David Holmes >> ??? ????2020?12?15? 15:26:56 >> ??? ????Yang Yi; HotSpot Open Source >> ??? Developers; >> ??? hotspot-jfr-dev >> ??? ????Re: ???Re: A solution to detect the footprint of Java >> ??? thread stack >> >> ??? Hi, >> >> ??? On 15/12/2020 5:02 pm, Yang Yi wrote: >> ???? > Hi?David, >> ???? > >> ???? > Thank?you?for?your?comments. >> ???? > >> ???? > >> >> >?How?do?you?actually?envisage?people?using?this??This?seems?more?of?a >> ???? > >> >> >?tuning?option,?but?you?can?tune?just?as?readily?by?adjusting?-Xss?in?the >> >> ???? > >> >> >?same?manner?you?would?set?the?warning?ratio.?I.e.?you'd?like?to?shrink >> ???? > >> >> >?your?stack?usage?but?are?not?sure?how?small?you?can?make?it?safely?so >> ???? > >> >> >?you?can?either?just?reduce?-Xss?and?see?if?it?works,?or?you?can?set?the >> ???? > >> >> >?warning?ratio?to?give?the?same?effective?-Xss?and?see?if?you?get?a?warning. >> >> ???? > >> ???? > Yes, we can indeed achieve similar goals by constantly adjusting >> ???? > -Xss, but adjusting -Xss is generally a way to make the >> ??? application work >> ???? > again after StackOverflowError occurs. The purpose of >> ???? > -XX:StackWarningRatio is to warn early before StackOverflowError >> ??? occurs. >> >> ??? But the problem there is that triggering the warning does not >> indicate >> ??? that a stackoverflow will in fact occur. It will only tell whether >> you >> ??? used a given percentage of your stack, not how much you have actually >> ??? used. So how does this help you avoid stackoverflow? If you used the >> ??? warning to increase -Xss without ever encountering stackoverflow then >> ??? you are just wasting memory and potentially reducing the number of >> ??? threads you can support. >> >> ??? Cheers, >> ??? David >> >> >> ???? > Based on my experience and observation, many developers use the >> ??? default >> ???? > value of ThreadStackSize(the default value of is 1M on >> ??? linux_x86), they >> ???? > will not adjust the value of this option unless a stack overflow >> ??? occurs. >> ???? > With the iterative development of the application, the size of >> ??? the stack >> ???? > may no longer meet the demand. It's helpful to warn about >> ??? insufficient >> ???? > stack space earlier in case of hurriedly troubleshooting and >> ??? adjusting >> ???? > the -Xss when the application throws StackOverflowError in the >> ???? > production environment. >> ???? > >> >> >> ???? > >> ???? > >?The?flag?would?need?to?be?diagnostic?rather?than?full?product. >> ???? > >> ???? > Accept. >> ???? > >> ???? > Best, >> ???? > Yang?Yi >> ???? > >> ???? > ------------------------------------------------------------------ >> ???? > ????David Holmes >> ???? > ????2020?12?15? 13:24:54 >> ???? > ????Yang Yi; HotSpot Open Source >> ???? > Developers; >> ???? > hotspot-jfr-dev >> ???? > ????Re: A solution to detect the footprint of Java thread >> stack >> ???? > >> ???? > Hi?Yang?Yi, >> ???? > >> ???? > On?14/12/2020?3:03?pm,???(??)?wrote: >> ???? > >?Hi?all, >> ???? > >> >> >?We?occasionally?get?stack?overflow?errors?if?the?application?has?too?many?deep?callings.?The?usual?solution?is?to?increase?-Xss,?but?there?is?no?guiding?opinion?telling?us?in?advance?that?the?thread?stack?space?is?not?enough.?This?patch?attempts?to?address?this?issue.?It?introduces?a?new?stack?zone(warning_zone)?for?Hotspot?VM,?which?can?be?used?to?detect?whether?the?footprint?ratio?of?the?thread?stack?has?reached?the?watermark?set?by?the?user. >> >> ???? > > >> ???? > >?The?current?stack?layout?is?as?follows: >> ???? > >> >> >?stack_base????????????????????????????????????????????????????????????????????????????????????stack_end >> >> ???? > >> >> >?--------------------------------------------------------------------------------------------------------------------------- >> >> ???? > >> >> >?|????????|???shadow?zone?|???????????????????warning?zone(added)???????????????????|?reserved?zone?|?yellow?zone?|?red?zone?| >> >> ???? > >> >> >?--------------------------------------------------------------------------------------------------------------------------- >> >> ???? > >> >> >???????????^rsp???????????????????|<-StackWarningRatio?%?of?available?stack-> >> >> ???? > > >> ???? > >> >> >?Users?can?set?the?option?-XX:StackWarningRatio=0?to?turn?off?this?feature(which?is?also?the?default?value)?and?there?will?be?no?warning?zone,?the?stack?layout?is?the?same?as?usual. >> >> ???? > >> >> >?If?the?user?sets?-XX:StackWarningRatio?to?50,?the?VM?will?protect?50%?of?the?available?stack?space(let?all?=?available+reserved+yellow+red;)?as?stack?warning?zone.?When?the?footprint?of?available?stack?space?reaches?50%,?that?is,?when?the?application?accesses?the?stack?warning?zone,?the?sigsegv?signal?will?be?triggered,?and?then?the?signal?handler?will?warn?this?access?in?some?ways(e.g.?send?the?JFR?event,?logging)?and?resume?current?execution.?As?a?prototype,?this?feature?is?only?implemented?on?x86_posix,?it?can?be?implemented?on?more?platforms?as?needed. >> >> ???? > > >> ???? > >> >> >?Could?anyone?give?some?suggestions??If?you?think?this?is?a?useful?feature,?I?will?file?an?issue?and?support?it?on?all?platforms.?Looking?forward?to?your?comments. >> >> ???? > >> ???? > >> How?do?you?actually?envisage?people?using?this??This?seems?more?of?a >> ???? > >> >> tuning?option,?but?you?can?tune?just?as?readily?by?adjusting?-Xss?in?the >> ???? > >> ???? > >> >> same?manner?you?would?set?the?warning?ratio.?I.e.?you'd?like?to?shrink >> ???? > >> your?stack?usage?but?are?not?sure?how?small?you?can?make?it?safely?so >> ???? > >> >> you?can?either?just?reduce?-Xss?and?see?if?it?works,?or?you?can?set?the >> ???? > >> >> warning?ratio?to?give?the?same?effective?-Xss?and?see?if?you?get?a?warning. >> >> ???? > >> ???? > The?flag?would?need?to?be?diagnostic?rather?than?full?product. >> ???? > >> ???? > Cheers, >> ???? > David >> ???? > >> ???? > >> >> >?Patch:?https://github.com/kelthuzadx/jdk/commit/a145b2ebb4ac568e3bb090cbe3e7f091e1dc69ea >> >> ???? > >?Diff:?https://github.com/kelthuzadx/jdk/compare/37dc675..a145b2e >> ???? > > >> ???? > >?Best, >> ???? > >?Yang?Yi >> ???? > > >> ???? > >> From stuefe at openjdk.java.net Wed Dec 16 13:54:09 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 16 Dec 2020 13:54:09 GMT Subject: RFR: JDK-8258479: Minor cleanups in VMError [v2] In-Reply-To: <7S7GO7A5oBUSvXbSpbE_7W_TfWGXCFLwHGgwzLGxv_o=.d4d7322d-d212-4cb8-a970-1e3312323c33@github.com> References: <7S7GO7A5oBUSvXbSpbE_7W_TfWGXCFLwHGgwzLGxv_o=.d4d7322d-d212-4cb8-a970-1e3312323c33@github.com> Message-ID: <47cCTH8gHY-ur2ZJLIAOgcPtEJjOj_GhHSrqm2w9q9U=.33e2c983-feb6-4cc5-922c-fd20add48aef@github.com> > A list of smaller cleanups, each one too small to justify an own issue: > > 1) VMError exposes is_error_reported(), fatal_error_in_progress() and get_first_error_tid(). These functions are used from outside to check on the state of error handling. They can be combined and duplicate coding removed. Also, VMError::_error_reported can be removed, since its redundant with VMError::_first_error_tid != -1) > 2) A lot of methods are unnecessarily public > 3) the `env_var` array in vmError.cpp can be limited to file scope > 4) definition of VMError static members should be combined to the start of the cpp file > 5) the comment describing VMError::report() is misplaced > 6) VMError::reset_signal_handlers() is badly named; nothing is reset here, the secondary signal handler is installed. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Fix Windows builds ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1802/files - new: https://git.openjdk.java.net/jdk/pull/1802/files/47edef83..47c59b57 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1802&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1802&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1802/head:pull/1802 PR: https://git.openjdk.java.net/jdk/pull/1802 From lfoltan at openjdk.java.net Wed Dec 16 14:54:01 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 16 Dec 2020 14:54:01 GMT Subject: RFR: 8253881: Hotspot/Serviceability Terminology Refresh In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 08:24:01 GMT, Mikael Vidstedt 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 hotspot code and tests. Terms were changed as follows: > > 1. whitelist -> removed or changed to allow-list/allowed > 2. blacklist -> removed > 3. chop-chop -> removed LGTM. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1798 From dcubed at openjdk.java.net Wed Dec 16 15:07:56 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 16 Dec 2020 15:07:56 GMT Subject: RFR: 8258447: Move make/hotspot/hotspot.script to make/scripts In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:28:25 GMT, Magnus Ihse Bursie wrote: > The hotspot launcher script is misplaced among the hotspot make files. It should move to make/scripts (and get a proper extension). The rename and makefile changes look good. I've used the script on occasion, but not recently (not in the last 6 months). ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1791 From lfoltan at openjdk.java.net Wed Dec 16 15:28:57 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 16 Dec 2020 15:28:57 GMT Subject: RFR: JDK-8258479: Minor cleanups in VMError [v2] In-Reply-To: <47cCTH8gHY-ur2ZJLIAOgcPtEJjOj_GhHSrqm2w9q9U=.33e2c983-feb6-4cc5-922c-fd20add48aef@github.com> References: <7S7GO7A5oBUSvXbSpbE_7W_TfWGXCFLwHGgwzLGxv_o=.d4d7322d-d212-4cb8-a970-1e3312323c33@github.com> <47cCTH8gHY-ur2ZJLIAOgcPtEJjOj_GhHSrqm2w9q9U=.33e2c983-feb6-4cc5-922c-fd20add48aef@github.com> Message-ID: On Wed, 16 Dec 2020 13:54:09 GMT, Thomas Stuefe wrote: >> A list of smaller cleanups, each one too small to justify an own issue: >> >> 1) VMError exposes is_error_reported(), fatal_error_in_progress() and get_first_error_tid(). These functions are used from outside to check on the state of error handling. They can be combined and duplicate coding removed. Also, VMError::_error_reported can be removed, since its redundant with VMError::_first_error_tid != -1) >> 2) A lot of methods are unnecessarily public >> 3) the `env_var` array in vmError.cpp can be limited to file scope >> 4) definition of VMError static members should be combined to the start of the cpp file >> 5) the comment describing VMError::report() is misplaced >> 6) VMError::reset_signal_handlers() is badly named; nothing is reset here, the secondary signal handler is installed. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Fix Windows builds Nice cleanup! A couple of files need copyright updated. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1802 From lfoltan at openjdk.java.net Wed Dec 16 15:45:57 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Wed, 16 Dec 2020 15:45:57 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 06:24:59 GMT, Ioi Lam wrote: > Currently, [globals.hpp](https://github.com/openjdk/jdk/blob/17ace8339dd8235f3811e3975d9ccc77910b0c77/src/hotspot/share/runtime/globals.hpp#L29) is including gc_globals.hpp. This exposes all the GC command-line flags to almost all cpp files. However, only about 1/3 of the cpp files would require gc_globals.hpp. > > This RFE improves modularity and HotSpot build time. > > **Review notes:** > - Please start with globals.hpp, gc_globals.hpp. > - Flags related to TLAB are frequently used by other header files. I moved these flags to a new header tlab_globals.hpp. > - Some tweaking of oop.hpp to avoid including gc_globals.hpp in this popular header file. (Otherwise gc_globals.hpp would be included by everyone). > - The other changes are just files that use GC flags. They should have included gc_globals.hpp but didn't. > > **Testing:** > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. LGTM. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1797 From dcubed at openjdk.java.net Wed Dec 16 15:57:04 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 16 Dec 2020 15:57:04 GMT Subject: RFR: 8253881: Hotspot/Serviceability Terminology Refresh In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 08:24:01 GMT, Mikael Vidstedt 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 hotspot code and tests. Terms were changed as follows: > > 1. whitelist -> removed or changed to allow-list/allowed > 2. blacklist -> removed > 3. chop-chop -> removed Thumbs up. Looks about the same as your prelim... ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1798 From prappo at openjdk.java.net Wed Dec 16 16:34:04 2020 From: prappo at openjdk.java.net (Pavel Rappo) Date: Wed, 16 Dec 2020 16:34:04 GMT Subject: RFR: 8253881: Hotspot/Serviceability Terminology Refresh In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 15:54:46 GMT, Daniel D. Daugherty 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 hotspot code and tests. Terms were changed as follows: >> >> 1. whitelist -> removed or changed to allow-list/allowed >> 2. blacklist -> removed >> 3. chop-chop -> removed > > Thumbs up. Looks about the same as your prelim... Although I'm not an expert in this area, I'm concerned whether the words remaining in `test/hotspot/jtreg/compiler/c2/stemmer/words` make up for the ones being deleted. If they don't (i.e. the removal of words results in test cases being discarded), then new words should be added to compensate. ------------- PR: https://git.openjdk.java.net/jdk/pull/1798 From mdoerr at openjdk.java.net Wed Dec 16 16:34:04 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Wed, 16 Dec 2020 16:34:04 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v11] In-Reply-To: <69k8Moh5KhGkjiymiWIupvM_BgMfCE5Vz6sNSMz6Mb0=.b17954a6-0130-4e3e-bccb-ceff35213867@github.com> References: <69k8Moh5KhGkjiymiWIupvM_BgMfCE5Vz6sNSMz6Mb0=.b17954a6-0130-4e3e-bccb-ceff35213867@github.com> Message-ID: On Wed, 16 Dec 2020 11:10:03 GMT, Claes Redestad wrote: >>> Hi Claes, sorry, I won't get to this before the holidays. @TheRealMDoerr maybe? >> >> I've put it into our nightly testing again. We should see results tomorrow if everything works. > >> I've put it into our nightly testing again. We should see results tomorrow if everything works. > > Perfect, thanks! Hi Claes, I noticed that you're using `log2i_exact` in ppc.ad. That's wrong, we're hitting assertions because it's not used for exact powers of 2. Please change to `log2i`. I'll test with that change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From hseigel at openjdk.java.net Wed Dec 16 16:35:12 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 16 Dec 2020 16:35:12 GMT Subject: RFR: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses [v3] In-Reply-To: References: Message-ID: <6bgjyi90ypZf2Je4J_v-V4FcDH8DwMh-qyW7kngwjVg=.e8f34eda-75a8-42af-9671-f7352a50444e@github.com> > Please review this small fix for JDK-8257700 to add logging to JVM_GetPermittedSubclasses(). The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS, and WIndows, tiers 3-5 on Linux x64, and by running the hotspot runtime sealed tests with -Xlog:class+sealed=trace and looking at the output. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1780/files - new: https://git.openjdk.java.net/jdk/pull/1780/files/4cb2719d..7883a52a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1780&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1780&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1780.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1780/head:pull/1780 PR: https://git.openjdk.java.net/jdk/pull/1780 From hseigel at openjdk.java.net Wed Dec 16 16:35:15 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 16 Dec 2020 16:35:15 GMT Subject: RFR: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses [v2] In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 22:17:54 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses > > src/hotspot/share/prims/jvm.cpp line 2129: > >> 2127: assert(c->is_instance_klass(), "must be"); >> 2128: InstanceKlass* ik = InstanceKlass::cast(c); >> 2129: log_trace(class, sealed)("Calling GetPermittedSubclasses for %s type %s", > > I don't know why this didn't complain about a missing ResourceMark, but can you add one just before line 2129 and it'll clean up any potential resource area uses for any external_name() calls. They're not that expensive so one would do without conditionalization. I added the ResourceMark in the latest commit. Thanks for pointing out that it was missing! Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1780 From hseigel at openjdk.java.net Wed Dec 16 16:35:14 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 16 Dec 2020 16:35:14 GMT Subject: RFR: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses [v2] In-Reply-To: References: Message-ID: <2eVPjIFg6ohi3xQOcON-KgRXCMz6GCZDRUIMaFpekJ0=.6a035b21-0ff3-43aa-8e53-430705927186@github.com> On Wed, 16 Dec 2020 00:44:56 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses > > Hi Harold, > Looks good. One minor comment below. > Thanks, > David Thanks Lois, Coleen, and David for reviewing this change. Please review the latest commit that adds the missing ResourceMark and removes the useless logging statement that David mentioned. Thanks! Harold > src/hotspot/share/prims/jvm.cpp line 2168: > >> 2166: // we had invalid entries so we need to compact the array >> 2167: log_trace(class, sealed)(" - compacting array from length %d to %d", >> 2168: length, count); > > Not sure this really adds any useful information, but your call. I agree that it is not useful. I've removed it. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1780 From redestad at openjdk.java.net Wed Dec 16 16:54:57 2020 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 16 Dec 2020 16:54:57 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v11] In-Reply-To: References: <69k8Moh5KhGkjiymiWIupvM_BgMfCE5Vz6sNSMz6Mb0=.b17954a6-0130-4e3e-bccb-ceff35213867@github.com> Message-ID: On Wed, 16 Dec 2020 16:15:39 GMT, Martin Doerr wrote: > Hi Claes, > I noticed that you're using `log2i_exact` in ppc.ad. That's wrong, we're hitting assertions because it's not used for exact powers of 2. Please change to `log2i`. I'll test with that change. To have the same semantics as before I guess `log2i_graceful` is the better fit. I picked `log2i_exact` since the variable names suggested they were powers of two. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From stuefe at openjdk.java.net Wed Dec 16 17:02:56 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 16 Dec 2020 17:02:56 GMT Subject: RFR: JDK-8258479: Minor cleanups in VMError [v2] In-Reply-To: References: <7S7GO7A5oBUSvXbSpbE_7W_TfWGXCFLwHGgwzLGxv_o=.d4d7322d-d212-4cb8-a970-1e3312323c33@github.com> <47cCTH8gHY-ur2ZJLIAOgcPtEJjOj_GhHSrqm2w9q9U=.33e2c983-feb6-4cc5-922c-fd20add48aef@github.com> Message-ID: <-hzV7TfXaE3LBRIhh5kvrSSIpmMaC5evzr1634DE6UM=.1c61ba62-a2aa-4a40-aaeb-ef9aa0324d9a@github.com> On Wed, 16 Dec 2020 15:25:59 GMT, Lois Foltan wrote: > Nice cleanup! A couple of files need copyright updated. > Lois Thank you Lois! I'll fix the copyrights before integrating. ------------- PR: https://git.openjdk.java.net/jdk/pull/1802 From coleenp at openjdk.java.net Wed Dec 16 17:08:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Dec 2020 17:08:56 GMT Subject: RFR: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses [v3] In-Reply-To: <6bgjyi90ypZf2Je4J_v-V4FcDH8DwMh-qyW7kngwjVg=.e8f34eda-75a8-42af-9671-f7352a50444e@github.com> References: <6bgjyi90ypZf2Je4J_v-V4FcDH8DwMh-qyW7kngwjVg=.e8f34eda-75a8-42af-9671-f7352a50444e@github.com> Message-ID: On Wed, 16 Dec 2020 16:35:12 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8257700 to add logging to JVM_GetPermittedSubclasses(). The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS, and WIndows, tiers 3-5 on Linux x64, and by running the hotspot runtime sealed tests with -Xlog:class+sealed=trace and looking at the output. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1780 From coleenp at openjdk.java.net Wed Dec 16 17:13:00 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Dec 2020 17:13:00 GMT Subject: RFR: JDK-8258479: Minor cleanups in VMError [v2] In-Reply-To: <47cCTH8gHY-ur2ZJLIAOgcPtEJjOj_GhHSrqm2w9q9U=.33e2c983-feb6-4cc5-922c-fd20add48aef@github.com> References: <7S7GO7A5oBUSvXbSpbE_7W_TfWGXCFLwHGgwzLGxv_o=.d4d7322d-d212-4cb8-a970-1e3312323c33@github.com> <47cCTH8gHY-ur2ZJLIAOgcPtEJjOj_GhHSrqm2w9q9U=.33e2c983-feb6-4cc5-922c-fd20add48aef@github.com> Message-ID: On Wed, 16 Dec 2020 13:54:09 GMT, Thomas Stuefe wrote: >> A list of smaller cleanups, each one too small to justify an own issue: >> >> 1) VMError exposes is_error_reported(), fatal_error_in_progress() and get_first_error_tid(). These functions are used from outside to check on the state of error handling. They can be combined and duplicate coding removed. Also, VMError::_error_reported can be removed, since its redundant with VMError::_first_error_tid != -1) >> 2) A lot of methods are unnecessarily public >> 3) the `env_var` array in vmError.cpp can be limited to file scope >> 4) definition of VMError static members should be combined to the start of the cpp file >> 5) the comment describing VMError::report() is misplaced >> 6) VMError::reset_signal_handlers() is badly named; nothing is reset here, the secondary signal handler is installed. > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Fix Windows builds Looks good! Thank you for this cleanup. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1802 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 ihse at openjdk.java.net Wed Dec 16 18:51:58 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 16 Dec 2020 18:51:58 GMT Subject: Integrated: 8258447: Move make/hotspot/hotspot.script to make/scripts In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 23:28:25 GMT, Magnus Ihse Bursie wrote: > The hotspot launcher script is misplaced among the hotspot make files. It should move to make/scripts (and get a proper extension). This pull request has now been integrated. Changeset: ab5d581b Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/ab5d581b Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8258447: Move make/hotspot/hotspot.script to make/scripts Reviewed-by: dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/1791 From hseigel at openjdk.java.net Wed Dec 16 19:23:58 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 16 Dec 2020 19:23:58 GMT Subject: Integrated: 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 15:45:25 GMT, Harold Seigel wrote: > Please review this small fix for JDK-8257700 to add logging to JVM_GetPermittedSubclasses(). The fix was tested with Mach5 tiers 1 and 2 on Linux, MacOS, and WIndows, tiers 3-5 on Linux x64, and by running the hotspot runtime sealed tests with -Xlog:class+sealed=trace and looking at the output. > > Thanks, Harold This pull request has now been integrated. Changeset: 330ce861 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/330ce861 Stats: 17 lines in 1 file changed: 16 ins; 1 del; 0 mod 8257700: Add logging for sealed classes in JVM_GetPermittedSubclasses Reviewed-by: lfoltan, coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1780 From iklam at openjdk.java.net Wed Dec 16 19:43:14 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 16 Dec 2020 19:43:14 GMT Subject: RFR: 8258075: Use auto variable declarations for enum iteration [v2] In-Reply-To: References: Message-ID: > The pattern used in https://github.com/openjdk/jdk/pull/1707 > > for (vmIntrinsicID index : EnumRange{}) { > nt[as_int(index)] = string; > } > > can be further simplified to the following without loss of readability, since the type of `index` would obviously be the type enclosed by `EnumRange<>` > > for (auto index : EnumRange{}) { > nt[as_int(index)] = string; > } > > (as suggested by John Rose) Ioi Lam 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 8258075-auto-declaration-enum-iter - 8258075: Use auto variable declarations for enum iteration ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1751/files - new: https://git.openjdk.java.net/jdk/pull/1751/files/7097f13b..71c31a84 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1751&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1751&range=00-01 Stats: 7462 lines in 211 files changed: 4911 ins; 1914 del; 637 mod Patch: https://git.openjdk.java.net/jdk/pull/1751.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1751/head:pull/1751 PR: https://git.openjdk.java.net/jdk/pull/1751 From iklam at openjdk.java.net Wed Dec 16 19:43:16 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 16 Dec 2020 19:43:16 GMT Subject: RFR: 8258075: Use auto variable declarations for enum iteration [v2] In-Reply-To: References: Message-ID: On Sat, 12 Dec 2020 00:05:15 GMT, Calvin Cheung wrote: >> Ioi Lam 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 8258075-auto-declaration-enum-iter >> - 8258075: Use auto variable declarations for enum iteration > > Looks good. Thanks @calvinccheung and @rose00 for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/1751 From iklam at openjdk.java.net Wed Dec 16 19:43:17 2020 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 16 Dec 2020 19:43:17 GMT Subject: Integrated: 8258075: Use auto variable declarations for enum iteration In-Reply-To: References: Message-ID: On Fri, 11 Dec 2020 22:33:33 GMT, Ioi Lam wrote: > The pattern used in https://github.com/openjdk/jdk/pull/1707 > > for (vmIntrinsicID index : EnumRange{}) { > nt[as_int(index)] = string; > } > > can be further simplified to the following without loss of readability, since the type of `index` would obviously be the type enclosed by `EnumRange<>` > > for (auto index : EnumRange{}) { > nt[as_int(index)] = string; > } > > (as suggested by John Rose) This pull request has now been integrated. Changeset: 59f4c4aa Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/59f4c4aa Stats: 16 lines in 6 files changed: 0 ins; 0 del; 16 mod 8258075: Use auto variable declarations for enum iteration Reviewed-by: jrose, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/1751 From coleenp at openjdk.java.net Wed Dec 16 23:05:04 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 16 Dec 2020 23:05:04 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions Message-ID: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> Please review some mostly superficial cleanups to the SystemDictionary code. See issue for more details. Tested with tier1-6. ------------- Commit messages: - Remove some unused includes. - 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions Changes: https://git.openjdk.java.net/jdk/pull/1808/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1808&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258408 Stats: 208 lines in 8 files changed: 38 ins; 71 del; 99 mod Patch: https://git.openjdk.java.net/jdk/pull/1808.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1808/head:pull/1808 PR: https://git.openjdk.java.net/jdk/pull/1808 From coleenp at openjdk.java.net Thu Dec 17 00:47:04 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 00:47:04 GMT Subject: RFR: 8257530: vmTestbase/metaspace/stressDictionary/StressDictionary.java timed out Message-ID: Increase the timeout for this test a bit. The bug didn't show any deadlocks or other indications that the test was stuck. Tested with 100x on linux, macosx and windows platforms. ------------- Commit messages: - 8257530: vmTestbase/metaspace/stressDictionary/StressDictionary.java timed out Changes: https://git.openjdk.java.net/jdk/pull/1810/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1810&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257530 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1810.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1810/head:pull/1810 PR: https://git.openjdk.java.net/jdk/pull/1810 From lmesnik at openjdk.java.net Thu Dec 17 00:49:02 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 17 Dec 2020 00:49:02 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition Message-ID: The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. I run all existing tests with enabled logging and sanity verified error messages. ------------- Commit messages: - updated. - redfine log added Changes: https://git.openjdk.java.net/jdk/pull/1811/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1811&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258061 Stats: 63 lines in 1 file changed: 53 ins; 10 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1811.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1811/head:pull/1811 PR: https://git.openjdk.java.net/jdk/pull/1811 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 jbhateja at openjdk.java.net Thu Dec 17 04:44:59 2020 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 17 Dec 2020 04:44:59 GMT Subject: Integrated: 8257772: Vectorizing clear memory operation using AVX-512 masked operations In-Reply-To: References: Message-ID: On Fri, 4 Dec 2020 18:28:44 GMT, Jatin Bhateja wrote: > A newly allocated memory is initialized either using user provided initialization values for various fields or setting the memory to zero as per java semantics (System initialization). > > C2 compiler creates ClearArray Node in order to perform system initialization. ClearArray accepts the number of Heap Words to be initialized, this number can be constant or a non-constant value. For constant number of heap words less than InitArrayShortSize (default value 64 bytes) currently compiler generates StoreL nodes which does the initialization at the granularity of 8 bytes. > > This patch vectorizes the initializing store operations for constant sized heap word less than InitArrayShortSize by emitting special instruction sequence for various tail sizes. > > In addition existing implementation for initialization under UseXMMForObjInit is extended to use masked operation to optimize tail initialization sequence. In case AVX3Threshold is set to 0 then new initialization sequence uses 64 byte ZMM registers. > > Following are the performance stats collected using micro-benchmark included with the patch. > > Testing : Tier1-Tier3 level tests are clean. > > System Configuration : Cascadelake, Intel Xeon Platinum 8280L @ 2.7 GHz, 2 socket, 28 cores per socket. > > ### Baseline: > Benchmark Mode Cnt Score Error Units > ClearMemory.testClearMemory16K thrpt 2 1427741.069 ops/s > ClearMemory.testClearMemory1K thrpt 2 47628368.596 ops/s > ClearMemory.testClearMemory1M thrpt 2 27388.979 ops/s > ClearMemory.testClearMemory24B thrpt 2 167681010.419 ops/s > ClearMemory.testClearMemory2K thrpt 2 22043948.290 ops/s > ClearMemory.testClearMemory32B thrpt 2 168599498.817 ops/s > ClearMemory.testClearMemory32K thrpt 2 775985.067 ops/s > ClearMemory.testClearMemory40B thrpt 2 153375273.800 ops/s > ClearMemory.testClearMemory48B thrpt 2 145328531.804 ops/s > ClearMemory.testClearMemory4K thrpt 2 6492257.452 ops/s > ClearMemory.testClearMemory56B thrpt 2 122376321.652 ops/s > ClearMemory.testClearMemory8K thrpt 2 2857444.413 ops/s > ClearMemory.testClearMemory8M thrpt 2 3461.674 ops/s > ### With Optimization: > Benchmark Mode Cnt Score Error Units > ClearMemory.testClearMemory16K thrpt 2 2529701.368 ops/s > ClearMemory.testClearMemory1K thrpt 2 50276682.550 ops/s > ClearMemory.testClearMemory1M thrpt 2 27458.588 ops/s > ClearMemory.testClearMemory24B thrpt 2 178751174.642 ops/s > ClearMemory.testClearMemory2K thrpt 2 22574802.694 ops/s > ClearMemory.testClearMemory32B thrpt 2 176630844.950 ops/s > ClearMemory.testClearMemory32K thrpt 2 1297627.181 ops/s > ClearMemory.testClearMemory40B thrpt 2 167469550.653 ops/s > ClearMemory.testClearMemory48B thrpt 2 159391163.006 ops/s > ClearMemory.testClearMemory4K thrpt 2 9045158.643 ops/s > ClearMemory.testClearMemory56B thrpt 2 134550172.421 ops/s > ClearMemory.testClearMemory8K thrpt 2 4581450.664 ops/s > ClearMemory.testClearMemory8M thrpt 2 3446.834 ops/s This pull request has now been integrated. Changeset: c11525a4 Author: Jatin Bhateja URL: https://git.openjdk.java.net/jdk/commit/c11525a4 Stats: 404 lines in 8 files changed: 376 ins; 3 del; 25 mod 8257772: Vectorizing clear memory operation using AVX-512 masked operations Reviewed-by: thartmann, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/1631 From stuefe at openjdk.java.net Thu Dec 17 05:07:02 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 17 Dec 2020 05:07:02 GMT Subject: RFR: JDK-8258479: Minor cleanups in VMError [v2] In-Reply-To: References: <7S7GO7A5oBUSvXbSpbE_7W_TfWGXCFLwHGgwzLGxv_o=.d4d7322d-d212-4cb8-a970-1e3312323c33@github.com> <47cCTH8gHY-ur2ZJLIAOgcPtEJjOj_GhHSrqm2w9q9U=.33e2c983-feb6-4cc5-922c-fd20add48aef@github.com> Message-ID: On Wed, 16 Dec 2020 17:10:00 GMT, Coleen Phillimore wrote: > Looks good! Thank you for this cleanup. :) Thanks Coleen! ------------- PR: https://git.openjdk.java.net/jdk/pull/1802 From stuefe at openjdk.java.net Thu Dec 17 05:29:10 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 17 Dec 2020 05:29:10 GMT Subject: RFR: JDK-8258479: Minor cleanups in VMError [v3] In-Reply-To: <7S7GO7A5oBUSvXbSpbE_7W_TfWGXCFLwHGgwzLGxv_o=.d4d7322d-d212-4cb8-a970-1e3312323c33@github.com> References: <7S7GO7A5oBUSvXbSpbE_7W_TfWGXCFLwHGgwzLGxv_o=.d4d7322d-d212-4cb8-a970-1e3312323c33@github.com> Message-ID: > A list of smaller cleanups, each one too small to justify an own issue: > > 1) VMError exposes is_error_reported(), fatal_error_in_progress() and get_first_error_tid(). These functions are used from outside to check on the state of error handling. They can be combined and duplicate coding removed. Also, VMError::_error_reported can be removed, since its redundant with VMError::_first_error_tid != -1) > 2) A lot of methods are unnecessarily public > 3) the `env_var` array in vmError.cpp can be limited to file scope > 4) definition of VMError static members should be combined to the start of the cpp file > 5) the comment describing VMError::report() is misplaced > 6) VMError::reset_signal_handlers() is badly named; nothing is reset here, the secondary signal handler is installed. Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Fix Copyrights ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1802/files - new: https://git.openjdk.java.net/jdk/pull/1802/files/47c59b57..b286e94c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1802&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1802&range=01-02 Stats: 7 lines in 6 files changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1802/head:pull/1802 PR: https://git.openjdk.java.net/jdk/pull/1802 From stuefe at openjdk.java.net Thu Dec 17 05:29:11 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 17 Dec 2020 05:29:11 GMT Subject: Integrated: JDK-8258479: Minor cleanups in VMError In-Reply-To: <7S7GO7A5oBUSvXbSpbE_7W_TfWGXCFLwHGgwzLGxv_o=.d4d7322d-d212-4cb8-a970-1e3312323c33@github.com> References: <7S7GO7A5oBUSvXbSpbE_7W_TfWGXCFLwHGgwzLGxv_o=.d4d7322d-d212-4cb8-a970-1e3312323c33@github.com> Message-ID: On Wed, 16 Dec 2020 12:27:31 GMT, Thomas Stuefe wrote: > A list of smaller cleanups, each one too small to justify an own issue: > > 1) VMError exposes is_error_reported(), fatal_error_in_progress() and get_first_error_tid(). These functions are used from outside to check on the state of error handling. They can be combined and duplicate coding removed. Also, VMError::_error_reported can be removed, since its redundant with VMError::_first_error_tid != -1) > 2) A lot of methods are unnecessarily public > 3) the `env_var` array in vmError.cpp can be limited to file scope > 4) definition of VMError static members should be combined to the start of the cpp file > 5) the comment describing VMError::report() is misplaced > 6) VMError::reset_signal_handlers() is badly named; nothing is reset here, the secondary signal handler is installed. This pull request has now been integrated. Changeset: 178c0018 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/178c0018 Stats: 140 lines in 8 files changed: 49 ins; 62 del; 29 mod 8258479: Minor cleanups in VMError Reviewed-by: lfoltan, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1802 From cjplummer at openjdk.java.net Thu Dec 17 05:30:00 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Dec 2020 05:30:00 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 00:44:18 GMT, Leonid Mesnik wrote: > The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. > I run all existing tests with enabled logging and sanity verified error messages. src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1003: > 1001: ("redefined class %s modifiers change error: modifiers changed from %d to %d.", > 1002: the_class->external_name(), old_flags, new_flags); > 1003: return JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_MODIFIERS_CHANGED; You've changed the ordering of the checks. I'm not sure why. src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 936: > 934: scratch_class->super()->name())) { > 935: log_trace(redefine, class, normalize) > 936: ("redefined class %s superclass change error: superclass changed from %s to %s.", I'm not so sure I like the style of the log message wording. I would prefer something like: error redefining class %s: superclass changed from %s to %s. The same comment applies to pretty much every error message below. Besides being more concise and easier to read, I don't like using "superclass change error" when there is no such formally defined error. The error is `JVMTI_ERROR_UNSUPPORTED_REDEFINITION_HIERARCHY_CHANGED`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From cjplummer at openjdk.java.net Thu Dec 17 05:33:58 2020 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 17 Dec 2020 05:33:58 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: References: Message-ID: <1em3Hqp5pzUBBViIiPvWEMSbELrUvmXloZ1BvlGZoWo=.edcca0ec-4173-42fa-8ccf-d055c3254578@github.com> On Thu, 17 Dec 2020 05:27:36 GMT, Chris Plummer wrote: >> The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. >> I run all existing tests with enabled logging and sanity verified error messages. > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 936: > >> 934: scratch_class->super()->name())) { >> 935: log_trace(redefine, class, normalize) >> 936: ("redefined class %s superclass change error: superclass changed from %s to %s.", > > I'm not so sure I like the style of the log message wording. I would prefer something like: > > error redefining class %s: superclass changed from %s to %s. > > The same comment applies to pretty much every error message below. Besides being more concise and easier to read, I don't like using "superclass change error" when there is no such formally defined error. The error is `JVMTI_ERROR_UNSUPPORTED_REDEFINITION_HIERARCHY_CHANGED`. I see now that you are just being consistent with the style used in existing logs, so I guess it's ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From david.holmes at oracle.com Thu Dec 17 06:45:53 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Dec 2020 16:45:53 +1000 Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: <341a8c19-e3fa-d1fe-caa9-240749dc4960@oracle.com> Hi Mauro, Dmitry, On 15/12/2020 6:21 pm, Mauro Lacy wrote: > On Fri, 11 Dec 2020 08:39:58 GMT, Mauro Lacy wrote: > >> Besides, I don't think the same is true of the other `Release` methods. This happens only with the `Critical` variant. > > Sorry for the confusion. The reported double free error always mentions `ReleasePrimitiveArrayCritical`, but as Dmitry says, this ends up affecting both APIs. Right - I'm fixing that incorrect message as well. But after giving this a lot of thought and research (see comments in https://bugs.openjdk.java.net/browse/JDK-8258185) I've decided that the appropriate fix here is simply to modify the fix for JDK-8193234 so that it only affects the ReleasePrimitiveArrayCritical case. It will still be incorrect to call ReleasePrimitiveArrayCritical more than once per GetPrimitiveArrayCritical, regardless of mode, due to the fact hotspot never returns a copy here. This programming error will not be observed in normal execution, but will be detected as a side-effect of the additional checking done under -Xcheck:jni. It may be possible to allow multiple calls to ReleasePrimitiveArrayCritical by checking if the native array is located in the Java heap or not, but this seems like a programming error to me as noted in the bug reports, and hence not something I want to support/encourage. I'll be creating a PR as soon as some further sanity testing has been done. Thanks, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1697 > From dholmes at openjdk.java.net Thu Dec 17 07:18:54 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Dec 2020 07:18:54 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions In-Reply-To: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> Message-ID: On Wed, 16 Dec 2020 23:01:11 GMT, Coleen Phillimore wrote: > Please review some mostly superficial cleanups to the SystemDictionary code. See issue for more details. > > Tested with tier1-6. Seems okay. Had to think a bit about the exception change. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1808 From github.com+11656534+maurolacy at openjdk.java.net Thu Dec 17 08:12:55 2020 From: github.com+11656534+maurolacy at openjdk.java.net (Mauro Lacy) Date: Thu, 17 Dec 2020 08:12:55 GMT Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: On Tue, 15 Dec 2020 08:18:28 GMT, Mauro Lacy wrote: >> David, I can't comment in the issue page (AFAIK), but I agree with what you wrote there. >> >> Just one more thing: The behaviour of `ReleasePrimitiveArrayCritical` with `JNI_COMMIT` **changes** depending on if the `-Xcheck:jni` flag is set or not. This is inconsistent behaviour. Probably introduced when trying to satisfy both usage patterns. >> >> Besides, I don't think the same is true of the other `Release` methods. This happens only with the `Critical` variant. > >> Besides, I don't think the same is true of the other `Release` methods. This happens only with the `Critical` variant. > > Sorry for (contributing to) the confusion. The reported double free error always mentions `ReleasePrimitiveArrayCritical`, but as Dmitry says, this ends up affecting both APIs. Hi David, Thanks for researching this thoroughly. What you propose is reasonable, given the circumstances: undocumented or badly documented usage in the specs, and a lot of existing code (even in books, etc) that use `JNI_COMMIT` basically as `0`. We faced the same weeks ago, when looking for examples, documentation, and use cases for this functionality. A couple comments: - Given that `JNI_COMMIT` is then effectively useless, maybe a good idea would be to deprecate it. This will break existing code, true, but a deprecation notice can be used, by example in the form of a compilation warning or so, for code that calls / uses it. Same in the docs, i. e. this is kept for historical reasons but will be deprecated soon, and so on. - I think in this case the best for us would be to simply drop support for `JNI_COMMIT` in the Rust JNI library. At least, for the ArrayCritical methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/1697 From roland at openjdk.java.net Thu Dec 17 08:25:06 2020 From: roland at openjdk.java.net (Roland Westrelin) Date: Thu, 17 Dec 2020 08:25:06 GMT Subject: [jdk16] RFR: 8258393: Shenandoah: "graph should be schedulable" assert failure Message-ID: This is a shenandoah bug but the fix is in shared code. At barrier expansion time, we need the raw memory state for the control at which the barrier is expanded. Before expansion, the memory graph is traversed and memory state for each control is recorded. In that process, if opportunities to improve the memory graph are found, the graph is modified. In the case of the failure, a raw memory load was assigned a call projection as control but for that control, no memory state was recorded and the fall back is to use the call's input memory state. As a consequence the load's memory input is updated to a wrong memory state. This causes the assert failure. The call has 2 memory projections: one for the fallthrough and one for the exception path. One projection is the memory state for the CatchProj for the fallthrough, the other one for the CatchProj of the exception path. For the control projection out of the call, there's no memory state that makes sense and assigning the control projection of the call as control for the load is the root cause of the problem. This happens because anti-dependence analysis is too conservative: a memory Phi that merges states from the exception and fallthrough path is considered a dependency and that pushed the load right after the call. I propose to be less conservative in anti-dependence analysis for Phis. For a Phi, when computing the LCA, I think it's sufficient to only consider region's inputs that we actually reach by following the memory edges and that's what I propose here. ------------- Commit messages: - test & fix Changes: https://git.openjdk.java.net/jdk16/pull/41/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=41&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258393 Stats: 110 lines in 3 files changed: 103 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk16/pull/41.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/41/head:pull/41 PR: https://git.openjdk.java.net/jdk16/pull/41 From david.holmes at oracle.com Thu Dec 17 11:31:55 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Dec 2020 21:31:55 +1000 Subject: RFR: 8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234 In-Reply-To: References: <4EwfB2P2LcJm6haSmXdwvG0AtEDeCzZpg2xaWqdf16A=.1dcae0cd-0871-444d-8a30-42911d204c2c@github.com> <4prgjcdzeJShXyAbgWR4fIz0rBrps_cgoRKtP7rMdYk=.35b2ac7f-c8f4-493b-b1dc-2f3c85e44391@github.com> <5LIC7byB6uP9LnNbElULHfVIrUAbH8715RoKVnuF7Kk=.f4682183-9000-4eb3-8324-bbb1316eef81@github.com> Message-ID: <344da6e4-0e22-0983-722e-36ceb688ce87@oracle.com> Hi Mauro, On 17/12/2020 6:12 pm, Mauro Lacy wrote: > On Tue, 15 Dec 2020 08:18:28 GMT, Mauro Lacy wrote: > >>> David, I can't comment in the issue page (AFAIK), but I agree with what you wrote there. >>> >>> Just one more thing: The behaviour of `ReleasePrimitiveArrayCritical` with `JNI_COMMIT` **changes** depending on if the `-Xcheck:jni` flag is set or not. This is inconsistent behaviour. Probably introduced when trying to satisfy both usage patterns. >>> >>> Besides, I don't think the same is true of the other `Release` methods. This happens only with the `Critical` variant. >> >>> Besides, I don't think the same is true of the other `Release` methods. This happens only with the `Critical` variant. >> >> Sorry for (contributing to) the confusion. The reported double free error always mentions `ReleasePrimitiveArrayCritical`, but as Dmitry says, this ends up affecting both APIs. > > Hi David, > > Thanks for researching this thoroughly. > What you propose is reasonable, given the circumstances: undocumented or badly documented usage in the specs, and a lot of existing code (even in books, etc) that use `JNI_COMMIT` basically as `0`. We faced the same weeks ago, when looking for examples, documentation, and use cases for this functionality. > > A couple comments: > - Given that `JNI_COMMIT` is then effectively useless, maybe a good idea would be to deprecate it. This will break existing code, true, but a deprecation notice can be used, by example in the form of a compilation warning or so, for code that calls / uses it. Same in the docs, i. e. this is kept for historical reasons but will be deprecated soon, and so on. Not withstanding the lack of clarity in the spec I think JNI_COMMIT still has a theoretical use whenever a copy is made. But we will look at issues of deprecation etc in the context of JDK-8258185. > - I think in this case the best for us would be to simply drop support for `JNI_COMMIT` in the Rust JNI library. At least, for the ArrayCritical methods. That sounds good. Thank you very much for raising this issue and working through the details. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1697 > From lucy at openjdk.java.net Thu Dec 17 11:54:58 2020 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 17 Dec 2020 11:54:58 GMT Subject: [jdk16] RFR: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 15:34:33 GMT, Richard Reingruber wrote: > // Continuation of https://github.com/openjdk/jdk/pull/1724 > // I'm taking over from @TheRealMDoerr who's busy with 11u downports > > Please help review this small PPC64 fix. > It replaces the call os::current_stack_pointer() in os::current_frame() > with __builtin_frame_address(0) which is available also with xlC used by the AIX > build. With this os::current_frame() is agnostic to C++ compiler inlining. > > Furthermore the fix changes os::current_frame() to return the correct > frame. Without the fix the returned frame is one frame to high which triggered > the assertion in trace_method_handle_stub(). > This change uncovers an issue with NativeCallStack::NativeCallStack(int toSkip, bool fillStack) > on PPC64. There the call os::get_native_stack() is not compiled > to a tail call therefore the frame of the NativeCallStack constructor needs to > be skipped on PPC64 too as on other platforms. > > Without this > > make run-test TEST=test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java > > fails. > > Furthermore the inline assembler from os::current_stack_pointer() is > removed. Instead __builtin_frame_address(0) is used again. > > The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms Changes look good. Thanks for fixing. Side note (not relevant for approval): Wouldn't it be nice to use the builtin just once and call os::current_stack_pointer() in os::current_frame()? ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk16/pull/24 From mdoerr at openjdk.java.net Thu Dec 17 12:12:58 2020 From: mdoerr at openjdk.java.net (Martin Doerr) Date: Thu, 17 Dec 2020 12:12:58 GMT Subject: RFR: 8257815: Replace global log2 functions with efficient implementations [v11] In-Reply-To: References: <69k8Moh5KhGkjiymiWIupvM_BgMfCE5Vz6sNSMz6Mb0=.b17954a6-0130-4e3e-bccb-ceff35213867@github.com> Message-ID: <9D4pRJcX5SOTHeBxQmxM23cQYrggeIyrflF-8bemMZs=.a3458e8c-f5d0-48bb-bbdc-ee2e625d7cf8@github.com> On Wed, 16 Dec 2020 16:52:09 GMT, Claes Redestad wrote: >> Hi Claes, >> I noticed that you're using `log2i_exact` in ppc.ad. That's wrong, we're hitting assertions because it's not used for exact powers of 2. Please change to `log2i`. I'll test with that change. > >> Hi Claes, >> I noticed that you're using `log2i_exact` in ppc.ad. That's wrong, we're hitting assertions because it's not used for exact powers of 2. Please change to `log2i`. I'll test with that change. > > To have the same semantics as before I guess `log2i_graceful` is the better fit. I picked `log2i_exact` since the variable names suggested they were powers of two. You're right, looks like `log2i_exact` should be used and only braces are wrong. I'll try to fix it and get back to you. Thanks for your patience. ------------- PR: https://git.openjdk.java.net/jdk/pull/1663 From rrich at openjdk.java.net Thu Dec 17 13:24:57 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Thu, 17 Dec 2020 13:24:57 GMT Subject: [jdk16] RFR: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 11:51:53 GMT, Lutz Schmidt wrote: > > > Changes look good. Thanks for fixing. Thanks for the review! > Side note (not relevant for approval): Wouldn't it be nice to use the builtin just once and call os::current_stack_pointer() in os::current_frame()? Yeah this would be nice but then we would be dependent to call inlining by the C++ compiler, i.e. we'd have to fiddle around with _NMT_NOINLINE_ again (btw: we could do the same on [s390 where _NMT_NOINLINE_ is used](https://github.com/openjdk/jdk/blob/83be8a902cee867c0e9d400e762f61896eb6df80/src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp#L197-L203)) ------------- PR: https://git.openjdk.java.net/jdk16/pull/24 From coleenp at openjdk.java.net Thu Dec 17 13:29:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 13:29:02 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: References: Message-ID: <5JnfETmHNoAT7qmq9s_CaoagDaQfluT7V8JYsnQ6GIQ=.896623d0-aa19-41bc-bead-e347b87b0114@github.com> On Thu, 17 Dec 2020 00:44:18 GMT, Leonid Mesnik wrote: > The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. > I run all existing tests with enabled logging and sanity verified error messages. src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 935: > 933: the_class->super()->name() != > 934: scratch_class->super()->name())) { > 935: log_trace(redefine, class, normalize) I think these would be useful to users so that these should be made log_info(redefine). All the other redefinition logging is useful for developers in debugging redefinition, and a user wouldn't really be able to follow the output unless they are very knowledgeable. Making this log_info(redefine) would let them see this without the noise of the other output. ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From coleenp at openjdk.java.net Thu Dec 17 13:40:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 13:40:01 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions In-Reply-To: References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> Message-ID: On Thu, 17 Dec 2020 07:15:46 GMT, David Holmes wrote: >> Please review some mostly superficial cleanups to the SystemDictionary code. See issue for more details. >> >> Tested with tier1-6. > > Seems okay. > > Had to think a bit about the exception change. > > Thanks, > David Thanks for the review, David. >Had to think a bit about the exception change. Me too, which is why I changed it. I didn't find a good reason to copy the exception when we didn't need to. ------------- PR: https://git.openjdk.java.net/jdk/pull/1808 From lfoltan at openjdk.java.net Thu Dec 17 15:35:57 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 17 Dec 2020 15:35:57 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions In-Reply-To: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> Message-ID: <5vG8-Px-CwlOHkHMGpX61MJfCJTTR36IwexoPKMw2Ts=.843ab43e-b28e-4210-bb66-5370e7b041b2@github.com> On Wed, 16 Dec 2020 23:01:11 GMT, Coleen Phillimore wrote: > Please review some mostly superficial cleanups to the SystemDictionary code. See issue for more details. > > Tested with tier1-6. Looks good. Lois src/hotspot/share/classfile/systemDictionary.cpp line 205: > 203: // lock. The results are being recorded in the performance counters defined in > 204: // ClassLoader::_sync_systemLoaderLockContentionRate and > 205: // ClassLoader::_sync_nonSystemLoaderLockConteionRate. nonSystemLoaderLockContentionRate misspelled. ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1808 From lfoltan at openjdk.java.net Thu Dec 17 15:43:56 2020 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 17 Dec 2020 15:43:56 GMT Subject: RFR: 8257530: vmTestbase/metaspace/stressDictionary/StressDictionary.java timed out In-Reply-To: References: Message-ID: <-kgH94iOKgef3Re7eD2SHtfQ38cQC9tqlD8H776Dplw=.efa16c4d-9dac-4e90-a8fd-825f717d7c3d@github.com> On Thu, 17 Dec 2020 00:42:00 GMT, Coleen Phillimore wrote: > Increase the timeout for this test a bit. The bug didn't show any deadlocks or other indications that the test was stuck. > Tested with 100x on linux, macosx and windows platforms. Looks good & trivial. Lois ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1810 From coleenp at openjdk.java.net Thu Dec 17 15:43:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 15:43:57 GMT Subject: RFR: 8257530: vmTestbase/metaspace/stressDictionary/StressDictionary.java timed out In-Reply-To: <-kgH94iOKgef3Re7eD2SHtfQ38cQC9tqlD8H776Dplw=.efa16c4d-9dac-4e90-a8fd-825f717d7c3d@github.com> References: <-kgH94iOKgef3Re7eD2SHtfQ38cQC9tqlD8H776Dplw=.efa16c4d-9dac-4e90-a8fd-825f717d7c3d@github.com> Message-ID: On Thu, 17 Dec 2020 15:38:34 GMT, Lois Foltan wrote: >> Increase the timeout for this test a bit. The bug didn't show any deadlocks or other indications that the test was stuck. >> Tested with 100x on linux, macosx and windows platforms. > > Looks good & trivial. > Lois Thanks Lois for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/1810 From coleenp at openjdk.java.net Thu Dec 17 15:43:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 15:43:58 GMT Subject: Integrated: 8257530: vmTestbase/metaspace/stressDictionary/StressDictionary.java timed out In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 00:42:00 GMT, Coleen Phillimore wrote: > Increase the timeout for this test a bit. The bug didn't show any deadlocks or other indications that the test was stuck. > Tested with 100x on linux, macosx and windows platforms. This pull request has now been integrated. Changeset: 8251b746 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/8251b746 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8257530: vmTestbase/metaspace/stressDictionary/StressDictionary.java timed out Reviewed-by: lfoltan ------------- PR: https://git.openjdk.java.net/jdk/pull/1810 From coleenp at openjdk.java.net Thu Dec 17 15:45:13 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 15:45:13 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions [v2] In-Reply-To: <5vG8-Px-CwlOHkHMGpX61MJfCJTTR36IwexoPKMw2Ts=.843ab43e-b28e-4210-bb66-5370e7b041b2@github.com> References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> <5vG8-Px-CwlOHkHMGpX61MJfCJTTR36IwexoPKMw2Ts=.843ab43e-b28e-4210-bb66-5370e7b041b2@github.com> Message-ID: <4Oyn4mZinBGFva5idFZiyRW7qTqaDTYflwQdF54_EsQ=.917b1ab3-b0c7-4a0a-8df3-2a8e25319edc@github.com> On Thu, 17 Dec 2020 15:32:00 GMT, Lois Foltan wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo. > > src/hotspot/share/classfile/systemDictionary.cpp line 205: > >> 203: // lock. The results are being recorded in the performance counters defined in >> 204: // ClassLoader::_sync_systemLoaderLockContentionRate and >> 205: // ClassLoader::_sync_nonSystemLoaderLockConteionRate. > > nonSystemLoaderLockContentionRate misspelled. Fixed. thanks for noticing that. ------------- PR: https://git.openjdk.java.net/jdk/pull/1808 From coleenp at openjdk.java.net Thu Dec 17 15:45:12 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 15:45:12 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions [v2] In-Reply-To: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> Message-ID: <5nbft2YflANjwNdJYywJgGsJaIqo3Le4aggHlDmhIpM=.4c63e765-49a9-476c-8cc0-bb982f16308b@github.com> > Please review some mostly superficial cleanups to the SystemDictionary code. See issue for more details. > > Tested with tier1-6. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix typo. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1808/files - new: https://git.openjdk.java.net/jdk/pull/1808/files/8452a352..0d9d6933 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1808&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1808&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1808.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1808/head:pull/1808 PR: https://git.openjdk.java.net/jdk/pull/1808 From lmesnik at openjdk.java.net Thu Dec 17 16:12:58 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 17 Dec 2020 16:12:58 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: References: Message-ID: <5FV52nh_1HBsZTOyYBVKKPQH8hYbh3gTfcYY5gkuEzY=.8a2bb58d-03bb-4452-813f-f8cfe4c9c6c4@github.com> On Thu, 17 Dec 2020 05:27:28 GMT, Chris Plummer wrote: >> The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. >> I run all existing tests with enabled logging and sanity verified error messages. > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1003: > >> 1001: ("redefined class %s modifiers change error: modifiers changed from %d to %d.", >> 1002: the_class->external_name(), old_flags, new_flags); >> 1003: return JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_MODIFIERS_CHANGED; > > You've changed the ordering of the checks. I'm not sure why. I changed the order to report about different names first if any of the variables are added/deleted. And report about different modifiers/offsets only if the names of variables are the same. The result should be the same because JVMTI_ERROR_UNSUPPORTED_REDEFINITION_SCHEMA_CHANGED is returned anyway. ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From lmesnik at openjdk.java.net Thu Dec 17 16:13:01 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 17 Dec 2020 16:13:01 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: <5JnfETmHNoAT7qmq9s_CaoagDaQfluT7V8JYsnQ6GIQ=.896623d0-aa19-41bc-bead-e347b87b0114@github.com> References: <5JnfETmHNoAT7qmq9s_CaoagDaQfluT7V8JYsnQ6GIQ=.896623d0-aa19-41bc-bead-e347b87b0114@github.com> Message-ID: On Thu, 17 Dec 2020 13:25:42 GMT, Coleen Phillimore wrote: >> The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. >> I run all existing tests with enabled logging and sanity verified error messages. > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 935: > >> 933: the_class->super()->name() != >> 934: scratch_class->super()->name())) { >> 935: log_trace(redefine, class, normalize) > > I think these would be useful to users so that these should be made log_info(redefine). All the other redefinition logging is useful for developers in debugging redefinition, and a user wouldn't really be able to follow the output unless they are very knowledgeable. Making this log_info(redefine) would let them see this without the noise of the other output. I've made them log_trace to be consistent with already existing logging introduced for nestmates related errors. Do you want to make all of them log_info in such case? ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From coleenp at openjdk.java.net Thu Dec 17 18:48:58 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 18:48:58 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: References: <5JnfETmHNoAT7qmq9s_CaoagDaQfluT7V8JYsnQ6GIQ=.896623d0-aa19-41bc-bead-e347b87b0114@github.com> Message-ID: <_0DS35gmr5jBx9MeDr36TUlGveC4oXScyAjFjYjE8UA=.afd3a44f-d358-4514-bdbe-9112715f4f18@github.com> On Thu, 17 Dec 2020 16:10:29 GMT, Leonid Mesnik wrote: >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 935: >> >>> 933: the_class->super()->name() != >>> 934: scratch_class->super()->name())) { >>> 935: log_trace(redefine, class, normalize) >> >> I think these would be useful to users so that these should be made log_info(redefine). All the other redefinition logging is useful for developers in debugging redefinition, and a user wouldn't really be able to follow the output unless they are very knowledgeable. Making this log_info(redefine) would let them see this without the noise of the other output. > > I've made them log_trace to be consistent with already existing logging introduced for nestmates related errors. Do you want to make all of them log_info in such case? I see. I think so, yes. Since you're returning an error from redefinition, a higher level logging seems warranted. ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From coleenp at openjdk.java.net Thu Dec 17 18:52:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 18:52:57 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions [v2] In-Reply-To: <5vG8-Px-CwlOHkHMGpX61MJfCJTTR36IwexoPKMw2Ts=.843ab43e-b28e-4210-bb66-5370e7b041b2@github.com> References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> <5vG8-Px-CwlOHkHMGpX61MJfCJTTR36IwexoPKMw2Ts=.843ab43e-b28e-4210-bb66-5370e7b041b2@github.com> Message-ID: On Thu, 17 Dec 2020 15:33:28 GMT, Lois Foltan wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo. > > Looks good. > Lois Thanks for the code reviews David and Lois. ------------- PR: https://git.openjdk.java.net/jdk/pull/1808 From coleenp at openjdk.java.net Thu Dec 17 18:52:59 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 18:52:59 GMT Subject: Integrated: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions In-Reply-To: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> Message-ID: <3mAkKVA_1Zg7FzoVfbDL90bXyQzDZIzpxSvWb_lTi4I=.f75ad655-2805-48ec-8eba-edde3b7ce601@github.com> On Wed, 16 Dec 2020 23:01:11 GMT, Coleen Phillimore wrote: > Please review some mostly superficial cleanups to the SystemDictionary code. See issue for more details. > > Tested with tier1-6. This pull request has now been integrated. Changeset: 6e824b3f Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/6e824b3f Stats: 208 lines in 8 files changed: 38 ins; 71 del; 99 mod 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions Reviewed-by: dholmes, lfoltan ------------- PR: https://git.openjdk.java.net/jdk/pull/1808 From coleenp at openjdk.java.net Thu Dec 17 19:05:55 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 17 Dec 2020 19:05:55 GMT Subject: RFR: JDK-8258469: Cleanup remaining safefetch test coding In-Reply-To: <6HkHFmD3f1TOVLB1zyP78S2gKIIySLMTlZN7N-g-Q4I=.9b9759be-06e5-4b6a-aa1f-53d0bbc8a387@github.com> References: <6HkHFmD3f1TOVLB1zyP78S2gKIIySLMTlZN7N-g-Q4I=.9b9759be-06e5-4b6a-aa1f-53d0bbc8a387@github.com> Message-ID: On Wed, 16 Dec 2020 09:20:14 GMT, Thomas Stuefe wrote: > JDK-8257828 fixed SafeFetch for non-java-thread situations on all platforms. It also introduced gtests. > JDK-8185734 fixed the problem that gtests were running without SEH catcher on Windows, preventing us from testing Windows x86 at least. > > Since we have now gtests to test SafeFetch, and since all these issues are fixed, we can remove the related test coding in stubRoutines.cpp. > > Testing: manual gtests and GH actions (the Linux x86 error can be ignored, see https://bugs.openjdk.java.net/browse/JDK-8258481). This looks great, thank you! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1799 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 lmesnik at openjdk.java.net Thu Dec 17 22:54:13 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 17 Dec 2020 22:54:13 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition [v2] In-Reply-To: References: Message-ID: > The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. > I run all existing tests with enabled logging and sanity verified error messages. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: updated log_trace to log_info ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1811/files - new: https://git.openjdk.java.net/jdk/pull/1811/files/801a0c2a..fe6dccf3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1811&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1811&range=00-01 Stats: 21 lines in 1 file changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/1811.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1811/head:pull/1811 PR: https://git.openjdk.java.net/jdk/pull/1811 From david.holmes at oracle.com Thu Dec 17 23:37:17 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Dec 2020 09:37:17 +1000 Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions In-Reply-To: References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> Message-ID: On 17/12/2020 11:40 pm, Coleen Phillimore wrote: > On Thu, 17 Dec 2020 07:15:46 GMT, David Holmes wrote: > >>> Please review some mostly superficial cleanups to the SystemDictionary code. See issue for more details. >>> >>> Tested with tier1-6. >> >> Seems okay. >> >> Had to think a bit about the exception change. >> >> Thanks, >> David > > Thanks for the review, David. >> Had to think a bit about the exception change. > Me too, which is why I changed it. I didn't find a good reason to copy the exception when we didn't need to. Copy it? It isn't it just saving it to be rethrown after we release the lock? The main reason for that code that I can see is to ensure there is no pending exception when we call the rest of the code in that block. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1808 > From lmesnik at openjdk.java.net Thu Dec 17 23:51:57 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 17 Dec 2020 23:51:57 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition [v2] In-Reply-To: <_0DS35gmr5jBx9MeDr36TUlGveC4oXScyAjFjYjE8UA=.afd3a44f-d358-4514-bdbe-9112715f4f18@github.com> References: <5JnfETmHNoAT7qmq9s_CaoagDaQfluT7V8JYsnQ6GIQ=.896623d0-aa19-41bc-bead-e347b87b0114@github.com> <_0DS35gmr5jBx9MeDr36TUlGveC4oXScyAjFjYjE8UA=.afd3a44f-d358-4514-bdbe-9112715f4f18@github.com> Message-ID: On Thu, 17 Dec 2020 18:46:14 GMT, Coleen Phillimore wrote: >> I've made them log_trace to be consistent with already existing logging introduced for nestmates related errors. Do you want to make all of them log_info in such case? > > I see. I think so, yes. Since you're returning an error from redefinition, a higher level logging seems warranted. I've updated logging to use log_info where error is returned. ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From coleenp at openjdk.java.net Fri Dec 18 02:09:57 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Dec 2020 02:09:57 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition [v2] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 22:54:13 GMT, Leonid Mesnik wrote: >> The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. >> I run all existing tests with enabled logging and sanity verified error messages. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated log_trace to log_info Looks good to me. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1811 From coleenp at openjdk.java.net Fri Dec 18 02:18:00 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Dec 2020 02:18:00 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions [v2] In-Reply-To: <5nbft2YflANjwNdJYywJgGsJaIqo3Le4aggHlDmhIpM=.4c63e765-49a9-476c-8cc0-bb982f16308b@github.com> References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> <5nbft2YflANjwNdJYywJgGsJaIqo3Le4aggHlDmhIpM=.4c63e765-49a9-476c-8cc0-bb982f16308b@github.com> Message-ID: On Thu, 17 Dec 2020 15:45:12 GMT, Coleen Phillimore wrote: >> Please review some mostly superficial cleanups to the SystemDictionary code. See issue for more details. >> >> Tested with tier1-6. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo. src/hotspot/share/classfile/systemDictionary.cpp line 1785: > 1783: assert(check != NULL, "definer missed recording success"); > 1784: #endif > 1785: return probe->instance_klass(); So this copies the exception into a Handle linkage_exception, and clears the exception. src/hotspot/share/classfile/systemDictionary.cpp line 1797: > 1795: { > 1796: MutexLocker mu(THREAD, SystemDictionary_lock); > 1797: PlaceholderEntry* probe = placeholders()->get_entry(name_hash, name_h, loader_data); This rethrows the exception at the end of the function. ------------- PR: https://git.openjdk.java.net/jdk/pull/1808 From coleenp at openjdk.java.net Fri Dec 18 02:18:01 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Dec 2020 02:18:01 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions [v2] In-Reply-To: References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> <5nbft2YflANjwNdJYywJgGsJaIqo3Le4aggHlDmhIpM=.4c63e765-49a9-476c-8cc0-bb982f16308b@github.com> Message-ID: <8cnDk1TzkQE3RO0o1vKClBh2BmKTTuJXg76PeIOC1YQ=.a0a55175-097b-46c7-a9de-0b2217d8c6ff@github.com> On Fri, 18 Dec 2020 02:11:13 GMT, Coleen Phillimore wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo. > > src/hotspot/share/classfile/systemDictionary.cpp line 1797: > >> 1795: { >> 1796: MutexLocker mu(THREAD, SystemDictionary_lock); >> 1797: PlaceholderEntry* probe = placeholders()->get_entry(name_hash, name_h, loader_data); > > This rethrows the exception at the end of the function. // definer must notify any waiting threads { MutexLocker mu(THREAD, SystemDictionary_lock); PlaceholderEntry* probe = placeholders()->get_entry(p_index, p_hash, name_h, loader_data); assert(probe != NULL, "DEFINE_CLASS placeholder lost?"); if (probe != NULL) { if (HAS_PENDING_EXCEPTION) { linkage_exception = Handle(THREAD,PENDING_EXCEPTION); CLEAR_PENDING_EXCEPTION; } else { probe->set_instance_klass(k); } probe->set_definer(NULL); placeholders()->find_and_remove(p_index, p_hash, name_h, loader_data, PlaceholderTable::DEFINE_CLASS, THREAD); SystemDictionary_lock->notify_all(); } } // Can't throw exception while holding lock due to rank ordering if (linkage_exception() != NULL) { THROW_OOP_(linkage_exception(), NULL); // throws exception and returns } ------------- PR: https://git.openjdk.java.net/jdk/pull/1808 From coleenp at openjdk.java.net Fri Dec 18 02:18:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Dec 2020 02:18:02 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions [v2] In-Reply-To: <8cnDk1TzkQE3RO0o1vKClBh2BmKTTuJXg76PeIOC1YQ=.a0a55175-097b-46c7-a9de-0b2217d8c6ff@github.com> References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> <5nbft2YflANjwNdJYywJgGsJaIqo3Le4aggHlDmhIpM=.4c63e765-49a9-476c-8cc0-bb982f16308b@github.com> <8cnDk1TzkQE3RO0o1vKClBh2BmKTTuJXg76PeIOC1YQ=.a0a55175-097b-46c7-a9de-0b2217d8c6ff@github.com> Message-ID: <9lh3-eps-1ncFB68P7XvyhI1DqVuq71lH_xMKwZD7Zo=.551f12f9-0877-49b6-b59c-8570aabf440c@github.com> On Fri, 18 Dec 2020 02:13:04 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/systemDictionary.cpp line 1797: >> >>> 1795: { >>> 1796: MutexLocker mu(THREAD, SystemDictionary_lock); >>> 1797: PlaceholderEntry* probe = placeholders()->get_entry(name_hash, name_h, loader_data); >> >> This rethrows the exception at the end of the function. > > // definer must notify any waiting threads > { > MutexLocker mu(THREAD, SystemDictionary_lock); > PlaceholderEntry* probe = placeholders()->get_entry(p_index, p_hash, name_h, loader_data); > assert(probe != NULL, "DEFINE_CLASS placeholder lost?"); > if (probe != NULL) { > if (HAS_PENDING_EXCEPTION) { > linkage_exception = Handle(THREAD,PENDING_EXCEPTION); > CLEAR_PENDING_EXCEPTION; > } else { > probe->set_instance_klass(k); > } > probe->set_definer(NULL); > placeholders()->find_and_remove(p_index, p_hash, name_h, loader_data, PlaceholderTable::DEFINE_CLASS, THREAD); > SystemDictionary_lock->notify_all(); > } > } > > // Can't throw exception while holding lock due to rank ordering > if (linkage_exception() != NULL) { > THROW_OOP_(linkage_exception(), NULL); // throws exception and returns > } // definer must notify any waiting threads { MutexLocker mu(THREAD, SystemDictionary_lock); PlaceholderEntry* probe = placeholders()->get_entry(name_hash, name_h, loader_data); assert(probe != NULL, "DEFINE_CLASS placeholder lost?"); if (!HAS_PENDING_EXCEPTION) { probe->set_instance_klass(k); } probe->set_definer(NULL); placeholders()->find_and_remove(name_hash, name_h, loader_data, PlaceholderTable::DEFINE_CLASS, THREAD); SystemDictionary_lock->notify_all(); } ------------- PR: https://git.openjdk.java.net/jdk/pull/1808 From coleenp at openjdk.java.net Fri Dec 18 02:18:02 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Dec 2020 02:18:02 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions [v2] In-Reply-To: <9lh3-eps-1ncFB68P7XvyhI1DqVuq71lH_xMKwZD7Zo=.551f12f9-0877-49b6-b59c-8570aabf440c@github.com> References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> <5nbft2YflANjwNdJYywJgGsJaIqo3Le4aggHlDmhIpM=.4c63e765-49a9-476c-8cc0-bb982f16308b@github.com> <8cnDk1TzkQE3RO0o1vKClBh2BmKTTuJXg76PeIOC1YQ=.a0a55175-097b-46c7-a9de-0b2217d8c6ff@github.com> <9lh3-eps-1ncFB68P7XvyhI1DqVuq71lH_xMKwZD7Zo=.551f12f9-0877-49b6-b59c-8570aabf440c@github.com> Message-ID: On Fri, 18 Dec 2020 02:14:12 GMT, Coleen Phillimore wrote: >> // definer must notify any waiting threads >> { >> MutexLocker mu(THREAD, SystemDictionary_lock); >> PlaceholderEntry* probe = placeholders()->get_entry(p_index, p_hash, name_h, loader_data); >> assert(probe != NULL, "DEFINE_CLASS placeholder lost?"); >> if (probe != NULL) { >> if (HAS_PENDING_EXCEPTION) { >> linkage_exception = Handle(THREAD,PENDING_EXCEPTION); >> CLEAR_PENDING_EXCEPTION; >> } else { >> probe->set_instance_klass(k); >> } >> probe->set_definer(NULL); >> placeholders()->find_and_remove(p_index, p_hash, name_h, loader_data, PlaceholderTable::DEFINE_CLASS, THREAD); >> SystemDictionary_lock->notify_all(); >> } >> } >> >> // Can't throw exception while holding lock due to rank ordering >> if (linkage_exception() != NULL) { >> THROW_OOP_(linkage_exception(), NULL); // throws exception and returns >> } > > // definer must notify any waiting threads > { > MutexLocker mu(THREAD, SystemDictionary_lock); > PlaceholderEntry* probe = placeholders()->get_entry(name_hash, name_h, loader_data); > assert(probe != NULL, "DEFINE_CLASS placeholder lost?"); > if (!HAS_PENDING_EXCEPTION) { > probe->set_instance_klass(k); > } > probe->set_definer(NULL); > placeholders()->find_and_remove(name_hash, name_h, loader_data, PlaceholderTable::DEFINE_CLASS, THREAD); > SystemDictionary_lock->notify_all(); > } old code vs. new code. ------------- PR: https://git.openjdk.java.net/jdk/pull/1808 From qingfeng.yy at alibaba-inc.com Fri Dec 18 03:10:32 2020 From: qingfeng.yy at alibaba-inc.com (Yang Yi) Date: Fri, 18 Dec 2020 11:10:32 +0800 Subject: =?UTF-8?B?UmU6IEEgc29sdXRpb24gdG8gZGV0ZWN0IHRoZSBmb290cHJpbnQgb2YgSmF2YSB0aHJlYWQg?= =?UTF-8?B?c3RhY2s=?= Message-ID: Hi all, Thank you all for your kind and constructive comments. I agree with David that adding a new warning zone is not the best way to implement this feature since it changes the current stack layout and it's hard to maintain, the effort may far outweigh the benefits. Nevertheless, I think it is necessary to monitor the stack footprint and let users know about that. NMT can be used for troubleshooting, but it is not suitable for monitoring the stack footprint. As mentioned by Thomas and Zhengyu, using JFR may be a more reasonable and easy way, so I re-implemented it using JFR according to Thomas? guidance. It sends ThreadStackUsage events from JFR periodic task thread: ``` jdk.ThreadStackUsage { startTime = 10:27:30.381 thread = "name1" (javaThreadId = 32) usedStackRatio = 71.60% usedStackSize = 736.0 kB stackSize = 1.0 MB } jdk.ThreadStackUsage { startTime = 10:27:30.381 thread = "name4" (javaThreadId = 35) usedStackRatio = 86.77% usedStackSize = 892.0 kB stackSize = 1.0 MB } ``` Users can adjust the stack size if they find that a thread stack usage is often on the edge of danger. For non-target users (believe this is the peak stack footprint in the system or other circumstances), they can completely ignore these events. Looking forward to your comments. Thanks,Yang Yi --------- Re-implemented patch: https://github.com/kelthuzadx/jdk/commit/cc2a9f112b8f3717594510fcd3981df267e23d3e ------------------------------------------------------------------ From:Zhengyu Gu Send Time:2020?12?16?(???) 20:54 To:David Holmes ; ??(??) ; hotspot-dev developers ; hotspot-jfr-dev Subject:Re: ???Re: ???Re: A solution to detect the footprint of Java thread stack Hi, I agree with David, I don't see a lot of benefits for adding warning zone. I believe the feature can be achieved by utilizing existing NMT functionality as Thomas pointed out, either vs. JFR or jcmd, to report thread stack physical sizes (committed size), since they do not shrink, you get the idea the maximum space a thread used. -Zhengyu On 12/16/20 12:03 AM, David Holmes wrote: > Adding back the mailing lists ... > > Hi, > > On 16/12/2020 1:00 pm, Yang Yi wrote: >> Hi David, >> >> The purpose of this option is to warn rather than avoiding stack >> overflow. It would tell users how much stack space they have been used >> and what is the percentage of the stack footprint in the total. If the >> ratio of stack footprint reaches - XX:StackWarningRatio=90 in many >> iterations of the application, the user can make a judgment, whether to >> increase the stack space to reduce the risk of StackOverflowError or >> keep the current stack size to save memory as much as possible. > > My concern is the cost:benefit ratio for this feature. It's code that > has to be added and maintained and may interact in unintended ways with > other features - like ReservedStackAccess. So to me I see the cost here > as moderate. The benefit seems very small to me. I don't recall ever > seeing a feature request for this, and I just searched for it. If people > were trying to size their applications in the way you suggest, or if > they wanted to do so, then I would have expected to see requests for > such functionality. At the moment this seems a solution in search of a > problem. > > Just my opinion of course. > > Cheers, > David > ----- > >> >> Best, >> Yang YI >> >> ------------------------------------------------------------------ >> ????David Holmes >> ? ??2020?12?15? 15:26:56 >> ????Yang Yi; HotSpot Open Source >> Developers; >> hotspot-jfr-dev >> ? ??Re: ???Re: A solution to detect the footprint of Java >> thread stack >> >> Hi, >> >> On 15/12/2020 5:02 pm, Yang Yi wrote: >> > Hi David, >> > >> > Thank you for your comments. >> > >> > >> >> > How do you actually envisage people using this? This seems more of a >> > >> >> > tuning option, but you can tune just as readily by adjusting -Xss in the >> >> > >> >> > same manner you would set the warning ratio. I.e. you'd like to shrink >> > >> >> > your stack usage but are not sure how small you can make it safely so >> > >> >> > you can either just reduce -Xss and see if it works, or you can set the >> > >> >> > warning ratio to give the same effective -Xss and see if you get a warning. >> >> > >> > Yes, we can indeed achieve similar goals by constantly adjusting >> > -Xss, but adjusting -Xss is generally a way to make the >> application work >> > again after StackOverflowError occurs. The purpose of >> > -XX:StackWarningRatio is to warn early before StackOverflowError >> occurs. >> >> But the problem there is that triggering the warning does not >> indicate >> that a stackoverflow will in fact occur. It will only tell whether >> you >> used a given percentage of your stack, not how much you have actually >> used. So how does this help you avoid stackoverflow? If you used the >> warning to increase -Xss without ever encountering stackoverflow then >> you are just wasting memory and potentially reducing the number of >> threads you can support. >> >> Cheers, >> David >> >> >> > Based on my experience and observation, many developers use the >> default >> > value of ThreadStackSize(the default value of is 1M on >> linux_x86), they >> > will not adjust the value of this option unless a stack overflow >> occurs. >> > With the iterative development of the application, the size of >> the stack >> > may no longer meet the demand. It's helpful to warn about >> insufficient >> > stack space earlier in case of hurriedly troubleshooting and >> adjusting >> > the -Xss when the application throws StackOverflowError in the >> > production environment. >> > >> >> >> > >> > > The flag would need to be diagnostic rather than full product. >> > >> > Accept. >> > >> > Best, >> > Yang Yi >> > >> > ------------------------------------------------------------------ >> > ????David Holmes >> > ? ??2020?12?15? 13:24:54 >> > ????Yang Yi; HotSpot Open Source >> > Developers; >> > hotspot-jfr-dev >> > ? ??Re: A solution to detect the footprint of Java thread >> stack >> > >> > Hi Yang Yi, >> > >> > On 14/12/2020 3:03 pm, ??(??) wrote: >> > > Hi all, >> > >> >> > We occasionally get stack overflow errors if the application has too many deep callings. The usual solution is to increase -Xss, but there is no guiding opinion telling us in advance that the thread stack space is not enough. This patch attempts to address this issue. It introduces a new stack zone(warning_zone) for Hotspot VM, which can be used to detect whether the footprint ratio of the thread stack has reached the watermark set by the user. >> >> > > >> > > The current stack layout is as follows: >> > >> >> > stack_base stack_end >> >> > >> >> > --------------------------------------------------------------------------------------------------------------------------- >> >> > >> >> > | | shadow zone | warning zone(added) | reserved zone | yellow zone | red zone | >> >> > >> >> > --------------------------------------------------------------------------------------------------------------------------- >> >> > >> >> > ^rsp |<-StackWarningRatio % of available stack-> >> >> > > >> > >> >> > Users can set the option -XX:StackWarningRatio=0 to turn off this feature(which is also the default value) and there will be no warning zone, the stack layout is the same as usual. >> >> > >> >> > If the user sets -XX:StackWarningRatio to 50, the VM will protect 50% of the available stack space(let all = available+reserved+yellow+red;) as stack warning zone. When the footprint of available stack space reaches 50%, that is, when the application accesses the stack warning zone, the sigsegv signal will be triggered, and then the signal handler will warn this access in some ways(e.g. send the JFR event, logging) and resume current execution. As a prototype, this feature is only implemented on x86_posix, it can be implemented on more platforms as needed. >> >> > > >> > >> >> > Could anyone give some suggestions? If you think this is a useful feature, I will file an issue and support it on all platforms. Looking forward to your comments. >> >> > >> > >> How do you actually envisage people using this? This seems more of a >> > >> >> tuning option, but you can tune just as readily by adjusting -Xss in the >> > >> > >> >> same manner you would set the warning ratio. I.e. you'd like to shrink >> > >> your stack usage but are not sure how small you can make it safely so >> > >> >> you can either just reduce -Xss and see if it works, or you can set the >> > >> >> warning ratio to give the same effective -Xss and see if you get a warning. >> >> > >> > The flag would need to be diagnostic rather than full product. >> > >> > Cheers, >> > David >> > >> > >> >> > Patch: https://github.com/kelthuzadx/jdk/commit/a145b2ebb4ac568e3bb090cbe3e7f091e1dc69ea >> >> > > Diff: https://github.com/kelthuzadx/jdk/compare/37dc675..a145b2e >> > > >> > > Best, >> > > Yang Yi >> > > >> > >> From sspitsyn at openjdk.java.net Fri Dec 18 03:20:59 2020 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Fri, 18 Dec 2020 03:20:59 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition [v2] In-Reply-To: References: Message-ID: On Thu, 17 Dec 2020 22:54:13 GMT, Leonid Mesnik wrote: >> The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. >> I run all existing tests with enabled logging and sanity verified error messages. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated log_trace to log_info Hi Leonid, It is useful and looks good. Just one nit: This line can be split after the comma: `1047 ("redefined class %s fields change error: some fields were %s.", the_class->external_name(), action); ` Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1811 From david.holmes at oracle.com Fri Dec 18 04:00:27 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Dec 2020 14:00:27 +1000 Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: <2f67d06f-4345-0d10-89a8-906beadcd737@oss.nttdata.com> References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> <7f324fb7-8b15-3ff7-11da-02daba312a98@oracle.com> <96579880-c0cc-85ac-8c87-f3b8e6ccb350@oss.nttdata.com> <6515a8b8-0c4a-d06a-af8e-a28a6c31d185@oss.nttdata.com> <82684a2f-5231-d64b-5175-8aa6c8e428e9@oracle.com> <93e65fc1-3052-706e-cabf-fb1ff4f7f895@oss.nttdata.com> <6e375192-bb36-3888-58b1-5cdc52688b08@oracle.com> <2f67d06f-4345-0d10-89a8-906beadcd737@oss.nttdata.com> Message-ID: <7a434941-6aaf-1c7e-8c32-02d45f5d6ae5@oracle.com> On 16/12/2020 5:36 pm, Yasumasa Suenaga wrote: > Hi David, > >> I'm not sure you mean exactly by DLL unloading mechanism is not hooked. > > I want to say we do not hook `FreeLibrary()` on Windows and `dlclose()` > on Linux. > Can we describe ""this function may be called - " at here? I think it is clear this refers to the VM doing the unloading not somebody issuing direct dlclose/FreeLibrary commands. David > > Cheers, > Yasumasa > > > On 2020/12/16 15:48, David Holmes wrote: >> On 16/12/2020 4:33 pm, Yasumasa Suenaga wrote: >>> Hi David, >>> >>>> "This function will be called by the VM when the library is about to >>>> be unloaded. The library will be unloaded (unless it is statically >>>> linked into the executable) and this function will be called if some >>>> platform specific mechanism causes the unload (an unload mechanism >>>> is not specified in this document) or the library is (in effect) >>>> unloaded by the termination of the VM. VM termination includes >>>> normal termination and VM failure, including start-up failure, but >>>> not, of course, uncontrolled shutdown. An implementation may also >>>> choose to not call this function if the >>>> Agent_OnAttach/Agent_OnAttach_L function reported an error (returned >>>> a non-zero value)." >>> >>> Thank you so much! >>> According to this, we can fix this bug simply. (We can unload agent >>> library without `Agent_OnUnload()` call) >> >> Yes I think it is reasonable to allow this. But of course there must >> be a general consensus. >> >>> However I think following sentence should be removed because DLL >>> unloading mechanism is not hooked, and also `Agent_OnUnload()` >>> wouldn't be called by dll unloading - it depends on VM termination / >>> failure / non-zero value from entry points. >>> >>> "this function will be called if some platform specific mechanism >>> causes the unload (an unload mechanism is not specified in this >>> document)" >> >> I'm not sure you mean exactly by DLL unloading mechanism is not >> hooked. But that sentence has to remain because it makes it clear that >> the decision as to when unloading occurs is up to an implementation >> and is not defined by the specification. >> >> Cheers, >> David >> ----- >> >>> >>> If you are OK, I will update CSR. >>> >>> >>> Cheers, >>> >>> Yasumasa >>> >>> >>> On 2020/12/16 11:09, David Holmes wrote: >>>> Hi Yasumasa, >>>> >>>> Sorry for the delay getting back to this. >>>> >>>> On 1/12/2020 4:41 pm, Yasumasa Suenaga wrote: >>>>> Hi David, >>>>> >>>>> On 2020/12/01 14:59, David Holmes wrote: >>>>>> Looking at the original webrev from September: >>>>>> >>>>>> https://cr.openjdk.java.net/~ysuenaga/JDK-8252657/webrev.00/src/hotspot/share/prims/jvmtiExport.cpp.cdiff.html >>>>>> >>>>>> >>>>>> The suggestion to unload the library if Agent_OnAttach fails seems >>>>>> quite reasonable - it is what happens if no Agent_OnAttach >>>>>> function can be found in the agent. >>>>>> >>>>>> But the specification is lacking because it simply states any such >>>>>> error is "ignored" - which is an oversimplification and I think >>>>>> was really intended to contrast with the abort behaviour if >>>>>> Agent_OnLoad fails. In addition the specification indicates that >>>>>> Agent_OnUnload is called any time the agent library is unloaded, >>>>>> except for "uncontrolled shutdown". This unfortunately suggests >>>>>> that before unloading the library after OnAttach fails, we also >>>>>> call OnUnload. That seems wrong and in fact the VM does not do >>>>>> that - and noone seems to have complained. >>>>>> >>>>>> Also note the specification states an agent "must export a >>>>>> start-up function ..." but doesn't say what happens if it doesn't >>>>>> do so. >>>>>> >>>>>> My gut feeling for what the specification should say here is that >>>>>> if the start-up function does not exist, or the call to >>>>>> Agent_OnAttach reports an error, then the agent library is >>>>>> immediately unloaded with no attempt to call the agent shutdown >>>>>> function (Agent_OnUnload). >>>>> >>>>> That's what I wanted to suggest! >>>>> I understand we need to consider following case in this issue, is >>>>> it right? >>>>> >>>>> Agent_OnLoad / Agent_OnLoad_L does not exist: >>>>> ???? - Agent_OnUnload is not called >>>>> ???? - DLL is not unloaded (JVM will abort) >>>>> >>>>> Agent_OnLoad / Agent_OnLoad_L failed: >>>>> ???? - Agent_OnUnload is not called >>>>> ???? - DLL is not unloaded (JVM will abort) >>>> >>>> These cases are already well covered. >>>> >>>>> Agent_OnAttach does not exist: >>>>> ???? - Agent_OnUnload is not called >>>>> ???? - DLL is unloaded >>>>> >>>>> Agent_OnAttach_L does not exist: >>>>> ???? - Agent_OnUnload is not called >>>>> ???? - DLL is not unloaded (static link) >>>> >>>> These cases are kind of implicitly covered, but could be clarified. >>>> >>>>> Agent_OnAttach failed: >>>>> ???? - Agent_OnUnload is not called >>>>> ???? - DLL is unloaded >>>>> >>>>> Agent_OnAttach_L faled: >>>>> ???? - Agent_OnUnload is not called >>>>> ???? - DLL is not unloaded (static link) >>>> >>>> These are the problematic cases. >>>> >>>>> >>>>>> But with my "compatibility glasses" on this may be too strong to >>>>>> retrofit to the specification as other VMs may behave differently. >>>>>> So as I stated in the CSR request we probably want to allow the >>>>>> current hotspot behaviour but not mandate it (unless we check with >>>>>> all the other VM implementations that such a specification is okay >>>>>> with them). >>>>> >>>>> Ok, for example, can we change the spec as following? >>>>> (Of course, this is not all) >>>>> >>>>> ``` >>>>> diff --git a/src/hotspot/share/prims/jvmti.xml >>>>> b/src/hotspot/share/prims/jvmti.xml >>>>> index 44553b8065f..57c87b1a71b 100644 >>>>> --- a/src/hotspot/share/prims/jvmti.xml >>>>> +++ b/src/hotspot/share/prims/jvmti.xml >>>>> @@ -688,7 +688,8 @@ Agent_OnUnload_L(JavaVM *vm) >>>>> ????? mechanism causes the unload (an unload mechanism is not >>>>> specified in this document) >>>>> ????? or the library is (in effect) unloaded by the termination of >>>>> the VM whether through >>>>> ????? normal termination or VM failure, including start-up failure. >>>>> -??? Uncontrolled shutdown is, of course, an exception to this rule. >>>>> +??? Uncontrolled shutdown is, of course, an exception to this >>>>> rule, and also it might not be called >>>>> +??? when start-up function does not exist or fails (returns >>>>> non-zero value). >>>> >>>> I think this is what was originally proposed and as I said then I >>>> don't like burying this detail inside the reference to uncontrolled >>>> shutdown. We should make this much more explicit which requires some >>>> reworking of the existing far-too-long sentence. >>>> >>>> "This function will be called by the VM when the library is about to >>>> be unloaded. The library will be unloaded (unless it is statically >>>> linked into the executable) and this function will be called if some >>>> platform specific mechanism causes the unload (an unload mechanism >>>> is not specified in this document) or the library is (in effect) >>>> unloaded by the termination of the VM. VM termination includes >>>> normal termination and VM failure, including start-up failure, but >>>> not, of course, uncontrolled shutdown. An implementation may also >>>> choose to not call this function if the >>>> Agent_OnAttach/Agent_OnAttach_L function reported an error (returned >>>> a non-zero value)." >>>> >>>> Cheers, >>>> David >>>> ----- >>>> >>>>> ????? Note the distinction between this function and the >>>>> ????? VM Death event: for the >>>>> VM Death event >>>>> ????? to be sent, the VM must have run at least to the point of >>>>> initialization and a valid >>>>> ``` >>>>> >>>>>> I agree that the more general issue of re-loading an agent is a >>>>>> separate issue. >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 1/12/2020 3:21 pm, David Holmes wrote: >>>>>>> On 1/12/2020 3:19 pm, David Holmes wrote: >>>>>>>> On 1/12/2020 2:46 pm, Yasumasa Suenaga wrote: >>>>>>>>> Hi Chris, David, >>>>>>>>> >>>>>>>>> Currently Agent_OnUnload() is not called when Agent_OnLoad() is >>>>>>>>> failed - JVM will abort. >>>>>>>>> Should we re-think this behavior? >>>>>>>> >>>>>>>> We should we rethink that? It is probably one of the clearest >>>>>>>> parts of the spec. If Agent_Onload fails that is considered a >>>>>>>> fatal error - end of story. >>>>>>> >>>>>>> I meant, of course, "Why should we rethink that?". >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> The issue is with Agent_onAttach and how its failure should, or >>>>>>>> should not, impact Agent_OnUnload. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> https://github.com/YaSuenag/jvmti-examples/tree/master/helloworld >>>>>>>>> >>>>>>>>> ``` >>>>>>>>> $ java -agentpath:/path/to/libhelloworld.so=error --version >>>>>>>>> Hello World from Agent_OnLoad() >>>>>>>>> ?? options = error >>>>>>>>> Error occurred during initialization of VM >>>>>>>>> agent library failed to init: /path/to/libhelloworld.so >>>>>>>>> ``` >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2020/12/01 11:44, David Holmes wrote: >>>>>>>>>> On 1/12/2020 11:45 am, Chris Plummer wrote: >>>>>>>>>>> On Fri, 2 Oct 2020 07:27:43 GMT, Yasumasa Suenaga >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>>> * Q3: What has to be done for statically linked agent? >>>>>>>>>>>> >>>>>>>>>>>> JVMTI spec says "unless it is statically linked into the >>>>>>>>>>>> executable", so I think we can ignore about >>>>>>>>>>>> Agent_OnUnload_L() in this PR. >>>>>>>>>>> >>>>>>>>>>> I don't think that makes sense. If you call it for >>>>>>>>>>> dynamically linked then you need to call it for statically >>>>>>>>>>> linked also. >>>>>>>>>> >>>>>>>>>> Agreed. Even though you can't physically unload the statically >>>>>>>>>> linked library, if it is logically unloaded by some mechanism, >>>>>>>>>> then Agent_OnUnload_L is supposed to be called. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> ------------- >>>>>>>>>>> >>>>>>>>>>> PR: https://git.openjdk.java.net/jdk/pull/19 >>>>>>>>>>> From dholmes at openjdk.java.net Fri Dec 18 04:18:58 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 18 Dec 2020 04:18:58 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions [v2] In-Reply-To: References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> <5nbft2YflANjwNdJYywJgGsJaIqo3Le4aggHlDmhIpM=.4c63e765-49a9-476c-8cc0-bb982f16308b@github.com> <8cnDk1TzkQE3RO0o1vKClBh2BmKTTuJXg76PeIOC1YQ=.a0a55175-097b-46c7-a9de-0b2217d8c6ff@github.com> <9lh3-eps-1ncFB68P7XvyhI1DqVuq71lH_xMKwZD7Zo=.551f12f9-0877-49b6-b59c-8570aabf440c@github.com> Message-ID: On Fri, 18 Dec 2020 02:14:44 GMT, Coleen Phillimore wrote: >> // definer must notify any waiting threads >> { >> MutexLocker mu(THREAD, SystemDictionary_lock); >> PlaceholderEntry* probe = placeholders()->get_entry(name_hash, name_h, loader_data); >> assert(probe != NULL, "DEFINE_CLASS placeholder lost?"); >> if (!HAS_PENDING_EXCEPTION) { >> probe->set_instance_klass(k); >> } >> probe->set_definer(NULL); >> placeholders()->find_and_remove(name_hash, name_h, loader_data, PlaceholderTable::DEFINE_CLASS, THREAD); >> SystemDictionary_lock->notify_all(); >> } > > old code vs. new code. Right so my point is that in the new code: probe->set_definer(NULL); placeholders()->find_and_remove(p_index, p_hash, name_h, loader_data, PlaceholderTable::DEFINE_CLASS, THREAD); SystemDictionary_lock->notify_all(); you can now call these while an exception is pending. Whether that is harmless or not depends on the details of that code. I poked around a little and it seems okay but it isn't at all obvious that it is okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/1808 From dholmes at openjdk.java.net Fri Dec 18 04:25:56 2020 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 18 Dec 2020 04:25:56 GMT Subject: RFR: JDK-8258469: Cleanup remaining safefetch test coding In-Reply-To: <6HkHFmD3f1TOVLB1zyP78S2gKIIySLMTlZN7N-g-Q4I=.9b9759be-06e5-4b6a-aa1f-53d0bbc8a387@github.com> References: <6HkHFmD3f1TOVLB1zyP78S2gKIIySLMTlZN7N-g-Q4I=.9b9759be-06e5-4b6a-aa1f-53d0bbc8a387@github.com> Message-ID: On Wed, 16 Dec 2020 09:20:14 GMT, Thomas Stuefe wrote: > JDK-8257828 fixed SafeFetch for non-java-thread situations on all platforms. It also introduced gtests. > JDK-8185734 fixed the problem that gtests were running without SEH catcher on Windows, preventing us from testing Windows x86 at least. > > Since we have now gtests to test SafeFetch, and since all these issues are fixed, we can remove the related test coding in stubRoutines.cpp. > > Testing: manual gtests and GH actions (the Linux x86 error can be ignored, see https://bugs.openjdk.java.net/browse/JDK-8258481). LGTM! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1799 From lmesnik at openjdk.java.net Fri Dec 18 04:52:13 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Fri, 18 Dec 2020 04:52:13 GMT Subject: RFR: 8258061: Improve diagnostic information about errors during class redefinition [v3] In-Reply-To: References: Message-ID: > The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. > I run all existing tests with enabled logging and sanity verified error messages. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: identation fixed after comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1811/files - new: https://git.openjdk.java.net/jdk/pull/1811/files/fe6dccf3..78e67d9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1811&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1811&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1811.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1811/head:pull/1811 PR: https://git.openjdk.java.net/jdk/pull/1811 From ysuenaga at openjdk.java.net Fri Dec 18 05:11:56 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 18 Dec 2020 05:11:56 GMT Subject: RFR: 8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed In-Reply-To: References: <1H1wUQdxCLU2qddqEIYSx2iOhIKL3b5etUmjsS6NBlU=.0bf1fe0c-8dcf-4ca0-bd57-b8794d5f2810@github.com> <80LJDTCsT_y-KlThryd5Bxu5RRyrjmKfs5p9vJUn61E=.68b594a0-fe58-4f4d-a49c-eec2e90f9373@github.com> Message-ID: On Tue, 1 Dec 2020 01:43:15 GMT, Chris Plummer wrote: >>> * Q1: Is it necessary to call the Agent_OnUnload()? >> >> [JVMTI spec of Agent_OnUnload()](https://docs.oracle.com/en/java/javase/15/docs/specs/jvmti.html#onunload) says this function will be called when the agent library will be unloaded by platform specific mechanism. OTOH it also says `Agent_OnUnload()` will be called both at VM termination and **by other reasons**. >> The spec don't say for the case if `Agent_OnAttach()` would be failed. IMHO `Agent_OnUnload()` should be called because this PR would unload library if `Agent_OnAttach()` failed. >> >>> * Q2: Would it be a JVMTI spec violation to call the Agent_OnAttach() multiple times? (It seems to be the case to me.) >> >> `Agent_OnAttach()` should be called only once per attach request, but VM should accept multiple attach request for same agent library. >> >> For example, we can add multiple `-agentlib` and `-agentpath` request as below. JVMTI agent might change behavior due to arguments or configuration file. >> >> -agentlib:test=profile=A -agentlib:test=profile=B -agentpath:/path/to/libtest=profile=C >> >> Agent developers should have responsibility for the behavior when more than one agent is loaded at a time. >> >>> * Q3: What has to be done for statically linked agent? >> >> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. >> >>> * Q4: Should the agent be correctly loadable in the first place? What were the reasons its loading to fail? >> >> Agent (`Agent_OnAttach()`) might fail due to error in agent logic. For example, some agents load configuration file at initialization. If the user gives wrong value, it will fail. >> >>> Yes, at least, a CSR is needed for this. >> >> I will file CSR for this PR after this discussion. > >> > * Q3: What has to be done for statically linked agent? >> >> JVMTI spec says "unless it is statically linked into the executable", so I think we can ignore about Agent_OnUnload_L() in this PR. > > I don't think that makes sense. If you call it for dynamically linked then you need to call it for statically linked also. @dholmes-ora Thank you for explanation! I updated [CSR](https://bugs.openjdk.java.net/browse/JDK-8256918). Could you review it? ------------- PR: https://git.openjdk.java.net/jdk/pull/19 From njian at openjdk.java.net Fri Dec 18 07:18:00 2020 From: njian at openjdk.java.net (Ningsheng Jian) Date: Fri, 18 Dec 2020 07:18:00 GMT Subject: [jdk16] RFR: 8258384: AArch64: SVE verify_ptrue fails on some tests Message-ID: After applying [1], some Vector API tests fail with SIGILL on SVE system. The SIGILL was triggered by verify_ptrue before c2 compiled function returns, which means that the preserved p7 register (as ptrue) has been clobbered before returning to c2 compiled code. (p7 is not preserved cross function calls, and system calls [2]). Currently we try to reinitialize ptrue at each entrypoint of returning from non-c2 compiled code, which indicating possible C or system calls. However, there's still one entrypoint missing, exception handling, as we may jump to c2 compiled code for exception handler. See OptoRuntime::generate_exception_blob(). Adding reinitialize_ptrue before jumping back to c2 compiled code in generate_exception_blob() could solve those Vector API test failures. Actually I had that in my initial test patch [3], I don't know why I missed that in final patch... I reran tests with the same approach of [3] and found that there's still something missing, the nmethod_entry_barrier() in c2 function prolog. The barrier may call to runtime code (see generate_method_entry_barrier()). To reduce the risk of missing such reinitialize_ptrue in newly added code in future, I think it would be better to do the reinitialize in pop_call_clobbered_registers(). P.S. the SIGILL message is also not clear, it should print detailed message as indicated by MacroAssembler::stop() call. This is caused by JDK-8255711 removing the message printing code. This patch also adds it back, so that it could print detailed message for abort. Tested with tier1-3 on SVE hardware. Also verified with the same approach of patch [3] with jtreg tests hotspot_all_no_apps and jdk:tier1-3 passed without incorrect ptrue value assertion failure. [1] https://github.com/openjdk/jdk/pull/1621 [2] https://github.com/torvalds/linux/blob/master/Documentation/arm64/sve.rst [3] http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch ------------- Commit messages: - 8258384: AArch64: SVE verify_ptrue fails on some tests Changes: https://git.openjdk.java.net/jdk16/pull/50/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=50&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258384 Stats: 54 lines in 7 files changed: 21 ins; 16 del; 17 mod Patch: https://git.openjdk.java.net/jdk16/pull/50.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/50/head:pull/50 PR: https://git.openjdk.java.net/jdk16/pull/50 From meir at redislabs.com Fri Dec 18 07:20:30 2020 From: meir at redislabs.com (Meir Shpilraien) Date: Fri, 18 Dec 2020 09:20:30 +0200 Subject: Embedded JDK how to replace the default allocator In-Reply-To: References: Message-ID: Hey Thomas, Thanks for your answer. Just to make sure I understand, are you suggesting that we change this file and recompile it? or there is any other way to do it? Thanks, Meir On Tue, Dec 15, 2020 at 8:37 PM Thomas St?fe wrote: > Yes, that is not so easy, as I wrote. > > If you only care for C heap, an approximation would be to hook into > os::malloc/os::free etc and do your counting there. See > hotspot/share/runtime/os.hpp/cpp. This only gives you C-heap usage from the > hotspot, but leaves out memory managed via mmap, and thread stacks, and > memory allocated from JDK libraries. > > Another way would be to somehow use NMT (Native Memory Tracking). Look it > up, or play around with -XX:NativeMemoryTracking. NMT tracks native memory > usage from the hotspot quite completely, including mmap (which includes the > java heap too) and thread stacks, depending on JDK version. You'd be still > in the dark about usage from JDK libraries, but it's a start. You could > print the NMT report into memory and parse that for your information. > > Cheers, Thomas > > On Tue, Dec 15, 2020 at 7:25 PM Guy Korland wrote: > >> > you are still not very forthcoming with information, so we don't know >> what your goal is. Total isolation of all allocations? Or just monitoring? >> Is partial isolation okay? >> >> Sorry for not being clear, we are trying to build an extension to Redis >> that will run an embedded JVM. In order to allow Redis monitor all the >> memory allocated by the JVM we need to make sure all the allocation are >> going through Redis allocation commands. >> We already managed to do it in the past with other VMs like CPython, WSAM >> & Lua, but didn't find an easy way to set it in OpenJDK. >> >> >> Regards, >> Guy Korland >> >> >> On Tue, Dec 15, 2020 at 8:54 AM Thomas St?fe >> wrote: >> >>> Hi, >>> >>> you are still not very forthcoming with information, so we don't know >>> what your goal is. Total isolation of all allocations? Or just monitoring? >>> Is partial isolation okay? >>> >>> Since I do not know what you need, here are some hints: >>> >>> - majority of allocations of a VM are not done via C-Heap but via >>> virtual memory APIs like mmap() or SystemV shm(). >>> >>> - C Heap allocations from the hotspot itself could be redirected, since >>> they go through the os::malloc... layer. I believe this also takes care of >>> C++ allocations >>> >>> - However, that is only a small part of all allocations, since any >>> library loaded via JNI (including both the JDK libraries themselves as well >>> as any third party JNI libraries we don't have control over) rolls their >>> own memory management by calling malloc or C++ new or mmap or... directly. >>> >>> - Also note that there may be places in the hotspot where C heap >>> allocated pointers are kept in a hashmap, and radically changing how the >>> pointers look like (different allocator) may mess with the efficiency of >>> those hash functions. >>> >>> So if you need total isolation, the only realistic way is as David >>> described: use LD_PRELOAD and provide redirections for all system level >>> APIs which allocate memory. >>> >>> The problem with redirecting C-Heap allocations at that level however is >>> that if you override free() you need to have perfect coverage of all >>> allocating APIs. These are not limited to malloc/calloc/free etc but there >>> are a number of other APIs which return their results in C-Heap allocated >>> buffers. And I have no idea honestly how to redirect C++ allocations via >>> LD_PRELOAD. >>> >>> Cheers, Thomas >>> >>> >>> On Tue, Dec 15, 2020 at 12:08 AM Guy Korland wrote: >>> >>>> >>>> I'm talking about replacing the malloc implementation, we're running on >>>> Linux. >>>> But, the tricky part is that my C application malloc should not be >>>> changed, only the libjvm.so when loaded embedded in my application. >>>> >>>> Regards, >>>> Guy Korland >>>> >>>> >>>> On Sun, Dec 13, 2020 at 12:15 PM Thomas St?fe >>>> wrote: >>>> >>>>> Hi Guy, >>>>> >>>>> What do you mean by default allocator? C-Heap? Mmap/shmat? And what OS >>>>> are you targeting? >>>>> >>>>> Cheers, Thomas >>>>> >>>>> On Fri, Dec 11, 2020 at 9:49 PM Guy Korland >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I'm sorry if that is not the right mailing list for such questions, >>>>>> please >>>>>> point me to the right one if it's not. >>>>>> >>>>>> We're embedding the OpenJDK in a C application, we already managed to >>>>>> make >>>>>> it work and run Java bytecode, but we are still missing one last >>>>>> piece, we >>>>>> need a way to replace the default memory allocator to use our >>>>>> allocator. >>>>>> >>>>>> Is there a way to do it? >>>>>> >>>>>> Thanks, >>>>>> Guy Korland >>>>>> >>>>> Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website. From stuefe at openjdk.java.net Fri Dec 18 08:15:55 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 18 Dec 2020 08:15:55 GMT Subject: RFR: JDK-8258469: Cleanup remaining safefetch test coding In-Reply-To: References: <6HkHFmD3f1TOVLB1zyP78S2gKIIySLMTlZN7N-g-Q4I=.9b9759be-06e5-4b6a-aa1f-53d0bbc8a387@github.com> Message-ID: <0nn5lCpYZ20l2R7QobclUm0hrjiNpa63ZJm4CNFL9_0=.6ca59fff-d8c1-4e3f-8106-0be0d9186c2a@github.com> On Fri, 18 Dec 2020 04:23:00 GMT, David Holmes wrote: >> JDK-8257828 fixed SafeFetch for non-java-thread situations on all platforms. It also introduced gtests. >> JDK-8185734 fixed the problem that gtests were running without SEH catcher on Windows, preventing us from testing Windows x86 at least. >> >> Since we have now gtests to test SafeFetch, and since all these issues are fixed, we can remove the related test coding in stubRoutines.cpp. >> >> Testing: manual gtests and GH actions (the Linux x86 error can be ignored, see https://bugs.openjdk.java.net/browse/JDK-8258481). > > LGTM! > > Thanks, > David Thanks Coleen and David! ------------- PR: https://git.openjdk.java.net/jdk/pull/1799 From stuefe at openjdk.java.net Fri Dec 18 08:15:57 2020 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 18 Dec 2020 08:15:57 GMT Subject: Integrated: JDK-8258469: Cleanup remaining safefetch test coding In-Reply-To: <6HkHFmD3f1TOVLB1zyP78S2gKIIySLMTlZN7N-g-Q4I=.9b9759be-06e5-4b6a-aa1f-53d0bbc8a387@github.com> References: <6HkHFmD3f1TOVLB1zyP78S2gKIIySLMTlZN7N-g-Q4I=.9b9759be-06e5-4b6a-aa1f-53d0bbc8a387@github.com> Message-ID: On Wed, 16 Dec 2020 09:20:14 GMT, Thomas Stuefe wrote: > JDK-8257828 fixed SafeFetch for non-java-thread situations on all platforms. It also introduced gtests. > JDK-8185734 fixed the problem that gtests were running without SEH catcher on Windows, preventing us from testing Windows x86 at least. > > Since we have now gtests to test SafeFetch, and since all these issues are fixed, we can remove the related test coding in stubRoutines.cpp. > > Testing: manual gtests and GH actions (the Linux x86 error can be ignored, see https://bugs.openjdk.java.net/browse/JDK-8258481). This pull request has now been integrated. Changeset: 853c0471 Author: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/853c0471 Stats: 70 lines in 4 files changed: 8 ins; 55 del; 7 mod 8258469: Cleanup remaining safefetch test coding Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/1799 From coleenp at openjdk.java.net Fri Dec 18 13:13:27 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Dec 2020 13:13:27 GMT Subject: RFR: 8258408: SystemDictionary passes TRAPS to functions that don't throw exceptions [v2] In-Reply-To: References: <0F0KI6Dw_ALuRR65v1mnsEEZVDpkRB2Ki0YbV5IS-2A=.1629206d-b37f-4309-b5ba-762bdb12bdb8@github.com> <5nbft2YflANjwNdJYywJgGsJaIqo3Le4aggHlDmhIpM=.4c63e765-49a9-476c-8cc0-bb982f16308b@github.com> <8cnDk1TzkQE3RO0o1vKClBh2BmKTTuJXg76PeIOC1YQ=.a0a55175-097b-46c7-a9de-0b2217d8c6ff@github.com> <9lh3-eps-1ncFB68P7XvyhI1DqVuq71lH_xMKwZD7Zo=.551f12f9-0877-49b6-b59c-8570aabf440c@github.com> Message-ID: On Fri, 18 Dec 2020 04:16:31 GMT, David Holmes wrote: >> old code vs. new code. > > Right so my point is that in the new code: > > probe->set_definer(NULL); > placeholders()->find_and_remove(p_index, p_hash, name_h, loader_data, PlaceholderTable::DEFINE_CLASS, THREAD); > SystemDictionary_lock->notify_all(); > > you can now call these while an exception is pending. Whether that is harmless or not depends on the details of that code. I poked around a little and it seems okay but it isn't at all obvious that it is okay. I spent some time reading through this code as well, because I couldn't see why we'd copy the exception. This is why I changed it, to prevent spending future time reading through this code. The other reason that I don't like declaring TRAPS for functions that don't throw exceptions is because it's unclear quickly at the call site that the placeholders() call can throw an exception, which would overwrite the one that's already in the _pending_exception field. It doesn't. I could have changed the find_and_remove() function to pass THREAD as the first parameter which would make it less suspicious looking, but I had to stop somewhere with this iteration to be nice to code reviewers. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/1808 From rrich at openjdk.java.net Fri Dec 18 13:18:25 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 18 Dec 2020 13:18:25 GMT Subject: [jdk16] RFR: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack In-Reply-To: References: Message-ID: <2Jm8FBMWjB9jhE1X3YfrWwcjT85Q2v91spRiJ1_Y-YE=.5c8e5be8-59dd-42dc-91bb-9bf1d80f43ba@github.com> On Wed, 16 Dec 2020 09:53:46 GMT, Martin Doerr wrote: >> // Continuation of https://github.com/openjdk/jdk/pull/1724 >> // I'm taking over from @TheRealMDoerr who's busy with 11u downports >> >> Please help review this small PPC64 fix. >> It replaces the call os::current_stack_pointer() in os::current_frame() >> with __builtin_frame_address(0) which is available also with xlC used by the AIX >> build. With this os::current_frame() is agnostic to C++ compiler inlining. >> >> Furthermore the fix changes os::current_frame() to return the correct >> frame. Without the fix the returned frame is one frame to high which triggered >> the assertion in trace_method_handle_stub(). >> This change uncovers an issue with NativeCallStack::NativeCallStack(int toSkip, bool fillStack) >> on PPC64. There the call os::get_native_stack() is not compiled >> to a tail call therefore the frame of the NativeCallStack constructor needs to >> be skipped on PPC64 too as on other platforms. >> >> Without this >> >> make run-test TEST=test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java >> >> fails. >> >> Furthermore the inline assembler from os::current_stack_pointer() is >> removed. Instead __builtin_frame_address(0) is used again. >> >> The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, >> SAP specific tests with fastdebug and release builds on all platforms > > Thank you for fixing it in jdk16 as discussed in the jdk PR! > Note that PR and JBS title must match, otherwise integration is blocked. Thanks again for the reviews @TheRealMDoerr, @RealLucy! ------------- PR: https://git.openjdk.java.net/jdk16/pull/24 From rrich at openjdk.java.net Fri Dec 18 13:18:26 2020 From: rrich at openjdk.java.net (Richard Reingruber) Date: Fri, 18 Dec 2020 13:18:26 GMT Subject: [jdk16] Integrated: 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack In-Reply-To: References: Message-ID: On Tue, 15 Dec 2020 15:34:33 GMT, Richard Reingruber wrote: > // Continuation of https://github.com/openjdk/jdk/pull/1724 > // I'm taking over from @TheRealMDoerr who's busy with 11u downports > > Please help review this small PPC64 fix. > It replaces the call os::current_stack_pointer() in os::current_frame() > with __builtin_frame_address(0) which is available also with xlC used by the AIX > build. With this os::current_frame() is agnostic to C++ compiler inlining. > > Furthermore the fix changes os::current_frame() to return the correct > frame. Without the fix the returned frame is one frame to high which triggered > the assertion in trace_method_handle_stub(). > This change uncovers an issue with NativeCallStack::NativeCallStack(int toSkip, bool fillStack) > on PPC64. There the call os::get_native_stack() is not compiled > to a tail call therefore the frame of the NativeCallStack constructor needs to > be skipped on PPC64 too as on other platforms. > > Without this > > make run-test TEST=test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java > > fails. > > Furthermore the inline assembler from os::current_stack_pointer() is > removed. Instead __builtin_frame_address(0) is used again. > > The fix passed our CI testing: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, > SAP specific tests with fastdebug and release builds on all platforms This pull request has now been integrated. Changeset: 1ce2e94f Author: Richard Reingruber URL: https://git.openjdk.java.net/jdk16/commit/1ce2e94f Stats: 31 lines in 3 files changed: 0 ins; 22 del; 9 mod 8256843: [PPC64] runtime/logging/RedefineClasses.java fails with assert: registers not saved on stack Reviewed-by: mdoerr, lucy ------------- PR: https://git.openjdk.java.net/jdk16/pull/24 From lmesnik at openjdk.java.net Fri Dec 18 16:42:58 2020 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Fri, 18 Dec 2020 16:42:58 GMT Subject: Integrated: 8258061: Improve diagnostic information about errors during class redefinition In-Reply-To: References: Message-ID: <6KqWtb-IpCQIGvKC-YtlOxZMe7eMfZiCcp8m3TJe7rk=.4387396e-ab8a-4d79-8a7f-b6190be3fb14@github.com> On Thu, 17 Dec 2020 00:44:18 GMT, Leonid Mesnik wrote: > The error code during class redefinition might be not enough to easily diagnose the problem. Some more logging might be useful to understand it. I encountered this problem when redefined methods with lambda usage. > I run all existing tests with enabled logging and sanity verified error messages. This pull request has now been integrated. Changeset: 71ae05d5 Author: Leonid Mesnik URL: https://git.openjdk.java.net/jdk/commit/71ae05d5 Stats: 72 lines in 1 file changed: 54 ins; 10 del; 8 mod 8258061: Improve diagnostic information about errors during class redefinition Reviewed-by: coleenp, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/1811 From richard.reingruber at sap.com Fri Dec 18 16:52:26 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 18 Dec 2020 16:52:26 +0000 Subject: AArch64: is a compressed class space at 2G a problem? Message-ID: Dear AArch64 experts, it appears to me that locating the compressed class space (ccs) at 2G is currently not possible on AArch64 [1][2]. This looks like a bug to me. Would you agree? I think the issue is that at [1] and [2] the start of ccs is passed to CompressedKlassPointers::is_valid_base()[3] instead of the encoding base which would be 0 if ccs starts at 2G. The question came up during review of https://github.com/openjdk/jdk/pull/1815 The test for the enhancement requires a special case for AArch64. Thanks, Richard. [1] The first attempt to map ccs in Metaspace::global_initialize() with UseCompressedOops disabled will be at HeapBaseMinAddress which is 2G. On AArch64 this is not done because CompressedKlassPointers::is_valid_base(2G) returns false[3]. https://github.com/openjdk/jdk/blob/853c04712d24788b6d30d54443ac9277a898311b/src/hotspot/share/memory/metaspace.cpp#L717 [2] In CompressedKlassPointers::initialize() there's an assertion that whould fail if ccs was located at 2G https://github.com/openjdk/jdk/blob/853c04712d24788b6d30d54443ac9277a898311b/src/hotspot/share/oops/compressedOops.cpp#L199 [3] CompressedKlassPointers::is_valid_base() https://github.com/openjdk/jdk/blob/853c04712d24788b6d30d54443ac9277a898311b/src/hotspot/share/oops/compressedOops.cpp#L266 From coleenp at openjdk.java.net Fri Dec 18 19:43:05 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 18 Dec 2020 19:43:05 GMT Subject: RFR: 8258032: Reconsider LEAF entry restrictions Message-ID: This change allows JRT_LEAF functions to create Handles because it doesn't need them but some code inside the VM needs Handles. There's a NoSafepointVerifier in JRT_LEAF functions. The JNI_LEAF and JVM_LEAF functions have NoHandleMark (so you can't create handles) but the transition ThreadInVMfromNative will reenable the HandleMarks, so that all this code doesn't have to do it itself. Tested with tier1-6. ------------- Commit messages: - 8258032: Reconsider LEAF entry restrictions Changes: https://git.openjdk.java.net/jdk/pull/1846/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1846&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258032 Stats: 102 lines in 17 files changed: 7 ins; 69 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/1846.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1846/head:pull/1846 PR: https://git.openjdk.java.net/jdk/pull/1846 From mikael at openjdk.java.net Sat Dec 19 00:32:56 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Sat, 19 Dec 2020 00:32:56 GMT Subject: RFR: 8253881: Hotspot/Serviceability Terminology Refresh In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 16:28:10 GMT, Pavel Rappo wrote: >> Thumbs up. Looks about the same as your prelim... > > Although I'm not an expert in this area, I'm concerned whether the words remaining in `test/hotspot/jtreg/compiler/c2/stemmer/words` make up for the ones being deleted. If they don't (i.e. the removal of words results in test cases being discarded), then new words should be added to compensate. I've checked with @vnkozlov and the removal of these few words should not affect the effectiveness of the test, so I'll leave it as-is. ------------- PR: https://git.openjdk.java.net/jdk/pull/1798 From mikael at openjdk.java.net Sat Dec 19 00:36:19 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Sat, 19 Dec 2020 00:36:19 GMT Subject: RFR: 8253881: Hotspot/Serviceability 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 hotspot code and tests. Terms were changed as follows: > > 1. whitelist -> removed or changed to allow-list/allowed > 2. blacklist -> removed > 3. chop-chop -> removed Mikael Vidstedt 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 - 8253881: Hotspot/Serviceability Terminology Refresh ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1798/files - new: https://git.openjdk.java.net/jdk/pull/1798/files/421dcc27..bf36b6d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1798&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1798&range=00-01 Stats: 8417 lines in 315 files changed: 5704 ins; 1567 del; 1146 mod Patch: https://git.openjdk.java.net/jdk/pull/1798.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1798/head:pull/1798 PR: https://git.openjdk.java.net/jdk/pull/1798 From mikael at openjdk.java.net Sat Dec 19 02:51:55 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Sat, 19 Dec 2020 02:51:55 GMT Subject: Integrated: 8253881: Hotspot/Serviceability Terminology Refresh In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 08:24:01 GMT, Mikael Vidstedt 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 hotspot code and tests. Terms were changed as follows: > > 1. whitelist -> removed or changed to allow-list/allowed > 2. blacklist -> removed > 3. chop-chop -> removed This pull request has now been integrated. Changeset: 64644a10 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/64644a10 Stats: 13 lines in 5 files changed: 0 ins; 7 del; 6 mod 8253881: Hotspot/Serviceability Terminology Refresh Reviewed-by: kbarrett, tschatzl, dholmes, lfoltan, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/1798 From aph at redhat.com Sat Dec 19 10:56:07 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 19 Dec 2020 10:56:07 +0000 Subject: AArch64: is a compressed class space at 2G a problem? In-Reply-To: References: Message-ID: <261b106a-bf7c-250e-fec3-d08d225f0681@redhat.com> On 12/18/20 4:52 PM, Reingruber, Richard wrote: > > it appears to me that locating the compressed class space (ccs) at 2G is > currently not possible on AArch64 [1][2]. This looks like a bug to me. Would you > agree? If the compressed class space is located at 2G then its encoding base should be zero. We don't care exactly where the space starts, but we do care very much that its encoding base is 4G-aligned. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ysuenaga at openjdk.java.net Mon Dec 21 01:36:59 2020 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 21 Dec 2020 01:36:59 GMT Subject: RFR: 8256916: Add JFR event for OutOfMemoryError In-Reply-To: References: <73crkD-SepaAqEyV2wuGyO8tnAHjQmiIOHjN9zovm8M=.3ea49ef3-a2f6-487e-b86a-956832861a46@github.com> <7n0kAmo0Qtlt0sD2XWE52BL_6BI0kMffisYLj8R8O38=.3d324a31-4909-4b6d-bc90-a63f7a6a41ef@github.com> Message-ID: On Wed, 2 Dec 2020 07:19:19 GMT, Erik Gahlin wrote: >> @egahlin Is this answer sufficient for you about OOM handling? All comments are welcome. > > I think there is a use case for getting an event when an OOM occurs, but the long term plan is to change so that a jdk.JavaErrorThrow is emitted when the exception is thrown, not when the object is allocated. When that is fixed, it will take care of OOME automatically - at all places. I think it is confusing for users to not get an event at every OOME and users/customers will file bugs. @egahlin OOME from JVM will not be reported because they are instantiated at JVM init stage and are kept in `Universe`, so they cannot be handled in `ThrowableTracer::traceError`. We can trace OOMEs which are happened in Java code at `ThrowableTracer::traceError`. However I'm not sure where the event should be handled in. For sake of simply, I want to add `jdk.OutOfMemoryError` event to `jdk.jfr` module as a Java class, and I want to emit it from `ThrowableTracer::traceError`, however it duplicates with a definition in JVM. OTOH we can implement to emit event from `ThrowableTracer::traceError` via `JVM` class, however need to add API to emit events with arbitrary arguments. ------------- PR: https://git.openjdk.java.net/jdk/pull/1403 From richard.reingruber at sap.com Mon Dec 21 08:55:30 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Mon, 21 Dec 2020 08:55:30 +0000 Subject: AArch64: is a compressed class space at 2G a problem? In-Reply-To: <261b106a-bf7c-250e-fec3-d08d225f0681@redhat.com> References: <261b106a-bf7c-250e-fec3-d08d225f0681@redhat.com> Message-ID: > On 12/18/20 4:52 PM, Reingruber, Richard wrote: > > > > it appears to me that locating the compressed class space (ccs) at 2G is > > currently not possible on AArch64 [1][2]. This looks like a bug to me. Would you > > agree? > If the compressed class space is located at 2G then its encoding > base should be zero. We don't care exactly where the space starts, > but we do care very much that its encoding base is 4G-aligned. Thanks for the feedback! I've created [1] to track this. Richard. [1] https://bugs.openjdk.java.net/browse/JDK-8258756 -----Original Message----- From: hotspot-dev On Behalf Of Andrew Haley Sent: Samstag, 19. Dezember 2020 11:56 To: hotspot-dev at openjdk.java.net Subject: Re: AArch64: is a compressed class space at 2G a problem? On 12/18/20 4:52 PM, Reingruber, Richard wrote: > > it appears to me that locating the compressed class space (ccs) at 2G is > currently not possible on AArch64 [1][2]. This looks like a bug to me. Would you > agree? If the compressed class space is located at 2G then its encoding base should be zero. We don't care exactly where the space starts, but we do care very much that its encoding base is 4G-aligned. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 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 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 aph at redhat.com Mon Dec 21 14:19:20 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 21 Dec 2020 14:19:20 +0000 Subject: AArch64: is a compressed class space at 2G a problem? In-Reply-To: References: <261b106a-bf7c-250e-fec3-d08d225f0681@redhat.com> Message-ID: On 12/21/20 8:55 AM, Reingruber, Richard wrote: >> On 12/18/20 4:52 PM, Reingruber, Richard wrote: >>> >>> it appears to me that locating the compressed class space (ccs) at 2G is >>> currently not possible on AArch64 [1][2]. This looks like a bug to me. Would you >>> agree? > >> If the compressed class space is located at 2G then its encoding >> base should be zero. We don't care exactly where the space starts, >> but we do care very much that its encoding base is 4G-aligned. > > Thanks for the feedback! I've created [1] to track this. This is bizarre. I'm pretty sure it used to work; maybe something else has changed. What we want, in pretty much every case, is an unshifted 4G-aligned encoding. Zero-based would be nice. Mind you, given that CDS seems to be on by default, I guess any weird options won't much be used anyway. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ihse at openjdk.java.net Mon Dec 21 16:05:56 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Dec 2020 16:05:56 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: <91erxiMDb4ftvSomuJYHPi9SX-v8Z2VLD2qEwCbz5tk=.b9ed01b5-f0e0-4ed7-9c1a-b06bc0e64640@github.com> <8Eqswd7tsVaGEXHdKDncXqKpW2tBsSeuY0PV6aTB9_c=.a6cf4957-9d31-4e89-bf44-e7b7852205d5@github.com> <2S00ucaPGiAQLeLOejt1kfXeYEc7ctEPeRCIcq1N0N8=.dbf1ea7a-8de4-48a5-8759-03495e3e3c08@github.com> <9oXnHULCd76_J69CKMVVZl3FfDte1pnt38y06LVV4Sg=.26a4ab2c-5ff7-4e2f-9428-0d8cd931d243@github.com> Message-ID: On Mon, 23 Nov 2020 15:55:43 GMT, Magnus Ihse Bursie wrote: >> I think a proper solution to both this and the Capstone implementation is to provide a proper framework for selecting the hsdis backend as a first step, and refactor the existing bfd implementation as the first such backend. After that, we can add llvm and capstone as alternative hsdis backend implementations. > > FWIW, I started working on a framework which would add support for selectable backends for hsdis. Unfortunately it was not as simple as I initially thought, so I had to put it on hold while directing my time to working on the winenv patch instead. > > I believe the proper way forward is to get the "selectable hsdis backend" framework in place, and then retrofit this patch to add LLVM support in that framework. If this means that this PR should be closed, or kept open until this is done, I don't know. Nag nag bot... I'm away for the holidays now, but I intend to pick up the work on the selectable hsdis backend when I return. So while this exact code is unlikely to be the one merged, it's good to have it open to allow me to double check the solutions picked here. ------------- PR: https://git.openjdk.java.net/jdk/pull/392 From richard.reingruber at sap.com Mon Dec 21 19:04:33 2020 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Mon, 21 Dec 2020 19:04:33 +0000 Subject: AArch64: is a compressed class space at 2G a problem? In-Reply-To: References: <261b106a-bf7c-250e-fec3-d08d225f0681@redhat.com> Message-ID: > >> If the compressed class space is located at 2G then its encoding > >> base should be zero. We don't care exactly where the space starts, > >> but we do care very much that its encoding base is 4G-aligned. > > > > Thanks for the feedback! I've created [1] to track this. > This is bizarre. I'm pretty sure it used to work; maybe something > else has changed. What we want, in pretty much every case, is an > unshifted 4G-aligned encoding. Zero-based would be nice. Looks like you'll get either zerobased with shift or 4G aligned encoding base without shift. I think it's only since compressed class pointers have become independent of compressed oops [1] that ccs can be allocated at HeapBaseMinAddress (2G) resulting in an unscaled encoding. Before ccs was put behind the compressed oops heap which was fitted at the end of the 4G range if possible or higher if it didn't fit there. So until [1] you could not get an unscaled encoding of class pointers. If I'm not mistaken it is like this in 11u. > Mind you, given that CDS seems to be on by default, I guess any weird options > won't much be used anyway. I don't think either it is a real problem. Reading the code can be confusing though. And AArch64 requires a special case in the new test case for [2]. Richard. [1] https://bugs.openjdk.java.net/browse/JDK-8241825 [2] https://bugs.openjdk.java.net/browse/JDK-8258576 -----Original Message----- From: Andrew Haley Sent: Montag, 21. Dezember 2020 15:19 To: Reingruber, Richard ; hotspot-dev at openjdk.java.net Subject: Re: AArch64: is a compressed class space at 2G a problem? On 12/21/20 8:55 AM, Reingruber, Richard wrote: >> On 12/18/20 4:52 PM, Reingruber, Richard wrote: >>> >>> it appears to me that locating the compressed class space (ccs) at 2G is >>> currently not possible on AArch64 [1][2]. This looks like a bug to me. Would you >>> agree? > >> If the compressed class space is located at 2G then its encoding >> base should be zero. We don't care exactly where the space starts, >> but we do care very much that its encoding base is 4G-aligned. > > Thanks for the feedback! I've created [1] to track this. This is bizarre. I'm pretty sure it used to work; maybe something else has changed. What we want, in pretty much every case, is an unshifted 4G-aligned encoding. Zero-based would be nice. Mind you, given that CDS seems to be on by default, I guess any weird options won't much be used anyway. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From luhenry at openjdk.java.net Mon Dec 21 23:21:55 2020 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Mon, 21 Dec 2020 23:21:55 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: <91erxiMDb4ftvSomuJYHPi9SX-v8Z2VLD2qEwCbz5tk=.b9ed01b5-f0e0-4ed7-9c1a-b06bc0e64640@github.com> <8Eqswd7tsVaGEXHdKDncXqKpW2tBsSeuY0PV6aTB9_c=.a6cf4957-9d31-4e89-bf44-e7b7852205d5@github.com> <2S00ucaPGiAQLeLOejt1kfXeYEc7ctEPeRCIcq1N0N8=.dbf1ea7a-8de4-48a5-8759-03495e3e3c08@github.com> <9oXnHULCd76_J69CKMVVZl3FfDte1pnt38y06LVV4Sg=.26a4ab2c-5ff7-4e2f-9428-0d8cd931d243@github.com> Message-ID: <4Ek_anRMgDzvodg-QJQuJWZOnx8pr8ulnnUf47OQ_ak=.d761073f-860c-43d0-a359-6f32f8bc2e2f@github.com> On Mon, 21 Dec 2020 16:03:31 GMT, Magnus Ihse Bursie wrote: >> FWIW, I started working on a framework which would add support for selectable backends for hsdis. Unfortunately it was not as simple as I initially thought, so I had to put it on hold while directing my time to working on the winenv patch instead. >> >> I believe the proper way forward is to get the "selectable hsdis backend" framework in place, and then retrofit this patch to add LLVM support in that framework. If this means that this PR should be closed, or kept open until this is done, I don't know. > > Nag nag bot... > > I'm away for the holidays now, but I intend to pick up the work on the selectable hsdis backend when I return. So while this exact code is unlikely to be the one merged, it's good to have it open to allow me to double check the solutions picked here. @magicus that PR fell off my plate, but I'm happy to pick it up based on your "selectable hsdis backend" change. ------------- PR: https://git.openjdk.java.net/jdk/pull/392 From coleenp at openjdk.java.net Tue Dec 22 13:11:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 22 Dec 2020 13:11:56 GMT Subject: RFR: 8258459: Decouple gc_globals.hpp from globals.hpp In-Reply-To: References: Message-ID: On Wed, 16 Dec 2020 06:24:59 GMT, Ioi Lam wrote: > Currently, [globals.hpp](https://github.com/openjdk/jdk/blob/17ace8339dd8235f3811e3975d9ccc77910b0c77/src/hotspot/share/runtime/globals.hpp#L29) is including gc_globals.hpp. This exposes all the GC command-line flags to almost all cpp files. However, only about 1/3 of the cpp files would require gc_globals.hpp. > > This RFE improves modularity and HotSpot build time. > > **Review notes:** > - Please start with globals.hpp, gc_globals.hpp. > - Flags related to TLAB are frequently used by other header files. I moved these flags to a new header tlab_globals.hpp. > - Some tweaking of oop.hpp to avoid including gc_globals.hpp in this popular header file. (Otherwise gc_globals.hpp would be included by everyone). > - The other changes are just files that use GC flags. They should have included gc_globals.hpp but didn't. > > **Testing:** > Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Looks good! I had a couple of minor change requests. src/hotspot/share/oops/oop.inline.hpp line 187: > 185: // disjunct below to fail if the two comparands are computed across such > 186: // a concurrent change. > 187: assert((s == klass->oop_size(this)) || It might be nicer to throw the second half of this assert into the .cpp file, like assert(s == klass->oop_size(this) || gc_has_forwarded(), "wrong array object size"); With the special comment above it in the cpp file. Then someone has the potential to add more information if the assert fails, and that gets Universe::hpp out of the inline file (if that helps with future cleanups). src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp line 61: > 59: } > 60: > 61: size_t ThreadLocalAllocBuffer::initial_refill_waste_limit() { return desired_size() / TLABRefillWasteFraction; } nit: please line this up. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1797 From kbarrett at openjdk.java.net Tue Dec 22 18:53:06 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 22 Dec 2020 18:53:06 GMT Subject: RFR: 8258810: Improve enum traits Message-ID: Please review these miscellaneous improvements to the enum iteration facility. Thanks to @albertnetymk for discussions. (1) Removed some unneeded stuff from EnumIterationTraits. (2) Various similar bits of error checking code are unified and shared via EnumIterationTraits. (3) Casts between the enum type and the underlying type are now done using helper functions in EnumIterationTraits. (4) JDK-8257466 added accessors for the EnumRange bounds and the index for an enumerator, but didn't account for the possibility of an empty subrange. Add assertions for that case. (5) Added some death tests to verify some of the error checking. Testing: mach5 tier1 ------------- Commit messages: - Improve enum traits and tests Changes: https://git.openjdk.java.net/jdk/pull/1868/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1868&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258810 Stats: 104 lines in 2 files changed: 78 ins; 8 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/1868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1868/head:pull/1868 PR: https://git.openjdk.java.net/jdk/pull/1868 From jwilhelm at openjdk.java.net Tue Dec 22 20:51:15 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 22 Dec 2020 20:51:15 GMT Subject: RFR: Merge jdk16 Message-ID: Forwardport JDK 16 -> JDK 17 ------------- Commit messages: - Merge - 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64 - 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows - 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java - 8258790: C2: Crash on empty macro node list - 8258443: doclint should be service-loaded with system class loader - 8255763: C2: OSR miscompilation caused by invalid memory instruction placement - 8258714: Shenandoah: Process references before evacuation during degen The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1870&range=00.0 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1870&range=00.1 Changes: https://git.openjdk.java.net/jdk/pull/1870/files Stats: 203 lines in 12 files changed: 181 ins; 13 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1870.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1870/head:pull/1870 PR: https://git.openjdk.java.net/jdk/pull/1870 From jwilhelm at openjdk.java.net Tue Dec 22 21:19:59 2020 From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson) Date: Tue, 22 Dec 2020 21:19:59 GMT Subject: Integrated: Merge jdk16 In-Reply-To: References: Message-ID: On Tue, 22 Dec 2020 20:45:38 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 16 -> JDK 17 This pull request has now been integrated. Changeset: f2bad3a0 Author: Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/f2bad3a0 Stats: 203 lines in 12 files changed: 181 ins; 13 del; 9 mod Merge ------------- PR: https://git.openjdk.java.net/jdk/pull/1870 From kbarrett at openjdk.java.net Wed Dec 23 01:14:04 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 23 Dec 2020 01:14:04 GMT Subject: RFR: 8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE Message-ID: Please review this change which adds the ENABLE_IF_PARAM macro. This is used in the definition of a function template when that definition is separate from the declaration and the declaration uses ENABLE_IF. For the separate definition to match the declaration, the non-type template parameter for SFINAE in the two places must be "equivalent", where that's defined in terms of tokens. Rather than requiring a separate definition match the ENABLE_IF expansion directly, the new macro is provided; it is maintained in parallel with ENABLE_IF to ensure the needed consistency. Alternative names for the new macro are possible. (1) This gives the following usage: template::value)> void foo(T x) { ... } and this for separate declaration and definition. template::value)> void foo(T x); // later separate definition template::value)> void foo(T x) { ... } (2) An alternative that isn't being proposed here, but which could be done instead, would be to drop the ENABLE_IF macro and use a type alias, with associated change of syntax. Suppose the name is EnableIfX (should probably be EnableIf, but need to deal with name conflict). It would be defined as template using EnableIfX = std::enable_if_t; and used as template::value> = 0> void foo(T x) { ... } and this for separate declaration and definition. template::value> = 0> void foo(T x); // later separate definition template::value>> void foo(T x) { ... } (3) Or we could not provide any syntactic help, and just write it all out everywhere: template::value, int> = 0> void foo(T x) { ... } and this for separate declaration and definition. template::value, int> = 0> void foo(T x); // later separate definition template::value, int>> void foo(T x) { ... } Testing: mach5 tier1 This includes some new gtests for the macros. There aren't any current non-test uses of ENABLE_IF_PARAM yet. ------------- Commit messages: - Add ENABLE_IF_PARAM, unit tests Changes: https://git.openjdk.java.net/jdk/pull/1873/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1873&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258853 Stats: 36 lines in 2 files changed: 31 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1873/head:pull/1873 PR: https://git.openjdk.java.net/jdk/pull/1873 From github.com+16932759+shqking at openjdk.java.net Wed Dec 23 01:52:01 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Wed, 23 Dec 2020 01:52:01 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion Message-ID: 1. '-Wdeprecated-copy' As specified in C++11 [1], "the generation of the implicitly-defined copy constructor is deprecated if T has a user-defined destructor or user-defined copy assignment operator". The rationale behind is the well-known Rule of Three [2]. Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' warns about the C++11 deprecation of implicitly declared copy constructor and assignment operator if one of them is user-provided. Defining an explicit copy constructor would suppress this warning. The main reason why debug build with gcc-9 or higher succeeds lies in the inconsistent warning behaviors between gcc and clang. See the reduced code example [5]. We suspect it might be return value optimization/copy elision [6] that drives gcc not to declare implicit copy constructor for this case. Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise warnings for deprecated defintions of copy constructors. However, '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 and clang-9 are not affected. 2. '-Wimplicit-int-float-conversion' Making the conversion explicit would fix it. Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. Therefore clang-8 and clang-9 are not affected. The flag with similar functionality in gcc is '-Wfloat-conversion', but it is not enabled by '-Wall' or '-Wextra'. That's why this warning does not apprear when building with gcc. [1] https://en.cppreference.com/w/cpp/language/copy_constructor [2] https://en.cppreference.com/w/cpp/language/rule_of_three [3] https://www.gnu.org/software/gcc/gcc-9/changes.html [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html [5] https://godbolt.org/z/err4jM [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines. ------------- Commit messages: - 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion Changes: https://git.openjdk.java.net/jdk/pull/1874/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1874&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258010 Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1874/head:pull/1874 PR: https://git.openjdk.java.net/jdk/pull/1874 From hseigel at openjdk.java.net Wed Dec 23 18:07:05 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 18:07:05 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError Message-ID: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Please review this change to replace the JVM ExitVMOnVerifyError option with asserts. The change was tested with tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. Thanks, Harold ------------- Commit messages: - 8258839: Remove JVM option ExitVMOnVerifyError Changes: https://git.openjdk.java.net/jdk/pull/1882/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1882&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258839 Stats: 21 lines in 4 files changed: 0 ins; 12 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/1882.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1882/head:pull/1882 PR: https://git.openjdk.java.net/jdk/pull/1882 From iignatyev at openjdk.java.net Wed Dec 23 18:14:55 2020 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 23 Dec 2020 18:14:55 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError In-Reply-To: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: On Wed, 23 Dec 2020 18:01:57 GMT, Harold Seigel wrote: > Please review this change to replace the JVM ExitVMOnVerifyError option with asserts. The change was tested with tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold ?? ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1882 From dcubed at openjdk.java.net Wed Dec 23 18:27:57 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 18:27:57 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError In-Reply-To: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: <5jUBICW5RqoVf4MoVBF0Ia04eIQ2pdQmpvdn6ndWCFU=.031577db-cd96-4f35-91ba-293f8b7f4f43@github.com> On Wed, 23 Dec 2020 18:01:57 GMT, Harold Seigel wrote: > Please review this change to replace the JVM ExitVMOnVerifyError option with asserts. The change was tested with tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold Changes requested by dcubed (Reviewer). src/hotspot/share/c1/c1_Runtime1.cpp line 539: > 537: "Exception not subclass of Throwable"); > 538: #endif > 539: The "#endif" can be deleted. src/hotspot/share/c1/c1_Runtime1.cpp line 534: > 532: } > 533: #ifdef ASSERT > 534: assert(exception.not_null(), "NULL exceptions should be handled by throw_exception"); The "#ifdef ASSERT" can be deleted. src/hotspot/share/jvmci/jvmciRuntime.cpp line 261: > 259: } > 260: #ifdef ASSERT > 261: assert(exception.not_null(), "NULL exceptions should be handled by throw_exception"); The "#fdef ASSERT" can be deleted. src/hotspot/share/jvmci/jvmciRuntime.cpp line 267: > 265: "Exception not subclass of Throwable"); > 266: #endif > 267: The "#endif" can be deleted. ------------- PR: https://git.openjdk.java.net/jdk/pull/1882 From dcubed at openjdk.java.net Wed Dec 23 18:27:58 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 18:27:58 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError In-Reply-To: <5jUBICW5RqoVf4MoVBF0Ia04eIQ2pdQmpvdn6ndWCFU=.031577db-cd96-4f35-91ba-293f8b7f4f43@github.com> References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> <5jUBICW5RqoVf4MoVBF0Ia04eIQ2pdQmpvdn6ndWCFU=.031577db-cd96-4f35-91ba-293f8b7f4f43@github.com> Message-ID: On Wed, 23 Dec 2020 18:25:18 GMT, Daniel D. Daugherty wrote: >> Please review this change to replace the JVM ExitVMOnVerifyError option with asserts. The change was tested with tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Changes requested by dcubed (Reviewer). Minor additional cleanups. ------------- PR: https://git.openjdk.java.net/jdk/pull/1882 From coleenp at openjdk.java.net Wed Dec 23 18:46:56 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 23 Dec 2020 18:46:56 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError In-Reply-To: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: On Wed, 23 Dec 2020 18:01:57 GMT, Harold Seigel wrote: > Please review this change to replace the JVM ExitVMOnVerifyError option with asserts. The change was tested with tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold +1 to Dan's comments. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1882 From hseigel at openjdk.java.net Wed Dec 23 20:12:11 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 20:12:11 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError [v2] In-Reply-To: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: > Please review this change to replace the JVM ExitVMOnVerifyError option with asserts. The change was tested with tiers 1 and 2 on Linux, Mac OS, 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: 8258839 Remove JVM option ExitVMOnVerifyError ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1882/files - new: https://git.openjdk.java.net/jdk/pull/1882/files/9397d7f2..33265742 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1882&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1882&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1882.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1882/head:pull/1882 PR: https://git.openjdk.java.net/jdk/pull/1882 From hseigel at openjdk.java.net Wed Dec 23 20:16:55 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 20:16:55 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError [v2] In-Reply-To: References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: On Wed, 23 Dec 2020 18:43:41 GMT, Coleen Phillimore wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258839 Remove JVM option ExitVMOnVerifyError > > +1 to Dan's comments. Please review this updated change that removes the unneeded #ifdef and #endif statements. Thanks, Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1882 From hseigel at openjdk.java.net Wed Dec 23 20:16:56 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 20:16:56 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError [v2] In-Reply-To: References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: On Wed, 23 Dec 2020 20:12:50 GMT, Harold Seigel wrote: >> +1 to Dan's comments. > > Please review this updated change that removes the unneeded #ifdef and #endif statements. > Thanks, Harold Thanks Igor, Dan and Coleen for the reviews and for pointing out the "#..." statements that could be deleted. Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/1882 From hseigel at openjdk.java.net Wed Dec 23 20:17:02 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 20:17:02 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError [v2] In-Reply-To: <5jUBICW5RqoVf4MoVBF0Ia04eIQ2pdQmpvdn6ndWCFU=.031577db-cd96-4f35-91ba-293f8b7f4f43@github.com> References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> <5jUBICW5RqoVf4MoVBF0Ia04eIQ2pdQmpvdn6ndWCFU=.031577db-cd96-4f35-91ba-293f8b7f4f43@github.com> Message-ID: On Wed, 23 Dec 2020 18:22:14 GMT, Daniel D. Daugherty wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258839 Remove JVM option ExitVMOnVerifyError > > src/hotspot/share/c1/c1_Runtime1.cpp line 539: > >> 537: "Exception not subclass of Throwable"); >> 538: #endif >> 539: > > The "#endif" can be deleted. deleted > src/hotspot/share/c1/c1_Runtime1.cpp line 534: > >> 532: } >> 533: #ifdef ASSERT >> 534: assert(exception.not_null(), "NULL exceptions should be handled by throw_exception"); > > The "#ifdef ASSERT" can be deleted. deleted > src/hotspot/share/jvmci/jvmciRuntime.cpp line 261: > >> 259: } >> 260: #ifdef ASSERT >> 261: assert(exception.not_null(), "NULL exceptions should be handled by throw_exception"); > > The "#fdef ASSERT" can be deleted. deleted > src/hotspot/share/jvmci/jvmciRuntime.cpp line 267: > >> 265: "Exception not subclass of Throwable"); >> 266: #endif >> 267: > > The "#endif" can be deleted. deleted ------------- PR: https://git.openjdk.java.net/jdk/pull/1882 From hseigel at openjdk.java.net Wed Dec 23 20:38:09 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 20:38:09 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError [v3] In-Reply-To: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: > Please review this change to replace the JVM ExitVMOnVerifyError option with asserts. The change was tested with tiers 1 and 2 on Linux, Mac OS, 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: 8258839 Remove JVM option ExitVMOnVerifyError ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1882/files - new: https://git.openjdk.java.net/jdk/pull/1882/files/33265742..7404befe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1882&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1882&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1882.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1882/head:pull/1882 PR: https://git.openjdk.java.net/jdk/pull/1882 From dcubed at openjdk.java.net Wed Dec 23 20:38:10 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 20:38:10 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError [v2] In-Reply-To: References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: On Wed, 23 Dec 2020 20:12:11 GMT, Harold Seigel wrote: >> Please review this change to replace the JVM ExitVMOnVerifyError option with asserts. The change was tested with tiers 1 and 2 on Linux, Mac OS, 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: > > 8258839 Remove JVM option ExitVMOnVerifyError Changes requested by dcubed (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1882 From coleenp at openjdk.java.net Wed Dec 23 20:38:10 2020 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 23 Dec 2020 20:38:10 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError [v3] In-Reply-To: References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: On Wed, 23 Dec 2020 20:35:06 GMT, Harold Seigel wrote: >> Please review this change to replace the JVM ExitVMOnVerifyError option with asserts. The change was tested with tiers 1 and 2 on Linux, Mac OS, 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: > > 8258839 Remove JVM option ExitVMOnVerifyError Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1882 From dcubed at openjdk.java.net Wed Dec 23 20:38:11 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 20:38:11 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError [v2] In-Reply-To: References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: On Wed, 23 Dec 2020 20:28:25 GMT, Daniel D. Daugherty wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258839 Remove JVM option ExitVMOnVerifyError > > Changes requested by dcubed (Reviewer). One file was fixed, but the other was not. ------------- PR: https://git.openjdk.java.net/jdk/pull/1882 From hseigel at openjdk.java.net Wed Dec 23 20:38:11 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 20:38:11 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError [v2] In-Reply-To: References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: On Wed, 23 Dec 2020 20:28:42 GMT, Daniel D. Daugherty wrote: >> Changes requested by dcubed (Reviewer). > > One file was fixed, but the other was not. Ugh! I forgot to stage the file. ------------- PR: https://git.openjdk.java.net/jdk/pull/1882 From dcubed at openjdk.java.net Wed Dec 23 20:38:12 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 20:38:12 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError [v3] In-Reply-To: References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> <5jUBICW5RqoVf4MoVBF0Ia04eIQ2pdQmpvdn6ndWCFU=.031577db-cd96-4f35-91ba-293f8b7f4f43@github.com> Message-ID: On Wed, 23 Dec 2020 20:13:30 GMT, Harold Seigel wrote: >> src/hotspot/share/jvmci/jvmciRuntime.cpp line 261: >> >>> 259: } >>> 260: #ifdef ASSERT >>> 261: assert(exception.not_null(), "NULL exceptions should be handled by throw_exception"); >> >> The "#fdef ASSERT" can be deleted. > > deleted This one is not yet fixed. >> src/hotspot/share/jvmci/jvmciRuntime.cpp line 267: >> >>> 265: "Exception not subclass of Throwable"); >>> 266: #endif >>> 267: >> >> The "#endif" can be deleted. > > deleted This one is not yet fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/1882 From dcubed at openjdk.java.net Wed Dec 23 20:52:55 2020 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 23 Dec 2020 20:52:55 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError [v3] In-Reply-To: References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: On Wed, 23 Dec 2020 20:38:09 GMT, Harold Seigel wrote: >> Please review this change to replace the JVM ExitVMOnVerifyError option with asserts. The change was tested with tiers 1 and 2 on Linux, Mac OS, 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: > > 8258839 Remove JVM option ExitVMOnVerifyError Thumbs up! ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1882 From hseigel at openjdk.java.net Wed Dec 23 20:52:56 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 20:52:56 GMT Subject: RFR: 8258839: Remove JVM option ExitVMOnVerifyError [v3] In-Reply-To: References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: On Wed, 23 Dec 2020 20:47:10 GMT, Daniel D. Daugherty wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> 8258839 Remove JVM option ExitVMOnVerifyError > > Thumbs up! Thanks again for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/1882 From hseigel at openjdk.java.net Wed Dec 23 20:52:58 2020 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 23 Dec 2020 20:52:58 GMT Subject: Integrated: 8258839: Remove JVM option ExitVMOnVerifyError In-Reply-To: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> References: <3Iw7p-GFOWrX9tbr6DeJiyT-5RtplQRDSnWxMUXHFgs=.16810d83-178c-4c67-9a57-f7f793c65276@github.com> Message-ID: On Wed, 23 Dec 2020 18:01:57 GMT, Harold Seigel wrote: > Please review this change to replace the JVM ExitVMOnVerifyError option with asserts. The change was tested with tiers 1 and 2 on Linux, Mac OS, and Windows, and tiers 3-5 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: fda09434 Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/fda09434 Stats: 25 lines in 4 files changed: 0 ins; 16 del; 9 mod 8258839: Remove JVM option ExitVMOnVerifyError Reviewed-by: iignatyev, dcubed, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/1882 From github.com+16932759+shqking at openjdk.java.net Thu Dec 24 00:29:02 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Thu, 24 Dec 2020 00:29:02 GMT Subject: RFR: 8258382: Fix optimization-unstable code Message-ID: Optimization-unstable code refers to code that is unexpectedly discarded by compiler optimizations due to undefined behavior in the program. We applied a static checker called STACK (prototype from SOSP'13 paper [1]) to OpenJDK source code and found the following eight sites of potential unstable code. Removing undefined behaviors would make the code stable. [1] https://css.csail.mit.edu/stack/ -------- Note that we tested locally Jtreg tests ( tier1 and jdk::tier3) were passed on Linux x86/aarch64 machines after apply this patch. ------------- Commit messages: - 8258382: Fix optimization-unstable code Changes: https://git.openjdk.java.net/jdk/pull/1886/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1886&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258382 Stats: 16 lines in 5 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/1886.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1886/head:pull/1886 PR: https://git.openjdk.java.net/jdk/pull/1886 From kbarrett at openjdk.java.net Thu Dec 24 13:29:53 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 24 Dec 2020 13:29:53 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 01:45:58 GMT, Hao Sun wrote: > 1. '-Wdeprecated-copy' > As specified in C++11 [1], "the generation of the implicitly-defined > copy constructor is deprecated if T has a user-defined destructor or > user-defined copy assignment operator". The rationale behind is the > well-known Rule of Three [2]. > > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' > warns about the C++11 deprecation of implicitly declared copy > constructor and assignment operator if one of them is user-provided. > Defining an explicit copy constructor would suppress this warning. > > The main reason why debug build with gcc-9 or higher succeeds lies in > the inconsistent warning behaviors between gcc and clang. See the > reduced code example [5]. We suspect it might be return value > optimization/copy elision [6] that drives gcc not to declare implicit > copy constructor for this case. > > Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise > warnings for deprecated defintions of copy constructors. However, > '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 > and clang-9 are not affected. > > 2. '-Wimplicit-int-float-conversion' > Making the conversion explicit would fix it. > > Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. > Therefore clang-8 and clang-9 are not affected. The flag with similar > functionality in gcc is '-Wfloat-conversion', but it is not enabled by > '-Wall' or '-Wextra'. That's why this warning does not apprear when > building with gcc. > > [1] https://en.cppreference.com/w/cpp/language/copy_constructor > [2] https://en.cppreference.com/w/cpp/language/rule_of_three > [3] https://www.gnu.org/software/gcc/gcc-9/changes.html > [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html > [5] https://godbolt.org/z/err4jM > [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization > > > Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines. I think the two issues described here are distinct and should be dealt with in separate bugs and PRs. Their only relation is that both arise with using clang-10. But they are very different problems, in very different parts of the code, and probably ought to be reviewed by folks from different teams. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From kbarrett at openjdk.java.net Thu Dec 24 17:29:56 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 24 Dec 2020 17:29:56 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion In-Reply-To: References: Message-ID: On Wed, 23 Dec 2020 01:45:58 GMT, Hao Sun wrote: > 1. '-Wdeprecated-copy' > As specified in C++11 [1], "the generation of the implicitly-defined > copy constructor is deprecated if T has a user-defined destructor or > user-defined copy assignment operator". The rationale behind is the > well-known Rule of Three [2]. > > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' > warns about the C++11 deprecation of implicitly declared copy > constructor and assignment operator if one of them is user-provided. > Defining an explicit copy constructor would suppress this warning. > > The main reason why debug build with gcc-9 or higher succeeds lies in > the inconsistent warning behaviors between gcc and clang. See the > reduced code example [5]. We suspect it might be return value > optimization/copy elision [6] that drives gcc not to declare implicit > copy constructor for this case. > > Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise > warnings for deprecated defintions of copy constructors. However, > '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 > and clang-9 are not affected. > > 2. '-Wimplicit-int-float-conversion' > Making the conversion explicit would fix it. > > Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. > Therefore clang-8 and clang-9 are not affected. The flag with similar > functionality in gcc is '-Wfloat-conversion', but it is not enabled by > '-Wall' or '-Wextra'. That's why this warning does not apprear when > building with gcc. > > [1] https://en.cppreference.com/w/cpp/language/copy_constructor > [2] https://en.cppreference.com/w/cpp/language/rule_of_three > [3] https://www.gnu.org/software/gcc/gcc-9/changes.html > [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html > [5] https://godbolt.org/z/err4jM > [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization > > > Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines. src/hotspot/share/opto/node.hpp line 1458: > 1456: // initialize to garbage > 1457: > 1458: DUIterator_Last (const DUIterator_Last& that) : DUIterator_Fast(that) {} Since DUIterator_Last is just delegating both the copy constructor and assignment operator to the base class, their copy constructor and assignment operator would be better as the default (either implicit or explicit using `=default`) rather than explicit code. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From kim.barrett at oracle.com Thu Dec 24 17:31:50 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 24 Dec 2020 12:31:50 -0500 Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion In-Reply-To: References: Message-ID: <9E9D468D-5560-4F3B-8F45-4D3182F403D2@oracle.com> > On Dec 22, 2020, at 8:52 PM, Hao Sun wrote: > > 1. '-Wdeprecated-copy' > As specified in C++11 [1], "the generation of the implicitly-defined > copy constructor is deprecated if T has a user-defined destructor or > user-defined copy assignment operator". The rationale behind is the > well-known Rule of Three [2]. > > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' > warns about the C++11 deprecation of implicitly declared copy > constructor and assignment operator if one of them is user-provided. > Defining an explicit copy constructor would suppress this warning. > > The main reason why debug build with gcc-9 or higher succeeds lies in > the inconsistent warning behaviors between gcc and clang. See the > reduced code example [5]. We suspect it might be return value > optimization/copy elision [6] that drives gcc not to declare implicit > copy constructor for this case. C++17 "guaranteed copy elision" is implemented in gcc7. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html Using -fno-elide-constructors makes it obvious that the deprecated implicit copy constructors are indeed being elided, so no deprecation warning. Why doesn't this patch similarly define DUIterator copy constructor? It seems to have the same issue, and I'm surprised clang-10 didn't complain about it too. Certainly gcc with -fno-elide-constructors complains about the defaulted implicit constructor. But I discovered something alarming while experimenting. Building with gcc10.2 with -fno-elide-constructors doesn't seem to be possible. I get different kinds of failures depending on how DUIterator is defined: - implict: deprecation warning (as expected) - =delete: error, deleted function used - =default: assert in os::free - _idx and reset from that: assert in reset Without -fno-elide-constructors, all of the variants seem to work except =delete, which still fails because the deleted function is used. (I didn't test the "working" cases extensively though.) So there's something problematic, though I don't understand the code well enough to understand what. Interestingly, some of the complexity and weirdness around copy/assign for these classes may be an attempt at providing something like move semantics in a C++98 code base. I've noticed a number of places in HotSpot that are doing that. Defining DUIterator_Fast and DUIterator_Last as movable but not copyable (explicitly delete the copy constructor and copy assign operator, and define the move constructor and move assign operator with the reset) works, even with -fno-elide-constructors. From kbarrett at openjdk.java.net Thu Dec 24 17:45:56 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 24 Dec 2020 17:45:56 GMT Subject: RFR: 8258382: Fix optimization-unstable code In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 00:24:32 GMT, Hao Sun wrote: > Optimization-unstable code refers to code that is unexpectedly discarded > by compiler optimizations due to undefined behavior in the program. > > We applied a static checker called STACK (prototype from SOSP'13 paper > [1]) to OpenJDK source code and found the following eight sites of > potential unstable code. > > Removing undefined behaviors would make the code stable. > > [1] https://css.csail.mit.edu/stack/ > > -------- > Note that we tested locally Jtreg tests ( tier1 and jdk::tier3) were passed on Linux x86/aarch64 machines after apply this patch. I think there are somewhere between two and four distinct issues here that should be dealt with in separate bugs and PRs (the number depends on how the compiler folks might like things done). Their only relation is that all were detected by the STACK tool. But they are in very different parts of the code and probably ought to be reviewed by folks from different teams. ------------- PR: https://git.openjdk.java.net/jdk/pull/1886 From kbarrett at openjdk.java.net Thu Dec 24 18:02:00 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 24 Dec 2020 18:02:00 GMT Subject: RFR: 8258382: Fix optimization-unstable code In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 00:24:32 GMT, Hao Sun wrote: > Optimization-unstable code refers to code that is unexpectedly discarded > by compiler optimizations due to undefined behavior in the program. > > We applied a static checker called STACK (prototype from SOSP'13 paper > [1]) to OpenJDK source code and found the following eight sites of > potential unstable code. > > Removing undefined behaviors would make the code stable. > > [1] https://css.csail.mit.edu/stack/ > > -------- > Note that we tested locally Jtreg tests ( tier1 and jdk::tier3) were passed on Linux x86/aarch64 machines after apply this patch. Changes requested by kbarrett (Reviewer). src/hotspot/share/gc/parallel/psPromotionLAB.hpp line 122: > 120: HeapWord* obj = top(); > 121: // Pointer overflow check is needed here. > 122: if (end() >= obj && size <= (size_t) (end() - obj)) { `top() <= end()` is always true by design and construction, so the `end() >= obj` test is unnecessary and undesirable. An assertion could be added, but there are lots of places where that relation is assumed to hold and that don't bother asserting, so I wouldn't bother here either. src/hotspot/share/gc/parallel/psPromotionLAB.hpp line 121: > 119: assert(_start_array != NULL, "Sanity"); > 120: HeapWord* obj = top(); > 121: // Pointer overflow check is needed here. The comment mentions pointer overflow checking, but that's not what's being checked for anymore. It's just checking whether there is space for the desired object. It's just that the check is now being done safely and correctly, where it wasn't before, but that's not interesting. I don't think any comment is needed anymore; the updated code (with my other suggestions) is obvious. src/hotspot/share/gc/parallel/psPromotionLAB.inline.hpp line 37: > 35: HeapWord* obj = top(); > 36: // Pointer overflow check is needed here. > 37: if (end() >= obj && size <= (size_t)(end() - obj)) { Same suggestions here as for the corresponding changes to the .hpp file. ------------- PR: https://git.openjdk.java.net/jdk/pull/1886 From kbarrett at openjdk.java.net Thu Dec 24 18:02:01 2020 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 24 Dec 2020 18:02:01 GMT Subject: RFR: 8258382: Fix optimization-unstable code In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 17:57:33 GMT, Kim Barrett wrote: >> Optimization-unstable code refers to code that is unexpectedly discarded >> by compiler optimizations due to undefined behavior in the program. >> >> We applied a static checker called STACK (prototype from SOSP'13 paper >> [1]) to OpenJDK source code and found the following eight sites of >> potential unstable code. >> >> Removing undefined behaviors would make the code stable. >> >> [1] https://css.csail.mit.edu/stack/ >> >> -------- >> Note that we tested locally Jtreg tests ( tier1 and jdk::tier3) were passed on Linux x86/aarch64 machines after apply this patch. > > src/hotspot/share/gc/parallel/psPromotionLAB.hpp line 122: > >> 120: HeapWord* obj = top(); >> 121: // Pointer overflow check is needed here. >> 122: if (end() >= obj && size <= (size_t) (end() - obj)) { > > `top() <= end()` is always true by design and construction, so the > `end() >= obj` test is unnecessary and undesirable. An assertion could > be added, but there are lots of places where that relation is assumed > to hold and that don't bother asserting, so I wouldn't bother here > either. Instead of `(size_t)(end() - obj)` use `pointer_delta(end(), obj)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1886 From xliu at openjdk.java.net Thu Dec 24 20:44:56 2020 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 24 Dec 2020 20:44:56 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 17:27:39 GMT, Kim Barrett wrote: >> 1. '-Wdeprecated-copy' >> As specified in C++11 [1], "the generation of the implicitly-defined >> copy constructor is deprecated if T has a user-defined destructor or >> user-defined copy assignment operator". The rationale behind is the >> well-known Rule of Three [2]. >> >> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' >> warns about the C++11 deprecation of implicitly declared copy >> constructor and assignment operator if one of them is user-provided. >> Defining an explicit copy constructor would suppress this warning. >> >> The main reason why debug build with gcc-9 or higher succeeds lies in >> the inconsistent warning behaviors between gcc and clang. See the >> reduced code example [5]. We suspect it might be return value >> optimization/copy elision [6] that drives gcc not to declare implicit >> copy constructor for this case. >> >> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise >> warnings for deprecated defintions of copy constructors. However, >> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 >> and clang-9 are not affected. >> >> 2. '-Wimplicit-int-float-conversion' >> Making the conversion explicit would fix it. >> >> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. >> Therefore clang-8 and clang-9 are not affected. The flag with similar >> functionality in gcc is '-Wfloat-conversion', but it is not enabled by >> '-Wall' or '-Wextra'. That's why this warning does not apprear when >> building with gcc. >> >> [1] https://en.cppreference.com/w/cpp/language/copy_constructor >> [2] https://en.cppreference.com/w/cpp/language/rule_of_three >> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html >> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html >> [5] https://godbolt.org/z/err4jM >> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization >> >> >> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines. > > src/hotspot/share/opto/node.hpp line 1458: > >> 1456: // initialize to garbage >> 1457: >> 1458: DUIterator_Last (const DUIterator_Last& that) : DUIterator_Fast(that) {} > > Since DUIterator_Last is just delegating both the copy constructor and > assignment operator to the base class, their copy constructor and > assignment operator would be better as the default (either implicit or > explicit using `=default`) rather than explicit code. Agree. c2 actually never uses the assignment operator of DUIterator_Last. It needs the copy constructor in this line. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1499 you can delete the following code or leave it =default. - void operator=(const DUIterator_Last& that) - { DUIterator_Fast::operator=(that); } ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From ayang at openjdk.java.net Thu Dec 24 20:46:55 2020 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 24 Dec 2020 20:46:55 GMT Subject: RFR: 8258810: Improve enum traits In-Reply-To: References: Message-ID: <5wNonxnCzpbxmF-Eb4DZ7E89L0BeqZXPb66Rw_PZvDo=.5d397ee6-fa8f-4860-add7-dada8f713063@github.com> On Tue, 22 Dec 2020 18:45:31 GMT, Kim Barrett wrote: > Please review these miscellaneous improvements to the enum iteration facility. > Thanks to @albertnetymk for discussions. > > (1) Removed some unneeded stuff from EnumIterationTraits. > > (2) Various similar bits of error checking code are unified and shared via > EnumIterationTraits. > > (3) Casts between the enum type and the underlying type are now done using > helper functions in EnumIterationTraits. > > (4) JDK-8257466 added accessors for the EnumRange bounds and the index for > an enumerator, but didn't account for the possibility of an empty subrange. > Add assertions for that case. > > (5) Added some death tests to verify some of the error checking. > > Testing: > mach5 tier1 I think `assert(size() > 0)` is more consistent with preceding documentation than `assert_not_empty()` in `first()` and `last()`. Very subjective though; up to you. ------------- Marked as reviewed by ayang (Author). PR: https://git.openjdk.java.net/jdk/pull/1868 From akozlov at openjdk.java.net Thu Dec 24 22:59:00 2020 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Thu, 24 Dec 2020 22:59:00 GMT Subject: Withdrawn: 8255416: Investigate err_msg to detect unnecessary uses In-Reply-To: References: Message-ID: <3NO1oMPee_x2Ikp_FE-yyPvw3DPuVktFbfqvV_X3jlc=.3f078544-3004-4302-990f-a22f484fcebc@github.com> On Wed, 28 Oct 2020 16:46:47 GMT, Anton Kozlov wrote: > Hi, > > When a single string without formatting arguments is provided to `err_msg`, it's redundancy, as the same message could be used without any err_msg. This is a follow-up to the discussion https://github.com/openjdk/jdk/pull/812#discussion_r511784050 > > Please review a change that makes `err_msg` with a single string to fail compilation. > > Detected uses of err_msg with a single string were eliminated as well. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/905 From github.com+16932759+shqking at openjdk.java.net Fri Dec 25 04:10:58 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Fri, 25 Dec 2020 04:10:58 GMT Subject: RFR: 8258382: Fix optimization-unstable code involving pointer overflow In-Reply-To: References: Message-ID: <2fkGSBXxFDcvw57wy1TI_m5tIQb-MWRjFCLWxDiWot4=.f7daff15-2a78-4ae2-aafb-95c47a3005d9@github.com> On Thu, 24 Dec 2020 17:59:42 GMT, Kim Barrett wrote: >> Optimization-unstable code refers to code that is unexpectedly discarded >> by compiler optimizations due to undefined behavior in the program. >> >> We applied a static checker called STACK (prototype from SOSP'13 paper >> [1]) to OpenJDK source code and found the following eight sites of >> potential unstable code. >> >> Removing undefined behaviors would make the code stable. >> >> [1] https://css.csail.mit.edu/stack/ >> >> -------- >> Note that we tested locally Jtreg tests ( tier1 and jdk::tier3) were passed on Linux x86/aarch64 machines after apply this patch. > > Changes requested by kbarrett (Reviewer). > I think there are somewhere between two and four distinct issues here > that should be dealt with in separate bugs and PRs (the number depends > on how the compiler folks might like things done). Their only relation > is that all were detected by the STACK tool. But they are in very > different parts of the code and probably ought to be reviewed by folks > from different teams. Thanks for your suggestion. I will put the other 6 issues involving signed integer overflow into another PR (https://bugs.openjdk.java.net/browse/JDK-8258946), and continue to use this PR to fix the pointer overflow checks. > src/hotspot/share/gc/parallel/psPromotionLAB.hpp line 121: > >> 119: assert(_start_array != NULL, "Sanity"); >> 120: HeapWord* obj = top(); >> 121: // Pointer overflow check is needed here. > > The comment mentions pointer overflow checking, but that's not what's > being checked for anymore. It's just checking whether there is space > for the desired object. It's just that the check is now being done > safely and correctly, where it wasn't before, but that's not interesting. > I don't think any comment is needed anymore; the updated code (with > my other suggestions) is obvious. Will remove in next revision. Thanks. > src/hotspot/share/gc/parallel/psPromotionLAB.inline.hpp line 37: > >> 35: HeapWord* obj = top(); >> 36: // Pointer overflow check is needed here. >> 37: if (end() >= obj && size <= (size_t)(end() - obj)) { > > Same suggestions here as for the corresponding changes to the .hpp file. Got it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1886 From github.com+16932759+shqking at openjdk.java.net Fri Dec 25 04:10:59 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Fri, 25 Dec 2020 04:10:59 GMT Subject: RFR: 8258382: Fix optimization-unstable code involving pointer overflow In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 17:57:44 GMT, Kim Barrett wrote: >> src/hotspot/share/gc/parallel/psPromotionLAB.hpp line 122: >> >>> 120: HeapWord* obj = top(); >>> 121: // Pointer overflow check is needed here. >>> 122: if (end() >= obj && size <= (size_t) (end() - obj)) { >> >> `top() <= end()` is always true by design and construction, so the >> `end() >= obj` test is unnecessary and undesirable. An assertion could >> be added, but there are lots of places where that relation is assumed >> to hold and that don't bother asserting, so I wouldn't bother here >> either. > > Instead of `(size_t)(end() - obj)` use `pointer_delta(end(), obj)`. Cool. Will update soon. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/1886 From github.com+16932759+shqking at openjdk.java.net Fri Dec 25 06:02:55 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Fri, 25 Dec 2020 06:02:55 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 20:42:01 GMT, Xin Liu wrote: >> src/hotspot/share/opto/node.hpp line 1458: >> >>> 1456: // initialize to garbage >>> 1457: >>> 1458: DUIterator_Last (const DUIterator_Last& that) : DUIterator_Fast(that) {} >> >> Since DUIterator_Last is just delegating both the copy constructor and >> assignment operator to the base class, their copy constructor and >> assignment operator would be better as the default (either implicit or >> explicit using `=default`) rather than explicit code. > > Agree. c2 actually never uses the assignment operator of DUIterator_Last. It needs the copy constructor in this line. > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/node.hpp#L1499 > > you can delete the following code or leave it =default. > - void operator=(const DUIterator_Last& that) > - { DUIterator_Fast::operator=(that); } Thanks for your comments. Will remove the assignment operator of DUIterator_Last. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From github.com+16932759+shqking at openjdk.java.net Fri Dec 25 06:16:55 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Fri, 25 Dec 2020 06:16:55 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion In-Reply-To: References: Message-ID: On Thu, 24 Dec 2020 13:27:33 GMT, Kim Barrett wrote: > I think the two issues described here are distinct and should be dealt > with in separate bugs and PRs. Their only relation is that both arise > with using clang-10. But they are very different problems, in very > different parts of the code, and probably ought to be reviewed by > folks from different teams. Thanks for your comment. Warning message of '-Wimplicit-int-float-conversion' was further encountered after we fixed the build failure caused by '-Wdeprecated-copy' first. That's why we put them in one PR initially. Yes. Your way is much better. But we suppose the issue of '-Wimplicit-int-float-conversion' is trivial and putting them in separate PRs might raise another internal review process (for our side) by which extra time is needed. I was wondering could we continue in one single PR. :) ------------- PR: https://git.openjdk.java.net/jdk/pull/1874 From github.com+16932759+shqking at openjdk.java.net Mon Dec 28 10:28:09 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Mon, 28 Dec 2020 10:28:09 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: References: Message-ID: > 1. '-Wdeprecated-copy' > As specified in C++11 [1], "the generation of the implicitly-defined > copy constructor is deprecated if T has a user-defined destructor or > user-defined copy assignment operator". The rationale behind is the > well-known Rule of Three [2]. > > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' > warns about the C++11 deprecation of implicitly declared copy > constructor and assignment operator if one of them is user-provided. > Defining an explicit copy constructor would suppress this warning. > > The main reason why debug build with gcc-9 or higher succeeds lies in > the inconsistent warning behaviors between gcc and clang. See the > reduced code example [5]. We suspect it might be return value > optimization/copy elision [6] that drives gcc not to declare implicit > copy constructor for this case. > > Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise > warnings for deprecated defintions of copy constructors. However, > '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 > and clang-9 are not affected. > > 2. '-Wimplicit-int-float-conversion' > Making the conversion explicit would fix it. > > Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. > Therefore clang-8 and clang-9 are not affected. The flag with similar > functionality in gcc is '-Wfloat-conversion', but it is not enabled by > '-Wall' or '-Wextra'. That's why this warning does not apprear when > building with gcc. > > [1] https://en.cppreference.com/w/cpp/language/copy_constructor > [2] https://en.cppreference.com/w/cpp/language/rule_of_three > [3] https://www.gnu.org/software/gcc/gcc-9/changes.html > [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html > [5] https://godbolt.org/z/err4jM > [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization > > > Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines. Hao Sun has updated the pull request incrementally with one additional commit since the last revision: Remove the unused assignment operator for DUIterator_Last Instead of adding the copy constructor, remove the assignment operator of DUIterator_Last since it's never used. Change-Id: Idf5658e38861eb2b0e724b064d17e9ab4e93905f CustomizedGitHooks: yes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1874/files - new: https://git.openjdk.java.net/jdk/pull/1874/files/124033f2..68679966 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1874&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1874&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1874/head:pull/1874 PR: https://git.openjdk.java.net/jdk/pull/1874 From x4e_x4e at protonmail.com Mon Dec 28 16:02:37 2020 From: x4e_x4e at protonmail.com (x4e_x4e) Date: Mon, 28 Dec 2020 16:02:37 +0000 Subject: Duplicate attributes in class files Message-ID: The current JVM specification (chapter 4) does not seem to place enough constraints on duplicate attributes. What I mean by this is if two attributes share the same name (but not necessarily the same length or content). The JVM specification does say that if two attributes have the same name and length this will result in a "conflict". This seems to contradict with the current behavior of the JVM to reject classes that contain known attributes with the same name, regardless of their length. See: https://github.com/openjdk/jdk/blob/779ee1104ca7f506bd1113004a84745824a507d4/src/hotspot/share/classfile/classFileParser.cpp#L1364 https://github.com/openjdk/jdk/blob/779ee1104ca7f506bd1113004a84745824a507d4/src/hotspot/share/classfile/classFileParser.cpp#L1395 https://github.com/openjdk/jdk/blob/779ee1104ca7f506bd1113004a84745824a507d4/src/hotspot/share/classfile/classFileParser.cpp#L2503 Would it be a good idea to update the specification to explicitly deny duplicate named attributes? This would also have a potential benefit of allowing attributes to be stored by implementations in HashTable for fast lookups by name. At the moment this seems to not be possible without collisions. From forax at univ-mlv.fr Mon Dec 28 16:42:26 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 28 Dec 2020 17:42:26 +0100 (CET) Subject: Duplicate attributes in class files In-Reply-To: References: Message-ID: <2110406982.185241.1609173746896.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "x4e_x4e" > ?: "hotspot-dev" > Envoy?: Lundi 28 D?cembre 2020 17:02:37 > Objet: Duplicate attributes in class files Hi ! > The current JVM specification (chapter 4) does not seem to place enough > constraints on duplicate attributes. > What I mean by this is if two attributes share the same name (but not > necessarily the same length or content). > > The JVM specification does say that if two attributes have the same name and > length this will result in a "conflict". It's not what the spec says, the text in section 4.7.1 "Two attributes that are intended to be distinct, but that happen to use the same attribute name and are of the same length, will conflict on implementations that recognize either attribute" refers to two user defined attributes. It's not about spec defined attributes but user defined attributes which should use the reverse DNS convention for their names to avoid name collision (conflict). For the attributes defined by the spec, you have to read the text corresponding to the specific attribute to know if you can have more than one or not, By example, you can have several attributes "ConstantValue" (4.7.2) but a method can not have more than one attribute "Code" (4.7.3). [...] regards, R?mi From xliu at openjdk.java.net Mon Dec 28 19:25:55 2020 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 28 Dec 2020 19:25:55 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: References: Message-ID: <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com> On Mon, 28 Dec 2020 10:28:09 GMT, Hao Sun wrote: >> 1. '-Wdeprecated-copy' >> As specified in C++11 [1], "the generation of the implicitly-defined >> copy constructor is deprecated if T has a user-defined destructor or >> user-defined copy assignment operator". The rationale behind is the >> well-known Rule of Three [2]. >> >> Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' >> warns about the C++11 deprecation of implicitly declared copy >> constructor and assignment operator if one of them is user-provided. >> Defining an explicit copy constructor would suppress this warning. >> >> The main reason why debug build with gcc-9 or higher succeeds lies in >> the inconsistent warning behaviors between gcc and clang. See the >> reduced code example [5]. We suspect it might be return value >> optimization/copy elision [6] that drives gcc not to declare implicit >> copy constructor for this case. >> >> Note that flag '-Wdeprecated' in clang-8 and clang-9 would also raise >> warnings for deprecated defintions of copy constructors. However, >> '-Wdeprecated' is not enabled by '-Wall' or '-Wextra'. Hence, clang-8 >> and clang-9 are not affected. >> >> 2. '-Wimplicit-int-float-conversion' >> Making the conversion explicit would fix it. >> >> Flag '-Wimplicit-int-float-conversion' is first introduced in clang-10. >> Therefore clang-8 and clang-9 are not affected. The flag with similar >> functionality in gcc is '-Wfloat-conversion', but it is not enabled by >> '-Wall' or '-Wextra'. That's why this warning does not apprear when >> building with gcc. >> >> [1] https://en.cppreference.com/w/cpp/language/copy_constructor >> [2] https://en.cppreference.com/w/cpp/language/rule_of_three >> [3] https://www.gnu.org/software/gcc/gcc-9/changes.html >> [4] https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html >> [5] https://godbolt.org/z/err4jM >> [6] https://en.wikipedia.org/wiki/Copy_elision#Return_value_optimization >> >> >> Note that we have tested with this patch, debug build succeeded with clang-10 on Linux X86/AArch64 machines. > > Hao Sun has updated the pull request incrementally with one additional commit since the last revision: > > Remove the unused assignment operator for DUIterator_Last > > Instead of adding the copy constructor, remove the assignment operator > of DUIterator_Last since it's never used. > > Change-Id: Idf5658e38861eb2b0e724b064d17e9ab4e93905f > CustomizedGitHooks: yes LGTM. It still needs other's approval. ------------- Marked as reviewed by xliu (no project role). PR: https://git.openjdk.java.net/jdk/pull/1874 From github.com+16932759+shqking at openjdk.java.net Wed Dec 30 03:33:58 2020 From: github.com+16932759+shqking at openjdk.java.net (Hao Sun) Date: Wed, 30 Dec 2020 03:33:58 GMT Subject: RFR: 8258010: Debug build failure with clang-10 due to -Wdeprecated-copy and -Wimplicit-int-float-conversion [v2] In-Reply-To: <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com> References: <68h4ANoO5jXI6VnotYyeHT8BlKV2CJnxaSaoiNc1OIM=.ccdb505f-1af9-48a6-a37e-0acb65b16749@github.com> Message-ID: On Mon, 28 Dec 2020 19:23:34 GMT, Xin Liu wrote: >> Hao Sun has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove the unused assignment operator for DUIterator_Last >> >> Instead of adding the copy constructor, remove the assignment operator >> of DUIterator_Last since it's never used. >> >> Change-Id: Idf5658e38861eb2b0e724b064d17e9ab4e93905f >> CustomizedGitHooks: yes > > LGTM. It still needs other's approval. > _Mailing list message from [Kim Barrett](mailto:kim.barrett at oracle.com) on [build-dev](mailto:build-dev at openjdk.java.net):_ > > > On Dec 22, 2020, at 8:52 PM, Hao Sun wrote: > > 1. '-Wdeprecated-copy' > > As specified in C++11 [1], "the generation of the implicitly-defined > > copy constructor is deprecated if T has a user-defined destructor or > > user-defined copy assignment operator". The rationale behind is the > > well-known Rule of Three [2]. > > Introduced since gcc-9 [3] and clang-10 [4], flag '-Wdeprecated-copy' > > warns about the C++11 deprecation of implicitly declared copy > > constructor and assignment operator if one of them is user-provided. > > Defining an explicit copy constructor would suppress this warning. > > The main reason why debug build with gcc-9 or higher succeeds lies in > > the inconsistent warning behaviors between gcc and clang. See the > > reduced code example [5]. We suspect it might be return value > > optimization/copy elision [6] that drives gcc not to declare implicit > > copy constructor for this case. > > C++17 "guaranteed copy elision" is implemented in gcc7. > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0135r1.html > Thanks for your comment. Initially we only suspected it might be copy elision that made gcc and clang to behave differently on this warning, and we were not aware of this flag '-fno-elide-constructors'. Thank you for pointing it out. > Using -fno-elide-constructors makes it obvious that the deprecated > implicit copy constructors are indeed being elided, so no deprecation > warning. > I suppose you want to express 'Using -**felide-constructors**' here. gcc with '-fno-elide-constructos' would produce derepcated warnings for this issue as clang-10 does. > Why doesn't this patch similarly define DUIterator copy constructor? > It seems to have the same issue, and I'm surprised clang-10 didn't > complain about it too. Certainly gcc with -fno-elide-constructors > complains about the defaulted implicit constructor. > I'm afraid we have noticed the same issue for 'DUIterator' before. Yes. It's weird that clang-10 didn't raise warning here. ( verified it on my local machine.) > But I discovered something alarming while experimenting. Building > with gcc10.2 with -fno-elide-constructors doesn't seem to be possible. > I get different kinds of failures depending on how DUIterator is > defined: > > - implict: deprecation warning (as expected) > - =delete: error, deleted function used > - =default: assert in os::free > - _idx and reset from that: assert in reset > > Without -fno-elide-constructors, all of the variants seem to work > except =delete, which still fails because the deleted function is > used. (I didn't test the "working" cases extensively though.) > > So there's something problematic, though I don't understand the code > well enough to understand what. Thanks for your tests. But I have no idea how to fix it right now either. Do you know anyone who is familiar with these code and maybe we can invite him/her to help take a look at this issue? Thanks. > > Interestingly, some of the complexity and weirdness around copy/assign > for these classes may be an attempt at providing something like move > semantics in a C++98 code base. I've noticed a number of places in > HotSpot that are doing that. > > Defining DUIterator_Fast and DUIterator_Last as movable but not > copyable (explicitly delete the copy constructor and copy assign > operator, and define the move constructor and move assign operator > with the reset) works, even with -fno-elide-constructors. ------------- PR: https://git.openjdk.java.net/jdk/pull/1874