From david.holmes at oracle.com Wed Nov 1 01:23:55 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Nov 2017 11:23:55 +1000 Subject: RFR(XL): 8185640: Thread-local handshakes In-Reply-To: References: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> <580AD7F0-2713-472C-A440-AAFDDA2D3EB3@oracle.com> <7591f6c0-7192-78c3-fe79-56a7785c43e4@oracle.com> <2ff79d24-90ab-822a-bd61-e01b79c01ada@redhat.com> <8d7678bf2281406da43cbe090276b51f@sap.com> <28bc3976-424d-1e05-cf7f-29bc38ccabcb@oracle.com> <818e352d5e3a450491cf0c140bf129d6@sap.com> <1c4a025da6ad4d39bedc1d6a12549b87@sap.com> <93cce80b-e9d7-f016-1324-2b0f5fac48c4@redhat.com> <59F1F3B3.10701@oracle.com> <43837915-a3a3-b36f-940e-1327937f0f17@redhat.com> <2EB9D7C3-B868-4C3E-BD88-6A4F92A39999@oracle.com> <59F2DC24.8050701@oracle.com> <59F2F01A.403@oracle.com> <4ebb905f23324a00b9cf10d8d410d420@sap.com> <9ff3abc3-9809-a9df-141b-15f0b05bd8a4@oracle.com> Message-ID: <3d3aea45-ccff-d5d1-d377-ddf4d4af9af0@oracle.com> Hi Robbin, On 1/11/2017 12:37 AM, Robbin Ehn wrote: > Thank you David for having a look. > > I updated after your review, I think I got it all, please see: > http://cr.openjdk.java.net/~rehn/8185640/v9/DavidH-Option-Cleanup-13/webrev/ That looks much clearer - thanks. > I'm also updating CSR with product_pd. > > Short thing: > > On 10/31/2017 11:27 AM, David Holmes wrote: >> >> I'm also thinking, if this is platform dependent then shouldn't >> ThreadLocalHandshakes be a product_pd flag, with pd specific default >> setting - and turning it on when on an unsupported platform should be >> a error ? > > Yes, the error checking already exists in: > > ?135 Flag::Error ThreadLocalHandshakesConstraintFunc(bool value, bool > verbose) { Ah I see. I'm not clear how this all hangs together. Is the constraint function only called if the flag is set on the command-line? Is it called before or after the other checking in arguments.cpp ? Thanks, David > ?136?? if (value) { > ?137???? if (!SafepointMechanism::supports_thread_local_poll()) { > ?138?????? CommandLineError::print(verbose, "ThreadLocalHandshakes not > yet supported on this platform\n"); > ?139?????? return Flag::VIOLATES_CONSTRAINT; > ?140???? } > ?141???? if (UseAOT JVMCI_ONLY(|| EnableJVMCI || UseJVMCICompiler)) { > ?142?????? CommandLineError::print(verbose, "ThreadLocalHandshakes not > yet supported in combination with AOT or JVMCI\n"); > ?143?????? return Flag::VIOLATES_CONSTRAINT; > ?144???? } > ?145?? } > ?146?? return Flag::SUCCESS; > ?147 } > > Sanity tested with handshake benchmark on all supported + 1 unsupported > platform. > > Thanks, Robbin > >> >> Thanks, >> David >> ----- >> >>> Here is webrev for changes needed: >>> http://cr.openjdk.java.net/~rehn/8185640/v8/Option-Cleanup-12/webrev/ >>> And here is CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8189942 >>> >>> Manual testing + basic testing done. >>> >>> And since I'm really hoping that this can be the last incremental, >>> here is my whole patch queue flatten out: >>> http://cr.openjdk.java.net/~rehn/8185640/v8/Full/webrev/ >>> >>> Thanks, Robbin >>> >>> On 10/27/2017 04:47 PM, Doerr, Martin wrote: >>>> Hi Robbin, >>>> >>>> excellent. I think this matches what Coleen had proposed, now. >>>> Thanks for doing all the work with so many incremental patches and >>>> for responding on so many discussions. Seems to be a tough piece of >>>> work. >>>> >>>> Best regards, >>>> Martin >>>> >>>> >>>> -----Original Message----- >>>> From: Robbin Ehn [mailto:robbin.ehn at oracle.com] >>>> Sent: Freitag, 27. Oktober 2017 15:15 >>>> To: Erik ?sterlund ; Andrew Haley >>>> ; Doerr, Martin ; Karen >>>> Kinnear ; Coleen Phillimore >>>> (coleen.phillimore at oracle.com) >>>> Cc: hotspot-dev developers >>>> Subject: Re: RFR(XL): 8185640: Thread-local handshakes >>>> >>>> Hi all, >>>> >>>> Poll in switches: >>>> http://cr.openjdk.java.net/~rehn/8185640/v7/Interpreter-Poll-Switch-10/ >>>> >>>> Poll in return: >>>> http://cr.openjdk.java.net/~rehn/8185640/v7/Interpreter-Poll-Ret-11/ >>>> >>>> Please take an extra look at poll in return. >>>> >>>> Sanity tested, big test run still running (99% complete - OK). >>>> >>>> Performance regression for the added polls increased to total of >>>> -0.68% vs >>>> global poll. (was -0.44%) >>>> >>>> We are discussing the opt-out option, the newest suggestion is to >>>> make it >>>> diagnostic. Opinions? >>>> >>>> For anyone applying these patches, the number 9 patch changes the >>>> option from >>>> product. I have not sent that out. >>>> >>>> Thanks, Robbin >>>> >>>> >>>> From dmitry.samersoff at bell-sw.com Wed Nov 1 07:44:36 2017 From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff) Date: Wed, 1 Nov 2017 10:44:36 +0300 Subject: [10] RFR 8186046 Minimal ConstantDynamic support In-Reply-To: <58726425-BA16-482B-A02E-3B0613CD5010@oracle.com> References: <93431280-9CBF-4722-961D-F2D2D0F83B4E@oracle.com> <58726425-BA16-482B-A02E-3B0613CD5010@oracle.com> Message-ID: Paul, Thank you! -Dmitry On 31.10.2017 20:32, Paul Sandoz wrote: > >> On 31 Oct 2017, at 05:58, Dmitry Samersoff wrote: >> >> Paul and Frederic, >> >> Thank you. >> >> One more question. Do we need to call verify_oop below? >> >> 509 { // Check for the null sentinel. >> ... >> 517 xorptr(result, result); // NULL object reference >> ... >> >> 521 if (VerifyOops) { >> 522 verify_oop(result); >> 523 } >> > > I believe it?s harmless. > > When the flag is on it eventually results in a call to the stub generated by generate_verify_oop: > > http://hg.openjdk.java.net/jdk10/hs/file/tip/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#l1023 > > // make sure object is 'reasonable' > __ testptr(rax, rax); > __ jcc(Assembler::zero, exit); // if obj is NULL it is OK > > If the oop is null the verification will exit safely. > > Paul. > >> -Dmitry >> >> >> On 31.10.2017 00:56, Frederic Parain wrote: >>> I?m seeing no issue with rcx being aliased in this code. >>> >>> Fred >>> >>>> On Oct 30, 2017, at 15:44, Paul Sandoz wrote: >>>> >>>> Hi, >>>> >>>> Thanks for reviewing. >>>> >>>>> On 30 Oct 2017, at 11:05, Dmitry Samersoff wrote: >>>>> >>>>> Paul, >>>>> >>>>> templateTable_x86.cpp: >>>>> >>>>> 564 const Register flags = rcx; >>>>> 565 const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1); >>>>> >>>>> Should we use another register for rarg under NOT_LP64 ? >>>>> >>>> >>>> I think it should be ok, it i ain?t an expert here on the interpreter and the calling conventions, so please correct me. >>>> >>>> Some more context: >>>> >>>> + const Register flags = rcx; >>>> + const Register rarg = NOT_LP64(rcx) LP64_ONLY(c_rarg1); >>>> + __ movl(rarg, (int)bytecode()); >>>> >>>> The current bytecode code is loaded into ?rarg? >>>> >>>> + call_VM(obj, CAST_FROM_FN_PTR(address, InterpreterRuntime::resolve_ldc), rarg); >>>> >>>> Then ?rarg" is the argument to the call to InterpreterRuntime::resolve_ldc, after which it is no longer referred to. >>>> >>>> +#ifndef _LP64 >>>> + // borrow rdi from locals >>>> + __ get_thread(rdi); >>>> + __ get_vm_result_2(flags, rdi); >>>> + __ restore_locals(); >>>> +#else >>>> + __ get_vm_result_2(flags, r15_thread); >>>> +#endif >>>> >>>> The result from the call is then loaded into flags. >>>> >>>> So i don?t think it matters in this case if rcx is aliased. >>>> >>>> Paul. >>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 10/26/2017 08:03 PM, Paul Sandoz wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following patch for minimal dynamic constant support: >>>>>> >>>>>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8186046 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8186209 >>>>>> >>>>>> This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good. >>>>>> >>>>>> By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex. >>>>>> >>>>>> A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository). >>>>>> >>>>>> Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments. >>>>>> >>>>>> The CSR for the VM specification is here: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8189199 >>>>>> >>>>>> the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles). >>>>>> >>>>>> Any AoT-related work will be deferred to a future release. >>>>>> >>>>>> ? >>>>>> >>>>>> This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte). >>>>>> >>>>>> We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches. >>>>>> >>>>>> ? >>>>>> >>>>>> Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants. >>>>>> >>>>>> One test uses class file bytes produced from a modified version of asmtools. The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test. >>>>>> >>>>>> ? >>>>>> >>>>>> Paul. >>>>>> >>>>> >>>> >>> >> >> > From robbin.ehn at oracle.com Wed Nov 1 09:37:50 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 1 Nov 2017 10:37:50 +0100 Subject: RFR(XL): 8185640: Thread-local handshakes In-Reply-To: <3d3aea45-ccff-d5d1-d377-ddf4d4af9af0@oracle.com> References: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> <7591f6c0-7192-78c3-fe79-56a7785c43e4@oracle.com> <2ff79d24-90ab-822a-bd61-e01b79c01ada@redhat.com> <8d7678bf2281406da43cbe090276b51f@sap.com> <28bc3976-424d-1e05-cf7f-29bc38ccabcb@oracle.com> <818e352d5e3a450491cf0c140bf129d6@sap.com> <1c4a025da6ad4d39bedc1d6a12549b87@sap.com> <93cce80b-e9d7-f016-1324-2b0f5fac48c4@redhat.com> <59F1F3B3.10701@oracle.com> <43837915-a3a3-b36f-940e-1327937f0f17@redhat.com> <2EB9D7C3-B868-4C3E-BD88-6A4F92A39999@oracle.com> <59F2DC24.8050701@oracle.com> <59F2F01A.403@oracle.com> <4ebb905f23324a00b9cf10d8d410d420@sap.com> <9ff3abc3-9809-a9df-141b-15f0b05bd8a4@oracle.com> <3d3aea45-ccff-d5d1-d377-ddf4d4af9af0@oracle.com> Message-ID: Hi David, On 11/01/2017 02:23 AM, David Holmes wrote: > Hi Robbin, > > On 1/11/2017 12:37 AM, Robbin Ehn wrote: >> Thank you David for having a look. >> >> I updated after your review, I think I got it all, please see: >> http://cr.openjdk.java.net/~rehn/8185640/v9/DavidH-Option-Cleanup-13/webrev/ > > That looks much clearer - thanks. Great! > >> I'm also updating CSR with product_pd. >> >> Short thing: >> >> On 10/31/2017 11:27 AM, David Holmes wrote: >>> >>> I'm also thinking, if this is platform dependent then shouldn't >>> ThreadLocalHandshakes be a product_pd flag, with pd specific default setting >>> - and turning it on when on an unsupported platform should be a error ? >> >> Yes, the error checking already exists in: >> >> ??135 Flag::Error ThreadLocalHandshakesConstraintFunc(bool value, bool verbose) { > > Ah I see. I'm not clear how this all hangs together. Is the constraint function > only called if the flag is set on the command-line? Is it called before or after > the other checking in arguments.cpp ? It's always called after argument parsing. /Robbin > > Thanks, > David > >> ??136?? if (value) { >> ??137???? if (!SafepointMechanism::supports_thread_local_poll()) { >> ??138?????? CommandLineError::print(verbose, "ThreadLocalHandshakes not yet >> supported on this platform\n"); >> ??139?????? return Flag::VIOLATES_CONSTRAINT; >> ??140???? } >> ??141???? if (UseAOT JVMCI_ONLY(|| EnableJVMCI || UseJVMCICompiler)) { >> ??142?????? CommandLineError::print(verbose, "ThreadLocalHandshakes not yet >> supported in combination with AOT or JVMCI\n"); >> ??143?????? return Flag::VIOLATES_CONSTRAINT; >> ??144???? } >> ??145?? } >> ??146?? return Flag::SUCCESS; >> ??147 } >> >> Sanity tested with handshake benchmark on all supported + 1 unsupported platform. >> >> Thanks, Robbin >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> Here is webrev for changes needed: >>>> http://cr.openjdk.java.net/~rehn/8185640/v8/Option-Cleanup-12/webrev/ >>>> And here is CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8189942 >>>> >>>> Manual testing + basic testing done. >>>> >>>> And since I'm really hoping that this can be the last incremental, here is >>>> my whole patch queue flatten out: >>>> http://cr.openjdk.java.net/~rehn/8185640/v8/Full/webrev/ >>>> >>>> Thanks, Robbin >>>> >>>> On 10/27/2017 04:47 PM, Doerr, Martin wrote: >>>>> Hi Robbin, >>>>> >>>>> excellent. I think this matches what Coleen had proposed, now. >>>>> Thanks for doing all the work with so many incremental patches and for >>>>> responding on so many discussions. Seems to be a tough piece of work. >>>>> >>>>> Best regards, >>>>> Martin >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Robbin Ehn [mailto:robbin.ehn at oracle.com] >>>>> Sent: Freitag, 27. Oktober 2017 15:15 >>>>> To: Erik ?sterlund ; Andrew Haley >>>>> ; Doerr, Martin ; Karen Kinnear >>>>> ; Coleen Phillimore >>>>> (coleen.phillimore at oracle.com) >>>>> Cc: hotspot-dev developers >>>>> Subject: Re: RFR(XL): 8185640: Thread-local handshakes >>>>> >>>>> Hi all, >>>>> >>>>> Poll in switches: >>>>> http://cr.openjdk.java.net/~rehn/8185640/v7/Interpreter-Poll-Switch-10/ >>>>> >>>>> Poll in return: >>>>> http://cr.openjdk.java.net/~rehn/8185640/v7/Interpreter-Poll-Ret-11/ >>>>> >>>>> Please take an extra look at poll in return. >>>>> >>>>> Sanity tested, big test run still running (99% complete - OK). >>>>> >>>>> Performance regression for the added polls increased to total of -0.68% vs >>>>> global poll. (was -0.44%) >>>>> >>>>> We are discussing the opt-out option, the newest suggestion is to make it >>>>> diagnostic. Opinions? >>>>> >>>>> For anyone applying these patches, the number 9 patch changes the option from >>>>> product. I have not sent that out. >>>>> >>>>> Thanks, Robbin >>>>> >>>>> >>>>> From david.holmes at oracle.com Wed Nov 1 09:46:23 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 Nov 2017 19:46:23 +1000 Subject: RFR(XL): 8185640: Thread-local handshakes In-Reply-To: References: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> <2ff79d24-90ab-822a-bd61-e01b79c01ada@redhat.com> <8d7678bf2281406da43cbe090276b51f@sap.com> <28bc3976-424d-1e05-cf7f-29bc38ccabcb@oracle.com> <818e352d5e3a450491cf0c140bf129d6@sap.com> <1c4a025da6ad4d39bedc1d6a12549b87@sap.com> <93cce80b-e9d7-f016-1324-2b0f5fac48c4@redhat.com> <59F1F3B3.10701@oracle.com> <43837915-a3a3-b36f-940e-1327937f0f17@redhat.com> <2EB9D7C3-B868-4C3E-BD88-6A4F92A39999@oracle.com> <59F2DC24.8050701@oracle.com> <59F2F01A.403@oracle.com> <4ebb905f23324a00b9cf10d8d410d420@sap.com> <9ff3abc3-9809-a9df-141b-15f0b05bd8a4@oracle.com> <3d3aea45-ccff-d5d1-d377-ddf4d4af9af0@oracle.com> Message-ID: <69dfebaf-b68a-32fa-8dbb-de829a2c8826@oracle.com> On 1/11/2017 7:37 PM, Robbin Ehn wrote: > Hi David, > > On 11/01/2017 02:23 AM, David Holmes wrote: >> Hi Robbin, >> >> On 1/11/2017 12:37 AM, Robbin Ehn wrote: >>> Thank you David for having a look. >>> >>> I updated after your review, I think I got it all, please see: >>> http://cr.openjdk.java.net/~rehn/8185640/v9/DavidH-Option-Cleanup-13/webrev/ >> >> >> That looks much clearer - thanks. > > Great! > >> >>> I'm also updating CSR with product_pd. >>> >>> Short thing: >>> >>> On 10/31/2017 11:27 AM, David Holmes wrote: >>>> >>>> I'm also thinking, if this is platform dependent then shouldn't >>>> ThreadLocalHandshakes be a product_pd flag, with pd specific default >>>> setting - and turning it on when on an unsupported platform should >>>> be a error ? >>> >>> Yes, the error checking already exists in: >>> >>> ??135 Flag::Error ThreadLocalHandshakesConstraintFunc(bool value, >>> bool verbose) { >> >> Ah I see. I'm not clear how this all hangs together. Is the constraint >> function only called if the flag is set on the command-line? Is it >> called before or after the other checking in arguments.cpp ? > > It's always called after argument parsing. Okay. I find it a bit confusing to have the flag processing logic split in two like this. But I'll leave it at that. Thanks, David > /Robbin > >> >> Thanks, >> David >> >>> ??136?? if (value) { >>> ??137???? if (!SafepointMechanism::supports_thread_local_poll()) { >>> ??138?????? CommandLineError::print(verbose, "ThreadLocalHandshakes >>> not yet supported on this platform\n"); >>> ??139?????? return Flag::VIOLATES_CONSTRAINT; >>> ??140???? } >>> ??141???? if (UseAOT JVMCI_ONLY(|| EnableJVMCI || UseJVMCICompiler)) { >>> ??142?????? CommandLineError::print(verbose, "ThreadLocalHandshakes >>> not yet supported in combination with AOT or JVMCI\n"); >>> ??143?????? return Flag::VIOLATES_CONSTRAINT; >>> ??144???? } >>> ??145?? } >>> ??146?? return Flag::SUCCESS; >>> ??147 } >>> >>> Sanity tested with handshake benchmark on all supported + 1 >>> unsupported platform. >>> >>> Thanks, Robbin >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Here is webrev for changes needed: >>>>> http://cr.openjdk.java.net/~rehn/8185640/v8/Option-Cleanup-12/webrev/ >>>>> And here is CSR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8189942 >>>>> >>>>> Manual testing + basic testing done. >>>>> >>>>> And since I'm really hoping that this can be the last incremental, >>>>> here is my whole patch queue flatten out: >>>>> http://cr.openjdk.java.net/~rehn/8185640/v8/Full/webrev/ >>>>> >>>>> Thanks, Robbin >>>>> >>>>> On 10/27/2017 04:47 PM, Doerr, Martin wrote: >>>>>> Hi Robbin, >>>>>> >>>>>> excellent. I think this matches what Coleen had proposed, now. >>>>>> Thanks for doing all the work with so many incremental patches and >>>>>> for responding on so many discussions. Seems to be a tough piece >>>>>> of work. >>>>>> >>>>>> Best regards, >>>>>> Martin >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Robbin Ehn [mailto:robbin.ehn at oracle.com] >>>>>> Sent: Freitag, 27. Oktober 2017 15:15 >>>>>> To: Erik ?sterlund ; Andrew Haley >>>>>> ; Doerr, Martin ; Karen >>>>>> Kinnear ; Coleen Phillimore >>>>>> (coleen.phillimore at oracle.com) >>>>>> Cc: hotspot-dev developers >>>>>> Subject: Re: RFR(XL): 8185640: Thread-local handshakes >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Poll in switches: >>>>>> http://cr.openjdk.java.net/~rehn/8185640/v7/Interpreter-Poll-Switch-10/ >>>>>> >>>>>> >>>>>> Poll in return: >>>>>> http://cr.openjdk.java.net/~rehn/8185640/v7/Interpreter-Poll-Ret-11/ >>>>>> >>>>>> Please take an extra look at poll in return. >>>>>> >>>>>> Sanity tested, big test run still running (99% complete - OK). >>>>>> >>>>>> Performance regression for the added polls increased to total of >>>>>> -0.68% vs >>>>>> global poll. (was -0.44%) >>>>>> >>>>>> We are discussing the opt-out option, the newest suggestion is to >>>>>> make it >>>>>> diagnostic. Opinions? >>>>>> >>>>>> For anyone applying these patches, the number 9 patch changes the >>>>>> option from >>>>>> product. I have not sent that out. >>>>>> >>>>>> Thanks, Robbin >>>>>> >>>>>> >>>>>> From daniel.daugherty at oracle.com Wed Nov 1 16:51:16 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 1 Nov 2017 12:51:16 -0400 Subject: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot In-Reply-To: References: <8671321f-398c-5f7f-634d-9d9664e04d87@oracle.com> <05bf853a-52f8-c450-4171-89f6b64d793a@oracle.com> <72f2aac7-ed20-c995-913b-ee4341a2a978@oracle.com> <55ec3559-c593-bcb6-51b0-4639da126068@oracle.com> <4509dce7-10f8-4558-2adb-90d4745e054e@oracle.com> <396ab0f7-3710-3f76-675a-5108bcb50af5@oracle.com> <51f09db9-06f5-ad01-bc92-1d73e1113f86@oracle.com> <66b590da-f94c-6d87-cf61-e269bf1afc0d@oracle.com> Message-ID: <0b049cc8-b3dc-cdfb-d71a-3e43274a1b9a@oracle.com> Just one comment about the location of "jvm.h". On 10/30/17 8:07 AM, coleen.phillimore at oracle.com wrote: > > > On 10/28/17 3:46 AM, David Holmes wrote: >> On 28/10/2017 3:47 AM, mandy chung wrote: >>> On 10/27/17 7:08 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 10/27/17 9:37 AM, David Holmes wrote: >>>>> >>>>> The one file that is needed is a hotspot file - jvm.h defines the >>>>> interface that hotspot exports via jvm.cpp. >>>>> >>>>> If you leave jvm.h in hotspot/prims then a very large chunk of >>>>> your boilerplate changes are not needed. The JDK code doesn't care >>>>> what the name of the directory is - whatever it is just gets added >>>>> as a -I directive (the JDK code will include "jvm.h" not >>>>> "prims/jvm.h" the way hotspot sources do. >>>>> >>>>> This isn't something we want to change back or move again later. >>>>> Whatever we do now we live with. >>>> >>>> I think it belongs with jni.h and I think the core libraries group >>>> would agree.?? It seems more natural there than buried in the >>>> hotspot prims directory.? I guess this is on hold while we have >>>> this debate.?? Sigh. >>>> >>>> Actually with -I directives, changing to jvm.h from prims/jvm.h >>>> would still work.?? Maybe we should change the name to jvm.hpp >>>> since it's jvm.cpp though??? Or maybe just have two divergent >>>> copies and close this as WNF. >>> >>> I also think hotspot/prims is not a good location. >>> src/java.base/share/include is a well-defined location for native >>> header files.? Maybe internal header files could be placed in >>> include/internal but this is a separate issue .? I should create an >>> issue for jvm.h and jmm.h (I looked at the files under the include >>> directory and jvm.h and jmm.h are the only two internal header files >>> in the include directory). >> >> Keeping it in prims avoids the need to touch many hotspot files, and >> with no changes needed on the JDK side because we use a -I directive >> to set the include path anyway. This is the exported VM interface so >> it makes sense to me for it to be located in the VM sources. >> >> But I'm not going to oppose this either way so it's up to Coleen. > > I've already disagreed that this file belongs in > src/hotspot/share/prims, so the include directive without prims is > preferred.? This allows putting jvm.h in a new place if/when that is > agreed upon. The jvm.h file describes the internal JVM_* API implemented by prims/jvm.cpp. Because this is an internal interface, the jvm.h file would traditionally be co-located with the implementation (jvm.cpp) (and not in an include directory). So I disagree with the proposal to move jvm.h and believe the single copy should be in prims/jvm.h. Dan >> >>> I do think removing the duplicated copy of jvm.h is a good change. >>> This is finally possible with the consolidated repository and we no >>> longer need to update two copies of jvm.h for any change to the JVM >> >> Unfortunately we did not do this though - hence the divergence >> between the two. The use of int versus long for jint is causing a >> real problem. >> >> Coleen also hit the other issue on the head. The JNI and JVM >> interfaces are C interfaces, not C++. The JDK code that uses them is >> compiled as C - so all good. But the JVM code that implements them is >> compiled as C++, and that is why we are getting issues with differing >> linkage directives. > > Well, there is now one source file for jvm.h and jni.h and their > machine dependent counterparts and 2500 lines of duplicated code is > removed with this change.? The issues with jint and linkages are > resolved and tested as well with this changeset. > > Thanks, > Coleen >> >> David >> ----- >> >>> interface.?? This change will work with -I directive setting to the >>> new location, if changed later. >>> >>> What do you think? >>> >>> Mandy > From vladimir.kozlov at oracle.com Wed Nov 1 17:12:31 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Nov 2017 10:12:31 -0700 Subject: RFR(S): 8187091: ReturnBlobToWrongHeapTest fails because of problems in CodeHeap::contains_blob() In-Reply-To: References: Message-ID: <8b12d73e-d3e5-da3b-9941-c59516e0134c@oracle.com> I submitted pre-integration testing. Will push after that. Vladimir On 10/30/17 12:34 PM, Volker Simonis wrote: > Hi Vladimir, > > this one is still pending (you only pushed "8166317: > InterpreterCodeSize should be computed"). > > Could you please also sponsor this one? > > The latest version is here: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/8187091.v2/ > > Thank you and best regards, > Volker > > On Tue, Sep 5, 2017 at 6:35 PM, Vladimir Kozlov > wrote: >> On 9/4/17 10:23 AM, Volker Simonis wrote: >>> >>> On Fri, Sep 1, 2017 at 6:00 PM, Vladimir Kozlov >>> wrote: >>>> >>>> Checking type is emulation of virtual call ;-) >>> >>> >>> I agree :) But it is only a bimorphic dispatch in this case which >>> should be still faster than a normal virtual call. >>> >>>> But I agree that it is simplest solution - one line change (excluding >>>> comment - comment is good BTW). >>>> >>> >>> Thanks. >>> >>>> You can also add guard AOT_ONLY() around aot specific code: >>>> >>>> const void* start = AOT_ONLY( (code_blob_type() == CodeBlobType::AOT) >>>> ? >>>> blob->code_begin() : ) (void*)blob; >>>> >>>> because we do have builds without AOT. >>>> >>> >>> Done. Please find the new webrev here: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8187091.v1/ >> >> >> Looks good. Thank you for updated CodeBlob description comment. >> >>> >>> Could you please sponsor the change once jdk10-hs opens again? >> >> >> We have to wait when jdk10 "consolidation" is finished. It may take 2 weeks. >> >>> >>> Thanks, >>> Volker >>> >>> PS: one thing which is still unclear to me is why you haven't caught >>> this issue before? Isn't >>> test/compiler/codecache/stress/ReturnBlobToWrongHeapTest.java part of >>> JPRT and/or your regular tests? >> >> >> test/compiler/codecache/stress are excluded from JPRT runs: >> >> https://bugs.openjdk.java.net/browse/JDK-8069021 >> >> Also these tests are marked with @key stress. Originally it was only 2 tests >> and ReturnBlobToWrongHeapTest.java was added later: >> >> https://bugs.openjdk.java.net/browse/JDK-8069021 >> >> I am trying to find which testing tier runs them. I will follow this. >> >> Thanks, >> Vladimir >> >> >>> >>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On 9/1/17 8:42 AM, Volker Simonis wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> can I please have a review and sponsor for the following small fix: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8187091/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8187091 >>>>> >>>>> We see failures in >>>>> test/compiler/codecache/stress/ReturnBlobToWrongHeapTest.java which >>>>> are cause by problems in CodeHeap::contains_blob() for corner cases >>>>> with CodeBlobs of zero size: >>>>> >>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>> # >>>>> # Internal Error (heap.cpp:248), pid=27586, tid=27587 >>>>> # guarantee((char*) b >= _memory.low_boundary() && (char*) b < >>>>> _memory.high()) failed: The block to be deallocated 0x00007fffe6666f80 >>>>> is not within the heap starting with 0x00007fffe6667000 and ending >>>>> with 0x00007fffe6ba000 >>>>> >>>>> The problem is that JDK-8183573 replaced >>>>> >>>>> virtual bool contains_blob(const CodeBlob* blob) const { return >>>>> low_boundary() <= (char*) blob && (char*) blob < high(); } >>>>> >>>>> by: >>>>> >>>>> bool contains_blob(const CodeBlob* blob) const { return >>>>> contains(blob->code_begin()); } >>>>> >>>>> But that my be wrong in the corner case where the size of the >>>>> CodeBlob's payload is zero (i.e. the CodeBlob consists only of the >>>>> 'header' - i.e. the C++ object itself) because in that case >>>>> CodeBlob::code_begin() points right behind the CodeBlob's header which >>>>> is a memory location which doesn't belong to the CodeBlob anymore. >>>>> >>>>> This exact corner case is exercised by ReturnBlobToWrongHeapTest which >>>>> allocates CodeBlobs of size zero (i.e. zero 'payload') with the help >>>>> of sun.hotspot.WhiteBox.allocateCodeBlob() until the CodeCache fills >>>>> up. The test first fills the 'non-profiled nmethods' CodeHeap. If the >>>>> 'non-profiled nmethods' CodeHeap is full, the VM automatically tries >>>>> to allocate from the 'profiled nmethods' CodeHeap until that fills up >>>>> as well. But in the CodeCache the 'profiled nmethods' CodeHeap is >>>>> located right before the non-profiled nmethods' CodeHeap. So if the >>>>> last CodeBlob allocated from the 'profiled nmethods' CodeHeap has a >>>>> payload size of zero and uses all the CodeHeaps remaining size, we >>>>> will end up with a CodeBlob whose code_begin() address will point >>>>> right behind the actual CodeHeap (i.e. it will point right at the >>>>> beginning of the adjacent, 'non-profiled nmethods' CodeHeap). This >>>>> will result in the above guarantee to fire, when we will try to free >>>>> the last allocated CodeBlob (with >>>>> sun.hotspot.WhiteBox.freeCodeBlob()). >>>>> >>>>> In a previous mail thread >>>>> >>>>> >>>>> (http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-August/028175.html) >>>>> Vladimir explained why JDK-8183573 was done: >>>>> >>>>>> About contains_blob(). The problem is that AOTCompiledMethod allocated >>>>>> in >>>>>> CHeap and not in aot code section (which is RO): >>>>>> >>>>>> >>>>>> >>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/8acd232fb52a/src/share/vm/aot/aotCompiledMethod.hpp#l124 >>>>>> >>>>>> It is allocated in CHeap after AOT library is loaded. Its code_begin() >>>>>> points to AOT code section but AOTCompiledMethod* >>>>>> points outside it (to normal malloced space) so you can't use >>>>>> (char*)blob >>>>>> address. >>>>> >>>>> >>>>> >>>>> and proposed these two fixes: >>>>> >>>>>> There are 2 ways to fix it, I think. >>>>>> One is to add new field to CodeBlobLayout and set it to blob* address >>>>>> for >>>>>> normal CodeCache blobs and to code_begin for >>>>>> AOT code. >>>>>> Second is to use contains(blob->code_end() - 1) assuming that AOT code >>>>>> is >>>>>> never zero. >>>>> >>>>> >>>>> >>>>> I came up with a slightly different solution - just use >>>>> 'CodeHeap::code_blob_type()' whether to use 'blob->code_begin()' (for >>>>> the AOT case) or '(void*)blob' (for all other blobs) as input for the >>>>> call to 'CodeHeap::contain()'. It's simple and still much cheaper than >>>>> a virtual call. What do you think? >>>>> >>>>> I've also updated the documentation of the CodeBlob class hierarchy in >>>>> codeBlob.hpp. Please let me know if I've missed something. >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> >>>> >> From coleen.phillimore at oracle.com Wed Nov 1 18:09:58 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 1 Nov 2017 14:09:58 -0400 Subject: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot In-Reply-To: <0b049cc8-b3dc-cdfb-d71a-3e43274a1b9a@oracle.com> References: <8671321f-398c-5f7f-634d-9d9664e04d87@oracle.com> <05bf853a-52f8-c450-4171-89f6b64d793a@oracle.com> <72f2aac7-ed20-c995-913b-ee4341a2a978@oracle.com> <55ec3559-c593-bcb6-51b0-4639da126068@oracle.com> <4509dce7-10f8-4558-2adb-90d4745e054e@oracle.com> <396ab0f7-3710-3f76-675a-5108bcb50af5@oracle.com> <51f09db9-06f5-ad01-bc92-1d73e1113f86@oracle.com> <66b590da-f94c-6d87-cf61-e269bf1afc0d@oracle.com> <0b049cc8-b3dc-cdfb-d71a-3e43274a1b9a@oracle.com> Message-ID: On 11/1/17 12:51 PM, Daniel D. Daugherty wrote: > Just one comment about the location of "jvm.h". > > > On 10/30/17 8:07 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 10/28/17 3:46 AM, David Holmes wrote: >>> On 28/10/2017 3:47 AM, mandy chung wrote: >>>> On 10/27/17 7:08 AM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 10/27/17 9:37 AM, David Holmes wrote: >>>>>> >>>>>> The one file that is needed is a hotspot file - jvm.h defines the >>>>>> interface that hotspot exports via jvm.cpp. >>>>>> >>>>>> If you leave jvm.h in hotspot/prims then a very large chunk of >>>>>> your boilerplate changes are not needed. The JDK code doesn't >>>>>> care what the name of the directory is - whatever it is just gets >>>>>> added as a -I directive (the JDK code will include "jvm.h" not >>>>>> "prims/jvm.h" the way hotspot sources do. >>>>>> >>>>>> This isn't something we want to change back or move again later. >>>>>> Whatever we do now we live with. >>>>> >>>>> I think it belongs with jni.h and I think the core libraries group >>>>> would agree.?? It seems more natural there than buried in the >>>>> hotspot prims directory.? I guess this is on hold while we have >>>>> this debate.?? Sigh. >>>>> >>>>> Actually with -I directives, changing to jvm.h from prims/jvm.h >>>>> would still work.?? Maybe we should change the name to jvm.hpp >>>>> since it's jvm.cpp though??? Or maybe just have two divergent >>>>> copies and close this as WNF. >>>> >>>> I also think hotspot/prims is not a good location. >>>> src/java.base/share/include is a well-defined location for native >>>> header files.? Maybe internal header files could be placed in >>>> include/internal but this is a separate issue .? I should create an >>>> issue for jvm.h and jmm.h (I looked at the files under the include >>>> directory and jvm.h and jmm.h are the only two internal header >>>> files in the include directory). >>> >>> Keeping it in prims avoids the need to touch many hotspot files, and >>> with no changes needed on the JDK side because we use a -I directive >>> to set the include path anyway. This is the exported VM interface so >>> it makes sense to me for it to be located in the VM sources. >>> >>> But I'm not going to oppose this either way so it's up to Coleen. >> >> I've already disagreed that this file belongs in >> src/hotspot/share/prims, so the include directive without prims is >> preferred.? This allows putting jvm.h in a new place if/when that is >> agreed upon. > > The jvm.h file describes the internal JVM_* API implemented by > prims/jvm.cpp. > Because this is an internal interface, the jvm.h file would > traditionally be > co-located with the implementation (jvm.cpp) (and not in an include > directory). > > So I disagree with the proposal to move jvm.h and believe the single copy > should be in prims/jvm.h. So, we have a variety of opinions.?? Please open another ticket to discuss this. thanks, Coleen > > Dan > > >>> >>>> I do think removing the duplicated copy of jvm.h is a good change. >>>> This is finally possible with the consolidated repository and we no >>>> longer need to update two copies of jvm.h for any change to the JVM >>> >>> Unfortunately we did not do this though - hence the divergence >>> between the two. The use of int versus long for jint is causing a >>> real problem. >>> >>> Coleen also hit the other issue on the head. The JNI and JVM >>> interfaces are C interfaces, not C++. The JDK code that uses them is >>> compiled as C - so all good. But the JVM code that implements them >>> is compiled as C++, and that is why we are getting issues with >>> differing linkage directives. >> >> Well, there is now one source file for jvm.h and jni.h and their >> machine dependent counterparts and 2500 lines of duplicated code is >> removed with this change.? The issues with jint and linkages are >> resolved and tested as well with this changeset. >> >> Thanks, >> Coleen >>> >>> David >>> ----- >>> >>>> interface.?? This change will work with -I directive setting to the >>>> new location, if changed later. >>>> >>>> What do you think? >>>> >>>> Mandy >> > From daniel.daugherty at oracle.com Wed Nov 1 18:34:25 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 1 Nov 2017 14:34:25 -0400 Subject: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot In-Reply-To: References: <8671321f-398c-5f7f-634d-9d9664e04d87@oracle.com> <05bf853a-52f8-c450-4171-89f6b64d793a@oracle.com> <72f2aac7-ed20-c995-913b-ee4341a2a978@oracle.com> <55ec3559-c593-bcb6-51b0-4639da126068@oracle.com> <4509dce7-10f8-4558-2adb-90d4745e054e@oracle.com> <396ab0f7-3710-3f76-675a-5108bcb50af5@oracle.com> <51f09db9-06f5-ad01-bc92-1d73e1113f86@oracle.com> <66b590da-f94c-6d87-cf61-e269bf1afc0d@oracle.com> <0b049cc8-b3dc-cdfb-d71a-3e43274a1b9a@oracle.com> Message-ID: > So, we have a variety of opinions.?? Please open another ticket to > discuss this. Sorry, I didn't realize that this fix pushed yesterday. I'm not completely caught up on all of the email. It's not worth another bug report (and more changes). Dan On 11/1/17 2:09 PM, coleen.phillimore at oracle.com wrote: > > > On 11/1/17 12:51 PM, Daniel D. Daugherty wrote: >> Just one comment about the location of "jvm.h". >> >> >> On 10/30/17 8:07 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 10/28/17 3:46 AM, David Holmes wrote: >>>> On 28/10/2017 3:47 AM, mandy chung wrote: >>>>> On 10/27/17 7:08 AM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> >>>>>> On 10/27/17 9:37 AM, David Holmes wrote: >>>>>>> >>>>>>> The one file that is needed is a hotspot file - jvm.h defines >>>>>>> the interface that hotspot exports via jvm.cpp. >>>>>>> >>>>>>> If you leave jvm.h in hotspot/prims then a very large chunk of >>>>>>> your boilerplate changes are not needed. The JDK code doesn't >>>>>>> care what the name of the directory is - whatever it is just >>>>>>> gets added as a -I directive (the JDK code will include "jvm.h" >>>>>>> not "prims/jvm.h" the way hotspot sources do. >>>>>>> >>>>>>> This isn't something we want to change back or move again later. >>>>>>> Whatever we do now we live with. >>>>>> >>>>>> I think it belongs with jni.h and I think the core libraries >>>>>> group would agree.?? It seems more natural there than buried in >>>>>> the hotspot prims directory.? I guess this is on hold while we >>>>>> have this debate.?? Sigh. >>>>>> >>>>>> Actually with -I directives, changing to jvm.h from prims/jvm.h >>>>>> would still work.?? Maybe we should change the name to jvm.hpp >>>>>> since it's jvm.cpp though??? Or maybe just have two divergent >>>>>> copies and close this as WNF. >>>>> >>>>> I also think hotspot/prims is not a good location. >>>>> src/java.base/share/include is a well-defined location for native >>>>> header files.? Maybe internal header files could be placed in >>>>> include/internal but this is a separate issue . I should create an >>>>> issue for jvm.h and jmm.h (I looked at the files under the include >>>>> directory and jvm.h and jmm.h are the only two internal header >>>>> files in the include directory). >>>> >>>> Keeping it in prims avoids the need to touch many hotspot files, >>>> and with no changes needed on the JDK side because we use a -I >>>> directive to set the include path anyway. This is the exported VM >>>> interface so it makes sense to me for it to be located in the VM >>>> sources. >>>> >>>> But I'm not going to oppose this either way so it's up to Coleen. >>> >>> I've already disagreed that this file belongs in >>> src/hotspot/share/prims, so the include directive without prims is >>> preferred.? This allows putting jvm.h in a new place if/when that is >>> agreed upon. >> >> The jvm.h file describes the internal JVM_* API implemented by >> prims/jvm.cpp. >> Because this is an internal interface, the jvm.h file would >> traditionally be >> co-located with the implementation (jvm.cpp) (and not in an include >> directory). >> >> So I disagree with the proposal to move jvm.h and believe the single >> copy >> should be in prims/jvm.h. > > So, we have a variety of opinions.?? Please open another ticket to > discuss this. > thanks, > Coleen >> >> Dan >> >> >>>> >>>>> I do think removing the duplicated copy of jvm.h is a good change. >>>>> This is finally possible with the consolidated repository and we >>>>> no longer need to update two copies of jvm.h for any change to the >>>>> JVM >>>> >>>> Unfortunately we did not do this though - hence the divergence >>>> between the two. The use of int versus long for jint is causing a >>>> real problem. >>>> >>>> Coleen also hit the other issue on the head. The JNI and JVM >>>> interfaces are C interfaces, not C++. The JDK code that uses them >>>> is compiled as C - so all good. But the JVM code that implements >>>> them is compiled as C++, and that is why we are getting issues with >>>> differing linkage directives. >>> >>> Well, there is now one source file for jvm.h and jni.h and their >>> machine dependent counterparts and 2500 lines of duplicated code is >>> removed with this change.? The issues with jint and linkages are >>> resolved and tested as well with this changeset. >>> >>> Thanks, >>> Coleen >>>> >>>> David >>>> ----- >>>> >>>>> interface.?? This change will work with -I directive setting to >>>>> the new location, if changed later. >>>>> >>>>> What do you think? >>>>> >>>>> Mandy >>> >> > > From mandy.chung at oracle.com Wed Nov 1 18:41:08 2017 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 1 Nov 2017 11:41:08 -0700 Subject: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot In-Reply-To: References: <8671321f-398c-5f7f-634d-9d9664e04d87@oracle.com> <05bf853a-52f8-c450-4171-89f6b64d793a@oracle.com> <72f2aac7-ed20-c995-913b-ee4341a2a978@oracle.com> <55ec3559-c593-bcb6-51b0-4639da126068@oracle.com> <4509dce7-10f8-4558-2adb-90d4745e054e@oracle.com> <396ab0f7-3710-3f76-675a-5108bcb50af5@oracle.com> <51f09db9-06f5-ad01-bc92-1d73e1113f86@oracle.com> <66b590da-f94c-6d87-cf61-e269bf1afc0d@oracle.com> <0b049cc8-b3dc-cdfb-d71a-3e43274a1b9a@oracle.com> Message-ID: On 11/1/17 11:09 AM, coleen.phillimore at oracle.com wrote: > > So, we have a variety of opinions.?? Please open another ticket to > discuss this. https://bugs.openjdk.java.net/browse/JDK-8190484 Mandy From coleen.phillimore at oracle.com Wed Nov 1 18:51:42 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 1 Nov 2017 14:51:42 -0400 Subject: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot In-Reply-To: References: <8671321f-398c-5f7f-634d-9d9664e04d87@oracle.com> <05bf853a-52f8-c450-4171-89f6b64d793a@oracle.com> <72f2aac7-ed20-c995-913b-ee4341a2a978@oracle.com> <55ec3559-c593-bcb6-51b0-4639da126068@oracle.com> <4509dce7-10f8-4558-2adb-90d4745e054e@oracle.com> <396ab0f7-3710-3f76-675a-5108bcb50af5@oracle.com> <51f09db9-06f5-ad01-bc92-1d73e1113f86@oracle.com> <66b590da-f94c-6d87-cf61-e269bf1afc0d@oracle.com> <0b049cc8-b3dc-cdfb-d71a-3e43274a1b9a@oracle.com> Message-ID: <35a4976e-7133-244e-a73b-4eab93f4f788@oracle.com> On 11/1/17 2:41 PM, mandy chung wrote: > > > On 11/1/17 11:09 AM, coleen.phillimore at oracle.com wrote: >> >> So, we have a variety of opinions.?? Please open another ticket to >> discuss this. > > https://bugs.openjdk.java.net/browse/JDK-8190484 > > Mandy Thanks Mandy!? There were arguments for and against these locations, and some alternate suggestions.? The way the sources are, they can be moved.? It may be a build system change to get the include directives correct for the _md.h files. I think the discussion should carry forward in the bug report so that the resulting code change matches what people have decided. thanks, Coleen From volker.simonis at gmail.com Wed Nov 1 22:16:03 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 1 Nov 2017 15:16:03 -0700 Subject: RFR(S): 8187091: ReturnBlobToWrongHeapTest fails because of problems in CodeHeap::contains_blob() In-Reply-To: <8b12d73e-d3e5-da3b-9941-c59516e0134c@oracle.com> References: <8b12d73e-d3e5-da3b-9941-c59516e0134c@oracle.com> Message-ID: Thanks Vladimir! On Wed, Nov 1, 2017 at 10:12 AM, Vladimir Kozlov wrote: > I submitted pre-integration testing. Will push after that. > > Vladimir > > > On 10/30/17 12:34 PM, Volker Simonis wrote: >> >> Hi Vladimir, >> >> this one is still pending (you only pushed "8166317: >> InterpreterCodeSize should be computed"). >> >> Could you please also sponsor this one? >> >> The latest version is here: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2017/8187091.v2/ >> >> Thank you and best regards, >> Volker >> >> On Tue, Sep 5, 2017 at 6:35 PM, Vladimir Kozlov >> wrote: >>> >>> On 9/4/17 10:23 AM, Volker Simonis wrote: >>>> >>>> >>>> On Fri, Sep 1, 2017 at 6:00 PM, Vladimir Kozlov >>>> wrote: >>>>> >>>>> >>>>> Checking type is emulation of virtual call ;-) >>>> >>>> >>>> >>>> I agree :) But it is only a bimorphic dispatch in this case which >>>> should be still faster than a normal virtual call. >>>> >>>>> But I agree that it is simplest solution - one line change (excluding >>>>> comment - comment is good BTW). >>>>> >>>> >>>> Thanks. >>>> >>>>> You can also add guard AOT_ONLY() around aot specific code: >>>>> >>>>> const void* start = AOT_ONLY( (code_blob_type() == >>>>> CodeBlobType::AOT) >>>>> ? >>>>> blob->code_begin() : ) (void*)blob; >>>>> >>>>> because we do have builds without AOT. >>>>> >>>> >>>> Done. Please find the new webrev here: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8187091.v1/ >>> >>> >>> >>> Looks good. Thank you for updated CodeBlob description comment. >>> >>>> >>>> Could you please sponsor the change once jdk10-hs opens again? >>> >>> >>> >>> We have to wait when jdk10 "consolidation" is finished. It may take 2 >>> weeks. >>> >>>> >>>> Thanks, >>>> Volker >>>> >>>> PS: one thing which is still unclear to me is why you haven't caught >>>> this issue before? Isn't >>>> test/compiler/codecache/stress/ReturnBlobToWrongHeapTest.java part of >>>> JPRT and/or your regular tests? >>> >>> >>> >>> test/compiler/codecache/stress are excluded from JPRT runs: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8069021 >>> >>> Also these tests are marked with @key stress. Originally it was only 2 >>> tests >>> and ReturnBlobToWrongHeapTest.java was added later: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8069021 >>> >>> I am trying to find which testing tier runs them. I will follow this. >>> >>> Thanks, >>> Vladimir >>> >>> >>>> >>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> >>>>> On 9/1/17 8:42 AM, Volker Simonis wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> can I please have a review and sponsor for the following small fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8187091/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8187091 >>>>>> >>>>>> We see failures in >>>>>> test/compiler/codecache/stress/ReturnBlobToWrongHeapTest.java which >>>>>> are cause by problems in CodeHeap::contains_blob() for corner cases >>>>>> with CodeBlobs of zero size: >>>>>> >>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>> # >>>>>> # Internal Error (heap.cpp:248), pid=27586, tid=27587 >>>>>> # guarantee((char*) b >= _memory.low_boundary() && (char*) b < >>>>>> _memory.high()) failed: The block to be deallocated 0x00007fffe6666f80 >>>>>> is not within the heap starting with 0x00007fffe6667000 and ending >>>>>> with 0x00007fffe6ba000 >>>>>> >>>>>> The problem is that JDK-8183573 replaced >>>>>> >>>>>> virtual bool contains_blob(const CodeBlob* blob) const { return >>>>>> low_boundary() <= (char*) blob && (char*) blob < high(); } >>>>>> >>>>>> by: >>>>>> >>>>>> bool contains_blob(const CodeBlob* blob) const { return >>>>>> contains(blob->code_begin()); } >>>>>> >>>>>> But that my be wrong in the corner case where the size of the >>>>>> CodeBlob's payload is zero (i.e. the CodeBlob consists only of the >>>>>> 'header' - i.e. the C++ object itself) because in that case >>>>>> CodeBlob::code_begin() points right behind the CodeBlob's header which >>>>>> is a memory location which doesn't belong to the CodeBlob anymore. >>>>>> >>>>>> This exact corner case is exercised by ReturnBlobToWrongHeapTest which >>>>>> allocates CodeBlobs of size zero (i.e. zero 'payload') with the help >>>>>> of sun.hotspot.WhiteBox.allocateCodeBlob() until the CodeCache fills >>>>>> up. The test first fills the 'non-profiled nmethods' CodeHeap. If the >>>>>> 'non-profiled nmethods' CodeHeap is full, the VM automatically tries >>>>>> to allocate from the 'profiled nmethods' CodeHeap until that fills up >>>>>> as well. But in the CodeCache the 'profiled nmethods' CodeHeap is >>>>>> located right before the non-profiled nmethods' CodeHeap. So if the >>>>>> last CodeBlob allocated from the 'profiled nmethods' CodeHeap has a >>>>>> payload size of zero and uses all the CodeHeaps remaining size, we >>>>>> will end up with a CodeBlob whose code_begin() address will point >>>>>> right behind the actual CodeHeap (i.e. it will point right at the >>>>>> beginning of the adjacent, 'non-profiled nmethods' CodeHeap). This >>>>>> will result in the above guarantee to fire, when we will try to free >>>>>> the last allocated CodeBlob (with >>>>>> sun.hotspot.WhiteBox.freeCodeBlob()). >>>>>> >>>>>> In a previous mail thread >>>>>> >>>>>> >>>>>> >>>>>> (http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-August/028175.html) >>>>>> Vladimir explained why JDK-8183573 was done: >>>>>> >>>>>>> About contains_blob(). The problem is that AOTCompiledMethod >>>>>>> allocated >>>>>>> in >>>>>>> CHeap and not in aot code section (which is RO): >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/8acd232fb52a/src/share/vm/aot/aotCompiledMethod.hpp#l124 >>>>>>> >>>>>>> It is allocated in CHeap after AOT library is loaded. Its >>>>>>> code_begin() >>>>>>> points to AOT code section but AOTCompiledMethod* >>>>>>> points outside it (to normal malloced space) so you can't use >>>>>>> (char*)blob >>>>>>> address. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> and proposed these two fixes: >>>>>> >>>>>>> There are 2 ways to fix it, I think. >>>>>>> One is to add new field to CodeBlobLayout and set it to blob* address >>>>>>> for >>>>>>> normal CodeCache blobs and to code_begin for >>>>>>> AOT code. >>>>>>> Second is to use contains(blob->code_end() - 1) assuming that AOT >>>>>>> code >>>>>>> is >>>>>>> never zero. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I came up with a slightly different solution - just use >>>>>> 'CodeHeap::code_blob_type()' whether to use 'blob->code_begin()' (for >>>>>> the AOT case) or '(void*)blob' (for all other blobs) as input for the >>>>>> call to 'CodeHeap::contain()'. It's simple and still much cheaper than >>>>>> a virtual call. What do you think? >>>>>> >>>>>> I've also updated the documentation of the CodeBlob class hierarchy in >>>>>> codeBlob.hpp. Please let me know if I've missed something. >>>>>> >>>>>> Thank you and best regards, >>>>>> Volker >>>>>> >>>>> >>> > From jini.george at oracle.com Thu Nov 2 04:54:03 2017 From: jini.george at oracle.com (Jini George) Date: Thu, 2 Nov 2017 10:24:03 +0530 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the changes >>>> are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> From tobias.hartmann at oracle.com Thu Nov 2 08:31:33 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 2 Nov 2017 09:31:33 +0100 Subject: RFR: 8190415: [JVMCI] JVMCIRuntime::adjust_comp_level must not swallow ThreadDeath In-Reply-To: References: Message-ID: <3ec0130b-af82-269f-418c-39d2c90e7afd@oracle.com> Hi Doug, this looks good to me. Best regards, Tobias On 31.10.2017 14:05, Doug Simon wrote: > Please review this change that fixes a JVMCI code path that was swallowing ThreadDeath exceptions and thus preventing Thread.stop from working as intended. > The webrev also contains some minor unrelated cleanup to mx_jvmci.py needed for supporting the consolidated repo. > > The internal test that caught this problem is now passing. > > https://bugs.openjdk.java.net/browse/JDK-8190415 > http://cr.openjdk.java.net/~dnsimon/8190415/ > > -Doug > From jini.george at oracle.com Thu Nov 2 04:54:03 2017 From: jini.george at oracle.com (Jini George) Date: Thu, 2 Nov 2017 10:24:03 +0530 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the changes >>>> are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoAqbJ+Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAGcrAAB2AAAABQBkAA8ABAAAAEVkZ2U= X-Source: SMTP:External Receive Connector X-SourceIPAddress: 195.190.135.10 X-EndOfInjectedXHeaders: 7733 Received: from mx.expurgate.net (195.190.135.10) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 05:54:39 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA7WZ-000EZw-D4 for axel.siebenborn at sap.com; Thu, 02 Nov 2017 05:54:39 +0100 Received: from [156.151.31.69] (helo=ucsinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.2.1-3) (envelope-from ) id 59faa50b-7c01-c0a8033409dd-9c971f454783-3 for ; Thu, 02 Nov 2017 05:54:38 +0100 Received: from aojmv0009 (unknown [137.254.59.6]) by ucsinet41.oracle.com with smtp id 4eb7_00c7_3ecf1c93_28fd_4a9f_97f0_f31de9ddb295; Thu, 02 Nov 2017 04:54:17 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 15A99229CEC; Thu, 2 Nov 2017 04:57:26 +0000 (UTC) X-Original-To: serviceability-dev at openjdk.java.net Delivered-To: serviceability-dev at openjdk.java.net Received: from ucsinet40.oracle.com (ucsinet40.oracle.com [156.151.31.68]) by aojmv0009 (Postfix) with ESMTP id 9CFF6229CC3; Thu, 2 Nov 2017 04:57:20 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by ucsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) id 37c3_8726_79982056_f63b_491d_a8be_57819e8c7dcc; Thu, 02 Nov 2017 04:54:08 +0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA24s8KW028461 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s84O013997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s7KK017107; Thu, 2 Nov 2017 04:54:08 GMT Received: from [10.177.158.142] (/10.177.158.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 21:54:07 -0700 Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 From: Jini George To: "serguei.spitsyn at oracle.com" , "serviceability-dev at openjdk.java.net" , "hotspot-runtime-dev at openjdk.java.net" , References: <18501902-23db-de6c-b83d-640cd33df836 at oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a at oracle.com> Organization: Oracle Corporation Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e at oracle.com> Date: Thu, 2 Nov 2017 10:24:03 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: serviceability-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Technical discussion about the development of serviceability technologies \(debugging, profiling, monitoring, and management\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: serviceability-dev-bounces at openjdk.java.net Sender: serviceability-dev X-purgate-ID: tlsNG-9b91ac/1509598479-00007C01-219CB02A/0/0 X-purgate-type: clean X-purgate-size: 2000 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTU2LjE1MS4zMS42OQBzZXJ2aWNlYWJpbGl0eS1kZXYtYm91bmNlc0BvcGVuamRrLmphdmEubmV0AGF4ZWwuc2llYmVuYm9ybkBzYXAuY29tADgwYzQ2ZTI0N2Q2MTBlYjNiNTQ5MmE5YWE2NzJjNzJjN2NiNjcwNDQ= X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: serviceability-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 04:54:39.6785 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 195.190.135.10 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: 8fba1fcd-01cd-4a67-1ee6-08d521add313 X-MS-Exchange-Organization-OriginalSize: 7400 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV=DEWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE=11997.291|UTH=0.001|RST=11997.244|QS=0.029|CATCM-McAfeeTxRoutingAgent=0.011|CATCM=0.011|CAT=0.012;2017-11-02T08:14:36.969Z Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the changes >>>> are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoAALN+Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAIMrAAB2AAAABQBkAA8ABAAAAEVkZ2U= X-Source: SMTP:External Receive Connector X-SourceIPAddress: 194.145.224.110 X-EndOfInjectedXHeaders: 7704 Received: from mx.expurgate.net (194.145.224.110) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 05:54:46 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA7Wg-0004R0-FP for axel.siebenborn at sap.com; Thu, 02 Nov 2017 05:54:46 +0100 Received: from [141.146.126.229] (helo=acsinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.3.1) (envelope-from ) id 59faa50f-65eb-c0a8029b09dd-8d927ee53db9-3 for ; Thu, 02 Nov 2017 05:54:45 +0100 Received: from aojmv0009 (aojmv0009.oracle.com [137.254.59.6]) by acsinet41.oracle.com with smtp id 6461_15f0_154b24ba_5aa0_408c_88bd_1cdb37c9c8f4; Thu, 02 Nov 2017 04:54:31 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 3B280229CF4; Thu, 2 Nov 2017 04:57:26 +0000 (UTC) X-Original-To: hotspot-runtime-dev at openjdk.java.net Delivered-To: hotspot-runtime-dev at openjdk.java.net Received: from ucsinet40.oracle.com (ucsinet40.oracle.com [156.151.31.68]) by aojmv0009 (Postfix) with ESMTP id 9CFF6229CC3; Thu, 2 Nov 2017 04:57:20 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by ucsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) id 37c3_8726_79982056_f63b_491d_a8be_57819e8c7dcc; Thu, 02 Nov 2017 04:54:08 +0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA24s8KW028461 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s84O013997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s7KK017107; Thu, 2 Nov 2017 04:54:08 GMT Received: from [10.177.158.142] (/10.177.158.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 21:54:07 -0700 Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 From: Jini George To: "serguei.spitsyn at oracle.com" , "serviceability-dev at openjdk.java.net" , "hotspot-runtime-dev at openjdk.java.net" , References: <18501902-23db-de6c-b83d-640cd33df836 at oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a at oracle.com> Organization: Oracle Corporation Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e at oracle.com> Date: Thu, 2 Nov 2017 10:24:03 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: hotspot-runtime-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical discussion about the development of the HotSpot runtime subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hotspot-runtime-dev-bounces at openjdk.java.net Sender: hotspot-runtime-dev X-purgate-ID: tlsNG-81024b/1509598486-000065EB-186BA960/0/0 X-purgate-type: clean X-purgate-size: 2000 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtcnVudGltZS1kZXYtYm91bmNlc0BvcGVuamRrLmphdmEubmV0AGF4ZWwuc2llYmVuYm9ybkBzYXAuY29tADE0ZjI2NjVmYTY4ZGRiOWMwNGJiMGU0MmE2Njk2M2ZiNWQxNzAyOGI= X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: hotspot-runtime-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 04:54:46.7566 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 194.145.224.110 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: 9365fa06-08de-47df-2865-08d521add74b X-MS-Exchange-Organization-OriginalSize: 7380 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV=DEWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE=11990.260|UTH=0.001|RST=11990.260|CATCM-McAfeeTxRoutingAgent=0.004|CATCM=0.005|CAT=0.006;2017-11-02T08:14:37.016Z Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the changes >>>> are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> From coleen.phillimore at oracle.com Thu Nov 2 11:39:11 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 2 Nov 2017 07:39:11 -0400 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Message-ID: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/src/hotspot/share/runtime/stackValue.hpp.udiff.html + return (*(int *)&_integer_value == *(int *)&value->_integer_value); I don't think the *(int*) casts for _integer_value are needed in these files.? Can you remove them? http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/cms/CompactibleFreeListSpace.java.udiff.html I'm not really sure why you still have SA code for CMS, since CMS is deprecated.? What does it do?? Can it be removed in a following cleanup? This cleanup looks good.? And thank you for doing this since I broke SA only yesterday. thanks, Coleen On 11/2/17 12:54 AM, Jini George wrote: > Could I please get one more review done for this ? > > Thanks, > Jini. > > On 10/27/2017 9:19 PM, Jini George wrote: >> Thank you very much, Serguei. >> >> -Jini. >> >> On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Jini, >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/24/17 00:31, Jini George wrote: >>>> Adding hotspot-dev too. >>>> >>>> Thanks, >>>> Jini. >>>> >>>> On 10/24/2017 12:05 PM, Jini George wrote: >>>>> Hello, >>>>> >>>>> As a part of SA next, I am working on writing a test case which >>>>> compares the fields and the types of the fields of the SA java >>>>> classes with the corresponding entries in the vmStructs tables. >>>>> This, to some extent, would help in preventing errors in SA due to >>>>> the changes in hotspot. As a precursor to this, I am in the >>>>> process of making some cleanup related changes (mostly in SA). I >>>>> plan to have the changes done in parts. For this webrev, most of >>>>> the changes are for: >>>>> >>>>> 1. Avoiding having some values being redefined in SA. Instead have >>>>> those exported through vmStructs, and read it in SA. >>>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>>> CompactibleFreeListSpace::IndexSetSize) >>>>> >>>>> Redefinition of hotspot values in SA makes SA error prone, when >>>>> the value gets altered in hotspot and the corresponding >>>>> modification gets missed out in SA. >>>>> >>>>> 2. To remove some unused code (JNIid.java). >>>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>>> 4. Modify variable names in SA and hotspot to match the >>>>> counterpart names, so that the comparison of the fields become >>>>> easier. Most of the changes belong to this group. >>>>> >>>>> Could I please get reviews done for these precursor changes ? >>>>> >>>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>>> >>>>> Thank you, >>>>> Jini. >>>>> >>> From felix.yang at linaro.org Thu Nov 2 14:14:46 2017 From: felix.yang at linaro.org (Felix Yang) Date: Thu, 2 Nov 2017 22:14:46 +0800 Subject: Question regarding "native-compiled frame" In-Reply-To: <148d5325-8c2c-d009-5de9-fd1a9529bab9@oracle.com> References: <6cc77474-c4eb-f1a7-9412-04addfed2811@oracle.com> <148d5325-8c2c-d009-5de9-fd1a9529bab9@oracle.com> Message-ID: Hi, Sorry for the late reply. I missed this email. Unfortunately, I wasn't able to catch a core dump file of the JVM. The hs error log is the same as the one reported on: https://bugs.openjdk.java.net/browse/JDK-8146224 Thanks. Felix On 19 September 2017 at 02:24, Chris Plummer wrote: > On 9/18/17 7:01 AM, Felix Yang wrote: > > Yes, the AArch64 port is doing the same thing as the x86 port. > > I noticed this issue when I was trying to analyze a recent JVM crash issue > which triggers on the x86-64 platform with an official Oracle jdk8u121 > release. > > It turns out that this bug happens very rarely (triggered only once for my > Java workload and I am unable to reproduce it). > > And I think it is the same as: https://bugs.openjdk.java.net/ > browse/JDK-8146224 which is still pending there. > > Looking at the assembly instructions in the hs error log file, I find the > SIGSEGV is triggered by the last return statement of frame::sender > function. > > frame::safe_for_sender() is suppose to prevent us from stepping into a > frame that could result in a JVM crash, even if the frame is corrupted. Do > you have any additional debugging info, like a gdb stack trace? > From daniel.daugherty at oracle.com Thu Nov 2 17:13:36 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 2 Nov 2017 13:13:36 -0400 Subject: RFR (S): 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: References: Message-ID: <85a49dcc-fd25-270a-b9a9-46d5c745d7e6@oracle.com> On 10/13/17 12:58 AM, serguei.spitsyn at oracle.com wrote: > Please, review a fix for: > https://bugs.openjdk.java.net/browse/JDK-8187289 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.1/ > > > Summary: > ? The issue is that the FRAME_POP event request is not cleaned if the > requested > ? method frame is popped but the notification mode is temporarily > disabled. > ? If later the notification mode is enabled again then it will post a > FRAME_POP > event on the first return from an arbitrary method with the same frame > depth. > ? Notification mode for JVMTI_EVENT_FRAME_POP events is checked in the > JvmtiExport::post_method_exit() under the condition: > ????? if (state->is_enabled(JVMTI_EVENT_FRAME_POP)) { > ? Just removing this condition would likely to introduce a performance > regression > ? in interpreted mode. To mitigate it the fix introduces new > JVMTI_SUPPORT_FLAG > ? can_generate_frame_pop_events that is is checked instead of the > notification mode. > ? Also, it is necessary to to keep the > state->is_interp_only_mode()turned on > ? while the JvmtiEnvThreadState has any FRAME_POP requests registered. > > ? One alternate approach to this fix is to leave the current behavior > as it is > ? but update the JVMTI spec with some clarification about this behavior. > > Testing: > ? Verified with new unit test serviceability/jvmti/NotifyFramePop. > ? Also ran the nsk.jvmti, nsk.jdi and jtreg jdk_jdi tests to make sure > there is no regression. > > Thanks, > Serguei First, I'm going to take a step back and look at the JVM/TI programming model for NotifyFramePop() and JVMTI_EVENT_FRAME_POP events. Here's the relevant JVM/TI spec links: https://docs.oracle.com/javase/9/docs/specs/jvmti.html#NotifyFramePop https://docs.oracle.com/javase/9/docs/specs/jvmti.html#FramePop ??? NotifyFramePop() is used by agent code to register interest in ??? when a target thread leaves a Java frame at a specific depth. ??? The target thread can be NULL which means that the current thread ??? is registering interest in itself. The frame is specified by a ??? 'depth' parameter so the agent is not expressing an interest in a ??? specific named function. Also note that NotifyFramePop() can only ??? register interest in Java frames. ??? The agent code must also enable the JVMTI_EVENT_FRAME_POP event in ??? order for the FRAME_POP event to be delivered to the agent's event ??? handler. There is no requirement to enable the FRAME_POP event before ??? calling NotifyFramePop(). Nor is there any requirement for clearing ??? existing frame interest entries when the FRAME_POP event is disabled. ??? If we have target thread call stack that looks like this: ??????? call_depth_0() ??????? call_depth_1() ??????? call_depth_2() ??????? agent_code() ??? The agent_code(), operating on the current thread, calls: ??????? callbacks.FramePop = frame_pop_callback; ??????? SetEventCallbacks(callbacks, size_of_callbacks); ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, NULL); ??????? NotifyFramePop(NULL, 1); ??? or it calls: ??????? callbacks.FramePop = frame_pop_callback; ??????? SetEventCallbacks(callbacks, size_of_callbacks); ??????? NotifyFramePop(NULL, 1); ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, NULL); ??? and in either case, we expect a FRAME_POP event to be posted when the ??? target thread returns from call_depth_1() to call_depth_0(). The ??? FRAME_POP event is typically disabled in the FRAME_POP event handler ??? function (frame_pop_callback) that is called when the FRAME_POP event ??? is posted. ??? Because disabling FRAME_POP is not specified to clear interest in a ??? frame, if the agent_code(), operating on the current thread, calls: ??????? callbacks.FramePop = frame_pop_callback; ??????? SetEventCallbacks(callbacks, size_of_callbacks); ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, NULL); ??????? NotifyFramePop(NULL, 1); ??????? SetEventNotificationMode(JVMTI_DISABLE, JVMTI_EVENT_FRAME_POP, NULL); ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, NULL); ??? then we expect a FRAME_POP event to be posted when the target thread ??? returns from call_depth_1 to call_depth_0 (and the frame_pop_callback() ??? event handler is called). Okay so I think that covers the general programming model and includes a scenario that shows why we can't clear interest in a frame when the FRAME_POP event is disabled. So we have this NotifyFramePop() function that registers interest in when a target thread leaves a Java frame at a specific depth. We don't have a ClearFramePop() or UnNotifyFramePop() function so the expected way to clear an existing frame interest entry is to do so when we leave that frame. So the current behavior where we can return from call_depth_1() to call_depth_0() without clearing the existing frame interest entry is a bug. Okay so I'm now caught up with this thread and I agree that we have a bug. Definitely a corner case, but a bug none the less. So far I don't see a reason to change any spec wording so let's look at the webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.1/ src/hotspot/share/prims/jvmtiExport.hpp ??? I'm wondering why the existing can_post_interpreter_events() can't ??? cover the case for us since we need to stay in interpreted mode. ??? Update: The existing can_post_interpreter_events() could be used ??? but the new can_generate_frame_pop_events() is more specific. I'm ??? okay with it. src/hotspot/share/prims/jvmtiExport.cpp ??? I agree that JvmtiExport::post_method_exit() needs to check a ??? condition other than "is_enabled(JVMTI_EVENT_FRAME_POP)", but ??? should it be can_generate_frame_pop_events() or should it be ??? can_post_interpreter_events()? ??? Update: The existing can_post_interpreter_events() could be used ??? but the new can_generate_frame_pop_events() is more specific. I'm ??? okay with it. src/hotspot/share/prims/jvmtiEventController.cpp ??? L513: ??? // This iteration will include JvmtiEnvThreadStates whoses environments ??????? Not yours, but could you please fix it? ??????? Typo: 'whoses' -> 'whose' ??? L523-542 - Perhaps we should refactor the code as: ? ? 523?? if (any_env_enabled != was_any_env_enabled) { ? ? 524???? // mark if event is truly enabled on this thread in any environment ? ? 525 state->thread_event_enable()->_event_enabled.set_bits(any_env_enabled); ? ? 526 ? ? 527 ??? // update the JavaThread cached value for thread-specific should_post_on_exceptions value ? ? 528 ??? bool should_post_on_exceptions = (any_env_enabled & SHOULD_POST_ON_EXCEPTIONS_BITS) != 0; ? ? 529 state->set_should_post_on_exceptions(should_post_on_exceptions); ? ? 530?? } ? ? 531 ? ? 532 ? // compute interp_only mode ? ? 533 ? bool should_be_interp = (any_env_enabled & INTERP_EVENT_BITS) != 0 || has_frame_pops; ? ? 534 ? bool is_now_interp = state->is_interp_only_mode(); ? ? 535?? if (should_be_interp != is_now_interp) { ? ? 536 ??? if (should_be_interp) { ? ? 537 ????? enter_interp_only_mode(state); ? ? 538 ??? } else { ? ? 539 ????? leave_interp_only_mode(state); ? ? 540 ??? } ? ? 541 ? } ??? My reasoning is that new L525 and L529 should only be called when ??? this is true: (any_env_enabled != was_any_env_enabled). We always ??? have to check for a change in interp_only mode because the new ??? has_frame_pops condition is independent of the ??? (any_env_enabled != was_any_env_enabled) check so we might as well ??? make that really clear. src/hotspot/share/prims/jvmtiManageCapabilities.cpp ??? Needs copyright year update. make/test/JtregNativeHotspot.gmk ??? No comments. test/hotspot/jtreg/serviceability/jvmti/NotifyFramePop/NotifyFramePopTest.java ??? L69: ??????? notifyFramePop(null); ??????? Please add comment above L69: ????????? // Ask for notification when we leave frame 1 (meth01). ??? L70:???????? setFramePopNotificationMode(false); ??????? Please add comment above L70: ????????? // Disabling FRAME_POP event notification should not ????????? // prevent the notification for frame 1 from being cleared ????????? // when we return from meth01. ??? L75: ??????? setFramePopNotificationMode(true); ??????? Please add comment above L75: ????????? // Enabling FRAME_POP event notification here should ????????? // not result in a FRAME_POP event when we return from ????????? // frame 1 (meth02) because we did not ask for a ????????? // notification when we leave frame 1 in the context of ????????? // this method (meth02). ??????? to replace this comment: ????????? L76: ??????? // We expect no FramePop event on the meth02() exit as the ????????? L77: ??????? // request from meth01() had to be clear at its exit. ??????? If you like my new comment. :-) test/hotspot/jtreg/serviceability/jvmti/NotifyFramePop/libNotifyFramePopTest.c ??? L73: ??????? jmethodID method, jboolean wasPopedByException) { ??????? Typo: 'wasPopedByException' -> 'wasPoppedByException' ??? L80: ??? result = FAILED; // This event is not expect ??????? Typo: 'expect' -> 'expected' ??? L101: jint? Agent_Initialize(JavaVM *jvm, char *options, void *reserved) { ??????? Extra space between 'jint' and function name. ??? L150: ??????? if (err != JVMTI_ERROR_NONE) { ??? L151: ??????????? printf("Failed to set notification mode for FRAME_POP events: %s (%d)\n", ??? L152: ?????????????????? TranslateError(err), err); ??????? This error message should also report the 'mode' we're ??????? trying to set for complete context. From tom.rodriguez at oracle.com Thu Nov 2 17:41:11 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 02 Nov 2017 10:41:11 -0700 Subject: RFR: 8190415: [JVMCI] JVMCIRuntime::adjust_comp_level must not swallow ThreadDeath In-Reply-To: References: Message-ID: <59FB58B7.8050808@oracle.com> Looks good. tom Doug Simon wrote: > Please review this change that fixes a JVMCI code path that was swallowing ThreadDeath exceptions and thus preventing Thread.stop from working as intended. > The webrev also contains some minor unrelated cleanup to mx_jvmci.py needed for supporting the consolidated repo. > > The internal test that caught this problem is now passing. > > https://bugs.openjdk.java.net/browse/JDK-8190415 > http://cr.openjdk.java.net/~dnsimon/8190415/ > > -Doug From rohitarulraj at gmail.com Fri Nov 3 03:30:41 2017 From: rohitarulraj at gmail.com (Rohit Arul Raj) Date: Fri, 3 Nov 2017 09:00:41 +0530 Subject: RFR: Newer AMD 17h (EPYC) Processor family defaults In-Reply-To: References: <4d4fe028-ea6a-4f77-ab69-5c2bc752e1f5@oracle.com> <47bc0a90-ed6a-220a-c3d1-b4df2d8bbc74@oracle.com> <9c53f889-e58e-33ac-3c05-874779b469d6@oracle.com> <45619e1a-9eb0-a540-193b-5187da3bf6bc@oracle.com> <66e4af43-c0e2-6d64-b69f-35166150ffa2@oracle.com> <11af0f62-ba6b-d533-d23c-750d2ca012c7@oracle.com> Message-ID: Hello Vladimir, Is there any update on pushing these changes to jdk10? Thanks, Rohit On Fri, Sep 22, 2017 at 1:11 PM, Rohit Arul Raj wrote: > Thanks Vladimir, > > On Wed, Sep 20, 2017 at 10:07 PM, Vladimir Kozlov > wrote: > >> __ cmpl(rax, 0x80000000); // Is cpuid(0x80000001) supported? > >> __ jcc(Assembler::belowEqual, done); > >> __ cmpl(rax, 0x80000004); // Is cpuid(0x80000005) supported? > >> - __ jccb(Assembler::belowEqual, ext_cpuid1); > >> + __ jcc(Assembler::belowEqual, ext_cpuid1); > > > > > > Good. You may need to increase size of the buffer too (to be safe) to > 1100: > > > > static const int stub_size = 1000; > > > > Please find the updated patch after the requested change. > > diff --git a/src/cpu/x86/vm/vm_version_x86.cpp > b/src/cpu/x86/vm/vm_version_x86.cpp > --- a/src/cpu/x86/vm/vm_version_x86.cpp > +++ b/src/cpu/x86/vm/vm_version_x86.cpp > @@ -46,7 +46,7 @@ > address VM_Version::_cpuinfo_cont_addr = 0; > > static BufferBlob* stub_blob; > -static const int stub_size = 1000; > +static const int stub_size = 1100; > > extern "C" { > typedef void (*get_cpu_info_stub_t)(void*); > @@ -70,7 +70,7 @@ > bool use_evex = FLAG_IS_DEFAULT(UseAVX) || (UseAVX > 2); > > Label detect_486, cpu486, detect_586, std_cpuid1, std_cpuid4; > - Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, > done, wrapup; > + Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, > ext_cpuid8, done, wrapup; > Label legacy_setup, save_restore_except, legacy_save_restore, > start_simd_check; > > StubCodeMark mark(this, "VM_Version", "get_cpu_info_stub"); > @@ -267,14 +267,30 @@ > __ cmpl(rax, 0x80000000); // Is cpuid(0x80000001) supported? > __ jcc(Assembler::belowEqual, done); > __ cmpl(rax, 0x80000004); // Is cpuid(0x80000005) supported? > - __ jccb(Assembler::belowEqual, ext_cpuid1); > + __ jcc(Assembler::belowEqual, ext_cpuid1); > __ cmpl(rax, 0x80000006); // Is cpuid(0x80000007) supported? > __ jccb(Assembler::belowEqual, ext_cpuid5); > __ cmpl(rax, 0x80000007); // Is cpuid(0x80000008) supported? > __ jccb(Assembler::belowEqual, ext_cpuid7); > + __ cmpl(rax, 0x80000008); // Is cpuid(0x80000009 and above) > supported? > + __ jccb(Assembler::belowEqual, ext_cpuid8); > + __ cmpl(rax, 0x8000001E); // Is cpuid(0x8000001E) supported? > + __ jccb(Assembler::below, ext_cpuid8); > + // > + // Extended cpuid(0x8000001E) > + // > + __ movl(rax, 0x8000001E); > + __ cpuid(); > + __ lea(rsi, Address(rbp, in_bytes(VM_Version::ext_ > cpuid1E_offset()))); > + __ movl(Address(rsi, 0), rax); > + __ movl(Address(rsi, 4), rbx); > + __ movl(Address(rsi, 8), rcx); > + __ movl(Address(rsi,12), rdx); > + > // > // Extended cpuid(0x80000008) > // > + __ bind(ext_cpuid8); > __ movl(rax, 0x80000008); > __ cpuid(); > __ lea(rsi, Address(rbp, in_bytes(VM_Version::ext_cpuid8_offset()))); > @@ -1109,11 +1125,27 @@ > } > > #ifdef COMPILER2 > - if (MaxVectorSize > 16) { > - // Limit vectors size to 16 bytes on current AMD cpus. > + if (cpu_family() < 0x17 && MaxVectorSize > 16) { > + // Limit vectors size to 16 bytes on AMD cpus < 17h. > FLAG_SET_DEFAULT(MaxVectorSize, 16); > } > #endif // COMPILER2 > + > + // Some defaults for AMD family 17h > + if ( cpu_family() == 0x17 ) { > + // On family 17h processors use XMM and UnalignedLoadStores for > Array Copy > + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); > + } > + if (supports_sse2() && FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { > + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); > + } > +#ifdef COMPILER2 > + if (supports_sse4_2() && FLAG_IS_DEFAULT(UseFPUForSpilling)) { > + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > + } > +#endif > + } > } > > if( is_intel() ) { // Intel cpus specific settings > diff --git a/src/cpu/x86/vm/vm_version_x86.hpp > b/src/cpu/x86/vm/vm_version_x86.hpp > --- a/src/cpu/x86/vm/vm_version_x86.hpp > +++ b/src/cpu/x86/vm/vm_version_x86.hpp > @@ -228,6 +228,15 @@ > } bits; > }; > > + union ExtCpuid1EEbx { > + uint32_t value; > + struct { > + uint32_t : 8, > + threads_per_core : 8, > + : 16; > + } bits; > + }; > + > union XemXcr0Eax { > uint32_t value; > struct { > @@ -398,6 +407,12 @@ > ExtCpuid8Ecx ext_cpuid8_ecx; > uint32_t ext_cpuid8_edx; // reserved > > + // cpuid function 0x8000001E // AMD 17h > + uint32_t ext_cpuid1E_eax; > + ExtCpuid1EEbx ext_cpuid1E_ebx; // threads per core (AMD17h) > + uint32_t ext_cpuid1E_ecx; > + uint32_t ext_cpuid1E_edx; // unused currently > + > // extended control register XCR0 (the XFEATURE_ENABLED_MASK register) > XemXcr0Eax xem_xcr0_eax; > uint32_t xem_xcr0_edx; // reserved > @@ -505,6 +520,14 @@ > result |= CPU_CLMUL; > if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) > result |= CPU_RTM; > + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > + result |= CPU_ADX; > + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > + result |= CPU_BMI2; > + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > + result |= CPU_SHA; > + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > + result |= CPU_FMA; > > // AMD features. > if (is_amd()) { > @@ -518,16 +541,8 @@ > } > // Intel features. > if(is_intel()) { > - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > - result |= CPU_ADX; > - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > - result |= CPU_BMI2; > - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > - result |= CPU_SHA; > if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) > result |= CPU_LZCNT; > - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > - result |= CPU_FMA; > // for Intel, ecx.bits.misalignsse bit (bit 8) indicates > support for prefetchw > if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { > result |= CPU_3DNOW_PREFETCH; > @@ -590,6 +605,7 @@ > static ByteSize ext_cpuid5_offset() { return > byte_offset_of(CpuidInfo, ext_cpuid5_eax); } > static ByteSize ext_cpuid7_offset() { return > byte_offset_of(CpuidInfo, ext_cpuid7_eax); } > static ByteSize ext_cpuid8_offset() { return > byte_offset_of(CpuidInfo, ext_cpuid8_eax); } > + static ByteSize ext_cpuid1E_offset() { return > byte_offset_of(CpuidInfo, ext_cpuid1E_eax); } > static ByteSize tpl_cpuidB0_offset() { return > byte_offset_of(CpuidInfo, tpl_cpuidB0_eax); } > static ByteSize tpl_cpuidB1_offset() { return > byte_offset_of(CpuidInfo, tpl_cpuidB1_eax); } > static ByteSize tpl_cpuidB2_offset() { return > byte_offset_of(CpuidInfo, tpl_cpuidB2_eax); } > @@ -673,8 +689,12 @@ > if (is_intel() && supports_processor_topology()) { > result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > - result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / > - cores_per_cpu(); > + if (cpu_family() >= 0x17) { > + result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; > + } else { > + result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / > + cores_per_cpu(); > + } > } > return (result == 0 ? 1 : result); > } > > Regards, > Rohit > > >> > >> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp > >> b/src/cpu/x86/vm/vm_version_x86.cpp > >> --- a/src/cpu/x86/vm/vm_version_x86.cpp > >> +++ b/src/cpu/x86/vm/vm_version_x86.cpp > >> @@ -70,7 +70,7 @@ > >> bool use_evex = FLAG_IS_DEFAULT(UseAVX) || (UseAVX > 2); > >> > >> Label detect_486, cpu486, detect_586, std_cpuid1, std_cpuid4; > >> - Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, > >> done, wrapup; > >> + Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, > >> ext_cpuid8, done, wrapup; > >> Label legacy_setup, save_restore_except, legacy_save_restore, > >> start_simd_check; > >> > >> StubCodeMark mark(this, "VM_Version", "get_cpu_info_stub"); > >> @@ -267,14 +267,30 @@ > >> __ cmpl(rax, 0x80000000); // Is cpuid(0x80000001) supported? > >> __ jcc(Assembler::belowEqual, done); > >> __ cmpl(rax, 0x80000004); // Is cpuid(0x80000005) supported? > >> - __ jccb(Assembler::belowEqual, ext_cpuid1); > >> + __ jcc(Assembler::belowEqual, ext_cpuid1); > >> __ cmpl(rax, 0x80000006); // Is cpuid(0x80000007) supported? > >> __ jccb(Assembler::belowEqual, ext_cpuid5); > >> __ cmpl(rax, 0x80000007); // Is cpuid(0x80000008) supported? > >> __ jccb(Assembler::belowEqual, ext_cpuid7); > >> + __ cmpl(rax, 0x80000008); // Is cpuid(0x80000009 and above) > >> supported? > >> + __ jccb(Assembler::belowEqual, ext_cpuid8); > >> + __ cmpl(rax, 0x8000001E); // Is cpuid(0x8000001E) supported? > >> + __ jccb(Assembler::below, ext_cpuid8); > >> + // > >> + // Extended cpuid(0x8000001E) > >> + // > >> + __ movl(rax, 0x8000001E); > >> + __ cpuid(); > >> + __ lea(rsi, Address(rbp, > >> in_bytes(VM_Version::ext_cpuid1E_offset()))); > >> + __ movl(Address(rsi, 0), rax); > >> + __ movl(Address(rsi, 4), rbx); > >> + __ movl(Address(rsi, 8), rcx); > >> + __ movl(Address(rsi,12), rdx); > >> + > >> // > >> // Extended cpuid(0x80000008) > >> // > >> + __ bind(ext_cpuid8); > >> __ movl(rax, 0x80000008); > >> __ cpuid(); > >> __ lea(rsi, Address(rbp, > >> in_bytes(VM_Version::ext_cpuid8_offset()))); > >> @@ -1109,11 +1125,27 @@ > >> } > >> > >> #ifdef COMPILER2 > >> - if (MaxVectorSize > 16) { > >> - // Limit vectors size to 16 bytes on current AMD cpus. > >> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { > >> + // Limit vectors size to 16 bytes on AMD cpus < 17h. > >> FLAG_SET_DEFAULT(MaxVectorSize, 16); > >> } > >> #endif // COMPILER2 > >> + > >> + // Some defaults for AMD family 17h > >> + if ( cpu_family() == 0x17 ) { > >> + // On family 17h processors use XMM and UnalignedLoadStores for > >> Array Copy > >> + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > >> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); > >> + } > >> + if (supports_sse2() && FLAG_IS_DEFAULT(UseUnalignedLoadStores)) > { > >> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); > >> + } > >> +#ifdef COMPILER2 > >> + if (supports_sse4_2() && FLAG_IS_DEFAULT(UseFPUForSpilling)) { > >> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > >> + } > >> +#endif > >> + } > >> } > >> > >> if( is_intel() ) { // Intel cpus specific settings > >> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp > >> b/src/cpu/x86/vm/vm_version_x86.hpp > >> --- a/src/cpu/x86/vm/vm_version_x86.hpp > >> +++ b/src/cpu/x86/vm/vm_version_x86.hpp > >> @@ -228,6 +228,15 @@ > >> } bits; > >> }; > >> > >> + union ExtCpuid1EEbx { > >> + uint32_t value; > >> + struct { > >> + uint32_t : 8, > >> + threads_per_core : 8, > >> + : 16; > >> + } bits; > >> + }; > >> + > >> union XemXcr0Eax { > >> uint32_t value; > >> struct { > >> @@ -398,6 +407,12 @@ > >> ExtCpuid8Ecx ext_cpuid8_ecx; > >> uint32_t ext_cpuid8_edx; // reserved > >> > >> + // cpuid function 0x8000001E // AMD 17h > >> + uint32_t ext_cpuid1E_eax; > >> + ExtCpuid1EEbx ext_cpuid1E_ebx; // threads per core (AMD17h) > >> + uint32_t ext_cpuid1E_ecx; > >> + uint32_t ext_cpuid1E_edx; // unused currently > >> + > >> // extended control register XCR0 (the XFEATURE_ENABLED_MASK > >> register) > >> XemXcr0Eax xem_xcr0_eax; > >> uint32_t xem_xcr0_edx; // reserved > >> @@ -505,6 +520,14 @@ > >> result |= CPU_CLMUL; > >> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) > >> result |= CPU_RTM; > >> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >> + result |= CPU_ADX; > >> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >> + result |= CPU_BMI2; > >> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >> + result |= CPU_SHA; > >> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >> + result |= CPU_FMA; > >> > >> // AMD features. > >> if (is_amd()) { > >> @@ -518,16 +541,8 @@ > >> } > >> // Intel features. > >> if(is_intel()) { > >> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >> - result |= CPU_ADX; > >> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >> - result |= CPU_BMI2; > >> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >> - result |= CPU_SHA; > >> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) > >> result |= CPU_LZCNT; > >> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >> - result |= CPU_FMA; > >> // for Intel, ecx.bits.misalignsse bit (bit 8) indicates > >> support for prefetchw > >> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { > >> result |= CPU_3DNOW_PREFETCH; > >> @@ -590,6 +605,7 @@ > >> static ByteSize ext_cpuid5_offset() { return > >> byte_offset_of(CpuidInfo, ext_cpuid5_eax); } > >> static ByteSize ext_cpuid7_offset() { return > >> byte_offset_of(CpuidInfo, ext_cpuid7_eax); } > >> static ByteSize ext_cpuid8_offset() { return > >> byte_offset_of(CpuidInfo, ext_cpuid8_eax); } > >> + static ByteSize ext_cpuid1E_offset() { return > >> byte_offset_of(CpuidInfo, ext_cpuid1E_eax); } > >> static ByteSize tpl_cpuidB0_offset() { return > >> byte_offset_of(CpuidInfo, tpl_cpuidB0_eax); } > >> static ByteSize tpl_cpuidB1_offset() { return > >> byte_offset_of(CpuidInfo, tpl_cpuidB1_eax); } > >> static ByteSize tpl_cpuidB2_offset() { return > >> byte_offset_of(CpuidInfo, tpl_cpuidB2_eax); } > >> @@ -673,8 +689,12 @@ > >> if (is_intel() && supports_processor_topology()) { > >> result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > >> } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > >> - result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / > >> - cores_per_cpu(); > >> + if (cpu_family() >= 0x17) { > >> + result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + > 1; > >> + } else { > >> + result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / > >> + cores_per_cpu(); > >> + } > >> } > >> return (result == 0 ? 1 : result); > >> } > >> > >> Please let me know your comments. > >> Thanks for your review. > >> > >> Regards, > >> Rohit > >> > >>> > >>> > >>> On 9/11/17 9:52 PM, Rohit Arul Raj wrote: > >>>> > >>>> > >>>> Hello David, > >>>> > >>>>>> > >>>>>> > >>>>>> 1. ExtCpuid1EEx > >>>>>> > >>>>>> Should this be ExtCpuid1EEbx? (I see the naming here is somewhat > >>>>>> inconsistent - and potentially confusing: I would have preferred to > >>>>>> see > >>>>>> things like ExtCpuid_1E_Ebx, to make it clear.) > >>>>> > >>>>> > >>>>> > >>>>> Yes, I can change it accordingly. > >>>>> > >>>> > >>>> I have attached the updated, re-tested patch as per your comments > above. > >>>> > >>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp > >>>> b/src/cpu/x86/vm/vm_version_x86.cpp > >>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp > >>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp > >>>> @@ -70,7 +70,7 @@ > >>>> bool use_evex = FLAG_IS_DEFAULT(UseAVX) || (UseAVX > 2); > >>>> > >>>> Label detect_486, cpu486, detect_586, std_cpuid1, std_cpuid4; > >>>> - Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, > >>>> done, wrapup; > >>>> + Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, > >>>> ext_cpuid8, done, wrapup; > >>>> Label legacy_setup, save_restore_except, legacy_save_restore, > >>>> start_simd_check; > >>>> > >>>> StubCodeMark mark(this, "VM_Version", "get_cpu_info_stub"); > >>>> @@ -272,9 +272,23 @@ > >>>> __ jccb(Assembler::belowEqual, ext_cpuid5); > >>>> __ cmpl(rax, 0x80000007); // Is cpuid(0x80000008) > supported? > >>>> __ jccb(Assembler::belowEqual, ext_cpuid7); > >>>> + __ cmpl(rax, 0x80000008); // Is cpuid(0x8000001E) supported? > >>>> + __ jccb(Assembler::belowEqual, ext_cpuid8); > >>>> + // > >>>> + // Extended cpuid(0x8000001E) > >>>> + // > >>>> + __ movl(rax, 0x8000001E); > >>>> + __ cpuid(); > >>>> + __ lea(rsi, Address(rbp, > >>>> in_bytes(VM_Version::ext_cpuid_1E_offset()))); > >>>> + __ movl(Address(rsi, 0), rax); > >>>> + __ movl(Address(rsi, 4), rbx); > >>>> + __ movl(Address(rsi, 8), rcx); > >>>> + __ movl(Address(rsi,12), rdx); > >>>> + > >>>> // > >>>> // Extended cpuid(0x80000008) > >>>> // > >>>> + __ bind(ext_cpuid8); > >>>> __ movl(rax, 0x80000008); > >>>> __ cpuid(); > >>>> __ lea(rsi, Address(rbp, > >>>> in_bytes(VM_Version::ext_cpuid8_offset()))); > >>>> @@ -1109,11 +1123,27 @@ > >>>> } > >>>> > >>>> #ifdef COMPILER2 > >>>> - if (MaxVectorSize > 16) { > >>>> - // Limit vectors size to 16 bytes on current AMD cpus. > >>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { > >>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. > >>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); > >>>> } > >>>> #endif // COMPILER2 > >>>> + > >>>> + // Some defaults for AMD family 17h > >>>> + if ( cpu_family() == 0x17 ) { > >>>> + // On family 17h processors use XMM and UnalignedLoadStores for > >>>> Array Copy > >>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > >>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); > >>>> + } > >>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseUnalignedLoadStores)) > { > >>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); > >>>> + } > >>>> +#ifdef COMPILER2 > >>>> + if (supports_sse4_2() && FLAG_IS_DEFAULT(UseFPUForSpilling)) { > >>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > >>>> + } > >>>> +#endif > >>>> + } > >>>> } > >>>> > >>>> if( is_intel() ) { // Intel cpus specific settings > >>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp > >>>> b/src/cpu/x86/vm/vm_version_x86.hpp > >>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp > >>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp > >>>> @@ -228,6 +228,15 @@ > >>>> } bits; > >>>> }; > >>>> > >>>> + union ExtCpuid_1E_Ebx { > >>>> + uint32_t value; > >>>> + struct { > >>>> + uint32_t : 8, > >>>> + threads_per_core : 8, > >>>> + : 16; > >>>> + } bits; > >>>> + }; > >>>> + > >>>> union XemXcr0Eax { > >>>> uint32_t value; > >>>> struct { > >>>> @@ -398,6 +407,12 @@ > >>>> ExtCpuid8Ecx ext_cpuid8_ecx; > >>>> uint32_t ext_cpuid8_edx; // reserved > >>>> > >>>> + // cpuid function 0x8000001E // AMD 17h > >>>> + uint32_t ext_cpuid_1E_eax; > >>>> + ExtCpuid_1E_Ebx ext_cpuid_1E_ebx; // threads per core (AMD17h) > >>>> + uint32_t ext_cpuid_1E_ecx; > >>>> + uint32_t ext_cpuid_1E_edx; // unused currently > >>>> + > >>>> // extended control register XCR0 (the XFEATURE_ENABLED_MASK > >>>> register) > >>>> XemXcr0Eax xem_xcr0_eax; > >>>> uint32_t xem_xcr0_edx; // reserved > >>>> @@ -505,6 +520,14 @@ > >>>> result |= CPU_CLMUL; > >>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) > >>>> result |= CPU_RTM; > >>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >>>> + result |= CPU_ADX; > >>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >>>> + result |= CPU_BMI2; > >>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >>>> + result |= CPU_SHA; > >>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >>>> + result |= CPU_FMA; > >>>> > >>>> // AMD features. > >>>> if (is_amd()) { > >>>> @@ -518,16 +541,8 @@ > >>>> } > >>>> // Intel features. > >>>> if(is_intel()) { > >>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >>>> - result |= CPU_ADX; > >>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >>>> - result |= CPU_BMI2; > >>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >>>> - result |= CPU_SHA; > >>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) > >>>> result |= CPU_LZCNT; > >>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >>>> - result |= CPU_FMA; > >>>> // for Intel, ecx.bits.misalignsse bit (bit 8) indicates > >>>> support for prefetchw > >>>> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { > >>>> result |= CPU_3DNOW_PREFETCH; > >>>> @@ -590,6 +605,7 @@ > >>>> static ByteSize ext_cpuid5_offset() { return > >>>> byte_offset_of(CpuidInfo, ext_cpuid5_eax); } > >>>> static ByteSize ext_cpuid7_offset() { return > >>>> byte_offset_of(CpuidInfo, ext_cpuid7_eax); } > >>>> static ByteSize ext_cpuid8_offset() { return > >>>> byte_offset_of(CpuidInfo, ext_cpuid8_eax); } > >>>> + static ByteSize ext_cpuid_1E_offset() { return > >>>> byte_offset_of(CpuidInfo, ext_cpuid_1E_eax); } > >>>> static ByteSize tpl_cpuidB0_offset() { return > >>>> byte_offset_of(CpuidInfo, tpl_cpuidB0_eax); } > >>>> static ByteSize tpl_cpuidB1_offset() { return > >>>> byte_offset_of(CpuidInfo, tpl_cpuidB1_eax); } > >>>> static ByteSize tpl_cpuidB2_offset() { return > >>>> byte_offset_of(CpuidInfo, tpl_cpuidB2_eax); } > >>>> @@ -673,8 +689,11 @@ > >>>> if (is_intel() && supports_processor_topology()) { > >>>> result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > >>>> } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > >>>> - result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / > >>>> - cores_per_cpu(); > >>>> + if (cpu_family() >= 0x17) > >>>> + result = _cpuid_info.ext_cpuid_1E_ebx.bits.threads_per_core > + > >>>> 1; > >>>> + else > >>>> + result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / > >>>> + cores_per_cpu(); > >>>> } > >>>> return (result == 0 ? 1 : result); > >>>> } > >>>> > >>>> > >>>> Please let me know your comments > >>>> > >>>> Thanks for your time. > >>>> > >>>> Regards, > >>>> Rohit > >>>> > >>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>> > >>>>>>> Reference: > >>>>>>> > >>>>>>> > >>>>>>> https://support.amd.com/TechDocs/54945_PPR_Family_17h_ > Models_00h-0Fh.pdf > >>>>>>> [Pg 82] > >>>>>>> > >>>>>>> CPUID_Fn8000001E_EBX [Core Identifiers] (CoreId) > >>>>>>> 15:8 ThreadsPerCore: threads per core. Read-only. Reset: > >>>>>>> XXh. > >>>>>>> The number of threads per core is ThreadsPerCore+1. > >>>>>>> > >>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>> @@ -70,7 +70,7 @@ > >>>>>>> bool use_evex = FLAG_IS_DEFAULT(UseAVX) || (UseAVX > 2); > >>>>>>> > >>>>>>> Label detect_486, cpu486, detect_586, std_cpuid1, > std_cpuid4; > >>>>>>> - Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, > ext_cpuid7, > >>>>>>> done, wrapup; > >>>>>>> + Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, > ext_cpuid7, > >>>>>>> ext_cpuid8, done, wrapup; > >>>>>>> Label legacy_setup, save_restore_except, > legacy_save_restore, > >>>>>>> start_simd_check; > >>>>>>> > >>>>>>> StubCodeMark mark(this, "VM_Version", "get_cpu_info_stub"); > >>>>>>> @@ -272,9 +272,23 @@ > >>>>>>> __ jccb(Assembler::belowEqual, ext_cpuid5); > >>>>>>> __ cmpl(rax, 0x80000007); // Is cpuid(0x80000008) > >>>>>>> supported? > >>>>>>> __ jccb(Assembler::belowEqual, ext_cpuid7); > >>>>>>> + __ cmpl(rax, 0x80000008); // Is cpuid(0x8000001E) > supported? > >>>>>>> + __ jccb(Assembler::belowEqual, ext_cpuid8); > >>>>>>> + // > >>>>>>> + // Extended cpuid(0x8000001E) > >>>>>>> + // > >>>>>>> + __ movl(rax, 0x8000001E); > >>>>>>> + __ cpuid(); > >>>>>>> + __ lea(rsi, Address(rbp, > >>>>>>> in_bytes(VM_Version::ext_cpuid1E_offset()))); > >>>>>>> + __ movl(Address(rsi, 0), rax); > >>>>>>> + __ movl(Address(rsi, 4), rbx); > >>>>>>> + __ movl(Address(rsi, 8), rcx); > >>>>>>> + __ movl(Address(rsi,12), rdx); > >>>>>>> + > >>>>>>> // > >>>>>>> // Extended cpuid(0x80000008) > >>>>>>> // > >>>>>>> + __ bind(ext_cpuid8); > >>>>>>> __ movl(rax, 0x80000008); > >>>>>>> __ cpuid(); > >>>>>>> __ lea(rsi, Address(rbp, > >>>>>>> in_bytes(VM_Version::ext_cpuid8_offset()))); > >>>>>>> @@ -1109,11 +1123,27 @@ > >>>>>>> } > >>>>>>> > >>>>>>> #ifdef COMPILER2 > >>>>>>> - if (MaxVectorSize > 16) { > >>>>>>> - // Limit vectors size to 16 bytes on current AMD cpus. > >>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { > >>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. > >>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); > >>>>>>> } > >>>>>>> #endif // COMPILER2 > >>>>>>> + > >>>>>>> + // Some defaults for AMD family 17h > >>>>>>> + if ( cpu_family() == 0x17 ) { > >>>>>>> + // On family 17h processors use XMM and UnalignedLoadStores > >>>>>>> for > >>>>>>> Array Copy > >>>>>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) > { > >>>>>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); > >>>>>>> + } > >>>>>>> + if (supports_sse2() && > >>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) > >>>>>>> { > >>>>>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); > >>>>>>> + } > >>>>>>> +#ifdef COMPILER2 > >>>>>>> + if (supports_sse4_2() && FLAG_IS_DEFAULT(UseFPUForSpilling)) > { > >>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > >>>>>>> + } > >>>>>>> +#endif > >>>>>>> + } > >>>>>>> } > >>>>>>> > >>>>>>> if( is_intel() ) { // Intel cpus specific settings > >>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>> @@ -228,6 +228,15 @@ > >>>>>>> } bits; > >>>>>>> }; > >>>>>>> > >>>>>>> + union ExtCpuid1EEx { > >>>>>>> + uint32_t value; > >>>>>>> + struct { > >>>>>>> + uint32_t : 8, > >>>>>>> + threads_per_core : 8, > >>>>>>> + : 16; > >>>>>>> + } bits; > >>>>>>> + }; > >>>>>>> + > >>>>>>> union XemXcr0Eax { > >>>>>>> uint32_t value; > >>>>>>> struct { > >>>>>>> @@ -398,6 +407,12 @@ > >>>>>>> ExtCpuid8Ecx ext_cpuid8_ecx; > >>>>>>> uint32_t ext_cpuid8_edx; // reserved > >>>>>>> > >>>>>>> + // cpuid function 0x8000001E // AMD 17h > >>>>>>> + uint32_t ext_cpuid1E_eax; > >>>>>>> + ExtCpuid1EEx ext_cpuid1E_ebx; // threads per core (AMD17h) > >>>>>>> + uint32_t ext_cpuid1E_ecx; > >>>>>>> + uint32_t ext_cpuid1E_edx; // unused currently > >>>>>>> + > >>>>>>> // extended control register XCR0 (the > XFEATURE_ENABLED_MASK > >>>>>>> register) > >>>>>>> XemXcr0Eax xem_xcr0_eax; > >>>>>>> uint32_t xem_xcr0_edx; // reserved > >>>>>>> @@ -505,6 +520,14 @@ > >>>>>>> result |= CPU_CLMUL; > >>>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) > >>>>>>> result |= CPU_RTM; > >>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >>>>>>> + result |= CPU_ADX; > >>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >>>>>>> + result |= CPU_BMI2; > >>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >>>>>>> + result |= CPU_SHA; > >>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >>>>>>> + result |= CPU_FMA; > >>>>>>> > >>>>>>> // AMD features. > >>>>>>> if (is_amd()) { > >>>>>>> @@ -518,16 +541,8 @@ > >>>>>>> } > >>>>>>> // Intel features. > >>>>>>> if(is_intel()) { > >>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >>>>>>> - result |= CPU_ADX; > >>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >>>>>>> - result |= CPU_BMI2; > >>>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >>>>>>> - result |= CPU_SHA; > >>>>>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) > >>>>>>> result |= CPU_LZCNT; > >>>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >>>>>>> - result |= CPU_FMA; > >>>>>>> // for Intel, ecx.bits.misalignsse bit (bit 8) indicates > >>>>>>> support for prefetchw > >>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { > >>>>>>> result |= CPU_3DNOW_PREFETCH; > >>>>>>> @@ -590,6 +605,7 @@ > >>>>>>> static ByteSize ext_cpuid5_offset() { return > >>>>>>> byte_offset_of(CpuidInfo, ext_cpuid5_eax); } > >>>>>>> static ByteSize ext_cpuid7_offset() { return > >>>>>>> byte_offset_of(CpuidInfo, ext_cpuid7_eax); } > >>>>>>> static ByteSize ext_cpuid8_offset() { return > >>>>>>> byte_offset_of(CpuidInfo, ext_cpuid8_eax); } > >>>>>>> + static ByteSize ext_cpuid1E_offset() { return > >>>>>>> byte_offset_of(CpuidInfo, ext_cpuid1E_eax); } > >>>>>>> static ByteSize tpl_cpuidB0_offset() { return > >>>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB0_eax); } > >>>>>>> static ByteSize tpl_cpuidB1_offset() { return > >>>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB1_eax); } > >>>>>>> static ByteSize tpl_cpuidB2_offset() { return > >>>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB2_eax); } > >>>>>>> @@ -673,8 +689,11 @@ > >>>>>>> if (is_intel() && supports_processor_topology()) { > >>>>>>> result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; > >>>>>>> } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { > >>>>>>> - result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / > >>>>>>> - cores_per_cpu(); > >>>>>>> + if (cpu_family() >= 0x17) > >>>>>>> + result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core > + > >>>>>>> 1; > >>>>>>> + else > >>>>>>> + result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu > / > >>>>>>> + cores_per_cpu(); > >>>>>>> } > >>>>>>> return (result == 0 ? 1 : result); > >>>>>>> } > >>>>>>> > >>>>>>> I have attached the patch for review. > >>>>>>> Please let me know your comments. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Rohit > >>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Vladimir > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>> > >>>>>>>>> No comments on AMD specific changes. > >>>>>>>>> > >>>>>>>>> Thanks, > >>>>>>>>> David > >>>>>>>>> ----- > >>>>>>>>> > >>>>>>>>> On 5/09/2017 3:43 PM, David Holmes wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 5/09/2017 3:29 PM, Rohit Arul Raj wrote: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Hello David, > >>>>>>>>>>> > >>>>>>>>>>> On Tue, Sep 5, 2017 at 10:31 AM, David Holmes > >>>>>>>>>>> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Rohit, > >>>>>>>>>>>> > >>>>>>>>>>>> I was unable to apply your patch to latest jdk10/hs/hotspot > >>>>>>>>>>>> repo. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I checked out the latest jdk10/hs/hotspot [parent: > >>>>>>>>>>> 13548:1a9c2e07a826] > >>>>>>>>>>> and was able to apply the patch > >>>>>>>>>>> [epyc-amd17h-defaults-3Sept.patch] > >>>>>>>>>>> without any issues. > >>>>>>>>>>> Can you share the error message that you are getting? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> I was getting this: > >>>>>>>>>> > >>>>>>>>>> applying hotspot.patch > >>>>>>>>>> patching file src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>> Hunk #1 FAILED at 1108 > >>>>>>>>>> 1 out of 1 hunks FAILED -- saving rejects to file > >>>>>>>>>> src/cpu/x86/vm/vm_version_x86.cpp.rej > >>>>>>>>>> patching file src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>> Hunk #2 FAILED at 522 > >>>>>>>>>> 1 out of 2 hunks FAILED -- saving rejects to file > >>>>>>>>>> src/cpu/x86/vm/vm_version_x86.hpp.rej > >>>>>>>>>> abort: patch failed to apply > >>>>>>>>>> > >>>>>>>>>> but I started again and this time it applied fine, so not sure > >>>>>>>>>> what > >>>>>>>>>> was > >>>>>>>>>> going on there. > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> David > >>>>>>>>>> > >>>>>>>>>>> Regards, > >>>>>>>>>>> Rohit > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 4/09/2017 2:42 AM, Rohit Arul Raj wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hello Vladimir, > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Sat, Sep 2, 2017 at 11:25 PM, Vladimir Kozlov > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Rohit, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 9/2/17 1:16 AM, Rohit Arul Raj wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hello Vladimir, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Changes look good. Only question I have is about > >>>>>>>>>>>>>>>> MaxVectorSize. > >>>>>>>>>>>>>>>> It > >>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>> set > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 16 only in presence of AVX: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/ > 046eab27258f/src/cpu/x86/vm/vm_version_x86.cpp#l945 > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Does that code works for AMD 17h too? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks for pointing that out. Yes, the code works fine for > >>>>>>>>>>>>>>> AMD > >>>>>>>>>>>>>>> 17h. > >>>>>>>>>>>>>>> So > >>>>>>>>>>>>>>> I have removed the surplus check for MaxVectorSize from my > >>>>>>>>>>>>>>> patch. > >>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>> have updated, re-tested and attached the patch. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Which check you removed? > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> My older patch had the below mentioned check which was > required > >>>>>>>>>>>>> on > >>>>>>>>>>>>> JDK9 where the default MaxVectorSize was 64. It has been > >>>>>>>>>>>>> handled > >>>>>>>>>>>>> better in openJDK10. So this check is not required anymore. > >>>>>>>>>>>>> > >>>>>>>>>>>>> + // Some defaults for AMD family 17h > >>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { > >>>>>>>>>>>>> ... > >>>>>>>>>>>>> ... > >>>>>>>>>>>>> + if (MaxVectorSize > 32) { > >>>>>>>>>>>>> + FLAG_SET_DEFAULT(MaxVectorSize, 32); > >>>>>>>>>>>>> + } > >>>>>>>>>>>>> .. > >>>>>>>>>>>>> .. > >>>>>>>>>>>>> + } > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I have one query regarding the setting of UseSHA flag: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/ > 046eab27258f/src/cpu/x86/vm/vm_version_x86.cpp#l821 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> AMD 17h has support for SHA. > >>>>>>>>>>>>>>> AMD 15h doesn't have support for SHA. Still "UseSHA" flag > >>>>>>>>>>>>>>> gets > >>>>>>>>>>>>>>> enabled for it based on the availability of BMI2 and AVX2. > Is > >>>>>>>>>>>>>>> there > >>>>>>>>>>>>>>> an > >>>>>>>>>>>>>>> underlying reason for this? I have handled this in the > patch > >>>>>>>>>>>>>>> but > >>>>>>>>>>>>>>> just > >>>>>>>>>>>>>>> wanted to confirm. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> It was done with next changes which use only AVX2 and BMI2 > >>>>>>>>>>>>>> instructions > >>>>>>>>>>>>>> to > >>>>>>>>>>>>>> calculate SHA-256: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/ > 6a17c49de974 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I don't know if AMD 15h supports these instructions and can > >>>>>>>>>>>>>> execute > >>>>>>>>>>>>>> that > >>>>>>>>>>>>>> code. You need to test it. > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Ok, got it. Since AMD15h has support for AVX2 and BMI2 > >>>>>>>>>>>>> instructions, > >>>>>>>>>>>>> it should work. > >>>>>>>>>>>>> Confirmed by running following sanity tests: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> ./hotspot/test/compiler/intrinsics/sha/sanity/ > TestSHA1Intrinsics.java > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> ./hotspot/test/compiler/intrinsics/sha/sanity/ > TestSHA512Intrinsics.java > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> ./hotspot/test/compiler/intrinsics/sha/sanity/ > TestSHA256Intrinsics.java > >>>>>>>>>>>>> > >>>>>>>>>>>>> So I have removed those SHA checks from my patch too. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Please find attached updated, re-tested patch. > >>>>>>>>>>>>> > >>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>> @@ -1109,11 +1109,27 @@ > >>>>>>>>>>>>> } > >>>>>>>>>>>>> > >>>>>>>>>>>>> #ifdef COMPILER2 > >>>>>>>>>>>>> - if (MaxVectorSize > 16) { > >>>>>>>>>>>>> - // Limit vectors size to 16 bytes on current AMD cpus. > >>>>>>>>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { > >>>>>>>>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. > >>>>>>>>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); > >>>>>>>>>>>>> } > >>>>>>>>>>>>> #endif // COMPILER2 > >>>>>>>>>>>>> + > >>>>>>>>>>>>> + // Some defaults for AMD family 17h > >>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { > >>>>>>>>>>>>> + // On family 17h processors use XMM and > >>>>>>>>>>>>> UnalignedLoadStores > >>>>>>>>>>>>> for > >>>>>>>>>>>>> Array Copy > >>>>>>>>>>>>> + if (supports_sse2() && > >>>>>>>>>>>>> FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { > >>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); > >>>>>>>>>>>>> + } > >>>>>>>>>>>>> + if (supports_sse2() && > >>>>>>>>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) > >>>>>>>>>>>>> { > >>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); > >>>>>>>>>>>>> + } > >>>>>>>>>>>>> +#ifdef COMPILER2 > >>>>>>>>>>>>> + if (supports_sse4_2() && > >>>>>>>>>>>>> FLAG_IS_DEFAULT(UseFPUForSpilling)) > >>>>>>>>>>>>> { > >>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > >>>>>>>>>>>>> + } > >>>>>>>>>>>>> +#endif > >>>>>>>>>>>>> + } > >>>>>>>>>>>>> } > >>>>>>>>>>>>> > >>>>>>>>>>>>> if( is_intel() ) { // Intel cpus specific settings > >>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>> @@ -505,6 +505,14 @@ > >>>>>>>>>>>>> result |= CPU_CLMUL; > >>>>>>>>>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) > >>>>>>>>>>>>> result |= CPU_RTM; > >>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >>>>>>>>>>>>> + result |= CPU_ADX; > >>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >>>>>>>>>>>>> + result |= CPU_BMI2; > >>>>>>>>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >>>>>>>>>>>>> + result |= CPU_SHA; > >>>>>>>>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >>>>>>>>>>>>> + result |= CPU_FMA; > >>>>>>>>>>>>> > >>>>>>>>>>>>> // AMD features. > >>>>>>>>>>>>> if (is_amd()) { > >>>>>>>>>>>>> @@ -515,19 +523,13 @@ > >>>>>>>>>>>>> result |= CPU_LZCNT; > >>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.sse4a != 0) > >>>>>>>>>>>>> result |= CPU_SSE4A; > >>>>>>>>>>>>> + if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) > >>>>>>>>>>>>> + result |= CPU_HT; > >>>>>>>>>>>>> } > >>>>>>>>>>>>> // Intel features. > >>>>>>>>>>>>> if(is_intel()) { > >>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >>>>>>>>>>>>> - result |= CPU_ADX; > >>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >>>>>>>>>>>>> - result |= CPU_BMI2; > >>>>>>>>>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >>>>>>>>>>>>> - result |= CPU_SHA; > >>>>>>>>>>>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel > != > >>>>>>>>>>>>> 0) > >>>>>>>>>>>>> result |= CPU_LZCNT; > >>>>>>>>>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >>>>>>>>>>>>> - result |= CPU_FMA; > >>>>>>>>>>>>> // for Intel, ecx.bits.misalignsse bit (bit 8) > >>>>>>>>>>>>> indicates > >>>>>>>>>>>>> support for prefetchw > >>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse > != > >>>>>>>>>>>>> 0) > >>>>>>>>>>>>> { > >>>>>>>>>>>>> result |= CPU_3DNOW_PREFETCH; > >>>>>>>>>>>>> > >>>>>>>>>>>>> Please let me know your comments. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks for your time. > >>>>>>>>>>>>> Rohit > >>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks for taking time to review the code. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>>>> @@ -1088,6 +1088,22 @@ > >>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>> FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); > >>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>> + if (supports_sha()) { > >>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA)) { > >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, true); > >>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>> + } else if (UseSHA || UseSHA1Intrinsics || > >>>>>>>>>>>>>>> UseSHA256Intrinsics > >>>>>>>>>>>>>>> || > >>>>>>>>>>>>>>> UseSHA512Intrinsics) { > >>>>>>>>>>>>>>> + if (!FLAG_IS_DEFAULT(UseSHA) || > >>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA1Intrinsics) || > >>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA256Intrinsics) || > >>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { > >>>>>>>>>>>>>>> + warning("SHA instructions are not available on > this > >>>>>>>>>>>>>>> CPU"); > >>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, false); > >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA1Intrinsics, false); > >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA256Intrinsics, false); > >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); > >>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> // some defaults for AMD family 15h > >>>>>>>>>>>>>>> if ( cpu_family() == 0x15 ) { > >>>>>>>>>>>>>>> @@ -1109,11 +1125,40 @@ > >>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> #ifdef COMPILER2 > >>>>>>>>>>>>>>> - if (MaxVectorSize > 16) { > >>>>>>>>>>>>>>> - // Limit vectors size to 16 bytes on current AMD > cpus. > >>>>>>>>>>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { > >>>>>>>>>>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. > >>>>>>>>>>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); > >>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>> #endif // COMPILER2 > >>>>>>>>>>>>>>> + > >>>>>>>>>>>>>>> + // Some defaults for AMD family 17h > >>>>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { > >>>>>>>>>>>>>>> + // On family 17h processors use XMM and > >>>>>>>>>>>>>>> UnalignedLoadStores > >>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>> Array Copy > >>>>>>>>>>>>>>> + if (supports_sse2() && > >>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseXMMForArrayCopy)) > >>>>>>>>>>>>>>> { > >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); > >>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>> + if (supports_sse2() && > >>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { > >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); > >>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>> + if (supports_bmi2() && > >>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseBMI2Instructions)) > >>>>>>>>>>>>>>> { > >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseBMI2Instructions, true); > >>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>> + if (UseSHA) { > >>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { > >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); > >>>>>>>>>>>>>>> + } else if (UseSHA512Intrinsics) { > >>>>>>>>>>>>>>> + warning("Intrinsics for SHA-384 and SHA-512 > crypto > >>>>>>>>>>>>>>> hash > >>>>>>>>>>>>>>> functions not available on this CPU."); > >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); > >>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>> +#ifdef COMPILER2 > >>>>>>>>>>>>>>> + if (supports_sse4_2()) { > >>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { > >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > >>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>> +#endif > >>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> if( is_intel() ) { // Intel cpus specific settings > >>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>>>> @@ -505,6 +505,14 @@ > >>>>>>>>>>>>>>> result |= CPU_CLMUL; > >>>>>>>>>>>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) > >>>>>>>>>>>>>>> result |= CPU_RTM; > >>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >>>>>>>>>>>>>>> + result |= CPU_ADX; > >>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >>>>>>>>>>>>>>> + result |= CPU_BMI2; > >>>>>>>>>>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >>>>>>>>>>>>>>> + result |= CPU_SHA; > >>>>>>>>>>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >>>>>>>>>>>>>>> + result |= CPU_FMA; > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> // AMD features. > >>>>>>>>>>>>>>> if (is_amd()) { > >>>>>>>>>>>>>>> @@ -515,19 +523,13 @@ > >>>>>>>>>>>>>>> result |= CPU_LZCNT; > >>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.sse4a != > 0) > >>>>>>>>>>>>>>> result |= CPU_SSE4A; > >>>>>>>>>>>>>>> + if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) > >>>>>>>>>>>>>>> + result |= CPU_HT; > >>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>> // Intel features. > >>>>>>>>>>>>>>> if(is_intel()) { > >>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >>>>>>>>>>>>>>> - result |= CPU_ADX; > >>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >>>>>>>>>>>>>>> - result |= CPU_BMI2; > >>>>>>>>>>>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >>>>>>>>>>>>>>> - result |= CPU_SHA; > >>>>>>>>>>>>>>> if(_cpuid_info.ext_cpuid1_ecx. > bits.lzcnt_intel > >>>>>>>>>>>>>>> != > >>>>>>>>>>>>>>> 0) > >>>>>>>>>>>>>>> result |= CPU_LZCNT; > >>>>>>>>>>>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >>>>>>>>>>>>>>> - result |= CPU_FMA; > >>>>>>>>>>>>>>> // for Intel, ecx.bits.misalignsse bit (bit 8) > >>>>>>>>>>>>>>> indicates > >>>>>>>>>>>>>>> support for prefetchw > >>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx. > bits.misalignsse > >>>>>>>>>>>>>>> != > >>>>>>>>>>>>>>> 0) { > >>>>>>>>>>>>>>> result |= CPU_3DNOW_PREFETCH; > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>> Rohit > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 9/1/17 8:04 AM, Rohit Arul Raj wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Fri, Sep 1, 2017 at 10:27 AM, Rohit Arul Raj > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Fri, Sep 1, 2017 at 3:01 AM, David Holmes > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Hi Rohit, > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> I think the patch needs updating for jdk10 as I already > >>>>>>>>>>>>>>>>>>> see > >>>>>>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>>> lot of > >>>>>>>>>>>>>>>>>>> logic > >>>>>>>>>>>>>>>>>>> around UseSHA in vm_version_x86.cpp. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Thanks David, I will update the patch wrt JDK10 source > >>>>>>>>>>>>>>>>>> base, > >>>>>>>>>>>>>>>>>> test > >>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>> resubmit for review. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>> Rohit > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Hi All, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I have updated the patch wrt openjdk10/hotspot (parent: > >>>>>>>>>>>>>>>>> 13519:71337910df60), did regression testing using jtreg > >>>>>>>>>>>>>>>>> ($make > >>>>>>>>>>>>>>>>> default) and didnt find any regressions. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Can anyone please volunteer to review this patch which > >>>>>>>>>>>>>>>>> sets > >>>>>>>>>>>>>>>>> flag/ISA > >>>>>>>>>>>>>>>>> defaults for newer AMD 17h (EPYC) processor? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> ************************* Patch > >>>>>>>>>>>>>>>>> **************************** > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>>>>>> @@ -1088,6 +1088,22 @@ > >>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(UseSSE42Intrinsics, > false); > >>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>> + if (supports_sha()) { > >>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA)) { > >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, true); > >>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>> + } else if (UseSHA || UseSHA1Intrinsics || > >>>>>>>>>>>>>>>>> UseSHA256Intrinsics > >>>>>>>>>>>>>>>>> || > >>>>>>>>>>>>>>>>> UseSHA512Intrinsics) { > >>>>>>>>>>>>>>>>> + if (!FLAG_IS_DEFAULT(UseSHA) || > >>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA1Intrinsics) || > >>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA256Intrinsics) || > >>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { > >>>>>>>>>>>>>>>>> + warning("SHA instructions are not available on > >>>>>>>>>>>>>>>>> this > >>>>>>>>>>>>>>>>> CPU"); > >>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, false); > >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA1Intrinsics, false); > >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA256Intrinsics, false); > >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); > >>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> // some defaults for AMD family 15h > >>>>>>>>>>>>>>>>> if ( cpu_family() == 0x15 ) { > >>>>>>>>>>>>>>>>> @@ -1109,11 +1125,43 @@ > >>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> #ifdef COMPILER2 > >>>>>>>>>>>>>>>>> - if (MaxVectorSize > 16) { > >>>>>>>>>>>>>>>>> - // Limit vectors size to 16 bytes on current AMD > >>>>>>>>>>>>>>>>> cpus. > >>>>>>>>>>>>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { > >>>>>>>>>>>>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < > 17h. > >>>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); > >>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>> #endif // COMPILER2 > >>>>>>>>>>>>>>>>> + > >>>>>>>>>>>>>>>>> + // Some defaults for AMD family 17h > >>>>>>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { > >>>>>>>>>>>>>>>>> + // On family 17h processors use XMM and > >>>>>>>>>>>>>>>>> UnalignedLoadStores > >>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>> Array Copy > >>>>>>>>>>>>>>>>> + if (supports_sse2() && > >>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseXMMForArrayCopy)) > >>>>>>>>>>>>>>>>> { > >>>>>>>>>>>>>>>>> + UseXMMForArrayCopy = true; > >>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>> + if (supports_sse2() && > >>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) > >>>>>>>>>>>>>>>>> { > >>>>>>>>>>>>>>>>> + UseUnalignedLoadStores = true; > >>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>> + if (supports_bmi2() && > >>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseBMI2Instructions)) { > >>>>>>>>>>>>>>>>> + UseBMI2Instructions = true; > >>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>> + if (MaxVectorSize > 32) { > >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(MaxVectorSize, 32); > >>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>> + if (UseSHA) { > >>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { > >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); > >>>>>>>>>>>>>>>>> + } else if (UseSHA512Intrinsics) { > >>>>>>>>>>>>>>>>> + warning("Intrinsics for SHA-384 and SHA-512 > >>>>>>>>>>>>>>>>> crypto > >>>>>>>>>>>>>>>>> hash > >>>>>>>>>>>>>>>>> functions not available on this CPU."); > >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); > >>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>> +#ifdef COMPILER2 > >>>>>>>>>>>>>>>>> + if (supports_sse4_2()) { > >>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { > >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > >>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>> +#endif > >>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> if( is_intel() ) { // Intel cpus specific > >>>>>>>>>>>>>>>>> settings > >>>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>>>>>> @@ -505,6 +505,14 @@ > >>>>>>>>>>>>>>>>> result |= CPU_CLMUL; > >>>>>>>>>>>>>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != > 0) > >>>>>>>>>>>>>>>>> result |= CPU_RTM; > >>>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >>>>>>>>>>>>>>>>> + result |= CPU_ADX; > >>>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >>>>>>>>>>>>>>>>> + result |= CPU_BMI2; > >>>>>>>>>>>>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >>>>>>>>>>>>>>>>> + result |= CPU_SHA; > >>>>>>>>>>>>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >>>>>>>>>>>>>>>>> + result |= CPU_FMA; > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> // AMD features. > >>>>>>>>>>>>>>>>> if (is_amd()) { > >>>>>>>>>>>>>>>>> @@ -515,19 +523,13 @@ > >>>>>>>>>>>>>>>>> result |= CPU_LZCNT; > >>>>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.sse4a > != > >>>>>>>>>>>>>>>>> 0) > >>>>>>>>>>>>>>>>> result |= CPU_SSE4A; > >>>>>>>>>>>>>>>>> + if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) > >>>>>>>>>>>>>>>>> + result |= CPU_HT; > >>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>> // Intel features. > >>>>>>>>>>>>>>>>> if(is_intel()) { > >>>>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >>>>>>>>>>>>>>>>> - result |= CPU_ADX; > >>>>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >>>>>>>>>>>>>>>>> - result |= CPU_BMI2; > >>>>>>>>>>>>>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >>>>>>>>>>>>>>>>> - result |= CPU_SHA; > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel > >>>>>>>>>>>>>>>>> != 0) > >>>>>>>>>>>>>>>>> result |= CPU_LZCNT; > >>>>>>>>>>>>>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >>>>>>>>>>>>>>>>> - result |= CPU_FMA; > >>>>>>>>>>>>>>>>> // for Intel, ecx.bits.misalignsse bit (bit > >>>>>>>>>>>>>>>>> 8) > >>>>>>>>>>>>>>>>> indicates > >>>>>>>>>>>>>>>>> support for prefetchw > >>>>>>>>>>>>>>>>> if > >>>>>>>>>>>>>>>>> (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse > >>>>>>>>>>>>>>>>> != > >>>>>>>>>>>>>>>>> 0) { > >>>>>>>>>>>>>>>>> result |= CPU_3DNOW_PREFETCH; > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> ****************************** > ******************************** > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>> Rohit > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 1/09/2017 1:11 AM, Rohit Arul Raj wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> On Thu, Aug 31, 2017 at 5:59 PM, David Holmes > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Hi Rohit, > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On 31/08/2017 7:03 PM, Rohit Arul Raj wrote: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> I would like an volunteer to review this patch > >>>>>>>>>>>>>>>>>>>>>> (openJDK9) > >>>>>>>>>>>>>>>>>>>>>> which > >>>>>>>>>>>>>>>>>>>>>> sets > >>>>>>>>>>>>>>>>>>>>>> flag/ISA defaults for newer AMD 17h (EPYC) processor > >>>>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>> help > >>>>>>>>>>>>>>>>>>>>>> us > >>>>>>>>>>>>>>>>>>>>>> with > >>>>>>>>>>>>>>>>>>>>>> the commit process. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Webrev: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/ > 08bsxaxupg8kbam/AADurTXLGIZ6C-tiIAi_Glyka?dl=0 > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Unfortunately patches can not be accepted from > systems > >>>>>>>>>>>>>>>>>>>>> outside > >>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>> OpenJDK > >>>>>>>>>>>>>>>>>>>>> infrastructure and ... > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> I have also attached the patch (hg diff -g) for > >>>>>>>>>>>>>>>>>>>>>> reference. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> ... unfortunately patches tend to get stripped by the > >>>>>>>>>>>>>>>>>>>>> mail > >>>>>>>>>>>>>>>>>>>>> servers. > >>>>>>>>>>>>>>>>>>>>> If > >>>>>>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>> patch is small please include it inline. Otherwise > you > >>>>>>>>>>>>>>>>>>>>> will > >>>>>>>>>>>>>>>>>>>>> need > >>>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>> find > >>>>>>>>>>>>>>>>>>>>> an > >>>>>>>>>>>>>>>>>>>>> OpenJDK Author who can host it for you on > >>>>>>>>>>>>>>>>>>>>> cr.openjdk.java.net. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> 3) I have done regression testing using jtreg ($make > >>>>>>>>>>>>>>>>>>>>>> default) > >>>>>>>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>> didnt find any regressions. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Sounds good, but until I see the patch it is hard to > >>>>>>>>>>>>>>>>>>>>> comment > >>>>>>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>>> testing > >>>>>>>>>>>>>>>>>>>>> requirements. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>> David > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Thanks David, > >>>>>>>>>>>>>>>>>>>> Yes, it's a small patch. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp > >>>>>>>>>>>>>>>>>>>> @@ -1051,6 +1051,22 @@ > >>>>>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(UseSSE42Intrinsics, > >>>>>>>>>>>>>>>>>>>> false); > >>>>>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>>>>> + if (supports_sha()) { > >>>>>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA)) { > >>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, true); > >>>>>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>>>>> + } else if (UseSHA || UseSHA1Intrinsics || > >>>>>>>>>>>>>>>>>>>> UseSHA256Intrinsics > >>>>>>>>>>>>>>>>>>>> || > >>>>>>>>>>>>>>>>>>>> UseSHA512Intrinsics) { > >>>>>>>>>>>>>>>>>>>> + if (!FLAG_IS_DEFAULT(UseSHA) || > >>>>>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA1Intrinsics) || > >>>>>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA256Intrinsics) || > >>>>>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { > >>>>>>>>>>>>>>>>>>>> + warning("SHA instructions are not available > on > >>>>>>>>>>>>>>>>>>>> this > >>>>>>>>>>>>>>>>>>>> CPU"); > >>>>>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, false); > >>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA1Intrinsics, false); > >>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA256Intrinsics, false); > >>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); > >>>>>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> // some defaults for AMD family 15h > >>>>>>>>>>>>>>>>>>>> if ( cpu_family() == 0x15 ) { > >>>>>>>>>>>>>>>>>>>> @@ -1072,11 +1088,43 @@ > >>>>>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> #ifdef COMPILER2 > >>>>>>>>>>>>>>>>>>>> - if (MaxVectorSize > 16) { > >>>>>>>>>>>>>>>>>>>> - // Limit vectors size to 16 bytes on current > AMD > >>>>>>>>>>>>>>>>>>>> cpus. > >>>>>>>>>>>>>>>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { > >>>>>>>>>>>>>>>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < > >>>>>>>>>>>>>>>>>>>> 17h. > >>>>>>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); > >>>>>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>>>>> #endif // COMPILER2 > >>>>>>>>>>>>>>>>>>>> + > >>>>>>>>>>>>>>>>>>>> + // Some defaults for AMD family 17h > >>>>>>>>>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { > >>>>>>>>>>>>>>>>>>>> + // On family 17h processors use XMM and > >>>>>>>>>>>>>>>>>>>> UnalignedLoadStores > >>>>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>> Array Copy > >>>>>>>>>>>>>>>>>>>> + if (supports_sse2() && > >>>>>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseXMMForArrayCopy)) > >>>>>>>>>>>>>>>>>>>> { > >>>>>>>>>>>>>>>>>>>> + UseXMMForArrayCopy = true; > >>>>>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>>>>> + if (supports_sse2() && > >>>>>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) > >>>>>>>>>>>>>>>>>>>> { > >>>>>>>>>>>>>>>>>>>> + UseUnalignedLoadStores = true; > >>>>>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>>>>> + if (supports_bmi2() && > >>>>>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseBMI2Instructions)) > >>>>>>>>>>>>>>>>>>>> { > >>>>>>>>>>>>>>>>>>>> + UseBMI2Instructions = true; > >>>>>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>>>>> + if (MaxVectorSize > 32) { > >>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(MaxVectorSize, 32); > >>>>>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>>>>> + if (UseSHA) { > >>>>>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { > >>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, > false); > >>>>>>>>>>>>>>>>>>>> + } else if (UseSHA512Intrinsics) { > >>>>>>>>>>>>>>>>>>>> + warning("Intrinsics for SHA-384 and SHA-512 > >>>>>>>>>>>>>>>>>>>> crypto > >>>>>>>>>>>>>>>>>>>> hash > >>>>>>>>>>>>>>>>>>>> functions not available on this CPU."); > >>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, > false); > >>>>>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>>>>> +#ifdef COMPILER2 > >>>>>>>>>>>>>>>>>>>> + if (supports_sse4_2()) { > >>>>>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { > >>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); > >>>>>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>>>>> +#endif > >>>>>>>>>>>>>>>>>>>> + } > >>>>>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> if( is_intel() ) { // Intel cpus specific > >>>>>>>>>>>>>>>>>>>> settings > >>>>>>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp > >>>>>>>>>>>>>>>>>>>> @@ -513,6 +513,16 @@ > >>>>>>>>>>>>>>>>>>>> result |= CPU_LZCNT; > >>>>>>>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx. > bits.sse4a > >>>>>>>>>>>>>>>>>>>> != > >>>>>>>>>>>>>>>>>>>> 0) > >>>>>>>>>>>>>>>>>>>> result |= CPU_SSE4A; > >>>>>>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) > >>>>>>>>>>>>>>>>>>>> + result |= CPU_BMI2; > >>>>>>>>>>>>>>>>>>>> + if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) > >>>>>>>>>>>>>>>>>>>> + result |= CPU_HT; > >>>>>>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) > >>>>>>>>>>>>>>>>>>>> + result |= CPU_ADX; > >>>>>>>>>>>>>>>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) > >>>>>>>>>>>>>>>>>>>> + result |= CPU_SHA; > >>>>>>>>>>>>>>>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) > >>>>>>>>>>>>>>>>>>>> + result |= CPU_FMA; > >>>>>>>>>>>>>>>>>>>> } > >>>>>>>>>>>>>>>>>>>> // Intel features. > >>>>>>>>>>>>>>>>>>>> if(is_intel()) { > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>>>>>>>> Rohit > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>> > >>>>> > > From vladimir.kozlov at oracle.com Fri Nov 3 05:03:20 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Nov 2017 22:03:20 -0700 Subject: RFR: Newer AMD 17h (EPYC) Processor family defaults In-Reply-To: References: <4d4fe028-ea6a-4f77-ab69-5c2bc752e1f5@oracle.com> <47bc0a90-ed6a-220a-c3d1-b4df2d8bbc74@oracle.com> <9c53f889-e58e-33ac-3c05-874779b469d6@oracle.com> <45619e1a-9eb0-a540-193b-5187da3bf6bc@oracle.com> <66e4af43-c0e2-6d64-b69f-35166150ffa2@oracle.com> <11af0f62-ba6b-d533-d23c-750d2ca012c7@oracle.com> Message-ID: <5ea23f66-1ef6-e49e-b21b-dbd84d21e68e@oracle.com> It was pushed long ago - Oct 3, see: http://hg.openjdk.java.net/jdk10/hs/rev/fde01e0fccb4 https://bugs.openjdk.java.net/browse/JDK-8187219 But we have to repositories jdk10/jdk10 master and jdk10/hs for Hotspot changes. We did not promoted changes from jdk10/hs to jdk10/jdk10. Testing currently is under way to do promotion. But I can not say in which jdk 10 build it will happened. Look for push notification in JDK-8187219. Regards, Vladimir On 11/2/17 8:30 PM, Rohit Arul Raj wrote: > Hello Vladimir, > > Is there any update on pushing these changes to jdk10? > > Thanks, > Rohit > > On Fri, Sep 22, 2017 at 1:11 PM, Rohit Arul Raj > wrote: > >> Thanks Vladimir, >> >> On Wed, Sep 20, 2017 at 10:07 PM, Vladimir Kozlov >> wrote: >>>> __ cmpl(rax, 0x80000000); // Is cpuid(0x80000001) supported? >>>> __ jcc(Assembler::belowEqual, done); >>>> __ cmpl(rax, 0x80000004); // Is cpuid(0x80000005) supported? >>>> - __ jccb(Assembler::belowEqual, ext_cpuid1); >>>> + __ jcc(Assembler::belowEqual, ext_cpuid1); >>> >>> >>> Good. You may need to increase size of the buffer too (to be safe) to >> 1100: >>> >>> static const int stub_size = 1000; >>> >> >> Please find the updated patch after the requested change. >> >> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >> b/src/cpu/x86/vm/vm_version_x86.cpp >> --- a/src/cpu/x86/vm/vm_version_x86.cpp >> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >> @@ -46,7 +46,7 @@ >> address VM_Version::_cpuinfo_cont_addr = 0; >> >> static BufferBlob* stub_blob; >> -static const int stub_size = 1000; >> +static const int stub_size = 1100; >> >> extern "C" { >> typedef void (*get_cpu_info_stub_t)(void*); >> @@ -70,7 +70,7 @@ >> bool use_evex = FLAG_IS_DEFAULT(UseAVX) || (UseAVX > 2); >> >> Label detect_486, cpu486, detect_586, std_cpuid1, std_cpuid4; >> - Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, >> done, wrapup; >> + Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, >> ext_cpuid8, done, wrapup; >> Label legacy_setup, save_restore_except, legacy_save_restore, >> start_simd_check; >> >> StubCodeMark mark(this, "VM_Version", "get_cpu_info_stub"); >> @@ -267,14 +267,30 @@ >> __ cmpl(rax, 0x80000000); // Is cpuid(0x80000001) supported? >> __ jcc(Assembler::belowEqual, done); >> __ cmpl(rax, 0x80000004); // Is cpuid(0x80000005) supported? >> - __ jccb(Assembler::belowEqual, ext_cpuid1); >> + __ jcc(Assembler::belowEqual, ext_cpuid1); >> __ cmpl(rax, 0x80000006); // Is cpuid(0x80000007) supported? >> __ jccb(Assembler::belowEqual, ext_cpuid5); >> __ cmpl(rax, 0x80000007); // Is cpuid(0x80000008) supported? >> __ jccb(Assembler::belowEqual, ext_cpuid7); >> + __ cmpl(rax, 0x80000008); // Is cpuid(0x80000009 and above) >> supported? >> + __ jccb(Assembler::belowEqual, ext_cpuid8); >> + __ cmpl(rax, 0x8000001E); // Is cpuid(0x8000001E) supported? >> + __ jccb(Assembler::below, ext_cpuid8); >> + // >> + // Extended cpuid(0x8000001E) >> + // >> + __ movl(rax, 0x8000001E); >> + __ cpuid(); >> + __ lea(rsi, Address(rbp, in_bytes(VM_Version::ext_ >> cpuid1E_offset()))); >> + __ movl(Address(rsi, 0), rax); >> + __ movl(Address(rsi, 4), rbx); >> + __ movl(Address(rsi, 8), rcx); >> + __ movl(Address(rsi,12), rdx); >> + >> // >> // Extended cpuid(0x80000008) >> // >> + __ bind(ext_cpuid8); >> __ movl(rax, 0x80000008); >> __ cpuid(); >> __ lea(rsi, Address(rbp, in_bytes(VM_Version::ext_cpuid8_offset()))); >> @@ -1109,11 +1125,27 @@ >> } >> >> #ifdef COMPILER2 >> - if (MaxVectorSize > 16) { >> - // Limit vectors size to 16 bytes on current AMD cpus. >> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >> + // Limit vectors size to 16 bytes on AMD cpus < 17h. >> FLAG_SET_DEFAULT(MaxVectorSize, 16); >> } >> #endif // COMPILER2 >> + >> + // Some defaults for AMD family 17h >> + if ( cpu_family() == 0x17 ) { >> + // On family 17h processors use XMM and UnalignedLoadStores for >> Array Copy >> + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >> + } >> + if (supports_sse2() && FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { >> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); >> + } >> +#ifdef COMPILER2 >> + if (supports_sse4_2() && FLAG_IS_DEFAULT(UseFPUForSpilling)) { >> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >> + } >> +#endif >> + } >> } >> >> if( is_intel() ) { // Intel cpus specific settings >> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >> b/src/cpu/x86/vm/vm_version_x86.hpp >> --- a/src/cpu/x86/vm/vm_version_x86.hpp >> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >> @@ -228,6 +228,15 @@ >> } bits; >> }; >> >> + union ExtCpuid1EEbx { >> + uint32_t value; >> + struct { >> + uint32_t : 8, >> + threads_per_core : 8, >> + : 16; >> + } bits; >> + }; >> + >> union XemXcr0Eax { >> uint32_t value; >> struct { >> @@ -398,6 +407,12 @@ >> ExtCpuid8Ecx ext_cpuid8_ecx; >> uint32_t ext_cpuid8_edx; // reserved >> >> + // cpuid function 0x8000001E // AMD 17h >> + uint32_t ext_cpuid1E_eax; >> + ExtCpuid1EEbx ext_cpuid1E_ebx; // threads per core (AMD17h) >> + uint32_t ext_cpuid1E_ecx; >> + uint32_t ext_cpuid1E_edx; // unused currently >> + >> // extended control register XCR0 (the XFEATURE_ENABLED_MASK register) >> XemXcr0Eax xem_xcr0_eax; >> uint32_t xem_xcr0_edx; // reserved >> @@ -505,6 +520,14 @@ >> result |= CPU_CLMUL; >> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) >> result |= CPU_RTM; >> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >> + result |= CPU_ADX; >> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >> + result |= CPU_BMI2; >> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >> + result |= CPU_SHA; >> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >> + result |= CPU_FMA; >> >> // AMD features. >> if (is_amd()) { >> @@ -518,16 +541,8 @@ >> } >> // Intel features. >> if(is_intel()) { >> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >> - result |= CPU_ADX; >> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >> - result |= CPU_BMI2; >> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >> - result |= CPU_SHA; >> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >> result |= CPU_LZCNT; >> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >> - result |= CPU_FMA; >> // for Intel, ecx.bits.misalignsse bit (bit 8) indicates >> support for prefetchw >> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { >> result |= CPU_3DNOW_PREFETCH; >> @@ -590,6 +605,7 @@ >> static ByteSize ext_cpuid5_offset() { return >> byte_offset_of(CpuidInfo, ext_cpuid5_eax); } >> static ByteSize ext_cpuid7_offset() { return >> byte_offset_of(CpuidInfo, ext_cpuid7_eax); } >> static ByteSize ext_cpuid8_offset() { return >> byte_offset_of(CpuidInfo, ext_cpuid8_eax); } >> + static ByteSize ext_cpuid1E_offset() { return >> byte_offset_of(CpuidInfo, ext_cpuid1E_eax); } >> static ByteSize tpl_cpuidB0_offset() { return >> byte_offset_of(CpuidInfo, tpl_cpuidB0_eax); } >> static ByteSize tpl_cpuidB1_offset() { return >> byte_offset_of(CpuidInfo, tpl_cpuidB1_eax); } >> static ByteSize tpl_cpuidB2_offset() { return >> byte_offset_of(CpuidInfo, tpl_cpuidB2_eax); } >> @@ -673,8 +689,12 @@ >> if (is_intel() && supports_processor_topology()) { >> result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >> } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { >> - result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >> - cores_per_cpu(); >> + if (cpu_family() >= 0x17) { >> + result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; >> + } else { >> + result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >> + cores_per_cpu(); >> + } >> } >> return (result == 0 ? 1 : result); >> } >> >> Regards, >> Rohit >> >>>> >>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>>> b/src/cpu/x86/vm/vm_version_x86.cpp >>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>>> @@ -70,7 +70,7 @@ >>>> bool use_evex = FLAG_IS_DEFAULT(UseAVX) || (UseAVX > 2); >>>> >>>> Label detect_486, cpu486, detect_586, std_cpuid1, std_cpuid4; >>>> - Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, >>>> done, wrapup; >>>> + Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, >>>> ext_cpuid8, done, wrapup; >>>> Label legacy_setup, save_restore_except, legacy_save_restore, >>>> start_simd_check; >>>> >>>> StubCodeMark mark(this, "VM_Version", "get_cpu_info_stub"); >>>> @@ -267,14 +267,30 @@ >>>> __ cmpl(rax, 0x80000000); // Is cpuid(0x80000001) supported? >>>> __ jcc(Assembler::belowEqual, done); >>>> __ cmpl(rax, 0x80000004); // Is cpuid(0x80000005) supported? >>>> - __ jccb(Assembler::belowEqual, ext_cpuid1); >>>> + __ jcc(Assembler::belowEqual, ext_cpuid1); >>>> __ cmpl(rax, 0x80000006); // Is cpuid(0x80000007) supported? >>>> __ jccb(Assembler::belowEqual, ext_cpuid5); >>>> __ cmpl(rax, 0x80000007); // Is cpuid(0x80000008) supported? >>>> __ jccb(Assembler::belowEqual, ext_cpuid7); >>>> + __ cmpl(rax, 0x80000008); // Is cpuid(0x80000009 and above) >>>> supported? >>>> + __ jccb(Assembler::belowEqual, ext_cpuid8); >>>> + __ cmpl(rax, 0x8000001E); // Is cpuid(0x8000001E) supported? >>>> + __ jccb(Assembler::below, ext_cpuid8); >>>> + // >>>> + // Extended cpuid(0x8000001E) >>>> + // >>>> + __ movl(rax, 0x8000001E); >>>> + __ cpuid(); >>>> + __ lea(rsi, Address(rbp, >>>> in_bytes(VM_Version::ext_cpuid1E_offset()))); >>>> + __ movl(Address(rsi, 0), rax); >>>> + __ movl(Address(rsi, 4), rbx); >>>> + __ movl(Address(rsi, 8), rcx); >>>> + __ movl(Address(rsi,12), rdx); >>>> + >>>> // >>>> // Extended cpuid(0x80000008) >>>> // >>>> + __ bind(ext_cpuid8); >>>> __ movl(rax, 0x80000008); >>>> __ cpuid(); >>>> __ lea(rsi, Address(rbp, >>>> in_bytes(VM_Version::ext_cpuid8_offset()))); >>>> @@ -1109,11 +1125,27 @@ >>>> } >>>> >>>> #ifdef COMPILER2 >>>> - if (MaxVectorSize > 16) { >>>> - // Limit vectors size to 16 bytes on current AMD cpus. >>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. >>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>>> } >>>> #endif // COMPILER2 >>>> + >>>> + // Some defaults for AMD family 17h >>>> + if ( cpu_family() == 0x17 ) { >>>> + // On family 17h processors use XMM and UnalignedLoadStores for >>>> Array Copy >>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>> + } >>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseUnalignedLoadStores)) >> { >>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); >>>> + } >>>> +#ifdef COMPILER2 >>>> + if (supports_sse4_2() && FLAG_IS_DEFAULT(UseFPUForSpilling)) { >>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>>> + } >>>> +#endif >>>> + } >>>> } >>>> >>>> if( is_intel() ) { // Intel cpus specific settings >>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>>> b/src/cpu/x86/vm/vm_version_x86.hpp >>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>>> @@ -228,6 +228,15 @@ >>>> } bits; >>>> }; >>>> >>>> + union ExtCpuid1EEbx { >>>> + uint32_t value; >>>> + struct { >>>> + uint32_t : 8, >>>> + threads_per_core : 8, >>>> + : 16; >>>> + } bits; >>>> + }; >>>> + >>>> union XemXcr0Eax { >>>> uint32_t value; >>>> struct { >>>> @@ -398,6 +407,12 @@ >>>> ExtCpuid8Ecx ext_cpuid8_ecx; >>>> uint32_t ext_cpuid8_edx; // reserved >>>> >>>> + // cpuid function 0x8000001E // AMD 17h >>>> + uint32_t ext_cpuid1E_eax; >>>> + ExtCpuid1EEbx ext_cpuid1E_ebx; // threads per core (AMD17h) >>>> + uint32_t ext_cpuid1E_ecx; >>>> + uint32_t ext_cpuid1E_edx; // unused currently >>>> + >>>> // extended control register XCR0 (the XFEATURE_ENABLED_MASK >>>> register) >>>> XemXcr0Eax xem_xcr0_eax; >>>> uint32_t xem_xcr0_edx; // reserved >>>> @@ -505,6 +520,14 @@ >>>> result |= CPU_CLMUL; >>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) >>>> result |= CPU_RTM; >>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>> + result |= CPU_ADX; >>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>> + result |= CPU_BMI2; >>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>> + result |= CPU_SHA; >>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>> + result |= CPU_FMA; >>>> >>>> // AMD features. >>>> if (is_amd()) { >>>> @@ -518,16 +541,8 @@ >>>> } >>>> // Intel features. >>>> if(is_intel()) { >>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>> - result |= CPU_ADX; >>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>> - result |= CPU_BMI2; >>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>> - result |= CPU_SHA; >>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >>>> result |= CPU_LZCNT; >>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>> - result |= CPU_FMA; >>>> // for Intel, ecx.bits.misalignsse bit (bit 8) indicates >>>> support for prefetchw >>>> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { >>>> result |= CPU_3DNOW_PREFETCH; >>>> @@ -590,6 +605,7 @@ >>>> static ByteSize ext_cpuid5_offset() { return >>>> byte_offset_of(CpuidInfo, ext_cpuid5_eax); } >>>> static ByteSize ext_cpuid7_offset() { return >>>> byte_offset_of(CpuidInfo, ext_cpuid7_eax); } >>>> static ByteSize ext_cpuid8_offset() { return >>>> byte_offset_of(CpuidInfo, ext_cpuid8_eax); } >>>> + static ByteSize ext_cpuid1E_offset() { return >>>> byte_offset_of(CpuidInfo, ext_cpuid1E_eax); } >>>> static ByteSize tpl_cpuidB0_offset() { return >>>> byte_offset_of(CpuidInfo, tpl_cpuidB0_eax); } >>>> static ByteSize tpl_cpuidB1_offset() { return >>>> byte_offset_of(CpuidInfo, tpl_cpuidB1_eax); } >>>> static ByteSize tpl_cpuidB2_offset() { return >>>> byte_offset_of(CpuidInfo, tpl_cpuidB2_eax); } >>>> @@ -673,8 +689,12 @@ >>>> if (is_intel() && supports_processor_topology()) { >>>> result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >>>> } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { >>>> - result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >>>> - cores_per_cpu(); >>>> + if (cpu_family() >= 0x17) { >>>> + result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + >> 1; >>>> + } else { >>>> + result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >>>> + cores_per_cpu(); >>>> + } >>>> } >>>> return (result == 0 ? 1 : result); >>>> } >>>> >>>> Please let me know your comments. >>>> Thanks for your review. >>>> >>>> Regards, >>>> Rohit >>>> >>>>> >>>>> >>>>> On 9/11/17 9:52 PM, Rohit Arul Raj wrote: >>>>>> >>>>>> >>>>>> Hello David, >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 1. ExtCpuid1EEx >>>>>>>> >>>>>>>> Should this be ExtCpuid1EEbx? (I see the naming here is somewhat >>>>>>>> inconsistent - and potentially confusing: I would have preferred to >>>>>>>> see >>>>>>>> things like ExtCpuid_1E_Ebx, to make it clear.) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yes, I can change it accordingly. >>>>>>> >>>>>> >>>>>> I have attached the updated, re-tested patch as per your comments >> above. >>>>>> >>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>> @@ -70,7 +70,7 @@ >>>>>> bool use_evex = FLAG_IS_DEFAULT(UseAVX) || (UseAVX > 2); >>>>>> >>>>>> Label detect_486, cpu486, detect_586, std_cpuid1, std_cpuid4; >>>>>> - Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, >>>>>> done, wrapup; >>>>>> + Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, >>>>>> ext_cpuid8, done, wrapup; >>>>>> Label legacy_setup, save_restore_except, legacy_save_restore, >>>>>> start_simd_check; >>>>>> >>>>>> StubCodeMark mark(this, "VM_Version", "get_cpu_info_stub"); >>>>>> @@ -272,9 +272,23 @@ >>>>>> __ jccb(Assembler::belowEqual, ext_cpuid5); >>>>>> __ cmpl(rax, 0x80000007); // Is cpuid(0x80000008) >> supported? >>>>>> __ jccb(Assembler::belowEqual, ext_cpuid7); >>>>>> + __ cmpl(rax, 0x80000008); // Is cpuid(0x8000001E) supported? >>>>>> + __ jccb(Assembler::belowEqual, ext_cpuid8); >>>>>> + // >>>>>> + // Extended cpuid(0x8000001E) >>>>>> + // >>>>>> + __ movl(rax, 0x8000001E); >>>>>> + __ cpuid(); >>>>>> + __ lea(rsi, Address(rbp, >>>>>> in_bytes(VM_Version::ext_cpuid_1E_offset()))); >>>>>> + __ movl(Address(rsi, 0), rax); >>>>>> + __ movl(Address(rsi, 4), rbx); >>>>>> + __ movl(Address(rsi, 8), rcx); >>>>>> + __ movl(Address(rsi,12), rdx); >>>>>> + >>>>>> // >>>>>> // Extended cpuid(0x80000008) >>>>>> // >>>>>> + __ bind(ext_cpuid8); >>>>>> __ movl(rax, 0x80000008); >>>>>> __ cpuid(); >>>>>> __ lea(rsi, Address(rbp, >>>>>> in_bytes(VM_Version::ext_cpuid8_offset()))); >>>>>> @@ -1109,11 +1123,27 @@ >>>>>> } >>>>>> >>>>>> #ifdef COMPILER2 >>>>>> - if (MaxVectorSize > 16) { >>>>>> - // Limit vectors size to 16 bytes on current AMD cpus. >>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>>>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. >>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>>>>> } >>>>>> #endif // COMPILER2 >>>>>> + >>>>>> + // Some defaults for AMD family 17h >>>>>> + if ( cpu_family() == 0x17 ) { >>>>>> + // On family 17h processors use XMM and UnalignedLoadStores for >>>>>> Array Copy >>>>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>> + } >>>>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseUnalignedLoadStores)) >> { >>>>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); >>>>>> + } >>>>>> +#ifdef COMPILER2 >>>>>> + if (supports_sse4_2() && FLAG_IS_DEFAULT(UseFPUForSpilling)) { >>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>>>>> + } >>>>>> +#endif >>>>>> + } >>>>>> } >>>>>> >>>>>> if( is_intel() ) { // Intel cpus specific settings >>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>> @@ -228,6 +228,15 @@ >>>>>> } bits; >>>>>> }; >>>>>> >>>>>> + union ExtCpuid_1E_Ebx { >>>>>> + uint32_t value; >>>>>> + struct { >>>>>> + uint32_t : 8, >>>>>> + threads_per_core : 8, >>>>>> + : 16; >>>>>> + } bits; >>>>>> + }; >>>>>> + >>>>>> union XemXcr0Eax { >>>>>> uint32_t value; >>>>>> struct { >>>>>> @@ -398,6 +407,12 @@ >>>>>> ExtCpuid8Ecx ext_cpuid8_ecx; >>>>>> uint32_t ext_cpuid8_edx; // reserved >>>>>> >>>>>> + // cpuid function 0x8000001E // AMD 17h >>>>>> + uint32_t ext_cpuid_1E_eax; >>>>>> + ExtCpuid_1E_Ebx ext_cpuid_1E_ebx; // threads per core (AMD17h) >>>>>> + uint32_t ext_cpuid_1E_ecx; >>>>>> + uint32_t ext_cpuid_1E_edx; // unused currently >>>>>> + >>>>>> // extended control register XCR0 (the XFEATURE_ENABLED_MASK >>>>>> register) >>>>>> XemXcr0Eax xem_xcr0_eax; >>>>>> uint32_t xem_xcr0_edx; // reserved >>>>>> @@ -505,6 +520,14 @@ >>>>>> result |= CPU_CLMUL; >>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) >>>>>> result |= CPU_RTM; >>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>> + result |= CPU_ADX; >>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>> + result |= CPU_BMI2; >>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>> + result |= CPU_SHA; >>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>> + result |= CPU_FMA; >>>>>> >>>>>> // AMD features. >>>>>> if (is_amd()) { >>>>>> @@ -518,16 +541,8 @@ >>>>>> } >>>>>> // Intel features. >>>>>> if(is_intel()) { >>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>> - result |= CPU_ADX; >>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>> - result |= CPU_BMI2; >>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>> - result |= CPU_SHA; >>>>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >>>>>> result |= CPU_LZCNT; >>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>> - result |= CPU_FMA; >>>>>> // for Intel, ecx.bits.misalignsse bit (bit 8) indicates >>>>>> support for prefetchw >>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { >>>>>> result |= CPU_3DNOW_PREFETCH; >>>>>> @@ -590,6 +605,7 @@ >>>>>> static ByteSize ext_cpuid5_offset() { return >>>>>> byte_offset_of(CpuidInfo, ext_cpuid5_eax); } >>>>>> static ByteSize ext_cpuid7_offset() { return >>>>>> byte_offset_of(CpuidInfo, ext_cpuid7_eax); } >>>>>> static ByteSize ext_cpuid8_offset() { return >>>>>> byte_offset_of(CpuidInfo, ext_cpuid8_eax); } >>>>>> + static ByteSize ext_cpuid_1E_offset() { return >>>>>> byte_offset_of(CpuidInfo, ext_cpuid_1E_eax); } >>>>>> static ByteSize tpl_cpuidB0_offset() { return >>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB0_eax); } >>>>>> static ByteSize tpl_cpuidB1_offset() { return >>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB1_eax); } >>>>>> static ByteSize tpl_cpuidB2_offset() { return >>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB2_eax); } >>>>>> @@ -673,8 +689,11 @@ >>>>>> if (is_intel() && supports_processor_topology()) { >>>>>> result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >>>>>> } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { >>>>>> - result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >>>>>> - cores_per_cpu(); >>>>>> + if (cpu_family() >= 0x17) >>>>>> + result = _cpuid_info.ext_cpuid_1E_ebx.bits.threads_per_core >> + >>>>>> 1; >>>>>> + else >>>>>> + result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >>>>>> + cores_per_cpu(); >>>>>> } >>>>>> return (result == 0 ? 1 : result); >>>>>> } >>>>>> >>>>>> >>>>>> Please let me know your comments >>>>>> >>>>>> Thanks for your time. >>>>>> >>>>>> Regards, >>>>>> Rohit >>>>>> >>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> Reference: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://support.amd.com/TechDocs/54945_PPR_Family_17h_ >> Models_00h-0Fh.pdf >>>>>>>>> [Pg 82] >>>>>>>>> >>>>>>>>> CPUID_Fn8000001E_EBX [Core Identifiers] (CoreId) >>>>>>>>> 15:8 ThreadsPerCore: threads per core. Read-only. Reset: >>>>>>>>> XXh. >>>>>>>>> The number of threads per core is ThreadsPerCore+1. >>>>>>>>> >>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>> @@ -70,7 +70,7 @@ >>>>>>>>> bool use_evex = FLAG_IS_DEFAULT(UseAVX) || (UseAVX > 2); >>>>>>>>> >>>>>>>>> Label detect_486, cpu486, detect_586, std_cpuid1, >> std_cpuid4; >>>>>>>>> - Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, >> ext_cpuid7, >>>>>>>>> done, wrapup; >>>>>>>>> + Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, >> ext_cpuid7, >>>>>>>>> ext_cpuid8, done, wrapup; >>>>>>>>> Label legacy_setup, save_restore_except, >> legacy_save_restore, >>>>>>>>> start_simd_check; >>>>>>>>> >>>>>>>>> StubCodeMark mark(this, "VM_Version", "get_cpu_info_stub"); >>>>>>>>> @@ -272,9 +272,23 @@ >>>>>>>>> __ jccb(Assembler::belowEqual, ext_cpuid5); >>>>>>>>> __ cmpl(rax, 0x80000007); // Is cpuid(0x80000008) >>>>>>>>> supported? >>>>>>>>> __ jccb(Assembler::belowEqual, ext_cpuid7); >>>>>>>>> + __ cmpl(rax, 0x80000008); // Is cpuid(0x8000001E) >> supported? >>>>>>>>> + __ jccb(Assembler::belowEqual, ext_cpuid8); >>>>>>>>> + // >>>>>>>>> + // Extended cpuid(0x8000001E) >>>>>>>>> + // >>>>>>>>> + __ movl(rax, 0x8000001E); >>>>>>>>> + __ cpuid(); >>>>>>>>> + __ lea(rsi, Address(rbp, >>>>>>>>> in_bytes(VM_Version::ext_cpuid1E_offset()))); >>>>>>>>> + __ movl(Address(rsi, 0), rax); >>>>>>>>> + __ movl(Address(rsi, 4), rbx); >>>>>>>>> + __ movl(Address(rsi, 8), rcx); >>>>>>>>> + __ movl(Address(rsi,12), rdx); >>>>>>>>> + >>>>>>>>> // >>>>>>>>> // Extended cpuid(0x80000008) >>>>>>>>> // >>>>>>>>> + __ bind(ext_cpuid8); >>>>>>>>> __ movl(rax, 0x80000008); >>>>>>>>> __ cpuid(); >>>>>>>>> __ lea(rsi, Address(rbp, >>>>>>>>> in_bytes(VM_Version::ext_cpuid8_offset()))); >>>>>>>>> @@ -1109,11 +1123,27 @@ >>>>>>>>> } >>>>>>>>> >>>>>>>>> #ifdef COMPILER2 >>>>>>>>> - if (MaxVectorSize > 16) { >>>>>>>>> - // Limit vectors size to 16 bytes on current AMD cpus. >>>>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>>>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. >>>>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>>>>>>>> } >>>>>>>>> #endif // COMPILER2 >>>>>>>>> + >>>>>>>>> + // Some defaults for AMD family 17h >>>>>>>>> + if ( cpu_family() == 0x17 ) { >>>>>>>>> + // On family 17h processors use XMM and UnalignedLoadStores >>>>>>>>> for >>>>>>>>> Array Copy >>>>>>>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) >> { >>>>>>>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>>>>> + } >>>>>>>>> + if (supports_sse2() && >>>>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) >>>>>>>>> { >>>>>>>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); >>>>>>>>> + } >>>>>>>>> +#ifdef COMPILER2 >>>>>>>>> + if (supports_sse4_2() && FLAG_IS_DEFAULT(UseFPUForSpilling)) >> { >>>>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>>>>>>>> + } >>>>>>>>> +#endif >>>>>>>>> + } >>>>>>>>> } >>>>>>>>> >>>>>>>>> if( is_intel() ) { // Intel cpus specific settings >>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>> @@ -228,6 +228,15 @@ >>>>>>>>> } bits; >>>>>>>>> }; >>>>>>>>> >>>>>>>>> + union ExtCpuid1EEx { >>>>>>>>> + uint32_t value; >>>>>>>>> + struct { >>>>>>>>> + uint32_t : 8, >>>>>>>>> + threads_per_core : 8, >>>>>>>>> + : 16; >>>>>>>>> + } bits; >>>>>>>>> + }; >>>>>>>>> + >>>>>>>>> union XemXcr0Eax { >>>>>>>>> uint32_t value; >>>>>>>>> struct { >>>>>>>>> @@ -398,6 +407,12 @@ >>>>>>>>> ExtCpuid8Ecx ext_cpuid8_ecx; >>>>>>>>> uint32_t ext_cpuid8_edx; // reserved >>>>>>>>> >>>>>>>>> + // cpuid function 0x8000001E // AMD 17h >>>>>>>>> + uint32_t ext_cpuid1E_eax; >>>>>>>>> + ExtCpuid1EEx ext_cpuid1E_ebx; // threads per core (AMD17h) >>>>>>>>> + uint32_t ext_cpuid1E_ecx; >>>>>>>>> + uint32_t ext_cpuid1E_edx; // unused currently >>>>>>>>> + >>>>>>>>> // extended control register XCR0 (the >> XFEATURE_ENABLED_MASK >>>>>>>>> register) >>>>>>>>> XemXcr0Eax xem_xcr0_eax; >>>>>>>>> uint32_t xem_xcr0_edx; // reserved >>>>>>>>> @@ -505,6 +520,14 @@ >>>>>>>>> result |= CPU_CLMUL; >>>>>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) >>>>>>>>> result |= CPU_RTM; >>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>> + result |= CPU_ADX; >>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>> + result |= CPU_BMI2; >>>>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>> + result |= CPU_SHA; >>>>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>> + result |= CPU_FMA; >>>>>>>>> >>>>>>>>> // AMD features. >>>>>>>>> if (is_amd()) { >>>>>>>>> @@ -518,16 +541,8 @@ >>>>>>>>> } >>>>>>>>> // Intel features. >>>>>>>>> if(is_intel()) { >>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>> - result |= CPU_ADX; >>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>> - result |= CPU_BMI2; >>>>>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>> - result |= CPU_SHA; >>>>>>>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >>>>>>>>> result |= CPU_LZCNT; >>>>>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>> - result |= CPU_FMA; >>>>>>>>> // for Intel, ecx.bits.misalignsse bit (bit 8) indicates >>>>>>>>> support for prefetchw >>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { >>>>>>>>> result |= CPU_3DNOW_PREFETCH; >>>>>>>>> @@ -590,6 +605,7 @@ >>>>>>>>> static ByteSize ext_cpuid5_offset() { return >>>>>>>>> byte_offset_of(CpuidInfo, ext_cpuid5_eax); } >>>>>>>>> static ByteSize ext_cpuid7_offset() { return >>>>>>>>> byte_offset_of(CpuidInfo, ext_cpuid7_eax); } >>>>>>>>> static ByteSize ext_cpuid8_offset() { return >>>>>>>>> byte_offset_of(CpuidInfo, ext_cpuid8_eax); } >>>>>>>>> + static ByteSize ext_cpuid1E_offset() { return >>>>>>>>> byte_offset_of(CpuidInfo, ext_cpuid1E_eax); } >>>>>>>>> static ByteSize tpl_cpuidB0_offset() { return >>>>>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB0_eax); } >>>>>>>>> static ByteSize tpl_cpuidB1_offset() { return >>>>>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB1_eax); } >>>>>>>>> static ByteSize tpl_cpuidB2_offset() { return >>>>>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB2_eax); } >>>>>>>>> @@ -673,8 +689,11 @@ >>>>>>>>> if (is_intel() && supports_processor_topology()) { >>>>>>>>> result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >>>>>>>>> } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { >>>>>>>>> - result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >>>>>>>>> - cores_per_cpu(); >>>>>>>>> + if (cpu_family() >= 0x17) >>>>>>>>> + result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core >> + >>>>>>>>> 1; >>>>>>>>> + else >>>>>>>>> + result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu >> / >>>>>>>>> + cores_per_cpu(); >>>>>>>>> } >>>>>>>>> return (result == 0 ? 1 : result); >>>>>>>>> } >>>>>>>>> >>>>>>>>> I have attached the patch for review. >>>>>>>>> Please let me know your comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Rohit >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>> >>>>>>>>>>> No comments on AMD specific changes. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>> On 5/09/2017 3:43 PM, David Holmes wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 5/09/2017 3:29 PM, Rohit Arul Raj wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Hello David, >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Sep 5, 2017 at 10:31 AM, David Holmes >>>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Rohit, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I was unable to apply your patch to latest jdk10/hs/hotspot >>>>>>>>>>>>>> repo. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I checked out the latest jdk10/hs/hotspot [parent: >>>>>>>>>>>>> 13548:1a9c2e07a826] >>>>>>>>>>>>> and was able to apply the patch >>>>>>>>>>>>> [epyc-amd17h-defaults-3Sept.patch] >>>>>>>>>>>>> without any issues. >>>>>>>>>>>>> Can you share the error message that you are getting? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I was getting this: >>>>>>>>>>>> >>>>>>>>>>>> applying hotspot.patch >>>>>>>>>>>> patching file src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>> Hunk #1 FAILED at 1108 >>>>>>>>>>>> 1 out of 1 hunks FAILED -- saving rejects to file >>>>>>>>>>>> src/cpu/x86/vm/vm_version_x86.cpp.rej >>>>>>>>>>>> patching file src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>> Hunk #2 FAILED at 522 >>>>>>>>>>>> 1 out of 2 hunks FAILED -- saving rejects to file >>>>>>>>>>>> src/cpu/x86/vm/vm_version_x86.hpp.rej >>>>>>>>>>>> abort: patch failed to apply >>>>>>>>>>>> >>>>>>>>>>>> but I started again and this time it applied fine, so not sure >>>>>>>>>>>> what >>>>>>>>>>>> was >>>>>>>>>>>> going on there. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> Rohit >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 4/09/2017 2:42 AM, Rohit Arul Raj wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello Vladimir, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, Sep 2, 2017 at 11:25 PM, Vladimir Kozlov >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Rohit, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9/2/17 1:16 AM, Rohit Arul Raj wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello Vladimir, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Changes look good. Only question I have is about >>>>>>>>>>>>>>>>>> MaxVectorSize. >>>>>>>>>>>>>>>>>> It >>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>> set >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 16 only in presence of AVX: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/ >> 046eab27258f/src/cpu/x86/vm/vm_version_x86.cpp#l945 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Does that code works for AMD 17h too? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks for pointing that out. Yes, the code works fine for >>>>>>>>>>>>>>>>> AMD >>>>>>>>>>>>>>>>> 17h. >>>>>>>>>>>>>>>>> So >>>>>>>>>>>>>>>>> I have removed the surplus check for MaxVectorSize from my >>>>>>>>>>>>>>>>> patch. >>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>> have updated, re-tested and attached the patch. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Which check you removed? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My older patch had the below mentioned check which was >> required >>>>>>>>>>>>>>> on >>>>>>>>>>>>>>> JDK9 where the default MaxVectorSize was 64. It has been >>>>>>>>>>>>>>> handled >>>>>>>>>>>>>>> better in openJDK10. So this check is not required anymore. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> + // Some defaults for AMD family 17h >>>>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> + if (MaxVectorSize > 32) { >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(MaxVectorSize, 32); >>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>> .. >>>>>>>>>>>>>>> .. >>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have one query regarding the setting of UseSHA flag: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/ >> 046eab27258f/src/cpu/x86/vm/vm_version_x86.cpp#l821 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> AMD 17h has support for SHA. >>>>>>>>>>>>>>>>> AMD 15h doesn't have support for SHA. Still "UseSHA" flag >>>>>>>>>>>>>>>>> gets >>>>>>>>>>>>>>>>> enabled for it based on the availability of BMI2 and AVX2. >> Is >>>>>>>>>>>>>>>>> there >>>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>>> underlying reason for this? I have handled this in the >> patch >>>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>> wanted to confirm. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It was done with next changes which use only AVX2 and BMI2 >>>>>>>>>>>>>>>> instructions >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> calculate SHA-256: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/ >> 6a17c49de974 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I don't know if AMD 15h supports these instructions and can >>>>>>>>>>>>>>>> execute >>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> code. You need to test it. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ok, got it. Since AMD15h has support for AVX2 and BMI2 >>>>>>>>>>>>>>> instructions, >>>>>>>>>>>>>>> it should work. >>>>>>>>>>>>>>> Confirmed by running following sanity tests: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ./hotspot/test/compiler/intrinsics/sha/sanity/ >> TestSHA1Intrinsics.java >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ./hotspot/test/compiler/intrinsics/sha/sanity/ >> TestSHA512Intrinsics.java >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ./hotspot/test/compiler/intrinsics/sha/sanity/ >> TestSHA256Intrinsics.java >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So I have removed those SHA checks from my patch too. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please find attached updated, re-tested patch. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>> @@ -1109,11 +1109,27 @@ >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> #ifdef COMPILER2 >>>>>>>>>>>>>>> - if (MaxVectorSize > 16) { >>>>>>>>>>>>>>> - // Limit vectors size to 16 bytes on current AMD cpus. >>>>>>>>>>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>>>>>>>>>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. >>>>>>>>>>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> #endif // COMPILER2 >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> + // Some defaults for AMD family 17h >>>>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { >>>>>>>>>>>>>>> + // On family 17h processors use XMM and >>>>>>>>>>>>>>> UnalignedLoadStores >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> Array Copy >>>>>>>>>>>>>>> + if (supports_sse2() && >>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>> + if (supports_sse2() && >>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) >>>>>>>>>>>>>>> { >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); >>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>> +#ifdef COMPILER2 >>>>>>>>>>>>>>> + if (supports_sse4_2() && >>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseFPUForSpilling)) >>>>>>>>>>>>>>> { >>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>> +#endif >>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> if( is_intel() ) { // Intel cpus specific settings >>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>> @@ -505,6 +505,14 @@ >>>>>>>>>>>>>>> result |= CPU_CLMUL; >>>>>>>>>>>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) >>>>>>>>>>>>>>> result |= CPU_RTM; >>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>>>>>>> + result |= CPU_ADX; >>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>>>>>>> + result |= CPU_BMI2; >>>>>>>>>>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>>>>>>> + result |= CPU_SHA; >>>>>>>>>>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>>>>>>> + result |= CPU_FMA; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> // AMD features. >>>>>>>>>>>>>>> if (is_amd()) { >>>>>>>>>>>>>>> @@ -515,19 +523,13 @@ >>>>>>>>>>>>>>> result |= CPU_LZCNT; >>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.sse4a != 0) >>>>>>>>>>>>>>> result |= CPU_SSE4A; >>>>>>>>>>>>>>> + if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) >>>>>>>>>>>>>>> + result |= CPU_HT; >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> // Intel features. >>>>>>>>>>>>>>> if(is_intel()) { >>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>>>>>>> - result |= CPU_ADX; >>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>>>>>>> - result |= CPU_BMI2; >>>>>>>>>>>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>>>>>>> - result |= CPU_SHA; >>>>>>>>>>>>>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel >> != >>>>>>>>>>>>>>> 0) >>>>>>>>>>>>>>> result |= CPU_LZCNT; >>>>>>>>>>>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>>>>>>> - result |= CPU_FMA; >>>>>>>>>>>>>>> // for Intel, ecx.bits.misalignsse bit (bit 8) >>>>>>>>>>>>>>> indicates >>>>>>>>>>>>>>> support for prefetchw >>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse >> != >>>>>>>>>>>>>>> 0) >>>>>>>>>>>>>>> { >>>>>>>>>>>>>>> result |= CPU_3DNOW_PREFETCH; >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please let me know your comments. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks for your time. >>>>>>>>>>>>>>> Rohit >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks for taking time to review the code. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>> @@ -1088,6 +1088,22 @@ >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(UseSSE42Intrinsics, false); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> + if (supports_sha()) { >>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA)) { >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, true); >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> + } else if (UseSHA || UseSHA1Intrinsics || >>>>>>>>>>>>>>>>> UseSHA256Intrinsics >>>>>>>>>>>>>>>>> || >>>>>>>>>>>>>>>>> UseSHA512Intrinsics) { >>>>>>>>>>>>>>>>> + if (!FLAG_IS_DEFAULT(UseSHA) || >>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA1Intrinsics) || >>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA256Intrinsics) || >>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { >>>>>>>>>>>>>>>>> + warning("SHA instructions are not available on >> this >>>>>>>>>>>>>>>>> CPU"); >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, false); >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA1Intrinsics, false); >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA256Intrinsics, false); >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> // some defaults for AMD family 15h >>>>>>>>>>>>>>>>> if ( cpu_family() == 0x15 ) { >>>>>>>>>>>>>>>>> @@ -1109,11 +1125,40 @@ >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> #ifdef COMPILER2 >>>>>>>>>>>>>>>>> - if (MaxVectorSize > 16) { >>>>>>>>>>>>>>>>> - // Limit vectors size to 16 bytes on current AMD >> cpus. >>>>>>>>>>>>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>>>>>>>>>>>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. >>>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> #endif // COMPILER2 >>>>>>>>>>>>>>>>> + >>>>>>>>>>>>>>>>> + // Some defaults for AMD family 17h >>>>>>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { >>>>>>>>>>>>>>>>> + // On family 17h processors use XMM and >>>>>>>>>>>>>>>>> UnalignedLoadStores >>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>> Array Copy >>>>>>>>>>>>>>>>> + if (supports_sse2() && >>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseXMMForArrayCopy)) >>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> + if (supports_sse2() && >>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> + if (supports_bmi2() && >>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseBMI2Instructions)) >>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseBMI2Instructions, true); >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> + if (UseSHA) { >>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >>>>>>>>>>>>>>>>> + } else if (UseSHA512Intrinsics) { >>>>>>>>>>>>>>>>> + warning("Intrinsics for SHA-384 and SHA-512 >> crypto >>>>>>>>>>>>>>>>> hash >>>>>>>>>>>>>>>>> functions not available on this CPU."); >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> +#ifdef COMPILER2 >>>>>>>>>>>>>>>>> + if (supports_sse4_2()) { >>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { >>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> +#endif >>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> if( is_intel() ) { // Intel cpus specific settings >>>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>> @@ -505,6 +505,14 @@ >>>>>>>>>>>>>>>>> result |= CPU_CLMUL; >>>>>>>>>>>>>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) >>>>>>>>>>>>>>>>> result |= CPU_RTM; >>>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>>>>>>>>> + result |= CPU_ADX; >>>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>>>>>>>>> + result |= CPU_BMI2; >>>>>>>>>>>>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>>>>>>>>> + result |= CPU_SHA; >>>>>>>>>>>>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>>>>>>>>> + result |= CPU_FMA; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> // AMD features. >>>>>>>>>>>>>>>>> if (is_amd()) { >>>>>>>>>>>>>>>>> @@ -515,19 +523,13 @@ >>>>>>>>>>>>>>>>> result |= CPU_LZCNT; >>>>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.sse4a != >> 0) >>>>>>>>>>>>>>>>> result |= CPU_SSE4A; >>>>>>>>>>>>>>>>> + if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) >>>>>>>>>>>>>>>>> + result |= CPU_HT; >>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>> // Intel features. >>>>>>>>>>>>>>>>> if(is_intel()) { >>>>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>>>>>>>>> - result |= CPU_ADX; >>>>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>>>>>>>>> - result |= CPU_BMI2; >>>>>>>>>>>>>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>>>>>>>>> - result |= CPU_SHA; >>>>>>>>>>>>>>>>> if(_cpuid_info.ext_cpuid1_ecx. >> bits.lzcnt_intel >>>>>>>>>>>>>>>>> != >>>>>>>>>>>>>>>>> 0) >>>>>>>>>>>>>>>>> result |= CPU_LZCNT; >>>>>>>>>>>>>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>>>>>>>>> - result |= CPU_FMA; >>>>>>>>>>>>>>>>> // for Intel, ecx.bits.misalignsse bit (bit 8) >>>>>>>>>>>>>>>>> indicates >>>>>>>>>>>>>>>>> support for prefetchw >>>>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx. >> bits.misalignsse >>>>>>>>>>>>>>>>> != >>>>>>>>>>>>>>>>> 0) { >>>>>>>>>>>>>>>>> result |= CPU_3DNOW_PREFETCH; >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> Rohit >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 9/1/17 8:04 AM, Rohit Arul Raj wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Sep 1, 2017 at 10:27 AM, Rohit Arul Raj >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Sep 1, 2017 at 3:01 AM, David Holmes >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Rohit, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I think the patch needs updating for jdk10 as I already >>>>>>>>>>>>>>>>>>>>> see >>>>>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>>> lot of >>>>>>>>>>>>>>>>>>>>> logic >>>>>>>>>>>>>>>>>>>>> around UseSHA in vm_version_x86.cpp. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks David, I will update the patch wrt JDK10 source >>>>>>>>>>>>>>>>>>>> base, >>>>>>>>>>>>>>>>>>>> test >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> resubmit for review. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>> Rohit >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I have updated the patch wrt openjdk10/hotspot (parent: >>>>>>>>>>>>>>>>>>> 13519:71337910df60), did regression testing using jtreg >>>>>>>>>>>>>>>>>>> ($make >>>>>>>>>>>>>>>>>>> default) and didnt find any regressions. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Can anyone please volunteer to review this patch which >>>>>>>>>>>>>>>>>>> sets >>>>>>>>>>>>>>>>>>> flag/ISA >>>>>>>>>>>>>>>>>>> defaults for newer AMD 17h (EPYC) processor? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ************************* Patch >>>>>>>>>>>>>>>>>>> **************************** >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>>>> @@ -1088,6 +1088,22 @@ >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(UseSSE42Intrinsics, >> false); >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>> + if (supports_sha()) { >>>>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA)) { >>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, true); >>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>> + } else if (UseSHA || UseSHA1Intrinsics || >>>>>>>>>>>>>>>>>>> UseSHA256Intrinsics >>>>>>>>>>>>>>>>>>> || >>>>>>>>>>>>>>>>>>> UseSHA512Intrinsics) { >>>>>>>>>>>>>>>>>>> + if (!FLAG_IS_DEFAULT(UseSHA) || >>>>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA1Intrinsics) || >>>>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA256Intrinsics) || >>>>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { >>>>>>>>>>>>>>>>>>> + warning("SHA instructions are not available on >>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>> CPU"); >>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, false); >>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA1Intrinsics, false); >>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA256Intrinsics, false); >>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> // some defaults for AMD family 15h >>>>>>>>>>>>>>>>>>> if ( cpu_family() == 0x15 ) { >>>>>>>>>>>>>>>>>>> @@ -1109,11 +1125,43 @@ >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> #ifdef COMPILER2 >>>>>>>>>>>>>>>>>>> - if (MaxVectorSize > 16) { >>>>>>>>>>>>>>>>>>> - // Limit vectors size to 16 bytes on current AMD >>>>>>>>>>>>>>>>>>> cpus. >>>>>>>>>>>>>>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>>>>>>>>>>>>>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < >> 17h. >>>>>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>> #endif // COMPILER2 >>>>>>>>>>>>>>>>>>> + >>>>>>>>>>>>>>>>>>> + // Some defaults for AMD family 17h >>>>>>>>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { >>>>>>>>>>>>>>>>>>> + // On family 17h processors use XMM and >>>>>>>>>>>>>>>>>>> UnalignedLoadStores >>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>> Array Copy >>>>>>>>>>>>>>>>>>> + if (supports_sse2() && >>>>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseXMMForArrayCopy)) >>>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>>> + UseXMMForArrayCopy = true; >>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>> + if (supports_sse2() && >>>>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) >>>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>>> + UseUnalignedLoadStores = true; >>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>> + if (supports_bmi2() && >>>>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseBMI2Instructions)) { >>>>>>>>>>>>>>>>>>> + UseBMI2Instructions = true; >>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>> + if (MaxVectorSize > 32) { >>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(MaxVectorSize, 32); >>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>> + if (UseSHA) { >>>>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { >>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >>>>>>>>>>>>>>>>>>> + } else if (UseSHA512Intrinsics) { >>>>>>>>>>>>>>>>>>> + warning("Intrinsics for SHA-384 and SHA-512 >>>>>>>>>>>>>>>>>>> crypto >>>>>>>>>>>>>>>>>>> hash >>>>>>>>>>>>>>>>>>> functions not available on this CPU."); >>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>> +#ifdef COMPILER2 >>>>>>>>>>>>>>>>>>> + if (supports_sse4_2()) { >>>>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { >>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>> +#endif >>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> if( is_intel() ) { // Intel cpus specific >>>>>>>>>>>>>>>>>>> settings >>>>>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>>>> @@ -505,6 +505,14 @@ >>>>>>>>>>>>>>>>>>> result |= CPU_CLMUL; >>>>>>>>>>>>>>>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != >> 0) >>>>>>>>>>>>>>>>>>> result |= CPU_RTM; >>>>>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>>>>>>>>>>> + result |= CPU_ADX; >>>>>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>>>>>>>>>>> + result |= CPU_BMI2; >>>>>>>>>>>>>>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>>>>>>>>>>> + result |= CPU_SHA; >>>>>>>>>>>>>>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>>>>>>>>>>> + result |= CPU_FMA; >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> // AMD features. >>>>>>>>>>>>>>>>>>> if (is_amd()) { >>>>>>>>>>>>>>>>>>> @@ -515,19 +523,13 @@ >>>>>>>>>>>>>>>>>>> result |= CPU_LZCNT; >>>>>>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.sse4a >> != >>>>>>>>>>>>>>>>>>> 0) >>>>>>>>>>>>>>>>>>> result |= CPU_SSE4A; >>>>>>>>>>>>>>>>>>> + if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) >>>>>>>>>>>>>>>>>>> + result |= CPU_HT; >>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>> // Intel features. >>>>>>>>>>>>>>>>>>> if(is_intel()) { >>>>>>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>>>>>>>>>>> - result |= CPU_ADX; >>>>>>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>>>>>>>>>>> - result |= CPU_BMI2; >>>>>>>>>>>>>>>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>>>>>>>>>>> - result |= CPU_SHA; >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel >>>>>>>>>>>>>>>>>>> != 0) >>>>>>>>>>>>>>>>>>> result |= CPU_LZCNT; >>>>>>>>>>>>>>>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>>>>>>>>>>> - result |= CPU_FMA; >>>>>>>>>>>>>>>>>>> // for Intel, ecx.bits.misalignsse bit (bit >>>>>>>>>>>>>>>>>>> 8) >>>>>>>>>>>>>>>>>>> indicates >>>>>>>>>>>>>>>>>>> support for prefetchw >>>>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>>> (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse >>>>>>>>>>>>>>>>>>> != >>>>>>>>>>>>>>>>>>> 0) { >>>>>>>>>>>>>>>>>>> result |= CPU_3DNOW_PREFETCH; >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> ****************************** >> ******************************** >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Rohit >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 1/09/2017 1:11 AM, Rohit Arul Raj wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Aug 31, 2017 at 5:59 PM, David Holmes >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Hi Rohit, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 31/08/2017 7:03 PM, Rohit Arul Raj wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I would like an volunteer to review this patch >>>>>>>>>>>>>>>>>>>>>>>> (openJDK9) >>>>>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>>>>> sets >>>>>>>>>>>>>>>>>>>>>>>> flag/ISA defaults for newer AMD 17h (EPYC) processor >>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>> help >>>>>>>>>>>>>>>>>>>>>>>> us >>>>>>>>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>>>>> the commit process. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/ >> 08bsxaxupg8kbam/AADurTXLGIZ6C-tiIAi_Glyka?dl=0 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Unfortunately patches can not be accepted from >> systems >>>>>>>>>>>>>>>>>>>>>>> outside >>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> OpenJDK >>>>>>>>>>>>>>>>>>>>>>> infrastructure and ... >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I have also attached the patch (hg diff -g) for >>>>>>>>>>>>>>>>>>>>>>>> reference. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> ... unfortunately patches tend to get stripped by the >>>>>>>>>>>>>>>>>>>>>>> mail >>>>>>>>>>>>>>>>>>>>>>> servers. >>>>>>>>>>>>>>>>>>>>>>> If >>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> patch is small please include it inline. Otherwise >> you >>>>>>>>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>>>>>>>> need >>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>> find >>>>>>>>>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>>>>>>>>> OpenJDK Author who can host it for you on >>>>>>>>>>>>>>>>>>>>>>> cr.openjdk.java.net. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 3) I have done regression testing using jtreg ($make >>>>>>>>>>>>>>>>>>>>>>>> default) >>>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>> didnt find any regressions. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Sounds good, but until I see the patch it is hard to >>>>>>>>>>>>>>>>>>>>>>> comment >>>>>>>>>>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>>>> testing >>>>>>>>>>>>>>>>>>>>>>> requirements. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks David, >>>>>>>>>>>>>>>>>>>>>> Yes, it's a small patch. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>>>>>>> @@ -1051,6 +1051,22 @@ >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(UseSSE42Intrinsics, >>>>>>>>>>>>>>>>>>>>>> false); >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> + if (supports_sha()) { >>>>>>>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA)) { >>>>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, true); >>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>> + } else if (UseSHA || UseSHA1Intrinsics || >>>>>>>>>>>>>>>>>>>>>> UseSHA256Intrinsics >>>>>>>>>>>>>>>>>>>>>> || >>>>>>>>>>>>>>>>>>>>>> UseSHA512Intrinsics) { >>>>>>>>>>>>>>>>>>>>>> + if (!FLAG_IS_DEFAULT(UseSHA) || >>>>>>>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA1Intrinsics) || >>>>>>>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA256Intrinsics) || >>>>>>>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { >>>>>>>>>>>>>>>>>>>>>> + warning("SHA instructions are not available >> on >>>>>>>>>>>>>>>>>>>>>> this >>>>>>>>>>>>>>>>>>>>>> CPU"); >>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, false); >>>>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA1Intrinsics, false); >>>>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA256Intrinsics, false); >>>>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> // some defaults for AMD family 15h >>>>>>>>>>>>>>>>>>>>>> if ( cpu_family() == 0x15 ) { >>>>>>>>>>>>>>>>>>>>>> @@ -1072,11 +1088,43 @@ >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> #ifdef COMPILER2 >>>>>>>>>>>>>>>>>>>>>> - if (MaxVectorSize > 16) { >>>>>>>>>>>>>>>>>>>>>> - // Limit vectors size to 16 bytes on current >> AMD >>>>>>>>>>>>>>>>>>>>>> cpus. >>>>>>>>>>>>>>>>>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>>>>>>>>>>>>>>>>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < >>>>>>>>>>>>>>>>>>>>>> 17h. >>>>>>>>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> #endif // COMPILER2 >>>>>>>>>>>>>>>>>>>>>> + >>>>>>>>>>>>>>>>>>>>>> + // Some defaults for AMD family 17h >>>>>>>>>>>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { >>>>>>>>>>>>>>>>>>>>>> + // On family 17h processors use XMM and >>>>>>>>>>>>>>>>>>>>>> UnalignedLoadStores >>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>> Array Copy >>>>>>>>>>>>>>>>>>>>>> + if (supports_sse2() && >>>>>>>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseXMMForArrayCopy)) >>>>>>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>>>>>> + UseXMMForArrayCopy = true; >>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>> + if (supports_sse2() && >>>>>>>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) >>>>>>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>>>>>> + UseUnalignedLoadStores = true; >>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>> + if (supports_bmi2() && >>>>>>>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseBMI2Instructions)) >>>>>>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>>>>>> + UseBMI2Instructions = true; >>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>> + if (MaxVectorSize > 32) { >>>>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(MaxVectorSize, 32); >>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>> + if (UseSHA) { >>>>>>>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { >>>>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, >> false); >>>>>>>>>>>>>>>>>>>>>> + } else if (UseSHA512Intrinsics) { >>>>>>>>>>>>>>>>>>>>>> + warning("Intrinsics for SHA-384 and SHA-512 >>>>>>>>>>>>>>>>>>>>>> crypto >>>>>>>>>>>>>>>>>>>>>> hash >>>>>>>>>>>>>>>>>>>>>> functions not available on this CPU."); >>>>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, >> false); >>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>> +#ifdef COMPILER2 >>>>>>>>>>>>>>>>>>>>>> + if (supports_sse4_2()) { >>>>>>>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { >>>>>>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>> +#endif >>>>>>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> if( is_intel() ) { // Intel cpus specific >>>>>>>>>>>>>>>>>>>>>> settings >>>>>>>>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>>>>>>> @@ -513,6 +513,16 @@ >>>>>>>>>>>>>>>>>>>>>> result |= CPU_LZCNT; >>>>>>>>>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx. >> bits.sse4a >>>>>>>>>>>>>>>>>>>>>> != >>>>>>>>>>>>>>>>>>>>>> 0) >>>>>>>>>>>>>>>>>>>>>> result |= CPU_SSE4A; >>>>>>>>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>>>>>>>>>>>>>> + result |= CPU_BMI2; >>>>>>>>>>>>>>>>>>>>>> + if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) >>>>>>>>>>>>>>>>>>>>>> + result |= CPU_HT; >>>>>>>>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>>>>>>>>>>>>>> + result |= CPU_ADX; >>>>>>>>>>>>>>>>>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>>>>>>>>>>>>>> + result |= CPU_SHA; >>>>>>>>>>>>>>>>>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>>>>>>>>>>>>>> + result |= CPU_FMA; >>>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>>> // Intel features. >>>>>>>>>>>>>>>>>>>>>> if(is_intel()) { >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>>>>>>> Rohit >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >> From rohitarulraj at gmail.com Fri Nov 3 07:21:33 2017 From: rohitarulraj at gmail.com (Rohit Arul Raj) Date: Fri, 3 Nov 2017 12:51:33 +0530 Subject: RFR: Newer AMD 17h (EPYC) Processor family defaults In-Reply-To: <5ea23f66-1ef6-e49e-b21b-dbd84d21e68e@oracle.com> References: <4d4fe028-ea6a-4f77-ab69-5c2bc752e1f5@oracle.com> <47bc0a90-ed6a-220a-c3d1-b4df2d8bbc74@oracle.com> <9c53f889-e58e-33ac-3c05-874779b469d6@oracle.com> <45619e1a-9eb0-a540-193b-5187da3bf6bc@oracle.com> <66e4af43-c0e2-6d64-b69f-35166150ffa2@oracle.com> <11af0f62-ba6b-d533-d23c-750d2ca012c7@oracle.com> <5ea23f66-1ef6-e49e-b21b-dbd84d21e68e@oracle.com> Message-ID: Vladimir, Thanks for the info. Regards, Rohit On Fri, Nov 3, 2017 at 10:33 AM, Vladimir Kozlov wrote: > It was pushed long ago - Oct 3, see: > > http://hg.openjdk.java.net/jdk10/hs/rev/fde01e0fccb4 > https://bugs.openjdk.java.net/browse/JDK-8187219 > > But we have to repositories jdk10/jdk10 master and jdk10/hs for Hotspot > changes. We did not promoted changes from jdk10/hs to jdk10/jdk10. Testing > currently is under way to do promotion. But I can not say in which jdk 10 > build it will happened. Look for push notification in JDK-8187219. > > Regards, > Vladimir > > On 11/2/17 8:30 PM, Rohit Arul Raj wrote: > >> Hello Vladimir, >> >> Is there any update on pushing these changes to jdk10? >> >> Thanks, >> Rohit >> >> On Fri, Sep 22, 2017 at 1:11 PM, Rohit Arul Raj >> wrote: >> >> Thanks Vladimir, >>> >>> On Wed, Sep 20, 2017 at 10:07 PM, Vladimir Kozlov >>> wrote: >>> >>>> __ cmpl(rax, 0x80000000); // Is cpuid(0x80000001) supported? >>>>> __ jcc(Assembler::belowEqual, done); >>>>> __ cmpl(rax, 0x80000004); // Is cpuid(0x80000005) supported? >>>>> - __ jccb(Assembler::belowEqual, ext_cpuid1); >>>>> + __ jcc(Assembler::belowEqual, ext_cpuid1); >>>>> >>>> >>>> >>>> Good. You may need to increase size of the buffer too (to be safe) to >>>> >>> 1100: >>> >>>> >>>> static const int stub_size = 1000; >>>> >>>> >>> Please find the updated patch after the requested change. >>> >>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>> b/src/cpu/x86/vm/vm_version_x86.cpp >>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>> @@ -46,7 +46,7 @@ >>> address VM_Version::_cpuinfo_cont_addr = 0; >>> >>> static BufferBlob* stub_blob; >>> -static const int stub_size = 1000; >>> +static const int stub_size = 1100; >>> >>> extern "C" { >>> typedef void (*get_cpu_info_stub_t)(void*); >>> @@ -70,7 +70,7 @@ >>> bool use_evex = FLAG_IS_DEFAULT(UseAVX) || (UseAVX > 2); >>> >>> Label detect_486, cpu486, detect_586, std_cpuid1, std_cpuid4; >>> - Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, >>> done, wrapup; >>> + Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, >>> ext_cpuid8, done, wrapup; >>> Label legacy_setup, save_restore_except, legacy_save_restore, >>> start_simd_check; >>> >>> StubCodeMark mark(this, "VM_Version", "get_cpu_info_stub"); >>> @@ -267,14 +267,30 @@ >>> __ cmpl(rax, 0x80000000); // Is cpuid(0x80000001) supported? >>> __ jcc(Assembler::belowEqual, done); >>> __ cmpl(rax, 0x80000004); // Is cpuid(0x80000005) supported? >>> - __ jccb(Assembler::belowEqual, ext_cpuid1); >>> + __ jcc(Assembler::belowEqual, ext_cpuid1); >>> __ cmpl(rax, 0x80000006); // Is cpuid(0x80000007) supported? >>> __ jccb(Assembler::belowEqual, ext_cpuid5); >>> __ cmpl(rax, 0x80000007); // Is cpuid(0x80000008) supported? >>> __ jccb(Assembler::belowEqual, ext_cpuid7); >>> + __ cmpl(rax, 0x80000008); // Is cpuid(0x80000009 and above) >>> supported? >>> + __ jccb(Assembler::belowEqual, ext_cpuid8); >>> + __ cmpl(rax, 0x8000001E); // Is cpuid(0x8000001E) supported? >>> + __ jccb(Assembler::below, ext_cpuid8); >>> + // >>> + // Extended cpuid(0x8000001E) >>> + // >>> + __ movl(rax, 0x8000001E); >>> + __ cpuid(); >>> + __ lea(rsi, Address(rbp, in_bytes(VM_Version::ext_ >>> cpuid1E_offset()))); >>> + __ movl(Address(rsi, 0), rax); >>> + __ movl(Address(rsi, 4), rbx); >>> + __ movl(Address(rsi, 8), rcx); >>> + __ movl(Address(rsi,12), rdx); >>> + >>> // >>> // Extended cpuid(0x80000008) >>> // >>> + __ bind(ext_cpuid8); >>> __ movl(rax, 0x80000008); >>> __ cpuid(); >>> __ lea(rsi, Address(rbp, in_bytes(VM_Version::ext_cpuid >>> 8_offset()))); >>> @@ -1109,11 +1125,27 @@ >>> } >>> >>> #ifdef COMPILER2 >>> - if (MaxVectorSize > 16) { >>> - // Limit vectors size to 16 bytes on current AMD cpus. >>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. >>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>> } >>> #endif // COMPILER2 >>> + >>> + // Some defaults for AMD family 17h >>> + if ( cpu_family() == 0x17 ) { >>> + // On family 17h processors use XMM and UnalignedLoadStores for >>> Array Copy >>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>> + } >>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { >>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); >>> + } >>> +#ifdef COMPILER2 >>> + if (supports_sse4_2() && FLAG_IS_DEFAULT(UseFPUForSpilling)) { >>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>> + } >>> +#endif >>> + } >>> } >>> >>> if( is_intel() ) { // Intel cpus specific settings >>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>> b/src/cpu/x86/vm/vm_version_x86.hpp >>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>> @@ -228,6 +228,15 @@ >>> } bits; >>> }; >>> >>> + union ExtCpuid1EEbx { >>> + uint32_t value; >>> + struct { >>> + uint32_t : 8, >>> + threads_per_core : 8, >>> + : 16; >>> + } bits; >>> + }; >>> + >>> union XemXcr0Eax { >>> uint32_t value; >>> struct { >>> @@ -398,6 +407,12 @@ >>> ExtCpuid8Ecx ext_cpuid8_ecx; >>> uint32_t ext_cpuid8_edx; // reserved >>> >>> + // cpuid function 0x8000001E // AMD 17h >>> + uint32_t ext_cpuid1E_eax; >>> + ExtCpuid1EEbx ext_cpuid1E_ebx; // threads per core (AMD17h) >>> + uint32_t ext_cpuid1E_ecx; >>> + uint32_t ext_cpuid1E_edx; // unused currently >>> + >>> // extended control register XCR0 (the XFEATURE_ENABLED_MASK >>> register) >>> XemXcr0Eax xem_xcr0_eax; >>> uint32_t xem_xcr0_edx; // reserved >>> @@ -505,6 +520,14 @@ >>> result |= CPU_CLMUL; >>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) >>> result |= CPU_RTM; >>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>> + result |= CPU_ADX; >>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>> + result |= CPU_BMI2; >>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>> + result |= CPU_SHA; >>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>> + result |= CPU_FMA; >>> >>> // AMD features. >>> if (is_amd()) { >>> @@ -518,16 +541,8 @@ >>> } >>> // Intel features. >>> if(is_intel()) { >>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>> - result |= CPU_ADX; >>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>> - result |= CPU_BMI2; >>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>> - result |= CPU_SHA; >>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >>> result |= CPU_LZCNT; >>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>> - result |= CPU_FMA; >>> // for Intel, ecx.bits.misalignsse bit (bit 8) indicates >>> support for prefetchw >>> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { >>> result |= CPU_3DNOW_PREFETCH; >>> @@ -590,6 +605,7 @@ >>> static ByteSize ext_cpuid5_offset() { return >>> byte_offset_of(CpuidInfo, ext_cpuid5_eax); } >>> static ByteSize ext_cpuid7_offset() { return >>> byte_offset_of(CpuidInfo, ext_cpuid7_eax); } >>> static ByteSize ext_cpuid8_offset() { return >>> byte_offset_of(CpuidInfo, ext_cpuid8_eax); } >>> + static ByteSize ext_cpuid1E_offset() { return >>> byte_offset_of(CpuidInfo, ext_cpuid1E_eax); } >>> static ByteSize tpl_cpuidB0_offset() { return >>> byte_offset_of(CpuidInfo, tpl_cpuidB0_eax); } >>> static ByteSize tpl_cpuidB1_offset() { return >>> byte_offset_of(CpuidInfo, tpl_cpuidB1_eax); } >>> static ByteSize tpl_cpuidB2_offset() { return >>> byte_offset_of(CpuidInfo, tpl_cpuidB2_eax); } >>> @@ -673,8 +689,12 @@ >>> if (is_intel() && supports_processor_topology()) { >>> result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >>> } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { >>> - result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >>> - cores_per_cpu(); >>> + if (cpu_family() >= 0x17) { >>> + result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + 1; >>> + } else { >>> + result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >>> + cores_per_cpu(); >>> + } >>> } >>> return (result == 0 ? 1 : result); >>> } >>> >>> Regards, >>> Rohit >>> >>> >>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>>>> b/src/cpu/x86/vm/vm_version_x86.cpp >>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>>>> @@ -70,7 +70,7 @@ >>>>> bool use_evex = FLAG_IS_DEFAULT(UseAVX) || (UseAVX > 2); >>>>> >>>>> Label detect_486, cpu486, detect_586, std_cpuid1, std_cpuid4; >>>>> - Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, >>>>> done, wrapup; >>>>> + Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, >>>>> ext_cpuid8, done, wrapup; >>>>> Label legacy_setup, save_restore_except, legacy_save_restore, >>>>> start_simd_check; >>>>> >>>>> StubCodeMark mark(this, "VM_Version", "get_cpu_info_stub"); >>>>> @@ -267,14 +267,30 @@ >>>>> __ cmpl(rax, 0x80000000); // Is cpuid(0x80000001) supported? >>>>> __ jcc(Assembler::belowEqual, done); >>>>> __ cmpl(rax, 0x80000004); // Is cpuid(0x80000005) supported? >>>>> - __ jccb(Assembler::belowEqual, ext_cpuid1); >>>>> + __ jcc(Assembler::belowEqual, ext_cpuid1); >>>>> __ cmpl(rax, 0x80000006); // Is cpuid(0x80000007) supported? >>>>> __ jccb(Assembler::belowEqual, ext_cpuid5); >>>>> __ cmpl(rax, 0x80000007); // Is cpuid(0x80000008) supported? >>>>> __ jccb(Assembler::belowEqual, ext_cpuid7); >>>>> + __ cmpl(rax, 0x80000008); // Is cpuid(0x80000009 and above) >>>>> supported? >>>>> + __ jccb(Assembler::belowEqual, ext_cpuid8); >>>>> + __ cmpl(rax, 0x8000001E); // Is cpuid(0x8000001E) supported? >>>>> + __ jccb(Assembler::below, ext_cpuid8); >>>>> + // >>>>> + // Extended cpuid(0x8000001E) >>>>> + // >>>>> + __ movl(rax, 0x8000001E); >>>>> + __ cpuid(); >>>>> + __ lea(rsi, Address(rbp, >>>>> in_bytes(VM_Version::ext_cpuid1E_offset()))); >>>>> + __ movl(Address(rsi, 0), rax); >>>>> + __ movl(Address(rsi, 4), rbx); >>>>> + __ movl(Address(rsi, 8), rcx); >>>>> + __ movl(Address(rsi,12), rdx); >>>>> + >>>>> // >>>>> // Extended cpuid(0x80000008) >>>>> // >>>>> + __ bind(ext_cpuid8); >>>>> __ movl(rax, 0x80000008); >>>>> __ cpuid(); >>>>> __ lea(rsi, Address(rbp, >>>>> in_bytes(VM_Version::ext_cpuid8_offset()))); >>>>> @@ -1109,11 +1125,27 @@ >>>>> } >>>>> >>>>> #ifdef COMPILER2 >>>>> - if (MaxVectorSize > 16) { >>>>> - // Limit vectors size to 16 bytes on current AMD cpus. >>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. >>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>>>> } >>>>> #endif // COMPILER2 >>>>> + >>>>> + // Some defaults for AMD family 17h >>>>> + if ( cpu_family() == 0x17 ) { >>>>> + // On family 17h processors use XMM and UnalignedLoadStores for >>>>> Array Copy >>>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>> + } >>>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseUnalignedLoadStores)) >>>>> >>>> { >>> >>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); >>>>> + } >>>>> +#ifdef COMPILER2 >>>>> + if (supports_sse4_2() && FLAG_IS_DEFAULT(UseFPUForSpilling)) { >>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>>>> + } >>>>> +#endif >>>>> + } >>>>> } >>>>> >>>>> if( is_intel() ) { // Intel cpus specific settings >>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>>>> b/src/cpu/x86/vm/vm_version_x86.hpp >>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>>>> @@ -228,6 +228,15 @@ >>>>> } bits; >>>>> }; >>>>> >>>>> + union ExtCpuid1EEbx { >>>>> + uint32_t value; >>>>> + struct { >>>>> + uint32_t : 8, >>>>> + threads_per_core : 8, >>>>> + : 16; >>>>> + } bits; >>>>> + }; >>>>> + >>>>> union XemXcr0Eax { >>>>> uint32_t value; >>>>> struct { >>>>> @@ -398,6 +407,12 @@ >>>>> ExtCpuid8Ecx ext_cpuid8_ecx; >>>>> uint32_t ext_cpuid8_edx; // reserved >>>>> >>>>> + // cpuid function 0x8000001E // AMD 17h >>>>> + uint32_t ext_cpuid1E_eax; >>>>> + ExtCpuid1EEbx ext_cpuid1E_ebx; // threads per core (AMD17h) >>>>> + uint32_t ext_cpuid1E_ecx; >>>>> + uint32_t ext_cpuid1E_edx; // unused currently >>>>> + >>>>> // extended control register XCR0 (the XFEATURE_ENABLED_MASK >>>>> register) >>>>> XemXcr0Eax xem_xcr0_eax; >>>>> uint32_t xem_xcr0_edx; // reserved >>>>> @@ -505,6 +520,14 @@ >>>>> result |= CPU_CLMUL; >>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) >>>>> result |= CPU_RTM; >>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>> + result |= CPU_ADX; >>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>> + result |= CPU_BMI2; >>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>> + result |= CPU_SHA; >>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>> + result |= CPU_FMA; >>>>> >>>>> // AMD features. >>>>> if (is_amd()) { >>>>> @@ -518,16 +541,8 @@ >>>>> } >>>>> // Intel features. >>>>> if(is_intel()) { >>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>> - result |= CPU_ADX; >>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>> - result |= CPU_BMI2; >>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>> - result |= CPU_SHA; >>>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >>>>> result |= CPU_LZCNT; >>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>> - result |= CPU_FMA; >>>>> // for Intel, ecx.bits.misalignsse bit (bit 8) indicates >>>>> support for prefetchw >>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { >>>>> result |= CPU_3DNOW_PREFETCH; >>>>> @@ -590,6 +605,7 @@ >>>>> static ByteSize ext_cpuid5_offset() { return >>>>> byte_offset_of(CpuidInfo, ext_cpuid5_eax); } >>>>> static ByteSize ext_cpuid7_offset() { return >>>>> byte_offset_of(CpuidInfo, ext_cpuid7_eax); } >>>>> static ByteSize ext_cpuid8_offset() { return >>>>> byte_offset_of(CpuidInfo, ext_cpuid8_eax); } >>>>> + static ByteSize ext_cpuid1E_offset() { return >>>>> byte_offset_of(CpuidInfo, ext_cpuid1E_eax); } >>>>> static ByteSize tpl_cpuidB0_offset() { return >>>>> byte_offset_of(CpuidInfo, tpl_cpuidB0_eax); } >>>>> static ByteSize tpl_cpuidB1_offset() { return >>>>> byte_offset_of(CpuidInfo, tpl_cpuidB1_eax); } >>>>> static ByteSize tpl_cpuidB2_offset() { return >>>>> byte_offset_of(CpuidInfo, tpl_cpuidB2_eax); } >>>>> @@ -673,8 +689,12 @@ >>>>> if (is_intel() && supports_processor_topology()) { >>>>> result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >>>>> } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { >>>>> - result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >>>>> - cores_per_cpu(); >>>>> + if (cpu_family() >= 0x17) { >>>>> + result = _cpuid_info.ext_cpuid1E_ebx.bits.threads_per_core + >>>>> >>>> 1; >>> >>>> + } else { >>>>> + result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >>>>> + cores_per_cpu(); >>>>> + } >>>>> } >>>>> return (result == 0 ? 1 : result); >>>>> } >>>>> >>>>> Please let me know your comments. >>>>> Thanks for your review. >>>>> >>>>> Regards, >>>>> Rohit >>>>> >>>>> >>>>>> >>>>>> On 9/11/17 9:52 PM, Rohit Arul Raj wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> Hello David, >>>>>>> >>>>>>> >>>>>>>>> >>>>>>>>> 1. ExtCpuid1EEx >>>>>>>>> >>>>>>>>> Should this be ExtCpuid1EEbx? (I see the naming here is somewhat >>>>>>>>> inconsistent - and potentially confusing: I would have preferred to >>>>>>>>> see >>>>>>>>> things like ExtCpuid_1E_Ebx, to make it clear.) >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yes, I can change it accordingly. >>>>>>>> >>>>>>>> >>>>>>> I have attached the updated, re-tested patch as per your comments >>>>>>> >>>>>> above. >>> >>>> >>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>> @@ -70,7 +70,7 @@ >>>>>>> bool use_evex = FLAG_IS_DEFAULT(UseAVX) || (UseAVX > 2); >>>>>>> >>>>>>> Label detect_486, cpu486, detect_586, std_cpuid1, std_cpuid4; >>>>>>> - Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, >>>>>>> done, wrapup; >>>>>>> + Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, ext_cpuid7, >>>>>>> ext_cpuid8, done, wrapup; >>>>>>> Label legacy_setup, save_restore_except, legacy_save_restore, >>>>>>> start_simd_check; >>>>>>> >>>>>>> StubCodeMark mark(this, "VM_Version", "get_cpu_info_stub"); >>>>>>> @@ -272,9 +272,23 @@ >>>>>>> __ jccb(Assembler::belowEqual, ext_cpuid5); >>>>>>> __ cmpl(rax, 0x80000007); // Is cpuid(0x80000008) >>>>>>> >>>>>> supported? >>> >>>> __ jccb(Assembler::belowEqual, ext_cpuid7); >>>>>>> + __ cmpl(rax, 0x80000008); // Is cpuid(0x8000001E) supported? >>>>>>> + __ jccb(Assembler::belowEqual, ext_cpuid8); >>>>>>> + // >>>>>>> + // Extended cpuid(0x8000001E) >>>>>>> + // >>>>>>> + __ movl(rax, 0x8000001E); >>>>>>> + __ cpuid(); >>>>>>> + __ lea(rsi, Address(rbp, >>>>>>> in_bytes(VM_Version::ext_cpuid_1E_offset()))); >>>>>>> + __ movl(Address(rsi, 0), rax); >>>>>>> + __ movl(Address(rsi, 4), rbx); >>>>>>> + __ movl(Address(rsi, 8), rcx); >>>>>>> + __ movl(Address(rsi,12), rdx); >>>>>>> + >>>>>>> // >>>>>>> // Extended cpuid(0x80000008) >>>>>>> // >>>>>>> + __ bind(ext_cpuid8); >>>>>>> __ movl(rax, 0x80000008); >>>>>>> __ cpuid(); >>>>>>> __ lea(rsi, Address(rbp, >>>>>>> in_bytes(VM_Version::ext_cpuid8_offset()))); >>>>>>> @@ -1109,11 +1123,27 @@ >>>>>>> } >>>>>>> >>>>>>> #ifdef COMPILER2 >>>>>>> - if (MaxVectorSize > 16) { >>>>>>> - // Limit vectors size to 16 bytes on current AMD cpus. >>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. >>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>>>>>> } >>>>>>> #endif // COMPILER2 >>>>>>> + >>>>>>> + // Some defaults for AMD family 17h >>>>>>> + if ( cpu_family() == 0x17 ) { >>>>>>> + // On family 17h processors use XMM and UnalignedLoadStores >>>>>>> for >>>>>>> Array Copy >>>>>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>>>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>>> + } >>>>>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseUnalignedLo >>>>>>> adStores)) >>>>>>> >>>>>> { >>> >>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); >>>>>>> + } >>>>>>> +#ifdef COMPILER2 >>>>>>> + if (supports_sse4_2() && FLAG_IS_DEFAULT(UseFPUForSpilling)) >>>>>>> { >>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>>>>>> + } >>>>>>> +#endif >>>>>>> + } >>>>>>> } >>>>>>> >>>>>>> if( is_intel() ) { // Intel cpus specific settings >>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>> @@ -228,6 +228,15 @@ >>>>>>> } bits; >>>>>>> }; >>>>>>> >>>>>>> + union ExtCpuid_1E_Ebx { >>>>>>> + uint32_t value; >>>>>>> + struct { >>>>>>> + uint32_t : 8, >>>>>>> + threads_per_core : 8, >>>>>>> + : 16; >>>>>>> + } bits; >>>>>>> + }; >>>>>>> + >>>>>>> union XemXcr0Eax { >>>>>>> uint32_t value; >>>>>>> struct { >>>>>>> @@ -398,6 +407,12 @@ >>>>>>> ExtCpuid8Ecx ext_cpuid8_ecx; >>>>>>> uint32_t ext_cpuid8_edx; // reserved >>>>>>> >>>>>>> + // cpuid function 0x8000001E // AMD 17h >>>>>>> + uint32_t ext_cpuid_1E_eax; >>>>>>> + ExtCpuid_1E_Ebx ext_cpuid_1E_ebx; // threads per core (AMD17h) >>>>>>> + uint32_t ext_cpuid_1E_ecx; >>>>>>> + uint32_t ext_cpuid_1E_edx; // unused currently >>>>>>> + >>>>>>> // extended control register XCR0 (the XFEATURE_ENABLED_MASK >>>>>>> register) >>>>>>> XemXcr0Eax xem_xcr0_eax; >>>>>>> uint32_t xem_xcr0_edx; // reserved >>>>>>> @@ -505,6 +520,14 @@ >>>>>>> result |= CPU_CLMUL; >>>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) >>>>>>> result |= CPU_RTM; >>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>> + result |= CPU_ADX; >>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>> + result |= CPU_BMI2; >>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>> + result |= CPU_SHA; >>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>> + result |= CPU_FMA; >>>>>>> >>>>>>> // AMD features. >>>>>>> if (is_amd()) { >>>>>>> @@ -518,16 +541,8 @@ >>>>>>> } >>>>>>> // Intel features. >>>>>>> if(is_intel()) { >>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>> - result |= CPU_ADX; >>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>> - result |= CPU_BMI2; >>>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>> - result |= CPU_SHA; >>>>>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >>>>>>> result |= CPU_LZCNT; >>>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>> - result |= CPU_FMA; >>>>>>> // for Intel, ecx.bits.misalignsse bit (bit 8) indicates >>>>>>> support for prefetchw >>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) { >>>>>>> result |= CPU_3DNOW_PREFETCH; >>>>>>> @@ -590,6 +605,7 @@ >>>>>>> static ByteSize ext_cpuid5_offset() { return >>>>>>> byte_offset_of(CpuidInfo, ext_cpuid5_eax); } >>>>>>> static ByteSize ext_cpuid7_offset() { return >>>>>>> byte_offset_of(CpuidInfo, ext_cpuid7_eax); } >>>>>>> static ByteSize ext_cpuid8_offset() { return >>>>>>> byte_offset_of(CpuidInfo, ext_cpuid8_eax); } >>>>>>> + static ByteSize ext_cpuid_1E_offset() { return >>>>>>> byte_offset_of(CpuidInfo, ext_cpuid_1E_eax); } >>>>>>> static ByteSize tpl_cpuidB0_offset() { return >>>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB0_eax); } >>>>>>> static ByteSize tpl_cpuidB1_offset() { return >>>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB1_eax); } >>>>>>> static ByteSize tpl_cpuidB2_offset() { return >>>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB2_eax); } >>>>>>> @@ -673,8 +689,11 @@ >>>>>>> if (is_intel() && supports_processor_topology()) { >>>>>>> result = _cpuid_info.tpl_cpuidB0_ebx.bits.logical_cpus; >>>>>>> } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { >>>>>>> - result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >>>>>>> - cores_per_cpu(); >>>>>>> + if (cpu_family() >= 0x17) >>>>>>> + result = _cpuid_info.ext_cpuid_1E_ebx.bits.threads_per_core >>>>>>> >>>>>> + >>> >>>> 1; >>>>>>> + else >>>>>>> + result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >>>>>>> + cores_per_cpu(); >>>>>>> } >>>>>>> return (result == 0 ? 1 : result); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> Please let me know your comments >>>>>>> >>>>>>> Thanks for your time. >>>>>>> >>>>>>> Regards, >>>>>>> Rohit >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>> Reference: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://support.amd.com/TechDocs/54945_PPR_Family_17h_ >>>>>>>>>> >>>>>>>>> Models_00h-0Fh.pdf >>> >>>> [Pg 82] >>>>>>>>>> >>>>>>>>>> CPUID_Fn8000001E_EBX [Core Identifiers] (CoreId) >>>>>>>>>> 15:8 ThreadsPerCore: threads per core. Read-only. Reset: >>>>>>>>>> XXh. >>>>>>>>>> The number of threads per core is ThreadsPerCore+1. >>>>>>>>>> >>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>> @@ -70,7 +70,7 @@ >>>>>>>>>> bool use_evex = FLAG_IS_DEFAULT(UseAVX) || (UseAVX > 2); >>>>>>>>>> >>>>>>>>>> Label detect_486, cpu486, detect_586, std_cpuid1, >>>>>>>>>> >>>>>>>>> std_cpuid4; >>> >>>> - Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, >>>>>>>>>> >>>>>>>>> ext_cpuid7, >>> >>>> done, wrapup; >>>>>>>>>> + Label sef_cpuid, ext_cpuid, ext_cpuid1, ext_cpuid5, >>>>>>>>>> >>>>>>>>> ext_cpuid7, >>> >>>> ext_cpuid8, done, wrapup; >>>>>>>>>> Label legacy_setup, save_restore_except, >>>>>>>>>> >>>>>>>>> legacy_save_restore, >>> >>>> start_simd_check; >>>>>>>>>> >>>>>>>>>> StubCodeMark mark(this, "VM_Version", >>>>>>>>>> "get_cpu_info_stub"); >>>>>>>>>> @@ -272,9 +272,23 @@ >>>>>>>>>> __ jccb(Assembler::belowEqual, ext_cpuid5); >>>>>>>>>> __ cmpl(rax, 0x80000007); // Is cpuid(0x80000008) >>>>>>>>>> supported? >>>>>>>>>> __ jccb(Assembler::belowEqual, ext_cpuid7); >>>>>>>>>> + __ cmpl(rax, 0x80000008); // Is cpuid(0x8000001E) >>>>>>>>>> >>>>>>>>> supported? >>> >>>> + __ jccb(Assembler::belowEqual, ext_cpuid8); >>>>>>>>>> + // >>>>>>>>>> + // Extended cpuid(0x8000001E) >>>>>>>>>> + // >>>>>>>>>> + __ movl(rax, 0x8000001E); >>>>>>>>>> + __ cpuid(); >>>>>>>>>> + __ lea(rsi, Address(rbp, >>>>>>>>>> in_bytes(VM_Version::ext_cpuid1E_offset()))); >>>>>>>>>> + __ movl(Address(rsi, 0), rax); >>>>>>>>>> + __ movl(Address(rsi, 4), rbx); >>>>>>>>>> + __ movl(Address(rsi, 8), rcx); >>>>>>>>>> + __ movl(Address(rsi,12), rdx); >>>>>>>>>> + >>>>>>>>>> // >>>>>>>>>> // Extended cpuid(0x80000008) >>>>>>>>>> // >>>>>>>>>> + __ bind(ext_cpuid8); >>>>>>>>>> __ movl(rax, 0x80000008); >>>>>>>>>> __ cpuid(); >>>>>>>>>> __ lea(rsi, Address(rbp, >>>>>>>>>> in_bytes(VM_Version::ext_cpuid8_offset()))); >>>>>>>>>> @@ -1109,11 +1123,27 @@ >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> #ifdef COMPILER2 >>>>>>>>>> - if (MaxVectorSize > 16) { >>>>>>>>>> - // Limit vectors size to 16 bytes on current AMD cpus. >>>>>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>>>>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. >>>>>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>>>>>>>>> } >>>>>>>>>> #endif // COMPILER2 >>>>>>>>>> + >>>>>>>>>> + // Some defaults for AMD family 17h >>>>>>>>>> + if ( cpu_family() == 0x17 ) { >>>>>>>>>> + // On family 17h processors use XMM and UnalignedLoadStores >>>>>>>>>> for >>>>>>>>>> Array Copy >>>>>>>>>> + if (supports_sse2() && FLAG_IS_DEFAULT(UseXMMForArray >>>>>>>>>> Copy)) >>>>>>>>>> >>>>>>>>> { >>> >>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>>>>>> + } >>>>>>>>>> + if (supports_sse2() && >>>>>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) >>>>>>>>>> { >>>>>>>>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); >>>>>>>>>> + } >>>>>>>>>> +#ifdef COMPILER2 >>>>>>>>>> + if (supports_sse4_2() && FLAG_IS_DEFAULT(UseFPUForSpill >>>>>>>>>> ing)) >>>>>>>>>> >>>>>>>>> { >>> >>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>>>>>>>>> + } >>>>>>>>>> +#endif >>>>>>>>>> + } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> if( is_intel() ) { // Intel cpus specific settings >>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>> @@ -228,6 +228,15 @@ >>>>>>>>>> } bits; >>>>>>>>>> }; >>>>>>>>>> >>>>>>>>>> + union ExtCpuid1EEx { >>>>>>>>>> + uint32_t value; >>>>>>>>>> + struct { >>>>>>>>>> + uint32_t : 8, >>>>>>>>>> + threads_per_core : 8, >>>>>>>>>> + : 16; >>>>>>>>>> + } bits; >>>>>>>>>> + }; >>>>>>>>>> + >>>>>>>>>> union XemXcr0Eax { >>>>>>>>>> uint32_t value; >>>>>>>>>> struct { >>>>>>>>>> @@ -398,6 +407,12 @@ >>>>>>>>>> ExtCpuid8Ecx ext_cpuid8_ecx; >>>>>>>>>> uint32_t ext_cpuid8_edx; // reserved >>>>>>>>>> >>>>>>>>>> + // cpuid function 0x8000001E // AMD 17h >>>>>>>>>> + uint32_t ext_cpuid1E_eax; >>>>>>>>>> + ExtCpuid1EEx ext_cpuid1E_ebx; // threads per core (AMD17h) >>>>>>>>>> + uint32_t ext_cpuid1E_ecx; >>>>>>>>>> + uint32_t ext_cpuid1E_edx; // unused currently >>>>>>>>>> + >>>>>>>>>> // extended control register XCR0 (the >>>>>>>>>> >>>>>>>>> XFEATURE_ENABLED_MASK >>> >>>> register) >>>>>>>>>> XemXcr0Eax xem_xcr0_eax; >>>>>>>>>> uint32_t xem_xcr0_edx; // reserved >>>>>>>>>> @@ -505,6 +520,14 @@ >>>>>>>>>> result |= CPU_CLMUL; >>>>>>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) >>>>>>>>>> result |= CPU_RTM; >>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>> + result |= CPU_ADX; >>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>> + result |= CPU_BMI2; >>>>>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>> + result |= CPU_SHA; >>>>>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>> + result |= CPU_FMA; >>>>>>>>>> >>>>>>>>>> // AMD features. >>>>>>>>>> if (is_amd()) { >>>>>>>>>> @@ -518,16 +541,8 @@ >>>>>>>>>> } >>>>>>>>>> // Intel features. >>>>>>>>>> if(is_intel()) { >>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>> - result |= CPU_ADX; >>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>> - result |= CPU_BMI2; >>>>>>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>> - result |= CPU_SHA; >>>>>>>>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel != 0) >>>>>>>>>> result |= CPU_LZCNT; >>>>>>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>> - result |= CPU_FMA; >>>>>>>>>> // for Intel, ecx.bits.misalignsse bit (bit 8) >>>>>>>>>> indicates >>>>>>>>>> support for prefetchw >>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.misalignsse != 0) >>>>>>>>>> { >>>>>>>>>> result |= CPU_3DNOW_PREFETCH; >>>>>>>>>> @@ -590,6 +605,7 @@ >>>>>>>>>> static ByteSize ext_cpuid5_offset() { return >>>>>>>>>> byte_offset_of(CpuidInfo, ext_cpuid5_eax); } >>>>>>>>>> static ByteSize ext_cpuid7_offset() { return >>>>>>>>>> byte_offset_of(CpuidInfo, ext_cpuid7_eax); } >>>>>>>>>> static ByteSize ext_cpuid8_offset() { return >>>>>>>>>> byte_offset_of(CpuidInfo, ext_cpuid8_eax); } >>>>>>>>>> + static ByteSize ext_cpuid1E_offset() { return >>>>>>>>>> byte_offset_of(CpuidInfo, ext_cpuid1E_eax); } >>>>>>>>>> static ByteSize tpl_cpuidB0_offset() { return >>>>>>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB0_eax); } >>>>>>>>>> static ByteSize tpl_cpuidB1_offset() { return >>>>>>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB1_eax); } >>>>>>>>>> static ByteSize tpl_cpuidB2_offset() { return >>>>>>>>>> byte_offset_of(CpuidInfo, tpl_cpuidB2_eax); } >>>>>>>>>> @@ -673,8 +689,11 @@ >>>>>>>>>> if (is_intel() && supports_processor_topology()) { >>>>>>>>>> result = _cpuid_info.tpl_cpuidB0_ebx.bi >>>>>>>>>> ts.logical_cpus; >>>>>>>>>> } else if (_cpuid_info.std_cpuid1_edx.bits.ht != 0) { >>>>>>>>>> - result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu / >>>>>>>>>> - cores_per_cpu(); >>>>>>>>>> + if (cpu_family() >= 0x17) >>>>>>>>>> + result = _cpuid_info.ext_cpuid1E_ebx.bi >>>>>>>>>> ts.threads_per_core >>>>>>>>>> >>>>>>>>> + >>> >>>> 1; >>>>>>>>>> + else >>>>>>>>>> + result = _cpuid_info.std_cpuid1_ebx.bits.threads_per_cpu >>>>>>>>>> >>>>>>>>> / >>> >>>> + cores_per_cpu(); >>>>>>>>>> } >>>>>>>>>> return (result == 0 ? 1 : result); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> I have attached the patch for review. >>>>>>>>>> Please let me know your comments. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Rohit >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>>> Vladimir >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>> >>>>>>>>>>>> No comments on AMD specific changes. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> On 5/09/2017 3:43 PM, David Holmes wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 5/09/2017 3:29 PM, Rohit Arul Raj wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello David, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Sep 5, 2017 at 10:31 AM, David Holmes >>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Rohit, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I was unable to apply your patch to latest jdk10/hs/hotspot >>>>>>>>>>>>>>> repo. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> I checked out the latest jdk10/hs/hotspot [parent: >>>>>>>>>>>>>> 13548:1a9c2e07a826] >>>>>>>>>>>>>> and was able to apply the patch >>>>>>>>>>>>>> [epyc-amd17h-defaults-3Sept.patch] >>>>>>>>>>>>>> without any issues. >>>>>>>>>>>>>> Can you share the error message that you are getting? >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I was getting this: >>>>>>>>>>>>> >>>>>>>>>>>>> applying hotspot.patch >>>>>>>>>>>>> patching file src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>> Hunk #1 FAILED at 1108 >>>>>>>>>>>>> 1 out of 1 hunks FAILED -- saving rejects to file >>>>>>>>>>>>> src/cpu/x86/vm/vm_version_x86.cpp.rej >>>>>>>>>>>>> patching file src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>> Hunk #2 FAILED at 522 >>>>>>>>>>>>> 1 out of 2 hunks FAILED -- saving rejects to file >>>>>>>>>>>>> src/cpu/x86/vm/vm_version_x86.hpp.rej >>>>>>>>>>>>> abort: patch failed to apply >>>>>>>>>>>>> >>>>>>>>>>>>> but I started again and this time it applied fine, so not sure >>>>>>>>>>>>> what >>>>>>>>>>>>> was >>>>>>>>>>>>> going on there. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> Rohit >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 4/09/2017 2:42 AM, Rohit Arul Raj wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello Vladimir, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sat, Sep 2, 2017 at 11:25 PM, Vladimir Kozlov >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Rohit, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 9/2/17 1:16 AM, Rohit Arul Raj wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hello Vladimir, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Changes look good. Only question I have is about >>>>>>>>>>>>>>>>>>> MaxVectorSize. >>>>>>>>>>>>>>>>>>> It >>>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>> set >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 16 only in presence of AVX: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 046eab27258f/src/cpu/x86/vm/vm_version_x86.cpp#l945 >>> >>>> >>>>>>>>>>>>>>>>>>> Does that code works for AMD 17h too? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks for pointing that out. Yes, the code works fine for >>>>>>>>>>>>>>>>>> AMD >>>>>>>>>>>>>>>>>> 17h. >>>>>>>>>>>>>>>>>> So >>>>>>>>>>>>>>>>>> I have removed the surplus check for MaxVectorSize from my >>>>>>>>>>>>>>>>>> patch. >>>>>>>>>>>>>>>>>> I >>>>>>>>>>>>>>>>>> have updated, re-tested and attached the patch. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Which check you removed? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> My older patch had the below mentioned check which was >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> required >>> >>>> on >>>>>>>>>>>>>>>> JDK9 where the default MaxVectorSize was 64. It has been >>>>>>>>>>>>>>>> handled >>>>>>>>>>>>>>>> better in openJDK10. So this check is not required anymore. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + // Some defaults for AMD family 17h >>>>>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { >>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>>> + if (MaxVectorSize > 32) { >>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(MaxVectorSize, 32); >>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>> .. >>>>>>>>>>>>>>>> .. >>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I have one query regarding the setting of UseSHA flag: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/file/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 046eab27258f/src/cpu/x86/vm/vm_version_x86.cpp#l821 >>> >>>> >>>>>>>>>>>>>>>>>> AMD 17h has support for SHA. >>>>>>>>>>>>>>>>>> AMD 15h doesn't have support for SHA. Still "UseSHA" flag >>>>>>>>>>>>>>>>>> gets >>>>>>>>>>>>>>>>>> enabled for it based on the availability of BMI2 and AVX2. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Is >>> >>>> there >>>>>>>>>>>>>>>>>> an >>>>>>>>>>>>>>>>>> underlying reason for this? I have handled this in the >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> patch >>> >>>> but >>>>>>>>>>>>>>>>>> just >>>>>>>>>>>>>>>>>> wanted to confirm. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It was done with next changes which use only AVX2 and BMI2 >>>>>>>>>>>>>>>>> instructions >>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>> calculate SHA-256: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://hg.openjdk.java.net/jdk10/hs/hotspot/rev/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 6a17c49de974 >>> >>>> >>>>>>>>>>>>>>>>> I don't know if AMD 15h supports these instructions and can >>>>>>>>>>>>>>>>> execute >>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>> code. You need to test it. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ok, got it. Since AMD15h has support for AVX2 and BMI2 >>>>>>>>>>>>>>>> instructions, >>>>>>>>>>>>>>>> it should work. >>>>>>>>>>>>>>>> Confirmed by running following sanity tests: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ./hotspot/test/compiler/intrinsics/sha/sanity/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TestSHA1Intrinsics.java >>> >>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ./hotspot/test/compiler/intrinsics/sha/sanity/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TestSHA512Intrinsics.java >>> >>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ./hotspot/test/compiler/intrinsics/sha/sanity/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> TestSHA256Intrinsics.java >>> >>>> >>>>>>>>>>>>>>>> So I have removed those SHA checks from my patch too. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please find attached updated, re-tested patch. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>> @@ -1109,11 +1109,27 @@ >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> #ifdef COMPILER2 >>>>>>>>>>>>>>>> - if (MaxVectorSize > 16) { >>>>>>>>>>>>>>>> - // Limit vectors size to 16 bytes on current AMD >>>>>>>>>>>>>>>> cpus. >>>>>>>>>>>>>>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>>>>>>>>>>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < 17h. >>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> #endif // COMPILER2 >>>>>>>>>>>>>>>> + >>>>>>>>>>>>>>>> + // Some defaults for AMD family 17h >>>>>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { >>>>>>>>>>>>>>>> + // On family 17h processors use XMM and >>>>>>>>>>>>>>>> UnalignedLoadStores >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> Array Copy >>>>>>>>>>>>>>>> + if (supports_sse2() && >>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseXMMForArrayCopy)) { >>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>> + if (supports_sse2() && >>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) >>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); >>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>> +#ifdef COMPILER2 >>>>>>>>>>>>>>>> + if (supports_sse4_2() && >>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseFPUForSpilling)) >>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>> +#endif >>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> if( is_intel() ) { // Intel cpus specific settings >>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>> @@ -505,6 +505,14 @@ >>>>>>>>>>>>>>>> result |= CPU_CLMUL; >>>>>>>>>>>>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) >>>>>>>>>>>>>>>> result |= CPU_RTM; >>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>>>>>>>> + result |= CPU_ADX; >>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>>>>>>>> + result |= CPU_BMI2; >>>>>>>>>>>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>>>>>>>> + result |= CPU_SHA; >>>>>>>>>>>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>>>>>>>> + result |= CPU_FMA; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> // AMD features. >>>>>>>>>>>>>>>> if (is_amd()) { >>>>>>>>>>>>>>>> @@ -515,19 +523,13 @@ >>>>>>>>>>>>>>>> result |= CPU_LZCNT; >>>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.sse4a != >>>>>>>>>>>>>>>> 0) >>>>>>>>>>>>>>>> result |= CPU_SSE4A; >>>>>>>>>>>>>>>> + if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) >>>>>>>>>>>>>>>> + result |= CPU_HT; >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> // Intel features. >>>>>>>>>>>>>>>> if(is_intel()) { >>>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>>>>>>>> - result |= CPU_ADX; >>>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>>>>>>>> - result |= CPU_BMI2; >>>>>>>>>>>>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>>>>>>>> - result |= CPU_SHA; >>>>>>>>>>>>>>>> if(_cpuid_info.ext_cpuid1_ecx.bits.lzcnt_intel >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> != >>> >>>> 0) >>>>>>>>>>>>>>>> result |= CPU_LZCNT; >>>>>>>>>>>>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>>>>>>>> - result |= CPU_FMA; >>>>>>>>>>>>>>>> // for Intel, ecx.bits.misalignsse bit (bit 8) >>>>>>>>>>>>>>>> indicates >>>>>>>>>>>>>>>> support for prefetchw >>>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bi >>>>>>>>>>>>>>>> ts.misalignsse >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> != >>> >>>> 0) >>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>> result |= CPU_3DNOW_PREFETCH; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Please let me know your comments. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks for your time. >>>>>>>>>>>>>>>> Rohit >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks for taking time to review the code. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.cpp >>>>>>>>>>>>>>>>>> @@ -1088,6 +1088,22 @@ >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(UseSSE42Intrinsics, >>>>>>>>>>>>>>>>>> false); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> + if (supports_sha()) { >>>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA)) { >>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, true); >>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>> + } else if (UseSHA || UseSHA1Intrinsics || >>>>>>>>>>>>>>>>>> UseSHA256Intrinsics >>>>>>>>>>>>>>>>>> || >>>>>>>>>>>>>>>>>> UseSHA512Intrinsics) { >>>>>>>>>>>>>>>>>> + if (!FLAG_IS_DEFAULT(UseSHA) || >>>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA1Intrinsics) || >>>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA256Intrinsics) || >>>>>>>>>>>>>>>>>> + !FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { >>>>>>>>>>>>>>>>>> + warning("SHA instructions are not available on >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> this >>> >>>> CPU"); >>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA, false); >>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA1Intrinsics, false); >>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA256Intrinsics, false); >>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> // some defaults for AMD family 15h >>>>>>>>>>>>>>>>>> if ( cpu_family() == 0x15 ) { >>>>>>>>>>>>>>>>>> @@ -1109,11 +1125,40 @@ >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> #ifdef COMPILER2 >>>>>>>>>>>>>>>>>> - if (MaxVectorSize > 16) { >>>>>>>>>>>>>>>>>> - // Limit vectors size to 16 bytes on current AMD >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> cpus. >>> >>>> + if (cpu_family() < 0x17 && MaxVectorSize > 16) { >>>>>>>>>>>>>>>>>> + // Limit vectors size to 16 bytes on AMD cpus < >>>>>>>>>>>>>>>>>> 17h. >>>>>>>>>>>>>>>>>> FLAG_SET_DEFAULT(MaxVectorSize, 16); >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> #endif // COMPILER2 >>>>>>>>>>>>>>>>>> + >>>>>>>>>>>>>>>>>> + // Some defaults for AMD family 17h >>>>>>>>>>>>>>>>>> + if ( cpu_family() == 0x17 ) { >>>>>>>>>>>>>>>>>> + // On family 17h processors use XMM and >>>>>>>>>>>>>>>>>> UnalignedLoadStores >>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>> Array Copy >>>>>>>>>>>>>>>>>> + if (supports_sse2() && >>>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseXMMForArrayCopy)) >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseXMMForArrayCopy, true); >>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>> + if (supports_sse2() && >>>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { >>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseUnalignedLoadStores, true); >>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>> + if (supports_bmi2() && >>>>>>>>>>>>>>>>>> FLAG_IS_DEFAULT(UseBMI2Instructions)) >>>>>>>>>>>>>>>>>> { >>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseBMI2Instructions, true); >>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>> + if (UseSHA) { >>>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { >>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >>>>>>>>>>>>>>>>>> + } else if (UseSHA512Intrinsics) { >>>>>>>>>>>>>>>>>> + warning("Intrinsics for SHA-384 and SHA-512 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> crypto >>> >>>> hash >>>>>>>>>>>>>>>>>> functions not available on this CPU."); >>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseSHA512Intrinsics, false); >>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>> +#ifdef COMPILER2 >>>>>>>>>>>>>>>>>> + if (supports_sse4_2()) { >>>>>>>>>>>>>>>>>> + if (FLAG_IS_DEFAULT(UseFPUForSpilling)) { >>>>>>>>>>>>>>>>>> + FLAG_SET_DEFAULT(UseFPUForSpilling, true); >>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>> +#endif >>>>>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> if( is_intel() ) { // Intel cpus specific >>>>>>>>>>>>>>>>>> settings >>>>>>>>>>>>>>>>>> diff --git a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>>> b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>>> --- a/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>>> +++ b/src/cpu/x86/vm/vm_version_x86.hpp >>>>>>>>>>>>>>>>>> @@ -505,6 +505,14 @@ >>>>>>>>>>>>>>>>>> result |= CPU_CLMUL; >>>>>>>>>>>>>>>>>> if (_cpuid_info.sef_cpuid7_ebx.bits.rtm != 0) >>>>>>>>>>>>>>>>>> result |= CPU_RTM; >>>>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>>>>>>>>>> + result |= CPU_ADX; >>>>>>>>>>>>>>>>>> + if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>>>>>>>>>> + result |= CPU_BMI2; >>>>>>>>>>>>>>>>>> + if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>>>>>>>>>> + result |= CPU_SHA; >>>>>>>>>>>>>>>>>> + if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>>>>>>>>>> + result |= CPU_FMA; >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> // AMD features. >>>>>>>>>>>>>>>>>> if (is_amd()) { >>>>>>>>>>>>>>>>>> @@ -515,19 +523,13 @@ >>>>>>>>>>>>>>>>>> result |= CPU_LZCNT; >>>>>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx.bits.sse4a >>>>>>>>>>>>>>>>>> != >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 0) >>> >>>> result |= CPU_SSE4A; >>>>>>>>>>>>>>>>>> + if(_cpuid_info.std_cpuid1_edx.bits.ht != 0) >>>>>>>>>>>>>>>>>> + result |= CPU_HT; >>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>> // Intel features. >>>>>>>>>>>>>>>>>> if(is_intel()) { >>>>>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.adx != 0) >>>>>>>>>>>>>>>>>> - result |= CPU_ADX; >>>>>>>>>>>>>>>>>> - if(_cpuid_info.sef_cpuid7_ebx.bits.bmi2 != 0) >>>>>>>>>>>>>>>>>> - result |= CPU_BMI2; >>>>>>>>>>>>>>>>>> - if (_cpuid_info.sef_cpuid7_ebx.bits.sha != 0) >>>>>>>>>>>>>>>>>> - result |= CPU_SHA; >>>>>>>>>>>>>>>>>> if(_cpuid_info.ext_cpuid1_ecx. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> bits.lzcnt_intel >>> >>>> != >>>>>>>>>>>>>>>>>> 0) >>>>>>>>>>>>>>>>>> result |= CPU_LZCNT; >>>>>>>>>>>>>>>>>> - if (_cpuid_info.std_cpuid1_ecx.bits.fma != 0) >>>>>>>>>>>>>>>>>> - result |= CPU_FMA; >>>>>>>>>>>>>>>>>> // for Intel, ecx.bits.misalignsse bit (bit >>>>>>>>>>>>>>>>>> 8) >>>>>>>>>>>>>>>>>> indicates >>>>>>>>>>>>>>>>>> support for prefetchw >>>>>>>>>>>>>>>>>> if (_cpuid_info.ext_cpuid1_ecx. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> bits.misalignsse >> >> From sharath.ballal at oracle.com Fri Nov 3 10:14:50 2017 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Fri, 3 Nov 2017 03:14:50 -0700 (PDT) Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Message-ID: Hi Jini, You have appended 'Field' for most of the SA variables. Example: private static CIntegerField pcOffsetField; pcOffsetField = type.getCIntegerField("_pc_offset"); However that is not the case in private static long MinChunkSizeInBytes; MinChunkSizeInBytes = (type.getCIntegerField("_min_chunk_size_in_bytes")).getValue(); You may want to follow the same convention here. Rest of the changes look ok. Thanks, Sharath (not a reviewer) -----Original Message----- From: Jini George Sent: Thursday, November 02, 2017 10:24 AM To: Serguei Spitsyn; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the >>>> changes are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoAqbJ+Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAGcrAAB2AAAABQBkAA8ABAAAAEVkZ2U= X-Source: SMTP:External Receive Connector X-SourceIPAddress: 195.190.135.10 X-EndOfInjectedXHeaders: 7733 Received: from mx.expurgate.net (195.190.135.10) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 05:54:39 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA7WZ-000EZw-D4 for axel.siebenborn at sap.com; Thu, 02 Nov 2017 05:54:39 +0100 Received: from [156.151.31.69] (helo=ucsinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.2.1-3) (envelope-from ) id 59faa50b-7c01-c0a8033409dd-9c971f454783-3 for ; Thu, 02 Nov 2017 05:54:38 +0100 Received: from aojmv0009 (unknown [137.254.59.6]) by ucsinet41.oracle.com with smtp id 4eb7_00c7_3ecf1c93_28fd_4a9f_97f0_f31de9ddb295; Thu, 02 Nov 2017 04:54:17 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 15A99229CEC; Thu, 2 Nov 2017 04:57:26 +0000 (UTC) X-Original-To: serviceability-dev at openjdk.java.net Delivered-To: serviceability-dev at openjdk.java.net Received: from ucsinet40.oracle.com (ucsinet40.oracle.com [156.151.31.68]) by aojmv0009 (Postfix) with ESMTP id 9CFF6229CC3; Thu, 2 Nov 2017 04:57:20 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by ucsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) id 37c3_8726_79982056_f63b_491d_a8be_57819e8c7dcc; Thu, 02 Nov 2017 04:54:08 +0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA24s8KW028461 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s84O013997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s7KK017107; Thu, 2 Nov 2017 04:54:08 GMT Received: from [10.177.158.142] (/10.177.158.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 21:54:07 -0700 Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 From: Jini George To: "serguei.spitsyn at oracle.com" , "serviceability-dev at openjdk.java.net" , "hotspot-runtime-dev at openjdk.java.net" , References: <18501902-23db-de6c-b83d-640cd33df836 at oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a at oracle.com> Organization: Oracle Corporation Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e at oracle.com> Date: Thu, 2 Nov 2017 10:24:03 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: serviceability-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Technical discussion about the development of serviceability technologies \(debugging, profiling, monitoring, and management\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: serviceability-dev-bounces at openjdk.java.net Sender: serviceability-dev X-purgate-ID: tlsNG-9b91ac/1509598479-00007C01-219CB02A/0/0 X-purgate-type: clean X-purgate-size: 2000 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTU2LjE1MS4zMS42OQBzZXJ2aWNlYWJpbGl0eS1kZXYtYm91bmNlc0BvcGVuamRrLmphdmEubmV0AGF4ZWwuc2llYmVuYm9ybkBzYXAuY29tADgwYzQ2ZTI0N2Q2MTBlYjNiNTQ5MmE5YWE2NzJjNzJjN2NiNjcwNDQ= X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: serviceability-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 04:54:39.6785 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 195.190.135.10 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: 8fba1fcd-01cd-4a67-1ee6-08d521add313 X-MS-Exchange-Organization-OriginalSize: 7400 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV=DEWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE=11997.291|UTH=0.001|RST=11997.244|QS=0.029|CATCM-McAfeeTxRoutingAgent=0.011|CATCM=0.011|CAT=0.012;2017-11-02T08:14:36.969Z Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the >>>> changes are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> X-sender: X-Receiver: X-CreatedBy: MSExchange15 X-HeloDomain: mx.expurgate.net X-ExtendedProps: BQBjAAoAALN+Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAIMrAAB2AAAABQBkAA8ABAAAAEVkZ2U= X-Source: SMTP:External Receive Connector X-SourceIPAddress: 194.145.224.110 X-EndOfInjectedXHeaders: 7704 Received: from mx.expurgate.net (194.145.224.110) by smtpgw03.sap-ag.de (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov 2017 05:54:46 +0100 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1eA7Wg-0004R0-FP for axel.siebenborn at sap.com; Thu, 02 Nov 2017 05:54:46 +0100 Received: from [141.146.126.229] (helo=acsinet41.oracle.com) by mxtls.expurgate.net with ESMTPS (eXpurgate 4.3.1) (envelope-from ) id 59faa50f-65eb-c0a8029b09dd-8d927ee53db9-3 for ; Thu, 02 Nov 2017 05:54:45 +0100 Received: from aojmv0009 (aojmv0009.oracle.com [137.254.59.6]) by acsinet41.oracle.com with smtp id 6461_15f0_154b24ba_5aa0_408c_88bd_1cdb37c9c8f4; Thu, 02 Nov 2017 04:54:31 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 3B280229CF4; Thu, 2 Nov 2017 04:57:26 +0000 (UTC) X-Original-To: hotspot-runtime-dev at openjdk.java.net Delivered-To: hotspot-runtime-dev at openjdk.java.net Received: from ucsinet40.oracle.com (ucsinet40.oracle.com [156.151.31.68]) by aojmv0009 (Postfix) with ESMTP id 9CFF6229CC3; Thu, 2 Nov 2017 04:57:20 +0000 (UTC) Received: from userp1040.oracle.com (unknown [156.151.31.81]) by ucsinet40.oracle.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) id 37c3_8726_79982056_f63b_491d_a8be_57819e8c7dcc; Thu, 02 Nov 2017 04:54:08 +0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA24s8KW028461 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s84O013997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s7KK017107; Thu, 2 Nov 2017 04:54:08 GMT Received: from [10.177.158.142] (/10.177.158.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 21:54:07 -0700 Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 From: Jini George To: "serguei.spitsyn at oracle.com" , "serviceability-dev at openjdk.java.net" , "hotspot-runtime-dev at openjdk.java.net" , References: <18501902-23db-de6c-b83d-640cd33df836 at oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a at oracle.com> Organization: Oracle Corporation Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e at oracle.com> Date: Thu, 2 Nov 2017 10:24:03 +0530 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: hotspot-runtime-dev at openjdk.java.net X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical discussion about the development of the HotSpot runtime subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hotspot-runtime-dev-bounces at openjdk.java.net Sender: hotspot-runtime-dev X-purgate-ID: tlsNG-81024b/1509598486-000065EB-186BA960/0/0 X-purgate-type: clean X-purgate-size: 2000 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtcnVudGltZS1kZXYtYm91bmNlc0BvcGVuamRrLmphdmEubmV0AGF4ZWwuc2llYmVuYm9ybkBzYXAuY29tADE0ZjI2NjVmYTY4ZGRiOWMwNGJiMGU0MmE2Njk2M2ZiNWQxNzAyOGI= X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-SAP-SPAM-Status: clean Return-Path: hotspot-runtime-dev-bounces at openjdk.java.net X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 04:54:46.7566 (UTC) X-MS-Exchange-Organization-OriginalClientIPAddress: 194.145.224.110 X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp X-MS-Exchange-Organization-Network-Message-Id: 9365fa06-08de-47df-2865-08d521add74b X-MS-Exchange-Organization-OriginalSize: 7380 X-MS-Exchange-Organization-HygienePolicy: Standard X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: LSRV=DEWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE=11990.260|UTH=0.001|RST=11990.260|CATCM-McAfeeTxRoutingAgent=0.004|CATCM=0.005|CAT=0.006;2017-11-02T08:14:37.016Z Could I please get one more review done for this ? Thanks, Jini. On 10/27/2017 9:19 PM, Jini George wrote: > Thank you very much, Serguei. > > -Jini. > > On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >> Hi Jini, >> >> The fix looks good to me. >> >> Thanks, >> Serguei >> >> >> On 10/24/17 00:31, Jini George wrote: >>> Adding hotspot-dev too. >>> >>> Thanks, >>> Jini. >>> >>> On 10/24/2017 12:05 PM, Jini George wrote: >>>> Hello, >>>> >>>> As a part of SA next, I am working on writing a test case which >>>> compares the fields and the types of the fields of the SA java >>>> classes with the corresponding entries in the vmStructs tables. >>>> This, to some extent, would help in preventing errors in SA due to >>>> the changes in hotspot. As a precursor to this, I am in the process >>>> of making some cleanup related changes (mostly in SA). I plan to >>>> have the changes done in parts. For this webrev, most of the >>>> changes are for: >>>> >>>> 1. Avoiding having some values being redefined in SA. Instead have >>>> those exported through vmStructs, and read it in SA. >>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>> CompactibleFreeListSpace::IndexSetSize) >>>> >>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>> value gets altered in hotspot and the corresponding modification >>>> gets missed out in SA. >>>> >>>> 2. To remove some unused code (JNIid.java). >>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>> names, so that the comparison of the fields become easier. Most of >>>> the changes belong to this group. >>>> >>>> Could I please get reviews done for these precursor changes ? >>>> >>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>> >>>> Thank you, >>>> Jini. >>>> >> From daniel.daugherty at oracle.com Fri Nov 3 11:56:39 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 3 Nov 2017 07:56:39 -0400 Subject: RFR (S): 8187289 NotifyFramePop request is not cleared if JVMTI_EVENT_FRAME_POP is disabled In-Reply-To: <80effdfa-5919-06c5-38d5-a3bd1ab857f1@oracle.com> References: <85a49dcc-fd25-270a-b9a9-46d5c745d7e6@oracle.com> <80effdfa-5919-06c5-38d5-a3bd1ab857f1@oracle.com> Message-ID: > http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ make/test/JtregNativeHotspot.gmk ??? No comments. src/hotspot/share/prims/jvmtiEventController.cpp ??? No comments. src/hotspot/share/prims/jvmtiExport.cpp ??? No comments. src/hotspot/share/prims/jvmtiExport.hpp ??? No comments. src/hotspot/share/prims/jvmtiManageCapabilities.cpp ??? No comments. test/hotspot/jtreg/serviceability/jvmti/NotifyFramePop/NotifyFramePopTest.java ??? No comments. test/hotspot/jtreg/serviceability/jvmti/NotifyFramePop/libNotifyFramePopTest.c ??? No comments. Thumbs up! Dan On 11/2/17 4:59 PM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > Thank you a lot for doing this review! > I was waiting for you for a couple of weeks. :) > > > On 11/2/17 10:13, Daniel D. Daugherty wrote: >> On 10/13/17 12:58 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review a fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8187289 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.1/ >>> >>> >>> Summary: >>> ? The issue is that the FRAME_POP event request is not cleaned if >>> the requested >>> ? method frame is popped but the notification mode is temporarily >>> disabled. >>> ? If later the notification mode is enabled again then it will post >>> a FRAME_POP >>> ? event on the first return from an arbitrary method with the same >>> frame depth. >>> ? Notification mode for JVMTI_EVENT_FRAME_POP events is checked in the >>> ? JvmtiExport::post_method_exit() under the condition: >>> ????? if (state->is_enabled(JVMTI_EVENT_FRAME_POP)) { >>> ? Just removing this condition would likely to introduce a >>> performance regression >>> ? in interpreted mode. To mitigate it the fix introduces new >>> JVMTI_SUPPORT_FLAG >>> ? can_generate_frame_pop_events that is is checked instead of the >>> notification mode. >>> ? Also, it is necessary to to keep the state->is_interp_only_mode() >>> turned on >>> ? while the JvmtiEnvThreadState has any FRAME_POP requests registered. >>> >>> ? One alternate approach to this fix is to leave the current >>> behavior as it is >>> ? but update the JVMTI spec with some clarification about this >>> behavior. >>> >>> Testing: >>> ? Verified with new unit test serviceability/jvmti/NotifyFramePop. >>> ? Also ran the nsk.jvmti, nsk.jdi and jtreg jdk_jdi tests to make >>> sure there is no regression. >>> >>> Thanks, >>> Serguei >> >> First, I'm going to take a step back and look at the JVM/TI programming >> model for NotifyFramePop() and JVMTI_EVENT_FRAME_POP events. Here's the >> relevant JVM/TI spec links: >> >> https://docs.oracle.com/javase/9/docs/specs/jvmti.html#NotifyFramePop >> https://docs.oracle.com/javase/9/docs/specs/jvmti.html#FramePop >> >> ??? NotifyFramePop() is used by agent code to register interest in >> ??? when a target thread leaves a Java frame at a specific depth. >> ??? The target thread can be NULL which means that the current thread >> ??? is registering interest in itself. The frame is specified by a >> ??? 'depth' parameter so the agent is not expressing an interest in a >> ??? specific named function. Also note that NotifyFramePop() can only >> ??? register interest in Java frames. >> >> ??? The agent code must also enable the JVMTI_EVENT_FRAME_POP event in >> ??? order for the FRAME_POP event to be delivered to the agent's event >> ??? handler. There is no requirement to enable the FRAME_POP event before >> ??? calling NotifyFramePop(). Nor is there any requirement for clearing >> ??? existing frame interest entries when the FRAME_POP event is disabled. > > All the above is correct. > Thank you for providing this background as it is useful for reviewers! > > >> ??? If we have target thread call stack that looks like this: >> >> ??????? call_depth_0() >> ??????? call_depth_1() >> ??????? call_depth_2() >> ??????? agent_code() >> >> ??? The agent_code(), operating on the current thread, calls: >> >> ??????? callbacks.FramePop = frame_pop_callback; >> ??????? SetEventCallbacks(callbacks, size_of_callbacks); >> ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, >> NULL); >> ??????? NotifyFramePop(NULL, 1); >> >> ??? or it calls: >> >> ??????? callbacks.FramePop = frame_pop_callback; >> ??????? SetEventCallbacks(callbacks, size_of_callbacks); >> ??????? NotifyFramePop(NULL, 1); >> ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, >> NULL); >> >> ??? and in either case, we expect a FRAME_POP event to be posted when the >> ??? target thread returns from call_depth_1() to call_depth_0(). The >> ??? FRAME_POP event is typically disabled in the FRAME_POP event handler >> ??? function (frame_pop_callback) that is called when the FRAME_POP event >> ??? is posted. >> >> ??? Because disabling FRAME_POP is not specified to clear interest in a >> ??? frame, if the agent_code(), operating on the current thread, calls: >> >> ??????? callbacks.FramePop = frame_pop_callback; >> ??????? SetEventCallbacks(callbacks, size_of_callbacks); >> ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, >> NULL); >> ??????? NotifyFramePop(NULL, 1); >> ??????? SetEventNotificationMode(JVMTI_DISABLE, >> JVMTI_EVENT_FRAME_POP, NULL); >> ??????? SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_FRAME_POP, >> NULL); >> >> ??? then we expect a FRAME_POP event to be posted when the target thread >> ??? returns from call_depth_1 to call_depth_0 (and the >> frame_pop_callback() >> ??? event handler is called). >> >> >> Okay so I think that covers the general programming model and includes >> a scenario that shows why we can't clear interest in a frame when the >> FRAME_POP event is disabled. > > The above is correct too. > > >> So we have this NotifyFramePop() function that registers interest in >> when a >> target thread leaves a Java frame at a specific depth. We don't have a >> ClearFramePop() or UnNotifyFramePop() function so the expected way to >> clear >> an existing frame interest entry is to do so when we leave that frame. So >> the current behavior where we can return from call_depth_1() to >> call_depth_0() >> without clearing the existing frame interest entry is a bug. > > Right. > > >> Okay so I'm now caught up with this thread and I agree that we have a >> bug. >> Definitely a corner case, but a bug none the less. So far I don't see a >> reason to change any spec wording so let's look at the webrev: > > Right but modulo what Alan said that bug fixing this bug we are going > to change the behavior. > So that at least we need a CSR and release note for this update. > > > >> >> > >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.1/ >> >> src/hotspot/share/prims/jvmtiExport.hpp >> ??? I'm wondering why the existing can_post_interpreter_events() can't >> ??? cover the case for us since we need to stay in interpreted mode. >> >> ??? Update: The existing can_post_interpreter_events() could be used >> ??? but the new can_generate_frame_pop_events() is more specific. I'm >> ??? okay with it. > > Ok, thanks. > > >> src/hotspot/share/prims/jvmtiExport.cpp >> ??? I agree that JvmtiExport::post_method_exit() needs to check a >> ??? condition other than "is_enabled(JVMTI_EVENT_FRAME_POP)", but >> ??? should it be can_generate_frame_pop_events() or should it be >> ??? can_post_interpreter_events()? >> >> ??? Update: The existing can_post_interpreter_events() could be used >> ??? but the new can_generate_frame_pop_events() is more specific. I'm >> ??? okay with it. > > Ok, thanks. > > >> src/hotspot/share/prims/jvmtiEventController.cpp >> ??? L513: ??? // This iteration will include JvmtiEnvThreadStates >> whoses environments >> ??????? Not yours, but could you please fix it? >> ??????? Typo: 'whoses' -> 'whose' > > Good eyes! > Fixed. > > >> ??? L523-542 - Perhaps we should refactor the code as: >> >> ? ? 523?? if (any_env_enabled != was_any_env_enabled) { >> ? ? 524???? // mark if event is truly enabled on this thread in any >> environment >> ? ? 525 >> state->thread_event_enable()->_event_enabled.set_bits(any_env_enabled); >> ? ? 526 >> ? ? 527 ??? // update the JavaThread cached value for thread-specific >> should_post_on_exceptions value >> ? ? 528 ??? bool should_post_on_exceptions = (any_env_enabled & >> SHOULD_POST_ON_EXCEPTIONS_BITS) != 0; >> ? ? 529 state->set_should_post_on_exceptions(should_post_on_exceptions); >> ? ? 530?? } >> ? ? 531 >> ? ? 532 ? // compute interp_only mode >> ? ? 533 ? bool should_be_interp = (any_env_enabled & >> INTERP_EVENT_BITS) != 0 || has_frame_pops; >> ? ? 534 ? bool is_now_interp = state->is_interp_only_mode(); >> ? ? 535?? if (should_be_interp != is_now_interp) { >> ? ? 536 ??? if (should_be_interp) { >> ? ? 537 ????? enter_interp_only_mode(state); >> ? ? 538 ??? } else { >> ? ? 539 ????? leave_interp_only_mode(state); >> ? ? 540 ??? } >> ? ? 541 ? } >> >> ??? My reasoning is that new L525 and L529 should only be called when >> ??? this is true: (any_env_enabled != was_any_env_enabled). We always >> ??? have to check for a change in interp_only mode because the new >> ??? has_frame_pops condition is independent of the >> ??? (any_env_enabled != was_any_env_enabled) check so we might as well >> ??? make that really clear. > > Refactored as you suggested. > Will need to test it well. > > >> src/hotspot/share/prims/jvmtiManageCapabilities.cpp >> ??? Needs copyright year update. > > Updated the copyright year, thanks. > > >> make/test/JtregNativeHotspot.gmk >> ??? No comments. >> >> test/hotspot/jtreg/serviceability/jvmti/NotifyFramePop/NotifyFramePopTest.java >> ??? L69: ??????? notifyFramePop(null); >> ??????? Please add comment above L69: >> >> ????????? // Ask for notification when we leave frame 1 (meth01). >> >> ??? L70:???????? setFramePopNotificationMode(false); >> ??????? Please add comment above L70: >> >> ????????? // Disabling FRAME_POP event notification should not >> ????????? // prevent the notification for frame 1 from being cleared >> ????????? // when we return from meth01. >> >> ??? L75: ??????? setFramePopNotificationMode(true); >> ??????? Please add comment above L75: >> >> ????????? // Enabling FRAME_POP event notification here should >> ????????? // not result in a FRAME_POP event when we return from >> ????????? // frame 1 (meth02) because we did not ask for a >> ????????? // notification when we leave frame 1 in the context of >> ????????? // this method (meth02). >> >> ??????? to replace this comment: >> >> ????????? L76: ??????? // We expect no FramePop event on the meth02() >> exit as the >> ????????? L77: ??????? // request from meth01() had to be clear at >> its exit. >> >> ??????? If you like my new comment. :-) > > Good suggestions, thanks. > Added the comments. > > >> test/hotspot/jtreg/serviceability/jvmti/NotifyFramePop/libNotifyFramePopTest.c >> ??? L73: ??????? jmethodID method, jboolean wasPopedByException) { >> ??????? Typo: 'wasPopedByException' -> 'wasPoppedByException' >> >> ??? L80: ??? result = FAILED; // This event is not expect >> ??????? Typo: 'expect' -> 'expected' >> >> ??? L101: jint? Agent_Initialize(JavaVM *jvm, char *options, void >> *reserved) { >> ??????? Extra space between 'jint' and function name. >> >> ??? L150: ??????? if (err != JVMTI_ERROR_NONE) { >> ??? L151: ??????????? printf("Failed to set notification mode for >> FRAME_POP events: %s (%d)\n", >> ??? L152: ?????????????????? TranslateError(err), err); >> ??????? This error message should also report the 'mode' we're >> ??????? trying to set for complete context. > > Good catches, thanks. > Fixed. > > > The updated webrev is: > http://cr.openjdk.java.net/%7Esspitsyn/webrevs/2017/hotspot/8187289-jvmti-framepop.2/ > > > I will also run the jvmti, jdi, jdwp and j.l.instrument tests. > > > Thanks, > Serguei > > From bob.vandette at oracle.com Fri Nov 3 15:58:50 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 3 Nov 2017 11:58:50 -0400 Subject: RFR: 8190283 - Default heap sizing options select a MaxHeapSize larger than available physical memory in some case Message-ID: Please review this simple change that alters the algorithm for selecting the default heap size on low (~100MB) memory environments. This issue is blocking the integration of the container improvements (https://bugs.openjdk.java.net/browse/JDK-8146115 ). BUG: https://bugs.openjdk.java.net/browse/JDK-8190283 WEBREV: http://bussund0417.us.oracle.com/export/users/bobv/jdk10hs-base/open/webrev/ Bob. From bob.vandette at oracle.com Fri Nov 3 16:42:15 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 3 Nov 2017 12:42:15 -0400 Subject: RFR: 8190283 - Default heap sizing options select a MaxHeapSize larger than available physical memory in some case In-Reply-To: References: Message-ID: I realized that I didn?t post the webrev on our external server. There was only 1 file changed. Here?s the diff: *** old/src/hotspot/share/runtime/arguments.cpp Fri Nov 3 11:50:07 2017 --- new/src/hotspot/share/runtime/arguments.cpp Fri Nov 3 11:50:07 2017 *** 2086,2098 **** --- 2086,2099 ---- // If the maximum heap size has not been set with -Xmx, // then set it as fraction of the size of physical memory, // respecting the maximum and minimum sizes of the heap. if (FLAG_IS_DEFAULT(MaxHeapSize)) { julong reasonable_max = (julong)((phys_mem * MaxRAMPercentage) / 100); if (phys_mem <= (julong)((MaxHeapSize * MinRAMPercentage) / 100)) { + const julong reasonable_min = (julong)((phys_mem * MinRAMPercentage) / 100); + if (reasonable_min < MaxHeapSize) { // Small physical memory, so use a minimum fraction of it for the heap ! reasonable_max = (julong)((phys_mem * MinRAMPercentage) / 100); ! reasonable_max = reasonable_min; } else { // Not-small physical memory, so require a heap at least // as large as MaxHeapSize reasonable_max = MAX2(reasonable_max, (julong)MaxHeapSize); } Bob > On Nov 3, 2017, at 11:58 AM, Bob Vandette wrote: > > Please review this simple change that alters the algorithm for selecting the > default heap size on low (~100MB) memory environments. > > This issue is blocking the integration of the container improvements (https://bugs.openjdk.java.net/browse/JDK-8146115 ). > > > BUG: > https://bugs.openjdk.java.net/browse/JDK-8190283 > > WEBREV: > http://bussund0417.us.oracle.com/export/users/bobv/jdk10hs-base/open/webrev/ > > Bob. > From bob.vandette at oracle.com Fri Nov 3 17:15:30 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 3 Nov 2017 13:15:30 -0400 Subject: RFR: 8190283 - Default heap sizing options select a MaxHeapSize larger than available physical memory in some case In-Reply-To: References: Message-ID: <8170F8A3-F666-4B00-9013-1B341D955917@oracle.com> > On Nov 3, 2017, at 12:42 PM, Bob Vandette wrote: > > I realized that I didn?t post the webrev on our external server. There was only 1 file changed. > Here?s the diff: > > *** old/src/hotspot/share/runtime/arguments.cpp Fri Nov 3 11:50:07 2017 > --- new/src/hotspot/share/runtime/arguments.cpp Fri Nov 3 11:50:07 2017 > > *** 2086,2098 **** > --- 2086,2099 ---- > // If the maximum heap size has not been set with -Xmx, > // then set it as fraction of the size of physical memory, > // respecting the maximum and minimum sizes of the heap. > if (FLAG_IS_DEFAULT(MaxHeapSize)) { > julong reasonable_max = (julong)((phys_mem * MaxRAMPercentage) / 100); > if (phys_mem <= (julong)((MaxHeapSize * MinRAMPercentage) / 100)) { > + const julong reasonable_min = (julong)((phys_mem * MinRAMPercentage) / 100); > + if (reasonable_min < MaxHeapSize) { > // Small physical memory, so use a minimum fraction of it for the heap > ! reasonable_max = (julong)((phys_mem * MinRAMPercentage) / 100); > ! reasonable_max = reasonable_min; > } else { > // Not-small physical memory, so require a heap at least > // as large as MaxHeapSize > reasonable_max = MAX2(reasonable_max, (julong)MaxHeapSize); > } > Bob > >> On Nov 3, 2017, at 11:58 AM, Bob Vandette wrote: >> >> Please review this simple change that alters the algorithm for selecting the >> default heap size on low (~100MB) memory environments. >> >> This issue is blocking the integration of the container improvements (https://bugs.openjdk.java.net/browse/JDK-8146115 ). >> >> >> BUG: >> https://bugs.openjdk.java.net/browse/JDK-8190283 >> >> WEBREV: >> http://bussund0417.us.oracle.com/export/users/bobv/jdk10hs-base/open/webrev/ >> >> Bob. >> > From karen.kinnear at oracle.com Fri Nov 3 18:14:53 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 3 Nov 2017 14:14:53 -0400 Subject: [10] RFR 8186046 Minimal ConstantDynamic support In-Reply-To: References: Message-ID: <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com> Thank you so much for doing this jointly. Couple of questions/comments: 1. thank you for making UseBootstrapCallInfo diagnostic 2. org/objectweb/asmClassReader.java why hardcoded 17 instead of ClassWriter.CONDY? 3. java/lang/invoke/package-info.java 128-134 Error handling could be clearer. My understanding is that if a LinkageError or subclass is thrown, this will be rethrown for all subsequent attempts. Other errors, e.g. VMError may retry resolution Also: after line 165: rules do not enable the JVM to share call sites. Is it worth noting anywhere that the Constant_Dynamic resolution is shared? 4. SD::find_java_mirror_for_type lines 2679+ ConDy should not be supporting CONSTANT_Class(?;? + FD) IIRC that is temporary for MVT but not part of ConDy?s spec, nor part of what should be checked in for 18.3 also line 2731 - remove comment about ?Foo;? 5. constantTag.hpp ofBasicType: case T_OBJECT return constantTag(JVM_CONSTANT_String) ? why not JVM_CONSTANT_CLASS? 6. SD::find_java_mirror_for_type You have resolve_or_null/fail doing CHECK_(empty) which should check for a NULL constant_type_klass. This is followed by an explicit if (constant_type_klass == NULL) ? is that needed? 7. reflection.cpp get_mirror_from_signature Looks like potential for side effects. Odd to set mirror_oop inside if (log_is_enabled) Is the intent to assert that k->java_mirror() == mirror_oop? Or is the issue that we have a make drop here and the potential for a safe point? If so, make a handle and extract it on return? ? Or better yet - don?t make any changes to reflection.cpp - not necessary 8. BootstrapMethodInvoker Could you possibly add a comment that the default today is vmIsPushing and IsPullModeBSM is false? Or find a slightly different naming to make that clearer? 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that was not ACC_STATIC? Or was not ACC_PUBLIC? Or was Or did I read the invoke dynamic method incorrectly? thanks, Karen > On Oct 26, 2017, at 1:03 PM, Paul Sandoz wrote: > > Hi, > > Please review the following patch for minimal dynamic constant support: > > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ > > https://bugs.openjdk.java.net/browse/JDK-8186046 > https://bugs.openjdk.java.net/browse/JDK-8186209 > > This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good. > > By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex. > > A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository). > > Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments. > > The CSR for the VM specification is here: > > https://bugs.openjdk.java.net/browse/JDK-8189199 > > the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles). > > Any AoT-related work will be deferred to a future release. > > ? > > This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte). > > We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches. > > ? > > Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants. > > One test uses class file bytes produced from a modified version of asmtools. The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test. > > ? > > Paul. From thomas.schatzl at oracle.com Fri Nov 3 18:55:24 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 03 Nov 2017 19:55:24 +0100 Subject: RFR: 8190283 - Default heap sizing options select a MaxHeapSize larger than available physical memory in some case In-Reply-To: References: Message-ID: <1509735324.2630.6.camel@oracle.com> Hi Bob, On Fri, 2017-11-03 at 11:58 -0400, Bob Vandette wrote: > Please review this simple change that alters the algorithm for > selecting the > default heap size on low (~100MB) memory environments. > > This issue is blocking the integration of the container improvements > (https://bugs.openjdk.java.net/browse/JDK-8146115). > > > BUG: > https://bugs.openjdk.java.net/browse/JDK-8190283 > > WEBREV: > http://bussund0417.us.oracle.com/export/users/bobv/jdk10hs-base/open/ > webrev/ > > looks good. :D Thomas From paul.sandoz at oracle.com Fri Nov 3 21:28:54 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 3 Nov 2017 14:28:54 -0700 Subject: [10] RFR 8186046 Minimal ConstantDynamic support In-Reply-To: <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com> References: <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com> Message-ID: <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com> > On 3 Nov 2017, at 11:14, Karen Kinnear wrote: > > Thank you so much for doing this jointly. > > Couple of questions/comments: > 1. thank you for making UseBootstrapCallInfo diagnostic > > 2. org/objectweb/asmClassReader.java > why hardcoded 17 instead of ClassWriter.CONDY? > I chose to make the absolute minimal amount of changes to our internal ASM to reduce possible conflicts as i anticipate that a new version of ASM with condy support will eventually be rolled in. > 3. java/lang/invoke/package-info.java 128-134 > Error handling could be clearer. > My understanding is that if a LinkageError or subclass is thrown, this will be rethrown > for all subsequent attempts. Other errors, e.g. VMError may retry resolution > > Also: after line 165: rules do not enable the JVM to share call sites. > Is it worth noting anywhere that the Constant_Dynamic resolution is shared? > > 4. SD::find_java_mirror_for_type > lines 2679+ > ConDy should not be supporting CONSTANT_Class(?;? + FD) > IIRC that is temporary for MVT but not part of ConDy?s spec, nor part of what > should be checked in for 18.3 Yes, i deleted lines 2678 to 2687 TempNewSymbol type_buf; if (type->utf8_length() > 1 && type->byte_at(0) == ';') { // Strip the quote, which may have come from CONSTANT_Class[";"+FD]. // (This logic corresponds to the use of "FieldType::is_obj" // in resolve_or_null. A field type can be unwrapped to a class // type and vice versa.) type = SymbolTable::new_symbol(type->as_C_string() + 1, type->utf8_length() - 1, CHECK_(empty)); type_buf = type; // will free later } > also line 2731 - remove comment about ?Foo;? > Removed. > 5. constantTag.hpp > ofBasicType: case T_OBJECT return constantTag(JVM_CONSTANT_String) ? > why not JVM_CONSTANT_CLASS? > We would have to ask John on that, i am guessing it does not matter much since round tripping is ok and it is the more benign of the mapping. I do find this sits awkwardly though, perhaps there is a more general cleanup that can follow in this regard? > 6. SD::find_java_mirror_for_type > You have resolve_or_null/fail doing CHECK_(empty) which should > check for a NULL constant_type_klass. This is followed by an explicit if > (constant_type_klass == NULL) ? is that needed? > Can SD:resolve_or_null return a null value when HAS_PENDING_EXCEPTION=false? I see other usages that suggest this to be the case. Where as for resolve_or_fail: Klass* SystemDictionary::resolve_or_fail(Symbol* class_name, Handle class_loader, Handle protection_domain, bool throw_error, TRAPS) { Klass* klass = resolve_or_null(class_name, class_loader, protection_domain, THREAD); if (HAS_PENDING_EXCEPTION || klass == NULL) { // can return a null klass klass = handle_resolution_exception(class_name, throw_error, klass, THREAD); } return klass; } It suggests we can change the code from: if (failure_mode == SignatureStream::ReturnNull) { constant_type_klass = resolve_or_null(type, class_loader, protection_domain, CHECK_(empty)); } else { bool throw_error = (failure_mode == SignatureStream::NCDFError); constant_type_klass = resolve_or_fail(type, class_loader, protection_domain, throw_error, CHECK_(empty)); } if (constant_type_klass == NULL) { return Handle(); // report failure this way } to if (failure_mode == SignatureStream::ReturnNull) { constant_type_klass = resolve_or_null(type, class_loader, protection_domain, CHECK_(empty)); if (constant_type_klass == NULL) { return Handle(); // report failure this way } } else { bool throw_error = (failure_mode == SignatureStream::NCDFError); constant_type_klass = resolve_or_fail(type, class_loader, protection_domain, throw_error, CHECK_(empty)); } ? > 7. reflection.cpp > get_mirror_from_signature > Looks like potential for side effects. Odd to set mirror_oop inside if (log_is_enabled) > Is the intent to assert that k->java_mirror() == mirror_oop? > Or is the issue that we have a make drop here and the potential for a safe point? > If so, make a handle and extract it on return? > > ? Or better yet - don?t make any changes to reflection.cpp - not necessary > Lois, John? My recollection was John was attempting to tunnel things through a single method find_java_mirror_for_type, but i agree the setting of mirror_oop is odd. > 8. BootstrapMethodInvoker > Could you possibly add a comment that the default today is vmIsPushing and IsPullModeBSM is false? > Or find a slightly different naming to make that clearer? boolean pullMode = isPullModeBSM(bootstrapMethod); // default value is false boolean vmIsPushing = !staticArgumentsPulled(info); // default value is true ? > > 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java > How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that > was not ACC_STATIC? https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23 See the note under bootstrap_method_ref. The kind of method handle is constrained because of the arguments that are pushed on the stack before invocation. I believe it?s possible to have a constructor, but the declaring class would need to be a subtype of CallSite in the case of indy, and a subtype of the constant value type in the case of condy. > Or was not ACC_PUBLIC? That?s dependent on the accessibility between the lookup class the the BSM declaring class. > Or was > Or did I read the invoke dynamic method incorrectly? > By default, and for convenience, the InstructionHelper assumes the BSM is declared by the lookup class. I recently modified that to support the BSM being declared on another class, to test the minimal set of BSMs for condy (separate issue [1]). Note it?s always possible to use the bytecode API more directly. So we can easily add more -ve tests for non-accessible or non-static BSMs. Paul. [1] http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ From david.holmes at oracle.com Mon Nov 6 00:55:04 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Nov 2017 10:55:04 +1000 Subject: [10] RFR 8186046 Minimal ConstantDynamic support In-Reply-To: <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com> References: <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com> <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com> Message-ID: <8cbd0397-a840-0c84-9a17-3dbe2a6bed1b@oracle.com> On 4/11/2017 7:28 AM, Paul Sandoz wrote: >> On 3 Nov 2017, at 11:14, Karen Kinnear wrote: >> 6. SD::find_java_mirror_for_type >> You have resolve_or_null/fail doing CHECK_(empty) which should >> check for a NULL constant_type_klass. This is followed by an explicit if >> (constant_type_klass == NULL) ? is that needed? >> > > Can SD:resolve_or_null return a null value when HAS_PENDING_EXCEPTION=false? I don't believe it actually can - the only reason you would get NULL is if something went wrong, for which an exception must be pending. However, even the internal implementation underlying this seems unclear on that point e.g in SystemDictionary::resolve_instance_class_or_null we have: if (HAS_PENDING_EXCEPTION || k == NULL) { return NULL; } David ----- > I see other usages that suggest this to be the case. Where as for resolve_or_fail: > > Klass* SystemDictionary::resolve_or_fail(Symbol* class_name, Handle class_loader, Handle protection_domain, bool throw_error, TRAPS) { > Klass* klass = resolve_or_null(class_name, class_loader, protection_domain, THREAD); > if (HAS_PENDING_EXCEPTION || klass == NULL) { > // can return a null klass > klass = handle_resolution_exception(class_name, throw_error, klass, THREAD); > } > return klass; > } > > > It suggests we can change the code from: > > if (failure_mode == SignatureStream::ReturnNull) { > constant_type_klass = resolve_or_null(type, class_loader, protection_domain, > CHECK_(empty)); > } else { > bool throw_error = (failure_mode == SignatureStream::NCDFError); > constant_type_klass = resolve_or_fail(type, class_loader, protection_domain, > throw_error, CHECK_(empty)); > } > if (constant_type_klass == NULL) { > return Handle(); // report failure this way > } > > to > > if (failure_mode == SignatureStream::ReturnNull) { > constant_type_klass = resolve_or_null(type, class_loader, protection_domain, > CHECK_(empty)); > if (constant_type_klass == NULL) { > return Handle(); // report failure this way > } > } else { > bool throw_error = (failure_mode == SignatureStream::NCDFError); > constant_type_klass = resolve_or_fail(type, class_loader, protection_domain, > throw_error, CHECK_(empty)); > } > > ? > > >> 7. reflection.cpp >> get_mirror_from_signature >> Looks like potential for side effects. Odd to set mirror_oop inside if (log_is_enabled) >> Is the intent to assert that k->java_mirror() == mirror_oop? >> Or is the issue that we have a make drop here and the potential for a safe point? >> If so, make a handle and extract it on return? >> >> ? Or better yet - don?t make any changes to reflection.cpp - not necessary >> > > Lois, John? > > My recollection was John was attempting to tunnel things through a single method find_java_mirror_for_type, but i agree the setting of mirror_oop is odd. > > > >> 8. BootstrapMethodInvoker >> Could you possibly add a comment that the default today is vmIsPushing and IsPullModeBSM is false? >> Or find a slightly different naming to make that clearer? > > boolean pullMode = isPullModeBSM(bootstrapMethod); // default value is false > boolean vmIsPushing = !staticArgumentsPulled(info); // default value is true > > ? > > >> >> 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java >> How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that >> was not ACC_STATIC? > > https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23 > > See the note under bootstrap_method_ref. The kind of method handle is constrained because of the arguments that are pushed on the stack before invocation. I believe it?s possible to have a constructor, but the declaring class would need to be a subtype of CallSite in the case of indy, and a subtype of the constant value type in the case of condy. > > >> Or was not ACC_PUBLIC? > > That?s dependent on the accessibility between the lookup class the the BSM declaring class. > > >> Or was >> Or did I read the invoke dynamic method incorrectly? >> > > By default, and for convenience, the InstructionHelper assumes the BSM is declared by the lookup class. I recently modified that to support the BSM being declared on another class, to test the minimal set of BSMs for condy (separate issue [1]). Note it?s always possible to use the bytecode API more directly. > > So we can easily add more -ve tests for non-accessible or non-static BSMs. > > Paul. > > [1] http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ > From stefan.johansson at oracle.com Mon Nov 6 15:51:48 2017 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Mon, 6 Nov 2017 16:51:48 +0100 Subject: RFR: 8190283 - Default heap sizing options select a MaxHeapSize larger than available physical memory in some case In-Reply-To: <1509735324.2630.6.camel@oracle.com> References: <1509735324.2630.6.camel@oracle.com> Message-ID: On 2017-11-03 19:55, Thomas Schatzl wrote: > Hi Bob, > > On Fri, 2017-11-03 at 11:58 -0400, Bob Vandette wrote: >> Please review this simple change that alters the algorithm for >> selecting the >> default heap size on low (~100MB) memory environments. >> >> This issue is blocking the integration of the container improvements >> (https://bugs.openjdk.java.net/browse/JDK-8146115). >> >> >> BUG: >> https://bugs.openjdk.java.net/browse/JDK-8190283 >> >> WEBREV: >> http://bussund0417.us.oracle.com/export/users/bobv/jdk10hs-base/open/ >> webrev/ >> >> > looks good. :D +1 StefanJ > > Thomas From glaubitz at physik.fu-berlin.de Mon Nov 6 18:50:04 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Mon, 6 Nov 2017 19:50:04 +0100 Subject: [RFR]: 8190570: Zero fails to build on linux-sparc due undefined reference Message-ID: <782165f4-3b22-fc61-0e80-d480e4d349ae@physik.fu-berlin.de> Hi! Trying to build Zero on linux-sparc currently fails with: === Output from failing command(s) repeated here === /usr/bin/printf "* For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:\n" * For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log || true) | /usr/bin/head -n 12 /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/init.o: In function `init_globals()': /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/init.cpp:120: undefined reference to `g1_barrier_stubs_init()' collect2: error: ld returned 1 exit status if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:\n" * For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log || true) | /usr/bin/head -n 12 /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/init.o: In function `init_globals()': /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/init.cpp:120: undefined reference to `g1_barrier_stubs_init()' collect2: error: ld returned 1 exit status if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "\n* All command lines available in /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.\n" * All command lines available in /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === This happens because of this snippet of code in src/hotspot/share/runtime/init.cpp: #if INCLUDE_ALL_GCS // depends on universe_init, must be before interpreter_init (currently only on SPARC) void g1_barrier_stubs_init() NOT_SPARC({}); #endif I have submitted a possible fix to webrev in [1]. Please review. Thanks, Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8190570/webrev.00/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From brent.christian at oracle.com Tue Nov 7 00:23:16 2017 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 6 Nov 2017 16:23:16 -0800 Subject: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) Message-ID: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> Hi, There are a couple opportunities to reduce the memory footprint of java.lang.StackFrameInfo (the internal implementation of java.lang.StackWalker.StackFrame): 8153682[1] : StackFrameInfo.declaringClass could be removed 8185925[2] : StackFrameInfo::walker field can be replaced with bitmap to save footprint I had a look using jol[3]. Removing only 'walker' helps only under 32- and 64-bit, but not with compressed oops. Removing both 'walker' and 'declaringClass' brings a benefit to compressed oops as well (though not for 16-byte aligned). The size change, in bytes, for each execution mode is as follows: 32-bit: 32->24 64-bit: 56->40 64/compressed oops: 32->24 64/compressed oops, 16-byte aligned: 32->32 (For reference, the jol reports for the baseline and specimen are at [4] and [5], respectively.) Please review my code change for this. The webrev is here: http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/ An automated test run is in progress. Thanks! -Brent -- 1. https://bugs.openjdk.java.net/browse/JDK-8153682 2. https://bugs.openjdk.java.net/browse/JDK-8185925 3. http://openjdk.java.net/projects/code-tools/jol/ 4. http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt 5. http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt From forax at univ-mlv.fr Tue Nov 7 07:45:32 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 7 Nov 2017 08:45:32 +0100 (CET) Subject: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) In-Reply-To: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> Message-ID: <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr> Hi Brent, if you declare retainClassRef as a byte, you can even compress the data structure a little bit more, no ? a boolean (as a field) uses 4 bytes while a byte uses welll 1 byte. Given that bci is a short, the VM will put both bci and retainClassRef on the same 32 bits slot. cheers, R?mi ----- Mail original ----- > De: "Brent Christian" > ?: "core-libs-dev" , "hotspot-dev" > Envoy?: Mardi 7 Novembre 2017 01:23:16 > Objet: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) > Hi, > > There are a couple opportunities to reduce the memory footprint of > java.lang.StackFrameInfo (the internal implementation of > java.lang.StackWalker.StackFrame): > > 8153682[1] : StackFrameInfo.declaringClass could be removed > 8185925[2] : StackFrameInfo::walker field can be replaced with bitmap to > save footprint > > I had a look using jol[3]. Removing only 'walker' helps only under 32- > and 64-bit, but not with compressed oops. Removing both 'walker' and > 'declaringClass' brings a benefit to compressed oops as well (though not > for 16-byte aligned). > > The size change, in bytes, for each execution mode is as follows: > > 32-bit: 32->24 > 64-bit: 56->40 > 64/compressed oops: 32->24 > 64/compressed oops, 16-byte aligned: 32->32 > > (For reference, the jol reports for the baseline and specimen are at [4] > and [5], respectively.) > > Please review my code change for this. The webrev is here: > http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/ > > An automated test run is in progress. > > Thanks! > -Brent > > -- > 1. https://bugs.openjdk.java.net/browse/JDK-8153682 > 2. https://bugs.openjdk.java.net/browse/JDK-8185925 > 3. http://openjdk.java.net/projects/code-tools/jol/ > 4. > http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt > 5. > http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt From muthusamy.chinnathambi at oracle.com Tue Nov 7 09:05:33 2017 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Tue, 7 Nov 2017 01:05:33 -0800 (PST) Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist Message-ID: <811da80f-e107-4d0c-903b-c109b592176e@default> Hi, Please review the backport of bug: "JDK-8170395: Metaspace initialization queries the wrong chunk freelist" to jdk8u-dev Please note that this is not a clean backport due to new entries in debug.cpp and copyright changes. Webrev: http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8170395 Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e971a72675a Test: Had run jtreg and jprt hotspot testsets. Regards, Muthusamy C From jini.george at oracle.com Tue Nov 7 09:16:54 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 7 Nov 2017 14:46:54 +0530 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Message-ID: Thank you very much, Coleen, for the review. My answers inline: On 11/2/2017 5:09 PM, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/src/hotspot/share/runtime/stackValue.hpp.udiff.html > > > + return (*(int *)&_integer_value == *(int *)&value->_integer_value); > > > I don't think the *(int*) casts for _integer_value are needed in these > files.? Can you remove them? [Jini] I think since _integer_value is of type intptr_t (which could be 8 or 4 bytes long depending on the data model), the removal of the casts could result in an incorrect comparison (mostly for the 64 bit environment). Let me know if you disagree. > http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/cms/CompactibleFreeListSpace.java.udiff.html > > > I'm not really sure why you still have SA code for CMS, since CMS is > deprecated.? What does it do?? Can it be removed in a following cleanup? [Jini] My understanding is that we would need to have it as long as we have it in Hotspot. Once the files src/hotspot/share/gc/cms/compactibleFreeListSpace* get removed from Hotspot, we can remove it from SA. Thank you, Jini. > > This cleanup looks good.? And thank you for doing this since I broke SA > only yesterday. > > thanks, > Coleen > > > On 11/2/17 12:54 AM, Jini George wrote: >> Could I please get one more review done for this ? >> >> Thanks, >> Jini. >> >> On 10/27/2017 9:19 PM, Jini George wrote: >>> Thank you very much, Serguei. >>> >>> -Jini. >>> >>> On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Jini, >>>> >>>> The fix looks good to me. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/24/17 00:31, Jini George wrote: >>>>> Adding hotspot-dev too. >>>>> >>>>> Thanks, >>>>> Jini. >>>>> >>>>> On 10/24/2017 12:05 PM, Jini George wrote: >>>>>> Hello, >>>>>> >>>>>> As a part of SA next, I am working on writing a test case which >>>>>> compares the fields and the types of the fields of the SA java >>>>>> classes with the corresponding entries in the vmStructs tables. >>>>>> This, to some extent, would help in preventing errors in SA due to >>>>>> the changes in hotspot. As a precursor to this, I am in the >>>>>> process of making some cleanup related changes (mostly in SA). I >>>>>> plan to have the changes done in parts. For this webrev, most of >>>>>> the changes are for: >>>>>> >>>>>> 1. Avoiding having some values being redefined in SA. Instead have >>>>>> those exported through vmStructs, and read it in SA. >>>>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>>>> CompactibleFreeListSpace::IndexSetSize) >>>>>> >>>>>> Redefinition of hotspot values in SA makes SA error prone, when >>>>>> the value gets altered in hotspot and the corresponding >>>>>> modification gets missed out in SA. >>>>>> >>>>>> 2. To remove some unused code (JNIid.java). >>>>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>>>> 4. Modify variable names in SA and hotspot to match the >>>>>> counterpart names, so that the comparison of the fields become >>>>>> easier. Most of the changes belong to this group. >>>>>> >>>>>> Could I please get reviews done for these precursor changes ? >>>>>> >>>>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>>>> >>>>>> Thank you, >>>>>> Jini. >>>>>> >>>> > From jini.george at oracle.com Tue Nov 7 09:24:54 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 7 Nov 2017 14:54:54 +0530 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Message-ID: <810c7db7-fe2a-45e1-92f9-2e34f1cc328a@oracle.com> Thank you very much, Sharath, for the review. My response inline: On 11/3/2017 3:44 PM, Sharath Ballal wrote: > Hi Jini, > > You have appended 'Field' for most of the SA variables. Example: > > private static CIntegerField pcOffsetField; > pcOffsetField = type.getCIntegerField("_pc_offset"); > > However that is not the case in > private static long MinChunkSizeInBytes; > MinChunkSizeInBytes = (type.getCIntegerField("_min_chunk_size_in_bytes")).getValue(); > > You may want to follow the same convention here. [Jini]: Unlike in the other cases, for MinChunkSizeInBytes, we are getting and storing the __value__ of the Field rather than the Field itself. Hence, I feel it might make more sense to not have 'Field' in this name. Thanks, Jini. > Rest of the changes look ok. > > Thanks, > Sharath (not a reviewer) > > > -----Original Message----- > From: Jini George > Sent: Thursday, November 02, 2017 10:24 AM > To: Serguei Spitsyn; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 > > Could I please get one more review done for this ? > > Thanks, > Jini. > > On 10/27/2017 9:19 PM, Jini George wrote: >> Thank you very much, Serguei. >> >> -Jini. >> >> On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Jini, >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/24/17 00:31, Jini George wrote: >>>> Adding hotspot-dev too. >>>> >>>> Thanks, >>>> Jini. >>>> >>>> On 10/24/2017 12:05 PM, Jini George wrote: >>>>> Hello, >>>>> >>>>> As a part of SA next, I am working on writing a test case which >>>>> compares the fields and the types of the fields of the SA java >>>>> classes with the corresponding entries in the vmStructs tables. >>>>> This, to some extent, would help in preventing errors in SA due to >>>>> the changes in hotspot. As a precursor to this, I am in the process >>>>> of making some cleanup related changes (mostly in SA). I plan to >>>>> have the changes done in parts. For this webrev, most of the >>>>> changes are for: >>>>> >>>>> 1. Avoiding having some values being redefined in SA. Instead have >>>>> those exported through vmStructs, and read it in SA. >>>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>>> CompactibleFreeListSpace::IndexSetSize) >>>>> >>>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>>> value gets altered in hotspot and the corresponding modification >>>>> gets missed out in SA. >>>>> >>>>> 2. To remove some unused code (JNIid.java). >>>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>>> names, so that the comparison of the fields become easier. Most of >>>>> the changes belong to this group. >>>>> >>>>> Could I please get reviews done for these precursor changes ? >>>>> >>>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>>> >>>>> Thank you, >>>>> Jini. >>>>> >>> > X-sender: > X-Receiver: > X-CreatedBy: MSExchange15 > X-HeloDomain: mx.expurgate.net > X-ExtendedProps: BQBjAAoAqbJ+Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAGcrAAB2AAAABQBkAA8ABAAAAEVkZ2U= > X-Source: SMTP:External Receive Connector > X-SourceIPAddress: 195.190.135.10 > X-EndOfInjectedXHeaders: 7733 > Received: from mx.expurgate.net (195.190.135.10) by smtpgw03.sap-ag.de > (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov > 2017 05:54:39 +0100 > Received: from mx.expurgate.net (helo=localhost) > by mx.expurgate.net with esmtp > id 1eA7WZ-000EZw-D4 > for axel.siebenborn at sap.com; Thu, 02 Nov 2017 05:54:39 +0100 > Received: from [156.151.31.69] (helo=ucsinet41.oracle.com) > by mxtls.expurgate.net with ESMTPS (eXpurgate 4.2.1-3) > (envelope-from ) > id 59faa50b-7c01-c0a8033409dd-9c971f454783-3 > for ; Thu, 02 Nov 2017 05:54:38 +0100 > Received: from aojmv0009 (unknown [137.254.59.6]) by ucsinet41.oracle.com with smtp > id 4eb7_00c7_3ecf1c93_28fd_4a9f_97f0_f31de9ddb295; > Thu, 02 Nov 2017 04:54:17 +0000 > Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) > by aojmv0009 (Postfix) with ESMTP id 15A99229CEC; > Thu, 2 Nov 2017 04:57:26 +0000 (UTC) > X-Original-To: serviceability-dev at openjdk.java.net > Delivered-To: serviceability-dev at openjdk.java.net > Received: from ucsinet40.oracle.com (ucsinet40.oracle.com [156.151.31.68]) by aojmv0009 (Postfix) with ESMTP id 9CFF6229CC3; Thu, 2 Nov 2017 04:57:20 +0000 (UTC) > Received: from userp1040.oracle.com (unknown [156.151.31.81]) by ucsinet40.oracle.com with smtp > (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) > id 37c3_8726_79982056_f63b_491d_a8be_57819e8c7dcc; > Thu, 02 Nov 2017 04:54:08 +0000 > Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id > vA24s8KW028461 > (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT > Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s84O013997 > (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT > Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s7KK017107; Thu, 2 Nov 2017 04:54:08 GMT > Received: from [10.177.158.142] (/10.177.158.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 21:54:07 -0700 > Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 > From: Jini George > To: "serguei.spitsyn at oracle.com" , > "serviceability-dev at openjdk.java.net" , > "hotspot-runtime-dev at openjdk.java.net" > , > References: <18501902-23db-de6c-b83d-640cd33df836 at oracle.com> > > <691d8166-5395-906a-4256-ef0ab2e2773a at oracle.com> > > Organization: Oracle Corporation > Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e at oracle.com> > Date: Thu, 2 Nov 2017 10:24:03 +0530 > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.4.0 > MIME-Version: 1.0 > In-Reply-To: > Content-Type: text/plain; charset="utf-8"; format=flowed > Content-Language: en-US > Content-Transfer-Encoding: 7bit > X-Source-IP: userv0022.oracle.com [156.151.31.74] > X-BeenThere: serviceability-dev at openjdk.java.net > X-Mailman-Version: 2.1.17 > Precedence: list > List-Id: "Technical discussion about the development of serviceability technologies \(debugging, profiling, monitoring, and management\)" > List-Unsubscribe: , > > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > > Errors-To: serviceability-dev-bounces at openjdk.java.net > Sender: serviceability-dev > X-purgate-ID: tlsNG-9b91ac/1509598479-00007C01-219CB02A/0/0 > X-purgate-type: clean > X-purgate-size: 2000 > X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de > Comment: eleven transport token MTU2LjE1MS4zMS42OQBzZXJ2aWNlYWJpbGl0eS1kZXYtYm91bmNlc0BvcGVuamRrLmphdmEubmV0AGF4ZWwuc2llYmVuYm9ybkBzYXAuY29tADgwYzQ2ZTI0N2Q2MTBlYjNiNTQ5MmE5YWE2NzJjNzJjN2NiNjcwNDQ= > X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) > X-purgate: clean > X-SAP-SPAM-Status: clean > Return-Path: serviceability-dev-bounces at openjdk.java.net > X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 04:54:39.6785 > (UTC) > X-MS-Exchange-Organization-OriginalClientIPAddress: 195.190.135.10 > X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 > X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp > X-MS-Exchange-Organization-AuthAs: Anonymous > X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp > X-MS-Exchange-Organization-Network-Message-Id: 8fba1fcd-01cd-4a67-1ee6-08d521add313 > X-MS-Exchange-Organization-OriginalSize: 7400 > X-MS-Exchange-Organization-HygienePolicy: Standard > X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: > LSRV=DEWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE=11997.291|UTH=0.001|RST=11997.244|QS=0.029|CATCM-McAfeeTxRoutingAgent=0.011|CATCM=0.011|CAT=0.012;2017-11-02T08:14:36.969Z > > Could I please get one more review done for this ? > > Thanks, > Jini. > > On 10/27/2017 9:19 PM, Jini George wrote: >> Thank you very much, Serguei. >> >> -Jini. >> >> On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Jini, >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/24/17 00:31, Jini George wrote: >>>> Adding hotspot-dev too. >>>> >>>> Thanks, >>>> Jini. >>>> >>>> On 10/24/2017 12:05 PM, Jini George wrote: >>>>> Hello, >>>>> >>>>> As a part of SA next, I am working on writing a test case which >>>>> compares the fields and the types of the fields of the SA java >>>>> classes with the corresponding entries in the vmStructs tables. >>>>> This, to some extent, would help in preventing errors in SA due to >>>>> the changes in hotspot. As a precursor to this, I am in the process >>>>> of making some cleanup related changes (mostly in SA). I plan to >>>>> have the changes done in parts. For this webrev, most of the >>>>> changes are for: >>>>> >>>>> 1. Avoiding having some values being redefined in SA. Instead have >>>>> those exported through vmStructs, and read it in SA. >>>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>>> CompactibleFreeListSpace::IndexSetSize) >>>>> >>>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>>> value gets altered in hotspot and the corresponding modification >>>>> gets missed out in SA. >>>>> >>>>> 2. To remove some unused code (JNIid.java). >>>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>>> names, so that the comparison of the fields become easier. Most of >>>>> the changes belong to this group. >>>>> >>>>> Could I please get reviews done for these precursor changes ? >>>>> >>>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>>> >>>>> Thank you, >>>>> Jini. >>>>> >>> > X-sender: > X-Receiver: > X-CreatedBy: MSExchange15 > X-HeloDomain: mx.expurgate.net > X-ExtendedProps: BQBjAAoAALN+Vtsd1QgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwAJAAAAQ0lBdWRpdGVkAgABBQBJAAIAAQUAYgAKAIMrAAB2AAAABQBkAA8ABAAAAEVkZ2U= > X-Source: SMTP:External Receive Connector > X-SourceIPAddress: 194.145.224.110 > X-EndOfInjectedXHeaders: 7704 > Received: from mx.expurgate.net (194.145.224.110) by smtpgw03.sap-ag.de > (155.56.66.98) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 2 Nov > 2017 05:54:46 +0100 > Received: from mx.expurgate.net (helo=localhost) > by mx.expurgate.net with esmtp > id 1eA7Wg-0004R0-FP > for axel.siebenborn at sap.com; Thu, 02 Nov 2017 05:54:46 +0100 > Received: from [141.146.126.229] (helo=acsinet41.oracle.com) > by mxtls.expurgate.net with ESMTPS (eXpurgate 4.3.1) > (envelope-from ) > id 59faa50f-65eb-c0a8029b09dd-8d927ee53db9-3 > for ; Thu, 02 Nov 2017 05:54:45 +0100 > Received: from aojmv0009 (aojmv0009.oracle.com [137.254.59.6]) by acsinet41.oracle.com with smtp > id 6461_15f0_154b24ba_5aa0_408c_88bd_1cdb37c9c8f4; > Thu, 02 Nov 2017 04:54:31 +0000 > Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) > by aojmv0009 (Postfix) with ESMTP id 3B280229CF4; > Thu, 2 Nov 2017 04:57:26 +0000 (UTC) > X-Original-To: hotspot-runtime-dev at openjdk.java.net > Delivered-To: hotspot-runtime-dev at openjdk.java.net > Received: from ucsinet40.oracle.com (ucsinet40.oracle.com [156.151.31.68]) by aojmv0009 (Postfix) with ESMTP id 9CFF6229CC3; Thu, 2 Nov 2017 04:57:20 +0000 (UTC) > Received: from userp1040.oracle.com (unknown [156.151.31.81]) by ucsinet40.oracle.com with smtp > (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384) > id 37c3_8726_79982056_f63b_491d_a8be_57819e8c7dcc; > Thu, 02 Nov 2017 04:54:08 +0000 > Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id > vA24s8KW028461 > (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT > Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s84O013997 > (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 2 Nov 2017 04:54:08 GMT > Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vA24s7KK017107; Thu, 2 Nov 2017 04:54:08 GMT > Received: from [10.177.158.142] (/10.177.158.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 01 Nov 2017 21:54:07 -0700 > Subject: Re: RFR: SA: JDK-8189798: SA cleanup - part 1 > From: Jini George > To: "serguei.spitsyn at oracle.com" , > "serviceability-dev at openjdk.java.net" , > "hotspot-runtime-dev at openjdk.java.net" > , > References: <18501902-23db-de6c-b83d-640cd33df836 at oracle.com> > > <691d8166-5395-906a-4256-ef0ab2e2773a at oracle.com> > > Organization: Oracle Corporation > Message-ID: <6b40cba4-fc4e-dc54-a506-62f64599331e at oracle.com> > Date: Thu, 2 Nov 2017 10:24:03 +0530 > User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.4.0 > MIME-Version: 1.0 > In-Reply-To: > Content-Type: text/plain; charset="utf-8"; format=flowed > Content-Language: en-US > Content-Transfer-Encoding: 7bit > X-Source-IP: userv0022.oracle.com [156.151.31.74] > X-BeenThere: hotspot-runtime-dev at openjdk.java.net > X-Mailman-Version: 2.1.17 > Precedence: list > List-Id: Technical discussion about the development of the HotSpot runtime subsystem > List-Unsubscribe: , > > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > > Errors-To: hotspot-runtime-dev-bounces at openjdk.java.net > Sender: hotspot-runtime-dev > X-purgate-ID: tlsNG-81024b/1509598486-000065EB-186BA960/0/0 > X-purgate-type: clean > X-purgate-size: 2000 > X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de > Comment: eleven transport token MTQxLjE0Ni4xMjYuMjI5AGhvdHNwb3QtcnVudGltZS1kZXYtYm91bmNlc0BvcGVuamRrLmphdmEubmV0AGF4ZWwuc2llYmVuYm9ybkBzYXAuY29tADE0ZjI2NjVmYTY4ZGRiOWMwNGJiMGU0MmE2Njk2M2ZiNWQxNzAyOGI= > X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) > X-purgate: clean > X-SAP-SPAM-Status: clean > Return-Path: hotspot-runtime-dev-bounces at openjdk.java.net > X-MS-Exchange-Organization-OriginalArrivalTime: 02 Nov 2017 04:54:46.7566 > (UTC) > X-MS-Exchange-Organization-OriginalClientIPAddress: 194.145.224.110 > X-MS-Exchange-Organization-OriginalServerIPAddress: 155.56.66.98 > X-MS-Exchange-Organization-AuthSource: DEWDFE13EDGE01.wdf.sap.corp > X-MS-Exchange-Organization-AuthAs: Anonymous > X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: DEWDFE13EDGE01.wdf.sap.corp > X-MS-Exchange-Organization-Network-Message-Id: 9365fa06-08de-47df-2865-08d521add74b > X-MS-Exchange-Organization-OriginalSize: 7380 > X-MS-Exchange-Organization-HygienePolicy: Standard > X-MS-Exchange-Organization-MessageHighPrecisionLatencyInProgress: > LSRV=DEWDFE13EDGE01.wdf.sap.corp:TOTAL-EDGE=11990.260|UTH=0.001|RST=11990.260|CATCM-McAfeeTxRoutingAgent=0.004|CATCM=0.005|CAT=0.006;2017-11-02T08:14:37.016Z > > Could I please get one more review done for this ? > > Thanks, > Jini. > > On 10/27/2017 9:19 PM, Jini George wrote: >> Thank you very much, Serguei. >> >> -Jini. >> >> On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Jini, >>> >>> The fix looks good to me. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/24/17 00:31, Jini George wrote: >>>> Adding hotspot-dev too. >>>> >>>> Thanks, >>>> Jini. >>>> >>>> On 10/24/2017 12:05 PM, Jini George wrote: >>>>> Hello, >>>>> >>>>> As a part of SA next, I am working on writing a test case which >>>>> compares the fields and the types of the fields of the SA java >>>>> classes with the corresponding entries in the vmStructs tables. >>>>> This, to some extent, would help in preventing errors in SA due to >>>>> the changes in hotspot. As a precursor to this, I am in the process >>>>> of making some cleanup related changes (mostly in SA). I plan to >>>>> have the changes done in parts. For this webrev, most of the >>>>> changes are for: >>>>> >>>>> 1. Avoiding having some values being redefined in SA. Instead have >>>>> those exported through vmStructs, and read it in SA. >>>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>>> CompactibleFreeListSpace::IndexSetSize) >>>>> >>>>> Redefinition of hotspot values in SA makes SA error prone, when the >>>>> value gets altered in hotspot and the corresponding modification >>>>> gets missed out in SA. >>>>> >>>>> 2. To remove some unused code (JNIid.java). >>>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>>> 4. Modify variable names in SA and hotspot to match the counterpart >>>>> names, so that the comparison of the fields become easier. Most of >>>>> the changes belong to this group. >>>>> >>>>> Could I please get reviews done for these precursor changes ? >>>>> >>>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>>> >>>>> Thank you, >>>>> Jini. >>>>> >>> From robbin.ehn at oracle.com Tue Nov 7 10:58:48 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 7 Nov 2017 11:58:48 +0100 Subject: RFR(XL): 8185640: Thread-local handshakes In-Reply-To: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> References: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> Message-ID: Hi all, First a bug have been found, when deopt happens in return, the return is re-executed and we hit an assert in the call_VM because last_sp is now not NULL. After some discussion the proposed solution is to move the poll after the explicit reset of last_sp. (Re-execution is always vtos.) This is fixed in #15 changeset, #14 just some copyright year updates. (#9 changeset was dropped before it went on RFR, so it's not listed) The JEP will be targeted to JDK 10 Friday and integration will happen shortly after. For completeness all inc and a full (rebased on jdk/hs), all on CC I'm adding as reviewers. The code will be committed on: "8189941: Implementation JEP 312: Thread-local handshake" Tested tier 1-5, jprt, all tonga. Martin can you have quick look at #15 changeset? Thanks, Robbin SafepointMechanism-0 http://cr.openjdk.java.net/~rehn/8185640/v10/SafepointMechanism-0/webrev/ PollingPage-1 http://cr.openjdk.java.net/~rehn/8185640/v10/PollingPage-1/webrev/ Handshakes-2 http://cr.openjdk.java.net/~rehn/8185640/v10/Handshakes-2/webrev/ Atomic-Update-Rebase-3 http://cr.openjdk.java.net/~rehn/8185640/v10/Atomic-Update-Rebase-3/webrev/ Coleen-n-Test-Cleanup-4 http://cr.openjdk.java.net/~rehn/8185640/v10/Coleen-n-Test-Cleanup-4/webrev/ Assorted-Karen-5 http://cr.openjdk.java.net/~rehn/8185640/v10/Assorted-Karen-5/webrev/ Support-Check-Haley-6 http://cr.openjdk.java.net/~rehn/8185640/v10/Support-Check-Haley-6/webrev/ Interpreter-Poll-7 http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-7/webrev/ Interpreter-Poll-Wide_Ret-8 http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Wide_Ret-8/webrev/ Interpreter-Poll-Switch-10 http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Switch-10/webrev/ Interpreter-Poll-Ret-11 http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-11/webrev/ Option-Cleanup-12 http://cr.openjdk.java.net/~rehn/8185640/v10/Option-Cleanup-12/webrev/ DavidH-Option-Cleanup-13 http://cr.openjdk.java.net/~rehn/8185640/v10/DavidH-Option-Cleanup-13/webrev/ Copyright-Update-14 http://cr.openjdk.java.net/~rehn/8185640/v10/Copyright-Update-14/webrev/ Interpreter-Poll-Ret-Deopt-Fix-15 http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-Deopt-Fix-15/webrev/ Full http://cr.openjdk.java.net/~rehn/8185640/v10/Full/webrev/ On 10/11/2017 03:37 PM, Robbin Ehn wrote: > Hi all, > > Starting the review of the code while JEP work is still not completed. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8185640 > > This JEP introduces a way to execute a callback on threads without performing a > global VM safepoint. It makes it both possible and cheap to stop individual > threads and not just all threads or none. > > Entire changeset: > http://cr.openjdk.java.net/~rehn/8185640/v0/flat/ > > Divided into 3-parts, > SafepointMechanism abstraction: > http://cr.openjdk.java.net/~rehn/8185640/v0/SafepointMechanism-0/ > Consolidating polling page allocation: > http://cr.openjdk.java.net/~rehn/8185640/v0/PollingPage-1/ > Handshakes: > http://cr.openjdk.java.net/~rehn/8185640/v0/Handshakes-2/ > > A handshake operation is a callback that is executed for each JavaThread while > that thread is in a safepoint safe state. The callback is executed either by the > thread itself or by the VM thread while keeping the thread in a blocked state. > The big difference between safepointing and handshaking is that the per thread > operation will be performed on all threads as soon as possible and they will > continue to execute as soon as it?s own operation is completed. If a JavaThread > is known to be running, then a handshake can be performed with that single > JavaThread as well. > > The current safepointing scheme is modified to perform an indirection through a > per-thread pointer which will allow a single thread's execution to be forced to > trap on the guard page. In order to force a thread to yield the VM updates the > per-thread pointer for the corresponding thread to point to the guarded page. > > Example of potential use-cases: > -Biased lock revocation > -External requests for stack traces > -Deoptimization > -Async exception delivery > -External suspension > -Eliding memory barriers > > All of these will benefit the VM moving towards becoming more low-latency > friendly by reducing the number of global safepoints. > Platforms that do not yet implement the per JavaThread poll, a fallback to > normal safepoint is in place. HandshakeOneThread will then be a normal > safepoint. The supported platforms are Linux x64 and Solaris SPARC. > > Tested heavily with various test suits and comes with a few new tests. > > Performance testing using standardized benchmark show no signification changes, > the latest number was -0.7% on Linux x64 and +1.5% Solaris SPARC (not > statistically ensured). A minor regression for the load vs load load on x64 is > expected and a slight increase on SPARC due to the cost of ?materializing? the > page vs load load. > The time to trigger a safepoint was measured on a large machine to not be an > issue. The looping over threads and arming the polling page will benefit from > the work on JavaThread life-cycle (8167108 - SMR and JavaThread Lifecycle: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024773.html) > which puts all JavaThreads in an array instead of a linked list. > > Thanks, Robbin From martin.doerr at sap.com Tue Nov 7 12:04:30 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 7 Nov 2017 12:04:30 +0000 Subject: RFR(XL): 8185640: Thread-local handshakes In-Reply-To: References: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> Message-ID: <2563f782bc464431898e61e4943aa78e@sap.com> Hi Robbin, first of all, sorry that my proposal caused much more work on your side than expected. I still appreciate that you're doing it. Thanks. I was not aware of this checking code on x86 in debug build. But it looks feasible to me to move the safepoint check after the last_sp handling. However, it looks like register_finalizer could get executed twice with the new implementation. So I'd prefer to generate the safepoint poll code only for the normal return bytecodes: if (SafepointMechanism::uses_thread_local_poll() && _desc->bytecode() != Bytecodes::_return_register_finalizer) Bytecodes::_return_register_finalizer is only used for returns from Object. constructor. I think we can live without safepoint poll there. I don't need to see a new webrev for this. Best regards, Martin -----Original Message----- From: Robbin Ehn [mailto:robbin.ehn at oracle.com] Sent: Dienstag, 7. November 2017 11:59 To: hotspot-dev developers Cc: Doerr, Martin ; Nils Eliasson ; Karen Kinnear ; Andrew Haley ; coleen.phillimore at oracle.com; David Holmes Subject: Re: RFR(XL): 8185640: Thread-local handshakes Hi all, First a bug have been found, when deopt happens in return, the return is re-executed and we hit an assert in the call_VM because last_sp is now not NULL. After some discussion the proposed solution is to move the poll after the explicit reset of last_sp. (Re-execution is always vtos.) This is fixed in #15 changeset, #14 just some copyright year updates. (#9 changeset was dropped before it went on RFR, so it's not listed) The JEP will be targeted to JDK 10 Friday and integration will happen shortly after. For completeness all inc and a full (rebased on jdk/hs), all on CC I'm adding as reviewers. The code will be committed on: "8189941: Implementation JEP 312: Thread-local handshake" Tested tier 1-5, jprt, all tonga. Martin can you have quick look at #15 changeset? Thanks, Robbin SafepointMechanism-0 http://cr.openjdk.java.net/~rehn/8185640/v10/SafepointMechanism-0/webrev/ PollingPage-1 http://cr.openjdk.java.net/~rehn/8185640/v10/PollingPage-1/webrev/ Handshakes-2 http://cr.openjdk.java.net/~rehn/8185640/v10/Handshakes-2/webrev/ Atomic-Update-Rebase-3 http://cr.openjdk.java.net/~rehn/8185640/v10/Atomic-Update-Rebase-3/webrev/ Coleen-n-Test-Cleanup-4 http://cr.openjdk.java.net/~rehn/8185640/v10/Coleen-n-Test-Cleanup-4/webrev/ Assorted-Karen-5 http://cr.openjdk.java.net/~rehn/8185640/v10/Assorted-Karen-5/webrev/ Support-Check-Haley-6 http://cr.openjdk.java.net/~rehn/8185640/v10/Support-Check-Haley-6/webrev/ Interpreter-Poll-7 http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-7/webrev/ Interpreter-Poll-Wide_Ret-8 http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Wide_Ret-8/webrev/ Interpreter-Poll-Switch-10 http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Switch-10/webrev/ Interpreter-Poll-Ret-11 http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-11/webrev/ Option-Cleanup-12 http://cr.openjdk.java.net/~rehn/8185640/v10/Option-Cleanup-12/webrev/ DavidH-Option-Cleanup-13 http://cr.openjdk.java.net/~rehn/8185640/v10/DavidH-Option-Cleanup-13/webrev/ Copyright-Update-14 http://cr.openjdk.java.net/~rehn/8185640/v10/Copyright-Update-14/webrev/ Interpreter-Poll-Ret-Deopt-Fix-15 http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-Deopt-Fix-15/webrev/ Full http://cr.openjdk.java.net/~rehn/8185640/v10/Full/webrev/ On 10/11/2017 03:37 PM, Robbin Ehn wrote: > Hi all, > > Starting the review of the code while JEP work is still not completed. > > JEP: https://bugs.openjdk.java.net/browse/JDK-8185640 > > This JEP introduces a way to execute a callback on threads without performing a > global VM safepoint. It makes it both possible and cheap to stop individual > threads and not just all threads or none. > > Entire changeset: > http://cr.openjdk.java.net/~rehn/8185640/v0/flat/ > > Divided into 3-parts, > SafepointMechanism abstraction: > http://cr.openjdk.java.net/~rehn/8185640/v0/SafepointMechanism-0/ > Consolidating polling page allocation: > http://cr.openjdk.java.net/~rehn/8185640/v0/PollingPage-1/ > Handshakes: > http://cr.openjdk.java.net/~rehn/8185640/v0/Handshakes-2/ > > A handshake operation is a callback that is executed for each JavaThread while > that thread is in a safepoint safe state. The callback is executed either by the > thread itself or by the VM thread while keeping the thread in a blocked state. > The big difference between safepointing and handshaking is that the per thread > operation will be performed on all threads as soon as possible and they will > continue to execute as soon as it?s own operation is completed. If a JavaThread > is known to be running, then a handshake can be performed with that single > JavaThread as well. > > The current safepointing scheme is modified to perform an indirection through a > per-thread pointer which will allow a single thread's execution to be forced to > trap on the guard page. In order to force a thread to yield the VM updates the > per-thread pointer for the corresponding thread to point to the guarded page. > > Example of potential use-cases: > -Biased lock revocation > -External requests for stack traces > -Deoptimization > -Async exception delivery > -External suspension > -Eliding memory barriers > > All of these will benefit the VM moving towards becoming more low-latency > friendly by reducing the number of global safepoints. > Platforms that do not yet implement the per JavaThread poll, a fallback to > normal safepoint is in place. HandshakeOneThread will then be a normal > safepoint. The supported platforms are Linux x64 and Solaris SPARC. > > Tested heavily with various test suits and comes with a few new tests. > > Performance testing using standardized benchmark show no signification changes, > the latest number was -0.7% on Linux x64 and +1.5% Solaris SPARC (not > statistically ensured). A minor regression for the load vs load load on x64 is > expected and a slight increase on SPARC due to the cost of ?materializing? the > page vs load load. > The time to trigger a safepoint was measured on a large machine to not be an > issue. The looping over threads and arming the polling page will benefit from > the work on JavaThread life-cycle (8167108 - SMR and JavaThread Lifecycle: > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024773.html) > which puts all JavaThreads in an array instead of a linked list. > > Thanks, Robbin From robbin.ehn at oracle.com Tue Nov 7 13:30:22 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 7 Nov 2017 14:30:22 +0100 Subject: RFR(XL): 8185640: Thread-local handshakes In-Reply-To: <2563f782bc464431898e61e4943aa78e@sap.com> References: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> <2563f782bc464431898e61e4943aa78e@sap.com> Message-ID: <2786d1cf-0d06-4cd5-3e74-05f8eee4b0b0@oracle.com> Hi Martin, On 11/07/2017 01:04 PM, Doerr, Martin wrote: > Hi Robbin, > > first of all, sorry that my proposal caused much more work on your side than expected. I still appreciate that you're doing it. Thanks. Thanks for reviewing! > > I was not aware of this checking code on x86 in debug build. But it looks feasible to me to move the safepoint check after the last_sp handling. > > However, it looks like register_finalizer could get executed twice with the new implementation. So I'd prefer to generate the safepoint poll code only for the normal return bytecodes: > if (SafepointMechanism::uses_thread_local_poll() && _desc->bytecode() != Bytecodes::_return_register_finalizer) > > Bytecodes::_return_register_finalizer is only used for returns from Object. constructor. I think we can live without safepoint poll there. I don't need to see a new webrev for this. I agree and I have updated the code and re-doing testing, seem good so far (as expected). Thanks, Robbin Patch (Martin-Interpreter-Poll-Ret-16) inline for reference: diff -r a5d35b8eb95a src/hotspot/cpu/sparc/templateTable_sparc.cpp --- a/src/hotspot/cpu/sparc/templateTable_sparc.cpp Tue Nov 07 11:34:12 2017 +0100 +++ b/src/hotspot/cpu/sparc/templateTable_sparc.cpp Tue Nov 07 14:17:24 2017 +0100 @@ -1917,1 +1917,1 @@ - if (SafepointMechanism::uses_thread_local_poll()) { + if (SafepointMechanism::uses_thread_local_poll() && _desc->bytecode() != Bytecodes::_return_register_finalizer) { diff -r a5d35b8eb95a src/hotspot/cpu/x86/templateTable_x86.cpp --- a/src/hotspot/cpu/x86/templateTable_x86.cpp Tue Nov 07 11:34:12 2017 +0100 +++ b/src/hotspot/cpu/x86/templateTable_x86.cpp Tue Nov 07 14:17:24 2017 +0100 @@ -2574,1 +2574,1 @@ - if (SafepointMechanism::uses_thread_local_poll()) { + if (SafepointMechanism::uses_thread_local_poll() && _desc->bytecode() != Bytecodes::_return_register_finalizer) { > > Best regards, > Martin > > > -----Original Message----- > From: Robbin Ehn [mailto:robbin.ehn at oracle.com] > Sent: Dienstag, 7. November 2017 11:59 > To: hotspot-dev developers > Cc: Doerr, Martin ; Nils Eliasson ; Karen Kinnear ; Andrew Haley ; coleen.phillimore at oracle.com; David Holmes > Subject: Re: RFR(XL): 8185640: Thread-local handshakes > > Hi all, > > First a bug have been found, when deopt happens in return, the return is > re-executed and we hit an assert in the call_VM because last_sp is now not NULL. > After some discussion the proposed solution is to move the poll after the > explicit reset of last_sp. (Re-execution is always vtos.) This is fixed in #15 > changeset, #14 just some copyright year updates. > (#9 changeset was dropped before it went on RFR, so it's not listed) > > The JEP will be targeted to JDK 10 Friday and integration will happen shortly > after. For completeness all inc and a full (rebased on jdk/hs), all on CC I'm > adding as reviewers. > > The code will be committed on: "8189941: Implementation JEP 312: Thread-local > handshake" > > Tested tier 1-5, jprt, all tonga. > > Martin can you have quick look at #15 changeset? > > Thanks, Robbin > > SafepointMechanism-0 > http://cr.openjdk.java.net/~rehn/8185640/v10/SafepointMechanism-0/webrev/ > > PollingPage-1 > http://cr.openjdk.java.net/~rehn/8185640/v10/PollingPage-1/webrev/ > > Handshakes-2 > http://cr.openjdk.java.net/~rehn/8185640/v10/Handshakes-2/webrev/ > > Atomic-Update-Rebase-3 > http://cr.openjdk.java.net/~rehn/8185640/v10/Atomic-Update-Rebase-3/webrev/ > > Coleen-n-Test-Cleanup-4 > http://cr.openjdk.java.net/~rehn/8185640/v10/Coleen-n-Test-Cleanup-4/webrev/ > > Assorted-Karen-5 > http://cr.openjdk.java.net/~rehn/8185640/v10/Assorted-Karen-5/webrev/ > > Support-Check-Haley-6 > http://cr.openjdk.java.net/~rehn/8185640/v10/Support-Check-Haley-6/webrev/ > > Interpreter-Poll-7 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-7/webrev/ > > Interpreter-Poll-Wide_Ret-8 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Wide_Ret-8/webrev/ > > Interpreter-Poll-Switch-10 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Switch-10/webrev/ > > Interpreter-Poll-Ret-11 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-11/webrev/ > > Option-Cleanup-12 > http://cr.openjdk.java.net/~rehn/8185640/v10/Option-Cleanup-12/webrev/ > > DavidH-Option-Cleanup-13 > http://cr.openjdk.java.net/~rehn/8185640/v10/DavidH-Option-Cleanup-13/webrev/ > > Copyright-Update-14 > http://cr.openjdk.java.net/~rehn/8185640/v10/Copyright-Update-14/webrev/ > > Interpreter-Poll-Ret-Deopt-Fix-15 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-Deopt-Fix-15/webrev/ > > Full > http://cr.openjdk.java.net/~rehn/8185640/v10/Full/webrev/ > > On 10/11/2017 03:37 PM, Robbin Ehn wrote: >> Hi all, >> >> Starting the review of the code while JEP work is still not completed. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8185640 >> >> This JEP introduces a way to execute a callback on threads without performing a >> global VM safepoint. It makes it both possible and cheap to stop individual >> threads and not just all threads or none. >> >> Entire changeset: >> http://cr.openjdk.java.net/~rehn/8185640/v0/flat/ >> >> Divided into 3-parts, >> SafepointMechanism abstraction: >> http://cr.openjdk.java.net/~rehn/8185640/v0/SafepointMechanism-0/ >> Consolidating polling page allocation: >> http://cr.openjdk.java.net/~rehn/8185640/v0/PollingPage-1/ >> Handshakes: >> http://cr.openjdk.java.net/~rehn/8185640/v0/Handshakes-2/ >> >> A handshake operation is a callback that is executed for each JavaThread while >> that thread is in a safepoint safe state. The callback is executed either by the >> thread itself or by the VM thread while keeping the thread in a blocked state. >> The big difference between safepointing and handshaking is that the per thread >> operation will be performed on all threads as soon as possible and they will >> continue to execute as soon as it?s own operation is completed. If a JavaThread >> is known to be running, then a handshake can be performed with that single >> JavaThread as well. >> >> The current safepointing scheme is modified to perform an indirection through a >> per-thread pointer which will allow a single thread's execution to be forced to >> trap on the guard page. In order to force a thread to yield the VM updates the >> per-thread pointer for the corresponding thread to point to the guarded page. >> >> Example of potential use-cases: >> -Biased lock revocation >> -External requests for stack traces >> -Deoptimization >> -Async exception delivery >> -External suspension >> -Eliding memory barriers >> >> All of these will benefit the VM moving towards becoming more low-latency >> friendly by reducing the number of global safepoints. >> Platforms that do not yet implement the per JavaThread poll, a fallback to >> normal safepoint is in place. HandshakeOneThread will then be a normal >> safepoint. The supported platforms are Linux x64 and Solaris SPARC. >> >> Tested heavily with various test suits and comes with a few new tests. >> >> Performance testing using standardized benchmark show no signification changes, >> the latest number was -0.7% on Linux x64 and +1.5% Solaris SPARC (not >> statistically ensured). A minor regression for the load vs load load on x64 is >> expected and a slight increase on SPARC due to the cost of ?materializing? the >> page vs load load. >> The time to trigger a safepoint was measured on a large machine to not be an >> issue. The looping over threads and arming the polling page will benefit from >> the work on JavaThread life-cycle (8167108 - SMR and JavaThread Lifecycle: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024773.html) >> which puts all JavaThreads in an array instead of a linked list. >> >> Thanks, Robbin From coleen.phillimore at oracle.com Tue Nov 7 13:45:52 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 7 Nov 2017 08:45:52 -0500 Subject: RFR(XL): 8185640: Thread-local handshakes In-Reply-To: <2563f782bc464431898e61e4943aa78e@sap.com> References: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> <2563f782bc464431898e61e4943aa78e@sap.com> Message-ID: On 11/7/17 7:04 AM, Doerr, Martin wrote: > Hi Robbin, > > first of all, sorry that my proposal caused much more work on your side than expected. I still appreciate that you're doing it. Thanks. > > I was not aware of this checking code on x86 in debug build. But it looks feasible to me to move the safepoint check after the last_sp handling. > > However, it looks like register_finalizer could get executed twice with the new implementation. So I'd prefer to generate the safepoint poll code only for the normal return bytecodes: > if (SafepointMechanism::uses_thread_local_poll() && _desc->bytecode() != Bytecodes::_return_register_finalizer) > > Bytecodes::_return_register_finalizer is only used for returns from Object. constructor. I think we can live without safepoint poll there. I don't need to see a new webrev for this. The TemplateTable::_return_register_finalizer bytecode wouldn't get run twice with deoptimization because TemplateInterpreter::deopt_reexecute_entry() will reexecute the _return_register_finalizer as a _return(vtos) bytecode.?? Very tricky indeed. Your suggested change would work also because call_VM for return_register_finalizer will do a safepoint check on the JRT_END transition, so there'd be only one check here, which is probably fine.? I still would like to see the safepoint poll in TemplateTable::_return after the call to return_register_finalizer since that's the order that the compiled code does it. thanks, Coleen > > Best regards, > Martin > > > -----Original Message----- > From: Robbin Ehn [mailto:robbin.ehn at oracle.com] > Sent: Dienstag, 7. November 2017 11:59 > To: hotspot-dev developers > Cc: Doerr, Martin ; Nils Eliasson ; Karen Kinnear ; Andrew Haley ; coleen.phillimore at oracle.com; David Holmes > Subject: Re: RFR(XL): 8185640: Thread-local handshakes > > Hi all, > > First a bug have been found, when deopt happens in return, the return is > re-executed and we hit an assert in the call_VM because last_sp is now not NULL. > After some discussion the proposed solution is to move the poll after the > explicit reset of last_sp. (Re-execution is always vtos.) This is fixed in #15 > changeset, #14 just some copyright year updates. > (#9 changeset was dropped before it went on RFR, so it's not listed) > > The JEP will be targeted to JDK 10 Friday and integration will happen shortly > after. For completeness all inc and a full (rebased on jdk/hs), all on CC I'm > adding as reviewers. > > The code will be committed on: "8189941: Implementation JEP 312: Thread-local > handshake" > > Tested tier 1-5, jprt, all tonga. > > Martin can you have quick look at #15 changeset? > > Thanks, Robbin > > SafepointMechanism-0 > http://cr.openjdk.java.net/~rehn/8185640/v10/SafepointMechanism-0/webrev/ > > PollingPage-1 > http://cr.openjdk.java.net/~rehn/8185640/v10/PollingPage-1/webrev/ > > Handshakes-2 > http://cr.openjdk.java.net/~rehn/8185640/v10/Handshakes-2/webrev/ > > Atomic-Update-Rebase-3 > http://cr.openjdk.java.net/~rehn/8185640/v10/Atomic-Update-Rebase-3/webrev/ > > Coleen-n-Test-Cleanup-4 > http://cr.openjdk.java.net/~rehn/8185640/v10/Coleen-n-Test-Cleanup-4/webrev/ > > Assorted-Karen-5 > http://cr.openjdk.java.net/~rehn/8185640/v10/Assorted-Karen-5/webrev/ > > Support-Check-Haley-6 > http://cr.openjdk.java.net/~rehn/8185640/v10/Support-Check-Haley-6/webrev/ > > Interpreter-Poll-7 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-7/webrev/ > > Interpreter-Poll-Wide_Ret-8 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Wide_Ret-8/webrev/ > > Interpreter-Poll-Switch-10 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Switch-10/webrev/ > > Interpreter-Poll-Ret-11 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-11/webrev/ > > Option-Cleanup-12 > http://cr.openjdk.java.net/~rehn/8185640/v10/Option-Cleanup-12/webrev/ > > DavidH-Option-Cleanup-13 > http://cr.openjdk.java.net/~rehn/8185640/v10/DavidH-Option-Cleanup-13/webrev/ > > Copyright-Update-14 > http://cr.openjdk.java.net/~rehn/8185640/v10/Copyright-Update-14/webrev/ > > Interpreter-Poll-Ret-Deopt-Fix-15 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-Deopt-Fix-15/webrev/ > > Full > http://cr.openjdk.java.net/~rehn/8185640/v10/Full/webrev/ > > On 10/11/2017 03:37 PM, Robbin Ehn wrote: >> Hi all, >> >> Starting the review of the code while JEP work is still not completed. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8185640 >> >> This JEP introduces a way to execute a callback on threads without performing a >> global VM safepoint. It makes it both possible and cheap to stop individual >> threads and not just all threads or none. >> >> Entire changeset: >> http://cr.openjdk.java.net/~rehn/8185640/v0/flat/ >> >> Divided into 3-parts, >> SafepointMechanism abstraction: >> http://cr.openjdk.java.net/~rehn/8185640/v0/SafepointMechanism-0/ >> Consolidating polling page allocation: >> http://cr.openjdk.java.net/~rehn/8185640/v0/PollingPage-1/ >> Handshakes: >> http://cr.openjdk.java.net/~rehn/8185640/v0/Handshakes-2/ >> >> A handshake operation is a callback that is executed for each JavaThread while >> that thread is in a safepoint safe state. The callback is executed either by the >> thread itself or by the VM thread while keeping the thread in a blocked state. >> The big difference between safepointing and handshaking is that the per thread >> operation will be performed on all threads as soon as possible and they will >> continue to execute as soon as it?s own operation is completed. If a JavaThread >> is known to be running, then a handshake can be performed with that single >> JavaThread as well. >> >> The current safepointing scheme is modified to perform an indirection through a >> per-thread pointer which will allow a single thread's execution to be forced to >> trap on the guard page. In order to force a thread to yield the VM updates the >> per-thread pointer for the corresponding thread to point to the guarded page. >> >> Example of potential use-cases: >> -Biased lock revocation >> -External requests for stack traces >> -Deoptimization >> -Async exception delivery >> -External suspension >> -Eliding memory barriers >> >> All of these will benefit the VM moving towards becoming more low-latency >> friendly by reducing the number of global safepoints. >> Platforms that do not yet implement the per JavaThread poll, a fallback to >> normal safepoint is in place. HandshakeOneThread will then be a normal >> safepoint. The supported platforms are Linux x64 and Solaris SPARC. >> >> Tested heavily with various test suits and comes with a few new tests. >> >> Performance testing using standardized benchmark show no signification changes, >> the latest number was -0.7% on Linux x64 and +1.5% Solaris SPARC (not >> statistically ensured). A minor regression for the load vs load load on x64 is >> expected and a slight increase on SPARC due to the cost of ?materializing? the >> page vs load load. >> The time to trigger a safepoint was measured on a large machine to not be an >> issue. The looping over threads and arming the polling page will benefit from >> the work on JavaThread life-cycle (8167108 - SMR and JavaThread Lifecycle: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024773.html) >> which puts all JavaThreads in an array instead of a linked list. >> >> Thanks, Robbin From coleen.phillimore at oracle.com Tue Nov 7 13:59:06 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 7 Nov 2017 08:59:06 -0500 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Message-ID: On 11/7/17 4:16 AM, Jini George wrote: > Thank you very much, Coleen, for the review. My answers inline: > > On 11/2/2017 5:09 PM, coleen.phillimore at oracle.com wrote: >> >> http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/src/hotspot/share/runtime/stackValue.hpp.udiff.html >> >> >> + return (*(int *)&_integer_value == *(int *)&value->_integer_value); >> >> >> I don't think the *(int*) casts for _integer_value are needed in >> these files.? Can you remove them? > > [Jini] I think since _integer_value is of type intptr_t (which could > be 8 or 4 bytes long depending on the data model), the removal of the > casts could result in an incorrect comparison (mostly for the 64 bit > environment). Let me know if you disagree. Maybe I read the field type wrong.? You can leave this as it is. > >> http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/cms/CompactibleFreeListSpace.java.udiff.html >> >> >> I'm not really sure why you still have SA code for CMS, since CMS is >> deprecated.? What does it do?? Can it be removed in a following cleanup? > > [Jini] My understanding is that we would need to have it as long as we > have it in Hotspot. Once the files > src/hotspot/share/gc/cms/compactibleFreeListSpace* get removed from > Hotspot, we can remove it from SA. Ok. Thanks, Coleen > > Thank you, > Jini. > >> >> This cleanup looks good.? And thank you for doing this since I broke >> SA only yesterday. >> >> thanks, >> Coleen >> >> >> On 11/2/17 12:54 AM, Jini George wrote: >>> Could I please get one more review done for this ? >>> >>> Thanks, >>> Jini. >>> >>> On 10/27/2017 9:19 PM, Jini George wrote: >>>> Thank you very much, Serguei. >>>> >>>> -Jini. >>>> >>>> On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Jini, >>>>> >>>>> The fix looks good to me. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 10/24/17 00:31, Jini George wrote: >>>>>> Adding hotspot-dev too. >>>>>> >>>>>> Thanks, >>>>>> Jini. >>>>>> >>>>>> On 10/24/2017 12:05 PM, Jini George wrote: >>>>>>> Hello, >>>>>>> >>>>>>> As a part of SA next, I am working on writing a test case which >>>>>>> compares the fields and the types of the fields of the SA java >>>>>>> classes with the corresponding entries in the vmStructs tables. >>>>>>> This, to some extent, would help in preventing errors in SA due >>>>>>> to the changes in hotspot. As a precursor to this, I am in the >>>>>>> process of making some cleanup related changes (mostly in SA). I >>>>>>> plan to have the changes done in parts. For this webrev, most of >>>>>>> the changes are for: >>>>>>> >>>>>>> 1. Avoiding having some values being redefined in SA. Instead >>>>>>> have those exported through vmStructs, and read it in SA. >>>>>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>>>>> CompactibleFreeListSpace::IndexSetSize) >>>>>>> >>>>>>> Redefinition of hotspot values in SA makes SA error prone, when >>>>>>> the value gets altered in hotspot and the corresponding >>>>>>> modification gets missed out in SA. >>>>>>> >>>>>>> 2. To remove some unused code (JNIid.java). >>>>>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>>>>> 4. Modify variable names in SA and hotspot to match the >>>>>>> counterpart names, so that the comparison of the fields become >>>>>>> easier. Most of the changes belong to this group. >>>>>>> >>>>>>> Could I please get reviews done for these precursor changes ? >>>>>>> >>>>>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>>>>> >>>>>>> Thank you, >>>>>>> Jini. >>>>>>> >>>>> >> From martin.doerr at sap.com Tue Nov 7 14:04:51 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 7 Nov 2017 14:04:51 +0000 Subject: RFR(XL): 8185640: Thread-local handshakes In-Reply-To: References: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> <2563f782bc464431898e61e4943aa78e@sap.com> Message-ID: <361782de7f2640ff866265a8572538dd@sap.com> Hi Coleen, > The TemplateTable::_return_register_finalizer bytecode wouldn't get run > twice with deoptimization because > TemplateInterpreter::deopt_reexecute_entry() will reexecute the > _return_register_finalizer as a _return(vtos) bytecode. Very tricky > indeed Probably not with deoptimization, but what about the following scenario: 1. Java thread executes register_finalizer 2. Safepoint poll in Bytecodes::_return_register_finalizer bytecode gets hit 3. VM reexecutes the bytecode after safepoint (bcp still points to the Bytecodes::_return_register_finalizer bytecode) This doesn't sound good to me. > I still would like to see the safepoint poll in TemplateTable::_return > after the call to return_register_finalizer since that's the order that > the compiled code does it. So that means, you'd expect the poll to be done after remove_activation. I think this may be more tricky to implement because we don't know where we return to (not necessarily an interpreted method). Right? Best regards, Martin -----Original Message----- From: coleen.phillimore at oracle.com [mailto:coleen.phillimore at oracle.com] Sent: Dienstag, 7. November 2017 14:46 To: Doerr, Martin ; Robbin Ehn ; hotspot-dev developers Cc: Nils Eliasson ; Karen Kinnear ; Andrew Haley ; David Holmes Subject: Re: RFR(XL): 8185640: Thread-local handshakes On 11/7/17 7:04 AM, Doerr, Martin wrote: > Hi Robbin, > > first of all, sorry that my proposal caused much more work on your side than expected. I still appreciate that you're doing it. Thanks. > > I was not aware of this checking code on x86 in debug build. But it looks feasible to me to move the safepoint check after the last_sp handling. > > However, it looks like register_finalizer could get executed twice with the new implementation. So I'd prefer to generate the safepoint poll code only for the normal return bytecodes: > if (SafepointMechanism::uses_thread_local_poll() && _desc->bytecode() != Bytecodes::_return_register_finalizer) > > Bytecodes::_return_register_finalizer is only used for returns from Object. constructor. I think we can live without safepoint poll there. I don't need to see a new webrev for this. The TemplateTable::_return_register_finalizer bytecode wouldn't get run twice with deoptimization because TemplateInterpreter::deopt_reexecute_entry() will reexecute the _return_register_finalizer as a _return(vtos) bytecode.?? Very tricky indeed. Your suggested change would work also because call_VM for return_register_finalizer will do a safepoint check on the JRT_END transition, so there'd be only one check here, which is probably fine.? I still would like to see the safepoint poll in TemplateTable::_return after the call to return_register_finalizer since that's the order that the compiled code does it. thanks, Coleen > > Best regards, > Martin > > > -----Original Message----- > From: Robbin Ehn [mailto:robbin.ehn at oracle.com] > Sent: Dienstag, 7. November 2017 11:59 > To: hotspot-dev developers > Cc: Doerr, Martin ; Nils Eliasson ; Karen Kinnear ; Andrew Haley ; coleen.phillimore at oracle.com; David Holmes > Subject: Re: RFR(XL): 8185640: Thread-local handshakes > > Hi all, > > First a bug have been found, when deopt happens in return, the return is > re-executed and we hit an assert in the call_VM because last_sp is now not NULL. > After some discussion the proposed solution is to move the poll after the > explicit reset of last_sp. (Re-execution is always vtos.) This is fixed in #15 > changeset, #14 just some copyright year updates. > (#9 changeset was dropped before it went on RFR, so it's not listed) > > The JEP will be targeted to JDK 10 Friday and integration will happen shortly > after. For completeness all inc and a full (rebased on jdk/hs), all on CC I'm > adding as reviewers. > > The code will be committed on: "8189941: Implementation JEP 312: Thread-local > handshake" > > Tested tier 1-5, jprt, all tonga. > > Martin can you have quick look at #15 changeset? > > Thanks, Robbin > > SafepointMechanism-0 > http://cr.openjdk.java.net/~rehn/8185640/v10/SafepointMechanism-0/webrev/ > > PollingPage-1 > http://cr.openjdk.java.net/~rehn/8185640/v10/PollingPage-1/webrev/ > > Handshakes-2 > http://cr.openjdk.java.net/~rehn/8185640/v10/Handshakes-2/webrev/ > > Atomic-Update-Rebase-3 > http://cr.openjdk.java.net/~rehn/8185640/v10/Atomic-Update-Rebase-3/webrev/ > > Coleen-n-Test-Cleanup-4 > http://cr.openjdk.java.net/~rehn/8185640/v10/Coleen-n-Test-Cleanup-4/webrev/ > > Assorted-Karen-5 > http://cr.openjdk.java.net/~rehn/8185640/v10/Assorted-Karen-5/webrev/ > > Support-Check-Haley-6 > http://cr.openjdk.java.net/~rehn/8185640/v10/Support-Check-Haley-6/webrev/ > > Interpreter-Poll-7 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-7/webrev/ > > Interpreter-Poll-Wide_Ret-8 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Wide_Ret-8/webrev/ > > Interpreter-Poll-Switch-10 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Switch-10/webrev/ > > Interpreter-Poll-Ret-11 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-11/webrev/ > > Option-Cleanup-12 > http://cr.openjdk.java.net/~rehn/8185640/v10/Option-Cleanup-12/webrev/ > > DavidH-Option-Cleanup-13 > http://cr.openjdk.java.net/~rehn/8185640/v10/DavidH-Option-Cleanup-13/webrev/ > > Copyright-Update-14 > http://cr.openjdk.java.net/~rehn/8185640/v10/Copyright-Update-14/webrev/ > > Interpreter-Poll-Ret-Deopt-Fix-15 > http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-Deopt-Fix-15/webrev/ > > Full > http://cr.openjdk.java.net/~rehn/8185640/v10/Full/webrev/ > > On 10/11/2017 03:37 PM, Robbin Ehn wrote: >> Hi all, >> >> Starting the review of the code while JEP work is still not completed. >> >> JEP: https://bugs.openjdk.java.net/browse/JDK-8185640 >> >> This JEP introduces a way to execute a callback on threads without performing a >> global VM safepoint. It makes it both possible and cheap to stop individual >> threads and not just all threads or none. >> >> Entire changeset: >> http://cr.openjdk.java.net/~rehn/8185640/v0/flat/ >> >> Divided into 3-parts, >> SafepointMechanism abstraction: >> http://cr.openjdk.java.net/~rehn/8185640/v0/SafepointMechanism-0/ >> Consolidating polling page allocation: >> http://cr.openjdk.java.net/~rehn/8185640/v0/PollingPage-1/ >> Handshakes: >> http://cr.openjdk.java.net/~rehn/8185640/v0/Handshakes-2/ >> >> A handshake operation is a callback that is executed for each JavaThread while >> that thread is in a safepoint safe state. The callback is executed either by the >> thread itself or by the VM thread while keeping the thread in a blocked state. >> The big difference between safepointing and handshaking is that the per thread >> operation will be performed on all threads as soon as possible and they will >> continue to execute as soon as it?s own operation is completed. If a JavaThread >> is known to be running, then a handshake can be performed with that single >> JavaThread as well. >> >> The current safepointing scheme is modified to perform an indirection through a >> per-thread pointer which will allow a single thread's execution to be forced to >> trap on the guard page. In order to force a thread to yield the VM updates the >> per-thread pointer for the corresponding thread to point to the guarded page. >> >> Example of potential use-cases: >> -Biased lock revocation >> -External requests for stack traces >> -Deoptimization >> -Async exception delivery >> -External suspension >> -Eliding memory barriers >> >> All of these will benefit the VM moving towards becoming more low-latency >> friendly by reducing the number of global safepoints. >> Platforms that do not yet implement the per JavaThread poll, a fallback to >> normal safepoint is in place. HandshakeOneThread will then be a normal >> safepoint. The supported platforms are Linux x64 and Solaris SPARC. >> >> Tested heavily with various test suits and comes with a few new tests. >> >> Performance testing using standardized benchmark show no signification changes, >> the latest number was -0.7% on Linux x64 and +1.5% Solaris SPARC (not >> statistically ensured). A minor regression for the load vs load load on x64 is >> expected and a slight increase on SPARC due to the cost of ?materializing? the >> page vs load load. >> The time to trigger a safepoint was measured on a large machine to not be an >> issue. The looping over threads and arming the polling page will benefit from >> the work on JavaThread life-cycle (8167108 - SMR and JavaThread Lifecycle: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024773.html) >> which puts all JavaThreads in an array instead of a linked list. >> >> Thanks, Robbin From thomas.stuefe at gmail.com Tue Nov 7 14:42:25 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 7 Nov 2017 15:42:25 +0100 Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist In-Reply-To: <811da80f-e107-4d0c-903b-c109b592176e@default> References: <811da80f-e107-4d0c-903b-c109b592176e@default> Message-ID: Hi Muthusamy, the webrev link seems to be dead. ..Thomas On Tue, Nov 7, 2017 at 10:05 AM, Muthusamy Chinnathambi < muthusamy.chinnathambi at oracle.com> wrote: > Hi, > > Please review the backport of bug: "JDK-8170395: Metaspace initialization > queries the wrong chunk freelist" to jdk8u-dev > > Please note that this is not a clean backport due to new entries in > debug.cpp and copyright changes. > > > Webrev: http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ > jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8170395 > Original patch pushed to jdk9: http://hg.openjdk.java.net/ > jdk9/jdk9/hotspot/rev/2e971a72675a > > Test: Had run jtreg and jprt hotspot testsets. > > Regards, > Muthusamy C > From coleen.phillimore at oracle.com Tue Nov 7 14:53:47 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 7 Nov 2017 09:53:47 -0500 Subject: RFR(XL): 8185640: Thread-local handshakes In-Reply-To: <361782de7f2640ff866265a8572538dd@sap.com> References: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> <2563f782bc464431898e61e4943aa78e@sap.com> <361782de7f2640ff866265a8572538dd@sap.com> Message-ID: On 11/7/17 9:04 AM, Doerr, Martin wrote: > Hi Coleen, > >> The TemplateTable::_return_register_finalizer bytecode wouldn't get run >> twice with deoptimization because >> TemplateInterpreter::deopt_reexecute_entry() will reexecute the >> _return_register_finalizer as a _return(vtos) bytecode. Very tricky >> indeed > Probably not with deoptimization, but what about the following scenario: > 1. Java thread executes register_finalizer > 2. Safepoint poll in Bytecodes::_return_register_finalizer bytecode gets hit > 3. VM reexecutes the bytecode after safepoint (bcp still points to the Bytecodes::_return_register_finalizer bytecode) > > This doesn't sound good to me. The deoptimization only happens when the compiled frame is on the top of the stack, not TemplateTable::_return(), ie the interpreter, and does not deoptimize for the safepoint poll in the compiled frame. See frame::should_be_deoptimized, and can_be_deoptimized (not sure the difference between the two). If the deopt happens for the return_register_finalizer call, it reruns the bytecode in the interpreter as Bytecodes::_return(vtos) rather than _return_register_finalizer, so that the registration doesn't happen twice.? See TemplateInterpreter::deopt_reexecute_entry(). This is what I've learned in the past couple of days!?? It's very subtle, and Dean filed an RFE https://bugs.openjdk.java.net/browse/JDK-8190817 to hopefully help make this clearer. > >> I still would like to see the safepoint poll in TemplateTable::_return >> after the call to return_register_finalizer since that's the order that >> the compiled code does it. > So that means, you'd expect the poll to be done after remove_activation. I think this may be more tricky to implement because we don't know where we return to (not necessarily an interpreted method). Right? Sorry, no, I'd like the polll to be after return_register_finalizer call in TemplateTable::_return.? remove_activation is a messy thing. Thanks, Coleen > > Best regards, > Martin > > > -----Original Message----- > From: coleen.phillimore at oracle.com [mailto:coleen.phillimore at oracle.com] > Sent: Dienstag, 7. November 2017 14:46 > To: Doerr, Martin ; Robbin Ehn ; hotspot-dev developers > Cc: Nils Eliasson ; Karen Kinnear ; Andrew Haley ; David Holmes > Subject: Re: RFR(XL): 8185640: Thread-local handshakes > > > > On 11/7/17 7:04 AM, Doerr, Martin wrote: >> Hi Robbin, >> >> first of all, sorry that my proposal caused much more work on your side than expected. I still appreciate that you're doing it. Thanks. >> >> I was not aware of this checking code on x86 in debug build. But it looks feasible to me to move the safepoint check after the last_sp handling. >> >> However, it looks like register_finalizer could get executed twice with the new implementation. So I'd prefer to generate the safepoint poll code only for the normal return bytecodes: >> if (SafepointMechanism::uses_thread_local_poll() && _desc->bytecode() != Bytecodes::_return_register_finalizer) >> >> Bytecodes::_return_register_finalizer is only used for returns from Object. constructor. I think we can live without safepoint poll there. I don't need to see a new webrev for this. > The TemplateTable::_return_register_finalizer bytecode wouldn't get run > twice with deoptimization because > TemplateInterpreter::deopt_reexecute_entry() will reexecute the > _return_register_finalizer as a _return(vtos) bytecode.?? Very tricky > indeed. > > Your suggested change would work also because call_VM for > return_register_finalizer will do a safepoint check on the JRT_END > transition, so there'd be only one check here, which is probably fine. > I still would like to see the safepoint poll in TemplateTable::_return > after the call to return_register_finalizer since that's the order that > the compiled code does it. > > thanks, > Coleen > >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: Robbin Ehn [mailto:robbin.ehn at oracle.com] >> Sent: Dienstag, 7. November 2017 11:59 >> To: hotspot-dev developers >> Cc: Doerr, Martin ; Nils Eliasson ; Karen Kinnear ; Andrew Haley ; coleen.phillimore at oracle.com; David Holmes >> Subject: Re: RFR(XL): 8185640: Thread-local handshakes >> >> Hi all, >> >> First a bug have been found, when deopt happens in return, the return is >> re-executed and we hit an assert in the call_VM because last_sp is now not NULL. >> After some discussion the proposed solution is to move the poll after the >> explicit reset of last_sp. (Re-execution is always vtos.) This is fixed in #15 >> changeset, #14 just some copyright year updates. >> (#9 changeset was dropped before it went on RFR, so it's not listed) >> >> The JEP will be targeted to JDK 10 Friday and integration will happen shortly >> after. For completeness all inc and a full (rebased on jdk/hs), all on CC I'm >> adding as reviewers. >> >> The code will be committed on: "8189941: Implementation JEP 312: Thread-local >> handshake" >> >> Tested tier 1-5, jprt, all tonga. >> >> Martin can you have quick look at #15 changeset? >> >> Thanks, Robbin >> >> SafepointMechanism-0 >> http://cr.openjdk.java.net/~rehn/8185640/v10/SafepointMechanism-0/webrev/ >> >> PollingPage-1 >> http://cr.openjdk.java.net/~rehn/8185640/v10/PollingPage-1/webrev/ >> >> Handshakes-2 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Handshakes-2/webrev/ >> >> Atomic-Update-Rebase-3 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Atomic-Update-Rebase-3/webrev/ >> >> Coleen-n-Test-Cleanup-4 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Coleen-n-Test-Cleanup-4/webrev/ >> >> Assorted-Karen-5 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Assorted-Karen-5/webrev/ >> >> Support-Check-Haley-6 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Support-Check-Haley-6/webrev/ >> >> Interpreter-Poll-7 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-7/webrev/ >> >> Interpreter-Poll-Wide_Ret-8 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Wide_Ret-8/webrev/ >> >> Interpreter-Poll-Switch-10 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Switch-10/webrev/ >> >> Interpreter-Poll-Ret-11 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-11/webrev/ >> >> Option-Cleanup-12 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Option-Cleanup-12/webrev/ >> >> DavidH-Option-Cleanup-13 >> http://cr.openjdk.java.net/~rehn/8185640/v10/DavidH-Option-Cleanup-13/webrev/ >> >> Copyright-Update-14 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Copyright-Update-14/webrev/ >> >> Interpreter-Poll-Ret-Deopt-Fix-15 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-Deopt-Fix-15/webrev/ >> >> Full >> http://cr.openjdk.java.net/~rehn/8185640/v10/Full/webrev/ >> >> On 10/11/2017 03:37 PM, Robbin Ehn wrote: >>> Hi all, >>> >>> Starting the review of the code while JEP work is still not completed. >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8185640 >>> >>> This JEP introduces a way to execute a callback on threads without performing a >>> global VM safepoint. It makes it both possible and cheap to stop individual >>> threads and not just all threads or none. >>> >>> Entire changeset: >>> http://cr.openjdk.java.net/~rehn/8185640/v0/flat/ >>> >>> Divided into 3-parts, >>> SafepointMechanism abstraction: >>> http://cr.openjdk.java.net/~rehn/8185640/v0/SafepointMechanism-0/ >>> Consolidating polling page allocation: >>> http://cr.openjdk.java.net/~rehn/8185640/v0/PollingPage-1/ >>> Handshakes: >>> http://cr.openjdk.java.net/~rehn/8185640/v0/Handshakes-2/ >>> >>> A handshake operation is a callback that is executed for each JavaThread while >>> that thread is in a safepoint safe state. The callback is executed either by the >>> thread itself or by the VM thread while keeping the thread in a blocked state. >>> The big difference between safepointing and handshaking is that the per thread >>> operation will be performed on all threads as soon as possible and they will >>> continue to execute as soon as it?s own operation is completed. If a JavaThread >>> is known to be running, then a handshake can be performed with that single >>> JavaThread as well. >>> >>> The current safepointing scheme is modified to perform an indirection through a >>> per-thread pointer which will allow a single thread's execution to be forced to >>> trap on the guard page. In order to force a thread to yield the VM updates the >>> per-thread pointer for the corresponding thread to point to the guarded page. >>> >>> Example of potential use-cases: >>> -Biased lock revocation >>> -External requests for stack traces >>> -Deoptimization >>> -Async exception delivery >>> -External suspension >>> -Eliding memory barriers >>> >>> All of these will benefit the VM moving towards becoming more low-latency >>> friendly by reducing the number of global safepoints. >>> Platforms that do not yet implement the per JavaThread poll, a fallback to >>> normal safepoint is in place. HandshakeOneThread will then be a normal >>> safepoint. The supported platforms are Linux x64 and Solaris SPARC. >>> >>> Tested heavily with various test suits and comes with a few new tests. >>> >>> Performance testing using standardized benchmark show no signification changes, >>> the latest number was -0.7% on Linux x64 and +1.5% Solaris SPARC (not >>> statistically ensured). A minor regression for the load vs load load on x64 is >>> expected and a slight increase on SPARC due to the cost of ?materializing? the >>> page vs load load. >>> The time to trigger a safepoint was measured on a large machine to not be an >>> issue. The looping over threads and arming the polling page will benefit from >>> the work on JavaThread life-cycle (8167108 - SMR and JavaThread Lifecycle: >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024773.html) >>> which puts all JavaThreads in an array instead of a linked list. >>> >>> Thanks, Robbin From martin.doerr at sap.com Tue Nov 7 15:08:45 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 7 Nov 2017 15:08:45 +0000 Subject: RFR(XL): 8185640: Thread-local handshakes In-Reply-To: References: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> <2563f782bc464431898e61e4943aa78e@sap.com> <361782de7f2640ff866265a8572538dd@sap.com> Message-ID: <342a53d864ca45b9b561e6b4b1ca8770@sap.com> Hi Coleen, my point was not related to deoptimization. Maybe I was not clear enough. It could happen with -Xint (no deoptimization at all). 1. Java thread executes register_finalizer 2. Safepoint poll in Bytecodes::_return_register_finalizer bytecode gets hit 3. VM reexecutes the bytecode after safepoint (bcp still points to the Bytecodes::_return_register_finalizer bytecode) Btw. the compilers generate the poll after popping the frame, so doing it after remove_activation would be closer to that. But I don't want to propose this, either. I share the opinion that this may be messy. Best regards, Martin -----Original Message----- From: coleen.phillimore at oracle.com [mailto:coleen.phillimore at oracle.com] Sent: Dienstag, 7. November 2017 15:54 To: Doerr, Martin ; Robbin Ehn ; hotspot-dev developers Cc: Nils Eliasson ; Karen Kinnear ; Andrew Haley ; David Holmes Subject: Re: RFR(XL): 8185640: Thread-local handshakes On 11/7/17 9:04 AM, Doerr, Martin wrote: > Hi Coleen, > >> The TemplateTable::_return_register_finalizer bytecode wouldn't get run >> twice with deoptimization because >> TemplateInterpreter::deopt_reexecute_entry() will reexecute the >> _return_register_finalizer as a _return(vtos) bytecode. Very tricky >> indeed > Probably not with deoptimization, but what about the following scenario: > 1. Java thread executes register_finalizer > 2. Safepoint poll in Bytecodes::_return_register_finalizer bytecode gets hit > 3. VM reexecutes the bytecode after safepoint (bcp still points to the Bytecodes::_return_register_finalizer bytecode) > > This doesn't sound good to me. The deoptimization only happens when the compiled frame is on the top of the stack, not TemplateTable::_return(), ie the interpreter, and does not deoptimize for the safepoint poll in the compiled frame. See frame::should_be_deoptimized, and can_be_deoptimized (not sure the difference between the two). If the deopt happens for the return_register_finalizer call, it reruns the bytecode in the interpreter as Bytecodes::_return(vtos) rather than _return_register_finalizer, so that the registration doesn't happen twice.? See TemplateInterpreter::deopt_reexecute_entry(). This is what I've learned in the past couple of days!?? It's very subtle, and Dean filed an RFE https://bugs.openjdk.java.net/browse/JDK-8190817 to hopefully help make this clearer. > >> I still would like to see the safepoint poll in TemplateTable::_return >> after the call to return_register_finalizer since that's the order that >> the compiled code does it. > So that means, you'd expect the poll to be done after remove_activation. I think this may be more tricky to implement because we don't know where we return to (not necessarily an interpreted method). Right? Sorry, no, I'd like the polll to be after return_register_finalizer call in TemplateTable::_return.? remove_activation is a messy thing. Thanks, Coleen > > Best regards, > Martin > > > -----Original Message----- > From: coleen.phillimore at oracle.com [mailto:coleen.phillimore at oracle.com] > Sent: Dienstag, 7. November 2017 14:46 > To: Doerr, Martin ; Robbin Ehn ; hotspot-dev developers > Cc: Nils Eliasson ; Karen Kinnear ; Andrew Haley ; David Holmes > Subject: Re: RFR(XL): 8185640: Thread-local handshakes > > > > On 11/7/17 7:04 AM, Doerr, Martin wrote: >> Hi Robbin, >> >> first of all, sorry that my proposal caused much more work on your side than expected. I still appreciate that you're doing it. Thanks. >> >> I was not aware of this checking code on x86 in debug build. But it looks feasible to me to move the safepoint check after the last_sp handling. >> >> However, it looks like register_finalizer could get executed twice with the new implementation. So I'd prefer to generate the safepoint poll code only for the normal return bytecodes: >> if (SafepointMechanism::uses_thread_local_poll() && _desc->bytecode() != Bytecodes::_return_register_finalizer) >> >> Bytecodes::_return_register_finalizer is only used for returns from Object. constructor. I think we can live without safepoint poll there. I don't need to see a new webrev for this. > The TemplateTable::_return_register_finalizer bytecode wouldn't get run > twice with deoptimization because > TemplateInterpreter::deopt_reexecute_entry() will reexecute the > _return_register_finalizer as a _return(vtos) bytecode.?? Very tricky > indeed. > > Your suggested change would work also because call_VM for > return_register_finalizer will do a safepoint check on the JRT_END > transition, so there'd be only one check here, which is probably fine. > I still would like to see the safepoint poll in TemplateTable::_return > after the call to return_register_finalizer since that's the order that > the compiled code does it. > > thanks, > Coleen > >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: Robbin Ehn [mailto:robbin.ehn at oracle.com] >> Sent: Dienstag, 7. November 2017 11:59 >> To: hotspot-dev developers >> Cc: Doerr, Martin ; Nils Eliasson ; Karen Kinnear ; Andrew Haley ; coleen.phillimore at oracle.com; David Holmes >> Subject: Re: RFR(XL): 8185640: Thread-local handshakes >> >> Hi all, >> >> First a bug have been found, when deopt happens in return, the return is >> re-executed and we hit an assert in the call_VM because last_sp is now not NULL. >> After some discussion the proposed solution is to move the poll after the >> explicit reset of last_sp. (Re-execution is always vtos.) This is fixed in #15 >> changeset, #14 just some copyright year updates. >> (#9 changeset was dropped before it went on RFR, so it's not listed) >> >> The JEP will be targeted to JDK 10 Friday and integration will happen shortly >> after. For completeness all inc and a full (rebased on jdk/hs), all on CC I'm >> adding as reviewers. >> >> The code will be committed on: "8189941: Implementation JEP 312: Thread-local >> handshake" >> >> Tested tier 1-5, jprt, all tonga. >> >> Martin can you have quick look at #15 changeset? >> >> Thanks, Robbin >> >> SafepointMechanism-0 >> http://cr.openjdk.java.net/~rehn/8185640/v10/SafepointMechanism-0/webrev/ >> >> PollingPage-1 >> http://cr.openjdk.java.net/~rehn/8185640/v10/PollingPage-1/webrev/ >> >> Handshakes-2 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Handshakes-2/webrev/ >> >> Atomic-Update-Rebase-3 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Atomic-Update-Rebase-3/webrev/ >> >> Coleen-n-Test-Cleanup-4 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Coleen-n-Test-Cleanup-4/webrev/ >> >> Assorted-Karen-5 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Assorted-Karen-5/webrev/ >> >> Support-Check-Haley-6 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Support-Check-Haley-6/webrev/ >> >> Interpreter-Poll-7 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-7/webrev/ >> >> Interpreter-Poll-Wide_Ret-8 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Wide_Ret-8/webrev/ >> >> Interpreter-Poll-Switch-10 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Switch-10/webrev/ >> >> Interpreter-Poll-Ret-11 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-11/webrev/ >> >> Option-Cleanup-12 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Option-Cleanup-12/webrev/ >> >> DavidH-Option-Cleanup-13 >> http://cr.openjdk.java.net/~rehn/8185640/v10/DavidH-Option-Cleanup-13/webrev/ >> >> Copyright-Update-14 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Copyright-Update-14/webrev/ >> >> Interpreter-Poll-Ret-Deopt-Fix-15 >> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-Deopt-Fix-15/webrev/ >> >> Full >> http://cr.openjdk.java.net/~rehn/8185640/v10/Full/webrev/ >> >> On 10/11/2017 03:37 PM, Robbin Ehn wrote: >>> Hi all, >>> >>> Starting the review of the code while JEP work is still not completed. >>> >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8185640 >>> >>> This JEP introduces a way to execute a callback on threads without performing a >>> global VM safepoint. It makes it both possible and cheap to stop individual >>> threads and not just all threads or none. >>> >>> Entire changeset: >>> http://cr.openjdk.java.net/~rehn/8185640/v0/flat/ >>> >>> Divided into 3-parts, >>> SafepointMechanism abstraction: >>> http://cr.openjdk.java.net/~rehn/8185640/v0/SafepointMechanism-0/ >>> Consolidating polling page allocation: >>> http://cr.openjdk.java.net/~rehn/8185640/v0/PollingPage-1/ >>> Handshakes: >>> http://cr.openjdk.java.net/~rehn/8185640/v0/Handshakes-2/ >>> >>> A handshake operation is a callback that is executed for each JavaThread while >>> that thread is in a safepoint safe state. The callback is executed either by the >>> thread itself or by the VM thread while keeping the thread in a blocked state. >>> The big difference between safepointing and handshaking is that the per thread >>> operation will be performed on all threads as soon as possible and they will >>> continue to execute as soon as it?s own operation is completed. If a JavaThread >>> is known to be running, then a handshake can be performed with that single >>> JavaThread as well. >>> >>> The current safepointing scheme is modified to perform an indirection through a >>> per-thread pointer which will allow a single thread's execution to be forced to >>> trap on the guard page. In order to force a thread to yield the VM updates the >>> per-thread pointer for the corresponding thread to point to the guarded page. >>> >>> Example of potential use-cases: >>> -Biased lock revocation >>> -External requests for stack traces >>> -Deoptimization >>> -Async exception delivery >>> -External suspension >>> -Eliding memory barriers >>> >>> All of these will benefit the VM moving towards becoming more low-latency >>> friendly by reducing the number of global safepoints. >>> Platforms that do not yet implement the per JavaThread poll, a fallback to >>> normal safepoint is in place. HandshakeOneThread will then be a normal >>> safepoint. The supported platforms are Linux x64 and Solaris SPARC. >>> >>> Tested heavily with various test suits and comes with a few new tests. >>> >>> Performance testing using standardized benchmark show no signification changes, >>> the latest number was -0.7% on Linux x64 and +1.5% Solaris SPARC (not >>> statistically ensured). A minor regression for the load vs load load on x64 is >>> expected and a slight increase on SPARC due to the cost of ?materializing? the >>> page vs load load. >>> The time to trigger a safepoint was measured on a large machine to not be an >>> issue. The looping over threads and arming the polling page will benefit from >>> the work on JavaThread life-cycle (8167108 - SMR and JavaThread Lifecycle: >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024773.html) >>> which puts all JavaThreads in an array instead of a linked list. >>> >>> Thanks, Robbin From jini.george at oracle.com Tue Nov 7 16:24:09 2017 From: jini.george at oracle.com (Jini George) Date: Tue, 7 Nov 2017 21:54:09 +0530 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Message-ID: <4a21bef5-43c1-dbbf-3b74-da63676dc88a@oracle.com> Thank you, Coleen. - Jini. On 11/7/2017 7:29 PM, coleen.phillimore at oracle.com wrote: > > > On 11/7/17 4:16 AM, Jini George wrote: >> Thank you very much, Coleen, for the review. My answers inline: >> >> On 11/2/2017 5:09 PM, coleen.phillimore at oracle.com wrote: >>> >>> http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/src/hotspot/share/runtime/stackValue.hpp.udiff.html >>> >>> >>> + return (*(int *)&_integer_value == *(int *)&value->_integer_value); >>> >>> >>> I don't think the *(int*) casts for _integer_value are needed in >>> these files.? Can you remove them? >> >> [Jini] I think since _integer_value is of type intptr_t (which could >> be 8 or 4 bytes long depending on the data model), the removal of the >> casts could result in an incorrect comparison (mostly for the 64 bit >> environment). Let me know if you disagree. > > Maybe I read the field type wrong.? You can leave this as it is. >> >>> http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/cms/CompactibleFreeListSpace.java.udiff.html >>> >>> >>> I'm not really sure why you still have SA code for CMS, since CMS is >>> deprecated.? What does it do?? Can it be removed in a following cleanup? >> >> [Jini] My understanding is that we would need to have it as long as we >> have it in Hotspot. Once the files >> src/hotspot/share/gc/cms/compactibleFreeListSpace* get removed from >> Hotspot, we can remove it from SA. > > Ok. > Thanks, > Coleen >> >> Thank you, >> Jini. >> >>> >>> This cleanup looks good.? And thank you for doing this since I broke >>> SA only yesterday. >>> >>> thanks, >>> Coleen >>> >>> >>> On 11/2/17 12:54 AM, Jini George wrote: >>>> Could I please get one more review done for this ? >>>> >>>> Thanks, >>>> Jini. >>>> >>>> On 10/27/2017 9:19 PM, Jini George wrote: >>>>> Thank you very much, Serguei. >>>>> >>>>> -Jini. >>>>> >>>>> On 10/27/2017 2:22 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Jini, >>>>>> >>>>>> The fix looks good to me. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 10/24/17 00:31, Jini George wrote: >>>>>>> Adding hotspot-dev too. >>>>>>> >>>>>>> Thanks, >>>>>>> Jini. >>>>>>> >>>>>>> On 10/24/2017 12:05 PM, Jini George wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> As a part of SA next, I am working on writing a test case which >>>>>>>> compares the fields and the types of the fields of the SA java >>>>>>>> classes with the corresponding entries in the vmStructs tables. >>>>>>>> This, to some extent, would help in preventing errors in SA due >>>>>>>> to the changes in hotspot. As a precursor to this, I am in the >>>>>>>> process of making some cleanup related changes (mostly in SA). I >>>>>>>> plan to have the changes done in parts. For this webrev, most of >>>>>>>> the changes are for: >>>>>>>> >>>>>>>> 1. Avoiding having some values being redefined in SA. Instead >>>>>>>> have those exported through vmStructs, and read it in SA. >>>>>>>> (CompactibleFreeListSpace::_min_chunk_size_in_bytes, >>>>>>>> CompactibleFreeListSpace::IndexSetSize) >>>>>>>> >>>>>>>> Redefinition of hotspot values in SA makes SA error prone, when >>>>>>>> the value gets altered in hotspot and the corresponding >>>>>>>> modification gets missed out in SA. >>>>>>>> >>>>>>>> 2. To remove some unused code (JNIid.java). >>>>>>>> 3. Add the missing "CMSBitMap::_bmStartWord" in vmStructs. >>>>>>>> 4. Modify variable names in SA and hotspot to match the >>>>>>>> counterpart names, so that the comparison of the fields become >>>>>>>> easier. Most of the changes belong to this group. >>>>>>>> >>>>>>>> Could I please get reviews done for these precursor changes ? >>>>>>>> >>>>>>>> JBS Id: https://bugs.openjdk.java.net/browse/JDK-8189798 >>>>>>>> webrev: http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/ >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Jini. >>>>>>>> >>>>>> >>> > From paul.sandoz at oracle.com Tue Nov 7 16:31:02 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Nov 2017 08:31:02 -0800 Subject: [10] RFR 8186046 Minimal ConstantDynamic support In-Reply-To: <8cbd0397-a840-0c84-9a17-3dbe2a6bed1b@oracle.com> References: <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com> <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com> <8cbd0397-a840-0c84-9a17-3dbe2a6bed1b@oracle.com> Message-ID: > On 5 Nov 2017, at 16:55, David Holmes wrote: > > On 4/11/2017 7:28 AM, Paul Sandoz wrote: >>> On 3 Nov 2017, at 11:14, Karen Kinnear wrote: >>> 6. SD::find_java_mirror_for_type >>> You have resolve_or_null/fail doing CHECK_(empty) which should >>> check for a NULL constant_type_klass. This is followed by an explicit if >>> (constant_type_klass == NULL) ? is that needed? >>> >> Can SD:resolve_or_null return a null value when HAS_PENDING_EXCEPTION=false? > > I don't believe it actually can - the only reason you would get NULL is if something went wrong, for which an exception must be pending. However, even the internal implementation underlying this seems unclear on that point Right, i am gonna leave things as they are for now unless we come up with a more definitive answer. Paul. > e.g in SystemDictionary::resolve_instance_class_or_null we have: > > if (HAS_PENDING_EXCEPTION || k == NULL) { > return NULL; > } > > David > ?? From brent.christian at oracle.com Tue Nov 7 16:42:33 2017 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 7 Nov 2017 08:42:33 -0800 Subject: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) In-Reply-To: <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr> References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, Remi Thanks for the idea. From my reading of the jol ouput: http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt I believe retainClassRef is already being stored in a single byte (i.e. SIZE of 1): OFFSET SIZE TYPE DESCRIPTION ... 10 1 boolean StackFrameInfo.retainClassRef Thanks, -Brent On 11/6/17 11:45 PM, Remi Forax wrote: > Hi Brent, > if you declare retainClassRef as a byte, you can even compress the data structure a little bit more, no ? > a boolean (as a field) uses 4 bytes while a byte uses welll 1 byte. > Given that bci is a short, the VM will put both bci and retainClassRef on the same 32 bits slot. > > cheers, > R?mi > > ----- Mail original ----- >> De: "Brent Christian" >> ?: "core-libs-dev" , "hotspot-dev" >> Envoy?: Mardi 7 Novembre 2017 01:23:16 >> Objet: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) > >> Hi, >> >> There are a couple opportunities to reduce the memory footprint of >> java.lang.StackFrameInfo (the internal implementation of >> java.lang.StackWalker.StackFrame): >> >> 8153682[1] : StackFrameInfo.declaringClass could be removed >> 8185925[2] : StackFrameInfo::walker field can be replaced with bitmap to >> save footprint >> >> I had a look using jol[3]. Removing only 'walker' helps only under 32- >> and 64-bit, but not with compressed oops. Removing both 'walker' and >> 'declaringClass' brings a benefit to compressed oops as well (though not >> for 16-byte aligned). >> >> The size change, in bytes, for each execution mode is as follows: >> >> 32-bit: 32->24 >> 64-bit: 56->40 >> 64/compressed oops: 32->24 >> 64/compressed oops, 16-byte aligned: 32->32 >> >> (For reference, the jol reports for the baseline and specimen are at [4] >> and [5], respectively.) >> >> Please review my code change for this. The webrev is here: >> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/ >> >> An automated test run is in progress. >> >> Thanks! >> -Brent >> >> -- >> 1. https://bugs.openjdk.java.net/browse/JDK-8153682 >> 2. https://bugs.openjdk.java.net/browse/JDK-8185925 >> 3. http://openjdk.java.net/projects/code-tools/jol/ >> 4. >> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt >> 5. >> http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt From coleen.phillimore at oracle.com Tue Nov 7 16:51:18 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 7 Nov 2017 11:51:18 -0500 Subject: RFR(XL): 8185640: Thread-local handshakes In-Reply-To: <342a53d864ca45b9b561e6b4b1ca8770@sap.com> References: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> <2563f782bc464431898e61e4943aa78e@sap.com> <361782de7f2640ff866265a8572538dd@sap.com> <342a53d864ca45b9b561e6b4b1ca8770@sap.com> Message-ID: <97d6d2e4-5179-7d26-c20a-badc7811ca07@oracle.com> On 11/7/17 10:08 AM, Doerr, Martin wrote: > Hi Coleen, > > my point was not related to deoptimization. Maybe I was not clear enough. It could happen with -Xint (no deoptimization at all). > 1. Java thread executes register_finalizer > 2. Safepoint poll in Bytecodes::_return_register_finalizer bytecode gets hit > 3. VM reexecutes the bytecode after safepoint (bcp still points to the Bytecodes::_return_register_finalizer bytecode) This is my confusion then.? Why would the TemplateTable::_return_register_finalizer bytecode be reexecuted because of the safepoint if not for deoptimization??? I expect it to continue at the point in the template after the call_VM and not reregister the finalizer. > > Btw. the compilers generate the poll after popping the frame, so doing it after remove_activation would be closer to that. But I don't want to propose this, either. I share the opinion that this may be messy. Agree. Coleen > > Best regards, > Martin > > > -----Original Message----- > From: coleen.phillimore at oracle.com [mailto:coleen.phillimore at oracle.com] > Sent: Dienstag, 7. November 2017 15:54 > To: Doerr, Martin ; Robbin Ehn ; hotspot-dev developers > Cc: Nils Eliasson ; Karen Kinnear ; Andrew Haley ; David Holmes > Subject: Re: RFR(XL): 8185640: Thread-local handshakes > > > > On 11/7/17 9:04 AM, Doerr, Martin wrote: >> Hi Coleen, >> >>> The TemplateTable::_return_register_finalizer bytecode wouldn't get run >>> twice with deoptimization because >>> TemplateInterpreter::deopt_reexecute_entry() will reexecute the >>> _return_register_finalizer as a _return(vtos) bytecode. Very tricky >>> indeed >> Probably not with deoptimization, but what about the following scenario: >> 1. Java thread executes register_finalizer >> 2. Safepoint poll in Bytecodes::_return_register_finalizer bytecode gets hit >> 3. VM reexecutes the bytecode after safepoint (bcp still points to the Bytecodes::_return_register_finalizer bytecode) >> >> This doesn't sound good to me. > The deoptimization only happens when the compiled frame is on the top of > the stack, not TemplateTable::_return(), ie the interpreter, and does > not deoptimize for the safepoint poll in the compiled frame. > > See frame::should_be_deoptimized, and can_be_deoptimized (not sure the > difference between the two). > > If the deopt happens for the return_register_finalizer call, it reruns > the bytecode in the interpreter as Bytecodes::_return(vtos) rather than > _return_register_finalizer, so that the registration doesn't happen > twice.? See TemplateInterpreter::deopt_reexecute_entry(). > > This is what I've learned in the past couple of days!?? It's very > subtle, and Dean filed an RFE > https://bugs.openjdk.java.net/browse/JDK-8190817 to hopefully help make > this clearer. > >> >>> I still would like to see the safepoint poll in TemplateTable::_return >>> after the call to return_register_finalizer since that's the order that >>> the compiled code does it. >> So that means, you'd expect the poll to be done after remove_activation. I think this may be more tricky to implement because we don't know where we return to (not necessarily an interpreted method). Right? > Sorry, no, I'd like the polll to be after return_register_finalizer call > in TemplateTable::_return.? remove_activation is a messy thing. > > Thanks, > Coleen >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: coleen.phillimore at oracle.com [mailto:coleen.phillimore at oracle.com] >> Sent: Dienstag, 7. November 2017 14:46 >> To: Doerr, Martin ; Robbin Ehn ; hotspot-dev developers >> Cc: Nils Eliasson ; Karen Kinnear ; Andrew Haley ; David Holmes >> Subject: Re: RFR(XL): 8185640: Thread-local handshakes >> >> >> >> On 11/7/17 7:04 AM, Doerr, Martin wrote: >>> Hi Robbin, >>> >>> first of all, sorry that my proposal caused much more work on your side than expected. I still appreciate that you're doing it. Thanks. >>> >>> I was not aware of this checking code on x86 in debug build. But it looks feasible to me to move the safepoint check after the last_sp handling. >>> >>> However, it looks like register_finalizer could get executed twice with the new implementation. So I'd prefer to generate the safepoint poll code only for the normal return bytecodes: >>> if (SafepointMechanism::uses_thread_local_poll() && _desc->bytecode() != Bytecodes::_return_register_finalizer) >>> >>> Bytecodes::_return_register_finalizer is only used for returns from Object. constructor. I think we can live without safepoint poll there. I don't need to see a new webrev for this. >> The TemplateTable::_return_register_finalizer bytecode wouldn't get run >> twice with deoptimization because >> TemplateInterpreter::deopt_reexecute_entry() will reexecute the >> _return_register_finalizer as a _return(vtos) bytecode.?? Very tricky >> indeed. >> >> Your suggested change would work also because call_VM for >> return_register_finalizer will do a safepoint check on the JRT_END >> transition, so there'd be only one check here, which is probably fine. >> I still would like to see the safepoint poll in TemplateTable::_return >> after the call to return_register_finalizer since that's the order that >> the compiled code does it. >> >> thanks, >> Coleen >> >>> Best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: Robbin Ehn [mailto:robbin.ehn at oracle.com] >>> Sent: Dienstag, 7. November 2017 11:59 >>> To: hotspot-dev developers >>> Cc: Doerr, Martin ; Nils Eliasson ; Karen Kinnear ; Andrew Haley ; coleen.phillimore at oracle.com; David Holmes >>> Subject: Re: RFR(XL): 8185640: Thread-local handshakes >>> >>> Hi all, >>> >>> First a bug have been found, when deopt happens in return, the return is >>> re-executed and we hit an assert in the call_VM because last_sp is now not NULL. >>> After some discussion the proposed solution is to move the poll after the >>> explicit reset of last_sp. (Re-execution is always vtos.) This is fixed in #15 >>> changeset, #14 just some copyright year updates. >>> (#9 changeset was dropped before it went on RFR, so it's not listed) >>> >>> The JEP will be targeted to JDK 10 Friday and integration will happen shortly >>> after. For completeness all inc and a full (rebased on jdk/hs), all on CC I'm >>> adding as reviewers. >>> >>> The code will be committed on: "8189941: Implementation JEP 312: Thread-local >>> handshake" >>> >>> Tested tier 1-5, jprt, all tonga. >>> >>> Martin can you have quick look at #15 changeset? >>> >>> Thanks, Robbin >>> >>> SafepointMechanism-0 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/SafepointMechanism-0/webrev/ >>> >>> PollingPage-1 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/PollingPage-1/webrev/ >>> >>> Handshakes-2 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Handshakes-2/webrev/ >>> >>> Atomic-Update-Rebase-3 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Atomic-Update-Rebase-3/webrev/ >>> >>> Coleen-n-Test-Cleanup-4 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Coleen-n-Test-Cleanup-4/webrev/ >>> >>> Assorted-Karen-5 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Assorted-Karen-5/webrev/ >>> >>> Support-Check-Haley-6 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Support-Check-Haley-6/webrev/ >>> >>> Interpreter-Poll-7 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-7/webrev/ >>> >>> Interpreter-Poll-Wide_Ret-8 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Wide_Ret-8/webrev/ >>> >>> Interpreter-Poll-Switch-10 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Switch-10/webrev/ >>> >>> Interpreter-Poll-Ret-11 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-11/webrev/ >>> >>> Option-Cleanup-12 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Option-Cleanup-12/webrev/ >>> >>> DavidH-Option-Cleanup-13 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/DavidH-Option-Cleanup-13/webrev/ >>> >>> Copyright-Update-14 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Copyright-Update-14/webrev/ >>> >>> Interpreter-Poll-Ret-Deopt-Fix-15 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-Deopt-Fix-15/webrev/ >>> >>> Full >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Full/webrev/ >>> >>> On 10/11/2017 03:37 PM, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> Starting the review of the code while JEP work is still not completed. >>>> >>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8185640 >>>> >>>> This JEP introduces a way to execute a callback on threads without performing a >>>> global VM safepoint. It makes it both possible and cheap to stop individual >>>> threads and not just all threads or none. >>>> >>>> Entire changeset: >>>> http://cr.openjdk.java.net/~rehn/8185640/v0/flat/ >>>> >>>> Divided into 3-parts, >>>> SafepointMechanism abstraction: >>>> http://cr.openjdk.java.net/~rehn/8185640/v0/SafepointMechanism-0/ >>>> Consolidating polling page allocation: >>>> http://cr.openjdk.java.net/~rehn/8185640/v0/PollingPage-1/ >>>> Handshakes: >>>> http://cr.openjdk.java.net/~rehn/8185640/v0/Handshakes-2/ >>>> >>>> A handshake operation is a callback that is executed for each JavaThread while >>>> that thread is in a safepoint safe state. The callback is executed either by the >>>> thread itself or by the VM thread while keeping the thread in a blocked state. >>>> The big difference between safepointing and handshaking is that the per thread >>>> operation will be performed on all threads as soon as possible and they will >>>> continue to execute as soon as it?s own operation is completed. If a JavaThread >>>> is known to be running, then a handshake can be performed with that single >>>> JavaThread as well. >>>> >>>> The current safepointing scheme is modified to perform an indirection through a >>>> per-thread pointer which will allow a single thread's execution to be forced to >>>> trap on the guard page. In order to force a thread to yield the VM updates the >>>> per-thread pointer for the corresponding thread to point to the guarded page. >>>> >>>> Example of potential use-cases: >>>> -Biased lock revocation >>>> -External requests for stack traces >>>> -Deoptimization >>>> -Async exception delivery >>>> -External suspension >>>> -Eliding memory barriers >>>> >>>> All of these will benefit the VM moving towards becoming more low-latency >>>> friendly by reducing the number of global safepoints. >>>> Platforms that do not yet implement the per JavaThread poll, a fallback to >>>> normal safepoint is in place. HandshakeOneThread will then be a normal >>>> safepoint. The supported platforms are Linux x64 and Solaris SPARC. >>>> >>>> Tested heavily with various test suits and comes with a few new tests. >>>> >>>> Performance testing using standardized benchmark show no signification changes, >>>> the latest number was -0.7% on Linux x64 and +1.5% Solaris SPARC (not >>>> statistically ensured). A minor regression for the load vs load load on x64 is >>>> expected and a slight increase on SPARC due to the cost of ?materializing? the >>>> page vs load load. >>>> The time to trigger a safepoint was measured on a large machine to not be an >>>> issue. The looping over threads and arming the polling page will benefit from >>>> the work on JavaThread life-cycle (8167108 - SMR and JavaThread Lifecycle: >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024773.html) >>>> which puts all JavaThreads in an array instead of a linked list. >>>> >>>> Thanks, Robbin From jesper.wilhelmsson at oracle.com Tue Nov 7 16:56:19 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 7 Nov 2017 17:56:19 +0100 Subject: RFR(xs): JDK-8190865 - Require jtreg 4.2 b10 Message-ID: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> Hi, Please review this minor change to use the latest jtreg version in HotSpot testing. This should get rid of the SocketTimeoutExceptions that we currently see in the HotSpot nightly. Bug: https://bugs.openjdk.java.net/browse/JDK-8190865 Patch: diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js --- a/make/conf/jib-profiles.js +++ b/make/conf/jib-profiles.js @@ -1060,7 +1060,7 @@ jtreg: { server: "javare", revision: "4.2", - build_number: "b09", + build_number: "b10", checksum_file: "MD5_VALUES", file: "jtreg_bin-4.2.zip", environment_name: "JT_HOME", Thanks, /Jesper From daniel.daugherty at oracle.com Tue Nov 7 17:05:06 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 7 Nov 2017 12:05:06 -0500 Subject: RFR(xs): JDK-8190865 - Require jtreg 4.2 b10 In-Reply-To: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> References: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> Message-ID: Thumbs up! Dan On 11/7/17 11:56 AM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > Please review this minor change to use the latest jtreg version in HotSpot testing. > This should get rid of the SocketTimeoutExceptions that we currently see in the HotSpot nightly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190865 > > Patch: > > diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js > --- a/make/conf/jib-profiles.js > +++ b/make/conf/jib-profiles.js > @@ -1060,7 +1060,7 @@ > jtreg: { > server: "javare", > revision: "4.2", > - build_number: "b09", > + build_number: "b10", > checksum_file: "MD5_VALUES", > file: "jtreg_bin-4.2.zip", > environment_name: "JT_HOME", > > Thanks, > /Jesper > From jesper.wilhelmsson at oracle.com Tue Nov 7 17:05:43 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 7 Nov 2017 18:05:43 +0100 Subject: RFR(xs): JDK-8190865 - Require jtreg 4.2 b10 In-Reply-To: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> References: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> Message-ID: Including build-dev. > On 7 Nov 2017, at 17:56, jesper.wilhelmsson at oracle.com wrote: > > Hi, > > Please review this minor change to use the latest jtreg version in HotSpot testing. > This should get rid of the SocketTimeoutExceptions that we currently see in the HotSpot nightly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190865 > > Patch: > > diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js > --- a/make/conf/jib-profiles.js > +++ b/make/conf/jib-profiles.js > @@ -1060,7 +1060,7 @@ > jtreg: { > server: "javare", > revision: "4.2", > - build_number: "b09", > + build_number: "b10", > checksum_file: "MD5_VALUES", > file: "jtreg_bin-4.2.zip", > environment_name: "JT_HOME", > > Thanks, > /Jesper > From jesper.wilhelmsson at oracle.com Tue Nov 7 17:06:24 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 7 Nov 2017 18:06:24 +0100 Subject: RFR(xs): JDK-8190865 - Require jtreg 4.2 b10 In-Reply-To: References: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> Message-ID: <54B25C39-892B-47CA-A697-D23B484E5709@oracle.com> Thanks! /Jesper > On 7 Nov 2017, at 18:05, Daniel D. Daugherty wrote: > > Thumbs up! > > Dan > > > On 11/7/17 11:56 AM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> >> Please review this minor change to use the latest jtreg version in HotSpot testing. >> This should get rid of the SocketTimeoutExceptions that we currently see in the HotSpot nightly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190865 >> >> Patch: >> >> diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js >> --- a/make/conf/jib-profiles.js >> +++ b/make/conf/jib-profiles.js >> @@ -1060,7 +1060,7 @@ >> jtreg: { >> server: "javare", >> revision: "4.2", >> - build_number: "b09", >> + build_number: "b10", >> checksum_file: "MD5_VALUES", >> file: "jtreg_bin-4.2.zip", >> environment_name: "JT_HOME", >> >> Thanks, >> /Jesper >> > From martin.doerr at sap.com Tue Nov 7 17:14:27 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 7 Nov 2017 17:14:27 +0000 Subject: RFR(XL): 8185640: Thread-local handshakes In-Reply-To: <97d6d2e4-5179-7d26-c20a-badc7811ca07@oracle.com> References: <6f2f6259-73f1-c09c-063e-39ae528fb96f@oracle.com> <2563f782bc464431898e61e4943aa78e@sap.com> <361782de7f2640ff866265a8572538dd@sap.com> <342a53d864ca45b9b561e6b4b1ca8770@sap.com> <97d6d2e4-5179-7d26-c20a-badc7811ca07@oracle.com> Message-ID: Hi Coleen, sorry, I had mixed up the two safepoint path in the interpreter. I had thought we'd jump to the safept_entry which performs the call_VM to InterpreterRuntime::at_safepoint and then starts dispatching again. This approach would re-execute the current bytecode. But we're calling InterpreterRuntime::at_safepoint directly which simply returns after the safepoint. So I'm ok with what you have proposed. Thanks. Best regards, Martin -----Original Message----- From: coleen.phillimore at oracle.com [mailto:coleen.phillimore at oracle.com] Sent: Dienstag, 7. November 2017 17:51 To: Doerr, Martin ; Robbin Ehn ; hotspot-dev developers Cc: Nils Eliasson ; Karen Kinnear ; Andrew Haley ; David Holmes Subject: Re: RFR(XL): 8185640: Thread-local handshakes On 11/7/17 10:08 AM, Doerr, Martin wrote: > Hi Coleen, > > my point was not related to deoptimization. Maybe I was not clear enough. It could happen with -Xint (no deoptimization at all). > 1. Java thread executes register_finalizer > 2. Safepoint poll in Bytecodes::_return_register_finalizer bytecode gets hit > 3. VM reexecutes the bytecode after safepoint (bcp still points to the Bytecodes::_return_register_finalizer bytecode) This is my confusion then.? Why would the TemplateTable::_return_register_finalizer bytecode be reexecuted because of the safepoint if not for deoptimization??? I expect it to continue at the point in the template after the call_VM and not reregister the finalizer. > > Btw. the compilers generate the poll after popping the frame, so doing it after remove_activation would be closer to that. But I don't want to propose this, either. I share the opinion that this may be messy. Agree. Coleen > > Best regards, > Martin > > > -----Original Message----- > From: coleen.phillimore at oracle.com [mailto:coleen.phillimore at oracle.com] > Sent: Dienstag, 7. November 2017 15:54 > To: Doerr, Martin ; Robbin Ehn ; hotspot-dev developers > Cc: Nils Eliasson ; Karen Kinnear ; Andrew Haley ; David Holmes > Subject: Re: RFR(XL): 8185640: Thread-local handshakes > > > > On 11/7/17 9:04 AM, Doerr, Martin wrote: >> Hi Coleen, >> >>> The TemplateTable::_return_register_finalizer bytecode wouldn't get run >>> twice with deoptimization because >>> TemplateInterpreter::deopt_reexecute_entry() will reexecute the >>> _return_register_finalizer as a _return(vtos) bytecode. Very tricky >>> indeed >> Probably not with deoptimization, but what about the following scenario: >> 1. Java thread executes register_finalizer >> 2. Safepoint poll in Bytecodes::_return_register_finalizer bytecode gets hit >> 3. VM reexecutes the bytecode after safepoint (bcp still points to the Bytecodes::_return_register_finalizer bytecode) >> >> This doesn't sound good to me. > The deoptimization only happens when the compiled frame is on the top of > the stack, not TemplateTable::_return(), ie the interpreter, and does > not deoptimize for the safepoint poll in the compiled frame. > > See frame::should_be_deoptimized, and can_be_deoptimized (not sure the > difference between the two). > > If the deopt happens for the return_register_finalizer call, it reruns > the bytecode in the interpreter as Bytecodes::_return(vtos) rather than > _return_register_finalizer, so that the registration doesn't happen > twice.? See TemplateInterpreter::deopt_reexecute_entry(). > > This is what I've learned in the past couple of days!?? It's very > subtle, and Dean filed an RFE > https://bugs.openjdk.java.net/browse/JDK-8190817 to hopefully help make > this clearer. > >> >>> I still would like to see the safepoint poll in TemplateTable::_return >>> after the call to return_register_finalizer since that's the order that >>> the compiled code does it. >> So that means, you'd expect the poll to be done after remove_activation. I think this may be more tricky to implement because we don't know where we return to (not necessarily an interpreted method). Right? > Sorry, no, I'd like the polll to be after return_register_finalizer call > in TemplateTable::_return.? remove_activation is a messy thing. > > Thanks, > Coleen >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: coleen.phillimore at oracle.com [mailto:coleen.phillimore at oracle.com] >> Sent: Dienstag, 7. November 2017 14:46 >> To: Doerr, Martin ; Robbin Ehn ; hotspot-dev developers >> Cc: Nils Eliasson ; Karen Kinnear ; Andrew Haley ; David Holmes >> Subject: Re: RFR(XL): 8185640: Thread-local handshakes >> >> >> >> On 11/7/17 7:04 AM, Doerr, Martin wrote: >>> Hi Robbin, >>> >>> first of all, sorry that my proposal caused much more work on your side than expected. I still appreciate that you're doing it. Thanks. >>> >>> I was not aware of this checking code on x86 in debug build. But it looks feasible to me to move the safepoint check after the last_sp handling. >>> >>> However, it looks like register_finalizer could get executed twice with the new implementation. So I'd prefer to generate the safepoint poll code only for the normal return bytecodes: >>> if (SafepointMechanism::uses_thread_local_poll() && _desc->bytecode() != Bytecodes::_return_register_finalizer) >>> >>> Bytecodes::_return_register_finalizer is only used for returns from Object. constructor. I think we can live without safepoint poll there. I don't need to see a new webrev for this. >> The TemplateTable::_return_register_finalizer bytecode wouldn't get run >> twice with deoptimization because >> TemplateInterpreter::deopt_reexecute_entry() will reexecute the >> _return_register_finalizer as a _return(vtos) bytecode.?? Very tricky >> indeed. >> >> Your suggested change would work also because call_VM for >> return_register_finalizer will do a safepoint check on the JRT_END >> transition, so there'd be only one check here, which is probably fine. >> I still would like to see the safepoint poll in TemplateTable::_return >> after the call to return_register_finalizer since that's the order that >> the compiled code does it. >> >> thanks, >> Coleen >> >>> Best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: Robbin Ehn [mailto:robbin.ehn at oracle.com] >>> Sent: Dienstag, 7. November 2017 11:59 >>> To: hotspot-dev developers >>> Cc: Doerr, Martin ; Nils Eliasson ; Karen Kinnear ; Andrew Haley ; coleen.phillimore at oracle.com; David Holmes >>> Subject: Re: RFR(XL): 8185640: Thread-local handshakes >>> >>> Hi all, >>> >>> First a bug have been found, when deopt happens in return, the return is >>> re-executed and we hit an assert in the call_VM because last_sp is now not NULL. >>> After some discussion the proposed solution is to move the poll after the >>> explicit reset of last_sp. (Re-execution is always vtos.) This is fixed in #15 >>> changeset, #14 just some copyright year updates. >>> (#9 changeset was dropped before it went on RFR, so it's not listed) >>> >>> The JEP will be targeted to JDK 10 Friday and integration will happen shortly >>> after. For completeness all inc and a full (rebased on jdk/hs), all on CC I'm >>> adding as reviewers. >>> >>> The code will be committed on: "8189941: Implementation JEP 312: Thread-local >>> handshake" >>> >>> Tested tier 1-5, jprt, all tonga. >>> >>> Martin can you have quick look at #15 changeset? >>> >>> Thanks, Robbin >>> >>> SafepointMechanism-0 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/SafepointMechanism-0/webrev/ >>> >>> PollingPage-1 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/PollingPage-1/webrev/ >>> >>> Handshakes-2 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Handshakes-2/webrev/ >>> >>> Atomic-Update-Rebase-3 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Atomic-Update-Rebase-3/webrev/ >>> >>> Coleen-n-Test-Cleanup-4 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Coleen-n-Test-Cleanup-4/webrev/ >>> >>> Assorted-Karen-5 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Assorted-Karen-5/webrev/ >>> >>> Support-Check-Haley-6 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Support-Check-Haley-6/webrev/ >>> >>> Interpreter-Poll-7 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-7/webrev/ >>> >>> Interpreter-Poll-Wide_Ret-8 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Wide_Ret-8/webrev/ >>> >>> Interpreter-Poll-Switch-10 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Switch-10/webrev/ >>> >>> Interpreter-Poll-Ret-11 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-11/webrev/ >>> >>> Option-Cleanup-12 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Option-Cleanup-12/webrev/ >>> >>> DavidH-Option-Cleanup-13 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/DavidH-Option-Cleanup-13/webrev/ >>> >>> Copyright-Update-14 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Copyright-Update-14/webrev/ >>> >>> Interpreter-Poll-Ret-Deopt-Fix-15 >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Interpreter-Poll-Ret-Deopt-Fix-15/webrev/ >>> >>> Full >>> http://cr.openjdk.java.net/~rehn/8185640/v10/Full/webrev/ >>> >>> On 10/11/2017 03:37 PM, Robbin Ehn wrote: >>>> Hi all, >>>> >>>> Starting the review of the code while JEP work is still not completed. >>>> >>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8185640 >>>> >>>> This JEP introduces a way to execute a callback on threads without performing a >>>> global VM safepoint. It makes it both possible and cheap to stop individual >>>> threads and not just all threads or none. >>>> >>>> Entire changeset: >>>> http://cr.openjdk.java.net/~rehn/8185640/v0/flat/ >>>> >>>> Divided into 3-parts, >>>> SafepointMechanism abstraction: >>>> http://cr.openjdk.java.net/~rehn/8185640/v0/SafepointMechanism-0/ >>>> Consolidating polling page allocation: >>>> http://cr.openjdk.java.net/~rehn/8185640/v0/PollingPage-1/ >>>> Handshakes: >>>> http://cr.openjdk.java.net/~rehn/8185640/v0/Handshakes-2/ >>>> >>>> A handshake operation is a callback that is executed for each JavaThread while >>>> that thread is in a safepoint safe state. The callback is executed either by the >>>> thread itself or by the VM thread while keeping the thread in a blocked state. >>>> The big difference between safepointing and handshaking is that the per thread >>>> operation will be performed on all threads as soon as possible and they will >>>> continue to execute as soon as it?s own operation is completed. If a JavaThread >>>> is known to be running, then a handshake can be performed with that single >>>> JavaThread as well. >>>> >>>> The current safepointing scheme is modified to perform an indirection through a >>>> per-thread pointer which will allow a single thread's execution to be forced to >>>> trap on the guard page. In order to force a thread to yield the VM updates the >>>> per-thread pointer for the corresponding thread to point to the guarded page. >>>> >>>> Example of potential use-cases: >>>> -Biased lock revocation >>>> -External requests for stack traces >>>> -Deoptimization >>>> -Async exception delivery >>>> -External suspension >>>> -Eliding memory barriers >>>> >>>> All of these will benefit the VM moving towards becoming more low-latency >>>> friendly by reducing the number of global safepoints. >>>> Platforms that do not yet implement the per JavaThread poll, a fallback to >>>> normal safepoint is in place. HandshakeOneThread will then be a normal >>>> safepoint. The supported platforms are Linux x64 and Solaris SPARC. >>>> >>>> Tested heavily with various test suits and comes with a few new tests. >>>> >>>> Performance testing using standardized benchmark show no signification changes, >>>> the latest number was -0.7% on Linux x64 and +1.5% Solaris SPARC (not >>>> statistically ensured). A minor regression for the load vs load load on x64 is >>>> expected and a slight increase on SPARC due to the cost of ?materializing? the >>>> page vs load load. >>>> The time to trigger a safepoint was measured on a large machine to not be an >>>> issue. The looping over threads and arming the polling page will benefit from >>>> the work on JavaThread life-cycle (8167108 - SMR and JavaThread Lifecycle: >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-October/024773.html) >>>> which puts all JavaThreads in an array instead of a linked list. >>>> >>>> Thanks, Robbin From mandy.chung at oracle.com Tue Nov 7 17:45:59 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 7 Nov 2017 09:45:59 -0800 Subject: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) In-Reply-To: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> Message-ID: <40ffc6a6-68c1-5654-e5c4-d451e7a2b9b7@oracle.com> On 11/6/17 4:23 PM, Brent Christian wrote: > Please review my code change for this.? The webrev is here: > http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/ > It's a good footprint improvement.? Thanks for doing this. StackFrameInfo.java 38 // Footprint improvement: MemberName::clazz can replace 39 // StackFrameInfo::declaringClass. The above comment can be removed. 41 private final boolean retainClassRef; JVMS [1] has a note about Hotspot implementation of boolean array that is encoded as a byte array. That explains JOL output that this boolean field is 8-bit in our implementation.? This field could be changed to a byte to hold additional flags, if any in the future.? It may be good to change this to a byte making the field size explicit. Otherwise looks good. Mandy [1] https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-2.html#jvms-2.3.4 > An automated test run is in progress. > > Thanks! > -Brent > > -- > 1. https://bugs.openjdk.java.net/browse/JDK-8153682 > 2. https://bugs.openjdk.java.net/browse/JDK-8185925 > 3. http://openjdk.java.net/projects/code-tools/jol/ > 4. > http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt > 5. > http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt From erik.joelsson at oracle.com Tue Nov 7 18:22:42 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 7 Nov 2017 10:22:42 -0800 Subject: RFR(xs): JDK-8190865 - Require jtreg 4.2 b10 In-Reply-To: References: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> Message-ID: <93da0fac-e7f4-b79c-51b9-a9b16f696166@oracle.com> Looks good. /Erik On 11/7/17 9:05 AM, jesper.wilhelmsson at oracle.com wrote: > Including build-dev. > >> On 7 Nov 2017, at 17:56, jesper.wilhelmsson at oracle.com wrote: >> >> Hi, >> >> Please review this minor change to use the latest jtreg version in HotSpot testing. >> This should get rid of the SocketTimeoutExceptions that we currently see in the HotSpot nightly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190865 >> >> Patch: >> >> diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js >> --- a/make/conf/jib-profiles.js >> +++ b/make/conf/jib-profiles.js >> @@ -1060,7 +1060,7 @@ >> jtreg: { >> server: "javare", >> revision: "4.2", >> - build_number: "b09", >> + build_number: "b10", >> checksum_file: "MD5_VALUES", >> file: "jtreg_bin-4.2.zip", >> environment_name: "JT_HOME", >> >> Thanks, >> /Jesper >> From forax at univ-mlv.fr Tue Nov 7 18:25:00 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 07 Nov 2017 18:25:00 +0000 Subject: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) In-Reply-To: References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr> Message-ID: My bad, I've calculated that the header was 8 bytes instead of 12, so I've supposed that the boolean was not stored in a byte. For my culture, why the header is 12 bytes, the pointer to the vtable is on 64bits and can not be compressed like the other oops ? R?mi On November 7, 2017 5:42:33 PM GMT+01:00, Brent Christian wrote: >Hi, Remi > >Thanks for the idea. From my reading of the jol ouput: > >http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt > > > >I believe retainClassRef is already being stored in a single byte (i.e. > >SIZE of 1): > > OFFSET SIZE TYPE DESCRIPTION >... > 10 1 boolean StackFrameInfo.retainClassRef > >Thanks, >-Brent > >On 11/6/17 11:45 PM, Remi Forax wrote: >> Hi Brent, >> if you declare retainClassRef as a byte, you can even compress the >data structure a little bit more, no ? >> a boolean (as a field) uses 4 bytes while a byte uses welll 1 byte. >> Given that bci is a short, the VM will put both bci and >retainClassRef on the same 32 bits slot. >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "Brent Christian" >>> ?: "core-libs-dev" , "hotspot-dev" > >>> Envoy?: Mardi 7 Novembre 2017 01:23:16 >>> Objet: RFR: 8185925 & 8153682 (footprint reduction of >java.lang.StackFrameInfo) >> >>> Hi, >>> >>> There are a couple opportunities to reduce the memory footprint of >>> java.lang.StackFrameInfo (the internal implementation of >>> java.lang.StackWalker.StackFrame): >>> >>> 8153682[1] : StackFrameInfo.declaringClass could be removed >>> 8185925[2] : StackFrameInfo::walker field can be replaced with >bitmap to >>> save footprint >>> >>> I had a look using jol[3]. Removing only 'walker' helps only under >32- >>> and 64-bit, but not with compressed oops. Removing both 'walker' >and >>> 'declaringClass' brings a benefit to compressed oops as well (though >not >>> for 16-byte aligned). >>> >>> The size change, in bytes, for each execution mode is as follows: >>> >>> 32-bit: 32->24 >>> 64-bit: 56->40 >>> 64/compressed oops: 32->24 >>> 64/compressed oops, 16-byte aligned: 32->32 >>> >>> (For reference, the jol reports for the baseline and specimen are at >[4] >>> and [5], respectively.) >>> >>> Please review my code change for this. The webrev is here: >>> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/ >>> >>> An automated test run is in progress. >>> >>> Thanks! >>> -Brent >>> >>> -- >>> 1. https://bugs.openjdk.java.net/browse/JDK-8153682 >>> 2. https://bugs.openjdk.java.net/browse/JDK-8185925 >>> 3. http://openjdk.java.net/projects/code-tools/jol/ >>> 4. >>> >http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt >>> 5. >>> >http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From paul.sandoz at oracle.com Tue Nov 7 18:38:57 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Nov 2017 10:38:57 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants Message-ID: Hi, Please review the patch that adds a minimal set of bootstrap methods can be be used for producing dynamic constants: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ The aim is to provide a small but common set of BSMs that are likely useful with ldc or as BSM arguments, filling in the gaps for constants that cannot be currently represented, such as null, primitive classes and VarHandles. It?s possible to get more sophisticated regarding say factories but that is something to consider later on. This patch is based off the minimal dynamic constant support (still in review): http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html Paul. From forax at univ-mlv.fr Tue Nov 7 19:33:11 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 7 Nov 2017 20:33:11 +0100 (CET) Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: References: Message-ID: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> Hi Paul, You have an import static requireNonNull but it is only used once in nullConstant, all other methods use Objects.requireNonNull. The test that checks that lookup, name and type are null or not is different in each method, so by example in primitiveClass, if type equals null, you get an IAE. I fail to see the point of using validateClassAccess(), if the BSM is used through an indy, the type is created only if the caller class can create it, so the test seems redundant. If it's not used by an indy, why do we need to test that ? Also, why it's not called in invoke ? There is also no reason to validate that the parameter type is the right one because the VM will validate the return type of the BSM is asTypable to the type sent as argument. Some methods use generics, so other don't. Given it's not useful to use generics if the methods is used as a BSM, i think the generics signature should be removed, otherwise, getstatic and invoke should use generics. In nullConstant, you do not need a requireNonNull here, getting you call isPrimitive() just after. In primitiveClass, the second test is equivalent to name.length() != 1, to remove the @SuppressWarnings, type should be declared as a Class>. Why not using getstatic to retrieve the field Type of the wrapper instead ? If you have invoke(), you do not need enumConstant because you can cook a constant method handle Enum.valueOf and send it to invoke. The methods that returns VarHandles are trickier because you need a Lookup object. getstatic should be renamed to getConstant because this is what it does. wrapping the Throwable in a LinkageError seems wrong to me given that a calls to a BSM already does that, so getstatic can just declare "throws Throawble" like invoke and you have the same semantics. in arrayVarHandle, the doc said that lookup is not used but lookup is used. in validateClassAccess, the return can be moved at the end of the method. and as a minor issue, all the ifs should be followed by curly braces per the coding convention. cheers, R?mi ----- Mail original ----- > De: "Paul Sandoz" > ?: "core-libs-dev" , "hotspot-dev" > Envoy?: Mardi 7 Novembre 2017 19:38:57 > Objet: RFR 8187742 Minimal set of bootstrap methods for dynamic constants > Hi, > > Please review the patch that adds a minimal set of bootstrap methods can be be > used for producing dynamic constants: > > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ > > > The aim is to provide a small but common set of BSMs that are likely useful with > ldc or as BSM arguments, filling in the gaps for constants that cannot be > currently represented, such as null, primitive classes and VarHandles. It?s > possible to get more sophisticated regarding say factories but that is > something to consider later on. > > This patch is based off the minimal dynamic constant support (still in review): > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html > > > Paul. From vitalyd at gmail.com Tue Nov 7 19:48:43 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 07 Nov 2017 19:48:43 +0000 Subject: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) In-Reply-To: References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr> Message-ID: On Tue, Nov 7, 2017 at 1:25 PM Remi Forax wrote: > My bad, > I've calculated that the header was 8 bytes instead of 12, so I've > supposed that the boolean was not stored in a byte. > > For my culture, why the header is 12 bytes, the pointer to the vtable is > on 64bits and can not be compressed like the other oops ? It?s 12 bytes (on x64) with compressed klass ptr; 8 bytes for the mark word and a 4 byte compressed klass ptr. It?s 16 bytes without compressed klass ptr. Or are you asking something else Remi? I think many folks would be upset if a boolean wasn?t stored as a byte :). > > > R?mi > > > On November 7, 2017 5:42:33 PM GMT+01:00, Brent Christian < > brent.christian at oracle.com> wrote: > >Hi, Remi > > > >Thanks for the idea. From my reading of the jol ouput: > > > > > http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt > > > > > > > >I believe retainClassRef is already being stored in a single byte (i.e. > > > >SIZE of 1): > > > > OFFSET SIZE TYPE DESCRIPTION > >... > > 10 1 boolean StackFrameInfo.retainClassRef > > > >Thanks, > >-Brent > > > >On 11/6/17 11:45 PM, Remi Forax wrote: > >> Hi Brent, > >> if you declare retainClassRef as a byte, you can even compress the > >data structure a little bit more, no ? > >> a boolean (as a field) uses 4 bytes while a byte uses welll 1 byte. > >> Given that bci is a short, the VM will put both bci and > >retainClassRef on the same 32 bits slot. > >> > >> cheers, > >> R?mi > >> > >> ----- Mail original ----- > >>> De: "Brent Christian" > >>> ?: "core-libs-dev" , "hotspot-dev" > > > >>> Envoy?: Mardi 7 Novembre 2017 01:23:16 > >>> Objet: RFR: 8185925 & 8153682 (footprint reduction of > >java.lang.StackFrameInfo) > >> > >>> Hi, > >>> > >>> There are a couple opportunities to reduce the memory footprint of > >>> java.lang.StackFrameInfo (the internal implementation of > >>> java.lang.StackWalker.StackFrame): > >>> > >>> 8153682[1] : StackFrameInfo.declaringClass could be removed > >>> 8185925[2] : StackFrameInfo::walker field can be replaced with > >bitmap to > >>> save footprint > >>> > >>> I had a look using jol[3]. Removing only 'walker' helps only under > >32- > >>> and 64-bit, but not with compressed oops. Removing both 'walker' > >and > >>> 'declaringClass' brings a benefit to compressed oops as well (though > >not > >>> for 16-byte aligned). > >>> > >>> The size change, in bytes, for each execution mode is as follows: > >>> > >>> 32-bit: 32->24 > >>> 64-bit: 56->40 > >>> 64/compressed oops: 32->24 > >>> 64/compressed oops, 16-byte aligned: 32->32 > >>> > >>> (For reference, the jol reports for the baseline and specimen are at > >[4] > >>> and [5], respectively.) > >>> > >>> Please review my code change for this. The webrev is here: > >>> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/ > >>> > >>> An automated test run is in progress. > >>> > >>> Thanks! > >>> -Brent > >>> > >>> -- > >>> 1. https://bugs.openjdk.java.net/browse/JDK-8153682 > >>> 2. https://bugs.openjdk.java.net/browse/JDK-8185925 > >>> 3. http://openjdk.java.net/projects/code-tools/jol/ > >>> 4. > >>> > > > http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt > >>> 5. > >>> > > > http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- Sent from my phone From karen.kinnear at oracle.com Tue Nov 7 20:04:57 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 7 Nov 2017 15:04:57 -0500 Subject: [10] RFR 8186046 Minimal ConstantDynamic support In-Reply-To: <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com> References: <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com> <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com> Message-ID: <22E25545-9DEA-4B3F-9735-8B34D9E69B2E@oracle.com> Paul, Thank you for the explanations. Asking for your help in some test case construction at the end here: >> 3. java/lang/invoke/package-info.java 128-134 >> Error handling could be clearer. >> My understanding is that if a LinkageError or subclass is thrown, this will be rethrown >> for all subsequent attempts. Other errors, e.g. VMError may retry resolution I was WRONG here - this does match the JVMS. Apologies for the confusion. >> >> 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java >> How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that >> was not ACC_STATIC? > > https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23 > > See the note under bootstrap_method_ref. The kind of method handle is constrained because of the arguments that are pushed on the stack before invocation. I believe it?s possible to have a constructor, but the declaring class would need to be a subtype of CallSite in the case of indy, and a subtype of the constant value type in the case of condy. > > >> Or was not ACC_PUBLIC? > > That?s dependent on the accessibility between the lookup class the the BSM declaring class. > > >> Or was >> Or did I read the invoke dynamic method incorrectly? >> > > By default, and for convenience, the InstructionHelper assumes the BSM is declared by the lookup class. I recently modified that to support the BSM being declared on another class, to test the minimal set of BSMs for condy (separate issue [1]). Note it?s always possible to use the bytecode API more directly. > > So we can easily add more -ve tests for non-accessible or non-static BSMs. Thank you - that is what we were trying to do - test BSM declared in another class, test in-accessible BSM and test non static method. Could you help us figure out how to 1) invoke a constructor? 2) invoke a virtual method? How do you pass the receiver? thanks, Karen > > Paul. > > [1] http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ From brent.christian at oracle.com Tue Nov 7 20:15:29 2017 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 7 Nov 2017 12:15:29 -0800 Subject: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) In-Reply-To: <40ffc6a6-68c1-5654-e5c4-d451e7a2b9b7@oracle.com> References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> <40ffc6a6-68c1-5654-e5c4-d451e7a2b9b7@oracle.com> Message-ID: <9dbc4181-3921-eae9-8ab1-72f781dc97fb@oracle.com> On 11/07/2017 09:45 AM, mandy chung wrote: > > StackFrameInfo.java > > 38 // Footprint improvement: MemberName::clazz can replace > 39 // StackFrameInfo::declaringClass. > > The above comment can be removed. Whoops - thanks. > 41 private final boolean retainClassRef; > > JVMS [1] has a note about Hotspot implementation of boolean array that > is encoded as a byte array. That explains JOL output that this boolean > field is 8-bit in our implementation. This field could be changed to a > byte to hold additional flags, if any in the future. It may be good to > change this to a byte making the field size explicit. Thanks for the link and explanation. I agree with making the change now. Updated webrev here: http://cr.openjdk.java.net/~bchristi/8185925/webrev.04/ -Brent From mandy.chung at oracle.com Tue Nov 7 20:22:31 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 7 Nov 2017 12:22:31 -0800 Subject: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) In-Reply-To: <9dbc4181-3921-eae9-8ab1-72f781dc97fb@oracle.com> References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> <40ffc6a6-68c1-5654-e5c4-d451e7a2b9b7@oracle.com> <9dbc4181-3921-eae9-8ab1-72f781dc97fb@oracle.com> Message-ID: On 11/7/17 12:15 PM, Brent Christian wrote: > Updated webrev here: > http://cr.openjdk.java.net/~bchristi/8185925/webrev.04/ Nit: FLAGS should be lower-case (not a constant) Otherwise looks good.?? No need for a new webrev. Mandy From coleen.phillimore at oracle.com Tue Nov 7 20:34:42 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 7 Nov 2017 15:34:42 -0500 Subject: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) In-Reply-To: <9dbc4181-3921-eae9-8ab1-72f781dc97fb@oracle.com> References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> <40ffc6a6-68c1-5654-e5c4-d451e7a2b9b7@oracle.com> <9dbc4181-3921-eae9-8ab1-72f781dc97fb@oracle.com> Message-ID: Hi Brent, The hotspot changes look good. Coleen On 11/7/17 3:15 PM, Brent Christian wrote: > On 11/07/2017 09:45 AM, mandy chung wrote: >> >> StackFrameInfo.java >> >> ? 38???? // Footprint improvement: MemberName::clazz can replace >> ? 39???? // StackFrameInfo::declaringClass. >> >> The above comment can be removed. > > Whoops - thanks. > >> 41 private final boolean retainClassRef; >> >> JVMS [1] has a note about Hotspot implementation of boolean array that >> is encoded as a byte array.? That explains JOL output that this boolean >> field is 8-bit in our implementation.? This field could be changed to a >> byte to hold additional flags, if any in the future.? It may be good to >> change this to a byte making the field size explicit. > > Thanks for the link and explanation.? I agree with making the change now. > > Updated webrev here: > http://cr.openjdk.java.net/~bchristi/8185925/webrev.04/ > > -Brent > From forax at univ-mlv.fr Tue Nov 7 20:45:04 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 07 Nov 2017 20:45:04 +0000 Subject: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) In-Reply-To: References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr> Message-ID: <9A992D58-6A73-4069-9297-DF242B27D734@univ-mlv.fr> On November 7, 2017 8:48:43 PM GMT+01:00, Vitaly Davidovich wrote: >On Tue, Nov 7, 2017 at 1:25 PM Remi Forax wrote: > >> My bad, >> I've calculated that the header was 8 bytes instead of 12, so I've >> supposed that the boolean was not stored in a byte. >> >> For my culture, why the header is 12 bytes, the pointer to the vtable >is >> on 64bits and can not be compressed like the other oops ? > >It?s 12 bytes (on x64) with compressed klass ptr; 8 bytes for the mark >word >and a 4 byte compressed klass ptr. It?s 16 bytes without compressed >klass >ptr. Or are you asking something else Remi? My question is more given you have compressed oops (and compressed klass) why the header is 12 bytes and not 8 bytes (a two words header). so why the mark word is 8 bytes and not 4 ? At worst it's a pointer and again you can use the compressed oops trick ? > >I think many folks would be upset if a boolean wasn?t stored as a byte >:). yes, right. Remi > >> >> >> R?mi >> >> >> On November 7, 2017 5:42:33 PM GMT+01:00, Brent Christian < >> brent.christian at oracle.com> wrote: >> >Hi, Remi >> > >> >Thanks for the idea. From my reading of the jol ouput: >> > >> > >> >http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt >> > >> > >> > >> >I believe retainClassRef is already being stored in a single byte >(i.e. >> > >> >SIZE of 1): >> > >> > OFFSET SIZE TYPE DESCRIPTION >> >... >> > 10 1 boolean StackFrameInfo.retainClassRef >> > >> >Thanks, >> >-Brent >> > >> >On 11/6/17 11:45 PM, Remi Forax wrote: >> >> Hi Brent, >> >> if you declare retainClassRef as a byte, you can even compress the >> >data structure a little bit more, no ? >> >> a boolean (as a field) uses 4 bytes while a byte uses welll 1 >byte. >> >> Given that bci is a short, the VM will put both bci and >> >retainClassRef on the same 32 bits slot. >> >> >> >> cheers, >> >> R?mi >> >> >> >> ----- Mail original ----- >> >>> De: "Brent Christian" >> >>> ?: "core-libs-dev" , >"hotspot-dev" >> > >> >>> Envoy?: Mardi 7 Novembre 2017 01:23:16 >> >>> Objet: RFR: 8185925 & 8153682 (footprint reduction of >> >java.lang.StackFrameInfo) >> >> >> >>> Hi, >> >>> >> >>> There are a couple opportunities to reduce the memory footprint >of >> >>> java.lang.StackFrameInfo (the internal implementation of >> >>> java.lang.StackWalker.StackFrame): >> >>> >> >>> 8153682[1] : StackFrameInfo.declaringClass could be removed >> >>> 8185925[2] : StackFrameInfo::walker field can be replaced with >> >bitmap to >> >>> save footprint >> >>> >> >>> I had a look using jol[3]. Removing only 'walker' helps only >under >> >32- >> >>> and 64-bit, but not with compressed oops. Removing both 'walker' >> >and >> >>> 'declaringClass' brings a benefit to compressed oops as well >(though >> >not >> >>> for 16-byte aligned). >> >>> >> >>> The size change, in bytes, for each execution mode is as follows: >> >>> >> >>> 32-bit: 32->24 >> >>> 64-bit: 56->40 >> >>> 64/compressed oops: 32->24 >> >>> 64/compressed oops, 16-byte aligned: 32->32 >> >>> >> >>> (For reference, the jol reports for the baseline and specimen are >at >> >[4] >> >>> and [5], respectively.) >> >>> >> >>> Please review my code change for this. The webrev is here: >> >>> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/ >> >>> >> >>> An automated test run is in progress. >> >>> >> >>> Thanks! >> >>> -Brent >> >>> >> >>> -- >> >>> 1. https://bugs.openjdk.java.net/browse/JDK-8153682 >> >>> 2. https://bugs.openjdk.java.net/browse/JDK-8185925 >> >>> 3. http://openjdk.java.net/projects/code-tools/jol/ >> >>> 4. >> >>> >> > >> >http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt >> >>> 5. >> >>> >> > >> >http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From paul.sandoz at oracle.com Tue Nov 7 20:54:06 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Nov 2017 12:54:06 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> References: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, You are asking a lot of the same questions we went through a number of times before landing where we are :-) > On 7 Nov 2017, at 11:33, Remi Forax wrote: > > Hi Paul, > > You have an import static requireNonNull but it is only used once in nullConstant, all other methods use Objects.requireNonNull. > Fixed. > The test that checks that lookup, name and type are null or not is different in each method, > so by example in primitiveClass, if type equals null, you get an IAE. > Fixed. > I fail to see the point of using validateClassAccess(), if the BSM is used through an indy, the type is created only if the caller class can create it, so the test seems redundant. If it's not used by an indy, why do we need to test that ? We are being deliberately conservative ensuring the lookup is consistent with the type in case nefarious byte code spinners punch a hole (not proven a hole can be punched, just being conservative). > Also, why it's not called in invoke ? > What ?it? are you referring to? > There is also no reason to validate that the parameter type is the right one because the VM will validate the return type of the BSM is asTypable to the type sent as argument. > Yes, but we prefer that the BSM reject thereby better signalling the source of the error. > Some methods use generics, so other don't. Given it's not useful to use generics if the methods is used as a BSM, i think the generics signature should be removed, otherwise, getstatic and invoke should use generics. > I updated the nullConstant method and removed the type variable. In general we try to be consistent with the explicit erasure unless it causes some contortion in the implementation as is the case for Enum. > In nullConstant, you do not need a requireNonNull here, getting you call isPrimitive() just after. > We decided to be explicit rather than implicit for all null checks. > In primitiveClass, the second test is equivalent to name.length() != 1, to remove the @SuppressWarnings, type should be declared as a Class>. Why not using getstatic to retrieve the field Type of the wrapper instead ? > Try passing Class.class to it. To be honest this is somewhat motivated by testing when called explicitly. > If you have invoke(), you do not need enumConstant because you can cook a constant method handle Enum.valueOf and send it to invoke. It?s also possible to support via getStatic as well, as is the case for primitive class. We went back and forth on the generic and specific axis. For cases where we considered constants are ?honorary" members of the constant pool we provide explicit BSMs. > The methods that returns VarHandles are trickier because you need a Lookup object. > > getstatic should be renamed to getConstant because this is what it does. No, we want to stick closely with the notion of what the BSM does, there is a close connection also with MethodHandle getStatic, it?s performing a static field access. ?getConstant? is too vague, notionally all the BSMs return constants. > wrapping the Throwable in a LinkageError seems wrong to me given that a calls to a BSM already does that, so getstatic can just declare "throws Throawble" like invoke and you have the same semantics. > We don?t want to declare Throwable for the API in this case. This try/catch is just ceremony since a getstatic MH in the implementation can only throw a VM error e.g. related to out of memory or stack overflow. I can add some comments in the code. Note that reflective exceptions are mapped to their equivalent errors. Although the BSM has been linked it is being asked to perform what can be considered further linkage. > in arrayVarHandle, the doc said that lookup is not used but lookup is used. > Fixed. > in validateClassAccess, the return can be moved at the end of the method. > > and as a minor issue, all the ifs should be followed by curly braces per the coding convention. > I expanded to curly braces. Paul. From john.r.rose at oracle.com Tue Nov 7 20:59:41 2017 From: john.r.rose at oracle.com (John Rose) Date: Tue, 7 Nov 2017 12:59:41 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> References: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> Message-ID: Good comments! I can handle a couple of them? On Nov 7, 2017, at 11:33 AM, Remi Forax wrote: > > I fail to see the point of using validateClassAccess(), if the BSM is used through an indy, the type is created only if the caller class can create it, so the test seems redundant. That's true, but? > If it's not used by an indy, why do we need to test that ? Also, why it's not called in invoke ? ?Enum.valueOf doesn't do a security check; that is its choice. This means that if you pass it an enum type that is not public or not in a package exported to you, you can still peek at its enum values. Meanwhile, when javac emits a reference to an enum, it does so with getstatic. The getstatic bytecode *does* perform access checks. The call to validateClassAccess performs those checks, for alignment with the semantics of getstatic. The internal use of Enum.valueOf is just a detail of the emulation of getstatic in the case of an enum. (Note to self: Never use enums to implement a shared secrets pattern.) For bootstrap methods I prefer to use the most restrictive set of applicable access rules, handshaking with the lookup. In the case of enums it doesn't matter much, as you say, because Enum.valueOf leaves the door open. I could go either way on this one. > There is also no reason to validate that the parameter type is the right one because the VM will validate the return type of the BSM is asTypable to the type sent as argument. For condy, having the BSM validate types is a code smell for the reason you mention. Also, when primitives (and value types) are in the mix, people usually code the validation incorrectly, since Class.isInstance is the wrong tool, and the right tool is non-obvious (MHs.identity.asType). Are you commenting on the return type adjustment in invoke? That's just a minor optimization to avoid (un)boxing, which should have no semantic effect. > Some methods use generics, so other don't. Given it's not useful to use generics if the methods is used as a BSM, i think the generics signature should be removed, otherwise, getstatic and invoke should use generics. The generics are present to make normal calls from source code type check. Use cases: Combinators, test code. > to remove the @SuppressWarnings, type should be declared as a Class>. Paul explained this one to me when I made the same objection. Turns out that the class literal "Class.class" (which is required to call that BSM from source code) can only have a raw type. Yuck. So we declare the formal with a matching amount of raw-ness. > Why not using getstatic to retrieve the field Type of the wrapper instead ? Because the descriptor is a more compact notation for a primitive type. Primitive type references will be common and we want them to be small. > If you have invoke(), you do not need enumConstant because you can cook a constant method handle Enum.valueOf and send it to invoke. The methods that returns VarHandles are trickier because you need a Lookup object. The set is minimal, but not that minimal. We *could* express *everything* using invoke but that would be grotesquely verbose and opaque. The "extra" API points are thought to be helpful in reducing class file size, and also clarifying the intentions of the affected constants. > getstatic should be renamed to getConstant because this is what it does. (I could go either way; since the JVM has ConstantValue attrs, "Constant" is a Thing. If it's getstatic I prefer getStatic, for alignment with pre-existing names in jli.) > wrapping the Throwable in a LinkageError seems wrong to me given that a calls to a BSM already does that, so getstatic can just declare "throws Throawble" like invoke and you have the same semantics. The point is that we are emulating the semantics of a getstatic instruction, which only throws LEs. We don't want other stuff to leak out of the implementation. Remember that "bytecode behavior" is a normative specification, to use when applicable. It's applicable here. Again, I could go either way on this one. Thanks, ? John From vitalyd at gmail.com Tue Nov 7 21:17:36 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 07 Nov 2017 21:17:36 +0000 Subject: RFR: 8185925 & 8153682 (footprint reduction of java.lang.StackFrameInfo) In-Reply-To: <9A992D58-6A73-4069-9297-DF242B27D734@univ-mlv.fr> References: <98013617-7d09-a8a9-6fd8-2bbdcd126eca@oracle.com> <1246227356.615417.1510040732859.JavaMail.zimbra@u-pem.fr> <9A992D58-6A73-4069-9297-DF242B27D734@univ-mlv.fr> Message-ID: On Tue, Nov 7, 2017 at 3:45 PM Remi Forax wrote: > > > On November 7, 2017 8:48:43 PM GMT+01:00, Vitaly Davidovich < > vitalyd at gmail.com> wrote: > >On Tue, Nov 7, 2017 at 1:25 PM Remi Forax wrote: > > > >> My bad, > >> I've calculated that the header was 8 bytes instead of 12, so I've > >> supposed that the boolean was not stored in a byte. > >> > >> For my culture, why the header is 12 bytes, the pointer to the vtable > >is > >> on 64bits and can not be compressed like the other oops ? > > > >It?s 12 bytes (on x64) with compressed klass ptr; 8 bytes for the mark > >word > >and a 4 byte compressed klass ptr. It?s 16 bytes without compressed > >klass > >ptr. Or are you asking something else Remi? > > My question is more given you have compressed oops (and compressed klass) > why the header is 12 bytes and not 8 bytes (a two words header). > > so why the mark word is 8 bytes and not 4 ? At worst it's a pointer and > again you can use the compressed oops trick ? http://hg.openjdk.java.net/jdk9/hs/hotspot/file/c68024d52834/src/share/vm/oops/markOop.hpp has a description of the layout - it?s not a pointer per se (although some states do encode one) but a bunch of metadata. > > > > > >I think many folks would be upset if a boolean wasn?t stored as a byte > >:). > > yes, right. > > Remi > > > > >> > >> > >> R?mi > >> > >> > >> On November 7, 2017 5:42:33 PM GMT+01:00, Brent Christian < > >> brent.christian at oracle.com> wrote: > >> >Hi, Remi > >> > > >> >Thanks for the idea. From my reading of the jol ouput: > >> > > >> > > >> > > > http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt > >> > > >> > > >> > > >> >I believe retainClassRef is already being stored in a single byte > >(i.e. > >> > > >> >SIZE of 1): > >> > > >> > OFFSET SIZE TYPE DESCRIPTION > >> >... > >> > 10 1 boolean StackFrameInfo.retainClassRef > >> > > >> >Thanks, > >> >-Brent > >> > > >> >On 11/6/17 11:45 PM, Remi Forax wrote: > >> >> Hi Brent, > >> >> if you declare retainClassRef as a byte, you can even compress the > >> >data structure a little bit more, no ? > >> >> a boolean (as a field) uses 4 bytes while a byte uses welll 1 > >byte. > >> >> Given that bci is a short, the VM will put both bci and > >> >retainClassRef on the same 32 bits slot. > >> >> > >> >> cheers, > >> >> R?mi > >> >> > >> >> ----- Mail original ----- > >> >>> De: "Brent Christian" > >> >>> ?: "core-libs-dev" , > >"hotspot-dev" > >> > > >> >>> Envoy?: Mardi 7 Novembre 2017 01:23:16 > >> >>> Objet: RFR: 8185925 & 8153682 (footprint reduction of > >> >java.lang.StackFrameInfo) > >> >> > >> >>> Hi, > >> >>> > >> >>> There are a couple opportunities to reduce the memory footprint > >of > >> >>> java.lang.StackFrameInfo (the internal implementation of > >> >>> java.lang.StackWalker.StackFrame): > >> >>> > >> >>> 8153682[1] : StackFrameInfo.declaringClass could be removed > >> >>> 8185925[2] : StackFrameInfo::walker field can be replaced with > >> >bitmap to > >> >>> save footprint > >> >>> > >> >>> I had a look using jol[3]. Removing only 'walker' helps only > >under > >> >32- > >> >>> and 64-bit, but not with compressed oops. Removing both 'walker' > >> >and > >> >>> 'declaringClass' brings a benefit to compressed oops as well > >(though > >> >not > >> >>> for 16-byte aligned). > >> >>> > >> >>> The size change, in bytes, for each execution mode is as follows: > >> >>> > >> >>> 32-bit: 32->24 > >> >>> 64-bit: 56->40 > >> >>> 64/compressed oops: 32->24 > >> >>> 64/compressed oops, 16-byte aligned: 32->32 > >> >>> > >> >>> (For reference, the jol reports for the baseline and specimen are > >at > >> >[4] > >> >>> and [5], respectively.) > >> >>> > >> >>> Please review my code change for this. The webrev is here: > >> >>> http://cr.openjdk.java.net/~bchristi/8185925/webrev.03/ > >> >>> > >> >>> An automated test run is in progress. > >> >>> > >> >>> Thanks! > >> >>> -Brent > >> >>> > >> >>> -- > >> >>> 1. https://bugs.openjdk.java.net/browse/JDK-8153682 > >> >>> 2. https://bugs.openjdk.java.net/browse/JDK-8185925 > >> >>> 3. http://openjdk.java.net/projects/code-tools/jol/ > >> >>> 4. > >> >>> > >> > > >> > > > http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.baseline.txt > >> >>> 5. > >> >>> > >> > > >> > > > http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt > >> > >> -- > >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > >> > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- Sent from my phone From forax at univ-mlv.fr Tue Nov 7 21:35:06 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 7 Nov 2017 22:35:06 +0100 (CET) Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: References: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> Message-ID: <876381003.1124033.1510090506277.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "John Rose" > ?: "R?mi Forax" > Cc: "Paul Sandoz" , "hotspot-dev" , "core-libs-dev" > > Envoy?: Mardi 7 Novembre 2017 21:59:41 > Objet: Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants > Good comments! I can handle a couple of them? > > On Nov 7, 2017, at 11:33 AM, Remi Forax wrote: >> >> I fail to see the point of using validateClassAccess(), if the BSM is used >> through an indy, the type is created only if the caller class can create it, so >> the test seems redundant. > > That's true, but? > >> If it's not used by an indy, why do we need to test that ? Also, why it's not >> called in invoke ? > > ?Enum.valueOf doesn't do a security check; that is its choice. > This means that if you pass it an enum type that is not public > or not in a package exported to you, you can still peek at its > enum values. Meanwhile, when javac emits a reference to > an enum, it does so with getstatic. The getstatic bytecode > *does* perform access checks. The call to validateClassAccess > performs those checks, for alignment with the semantics > of getstatic. The internal use of Enum.valueOf is just a detail > of the emulation of getstatic in the case of an enum. > > (Note to self: Never use enums to implement a shared > secrets pattern.) > > For bootstrap methods I prefer to use the most restrictive > set of applicable access rules, handshaking with the lookup. > > In the case of enums it doesn't matter much, as you say, > because Enum.valueOf leaves the door open. > > I could go either way on this one. As you said, javac use getstatic (the bytecode), why not reuse getstatic (the BSM) in that case, being a field of an enum doesn't seem important and at least you are sure that you have the semantics of getstatic (you miss the cache in java.lang.Class but i'm not sure it worth it). > >> There is also no reason to validate that the parameter type is the right one >> because the VM will validate the return type of the BSM is asTypable to the >> type sent as argument. > > For condy, having the BSM validate types is a code smell > for the reason you mention. Also, when primitives (and value > types) are in the mix, people usually code the validation > incorrectly, since Class.isInstance is the wrong tool, and > the right tool is non-obvious (MHs.identity.asType). > > Are you commenting on the return type adjustment in invoke? > That's just a minor optimization to avoid (un)boxing, which > should have no semantic effect. no, the return type adjustment is ok for me, it avoid unboxing + boxing if the original handle returns a primitive. > >> Some methods use generics, so other don't. Given it's not useful to use generics >> if the methods is used as a BSM, i think the generics signature should be >> removed, otherwise, getstatic and invoke should use generics. > > The generics are present to make normal calls from source > code type check. Use cases: Combinators, test code. so getstatic and invoke should have generics in their signature too. > >> to remove the @SuppressWarnings, type should be declared as a Class>. > > Paul explained this one to me when I made the same objection. Turns > out that the class literal "Class.class" (which is required to call that > BSM from source code) can only have a raw type. Yuck. So we > declare the formal with a matching amount of raw-ness. yes, right X.class and x.getClass() are the two rules in the JLS that can introduce raw types. I think i prefer 'type' to be typed as a Class in that case, it's not a raw type and you can assign Class> to it. > >> Why not using getstatic to retrieve the field Type of the wrapper instead ? > > Because the descriptor is a more compact notation for a primitive type. > Primitive type references will be common and we want them to be small. Ok, you have to send the wrapper type if you use getstatic, so you are saving a reference to the wrapper type. > >> If you have invoke(), you do not need enumConstant because you can cook a >> constant method handle Enum.valueOf and send it to invoke. The methods that >> returns VarHandles are trickier because you need a Lookup object. > > The set is minimal, but not that minimal. We *could* express *everything* > using invoke but that would be grotesquely verbose and opaque. > The "extra" API points are thought to be helpful in reducing class file size, > and also clarifying the intentions of the affected constants. > >> getstatic should be renamed to getConstant because this is what it does. > > (I could go either way; since the JVM has ConstantValue attrs, "Constant" > is a Thing. If it's getstatic I prefer getStatic, for alignment with > pre-existing > names in jli.) perhaps getFinalStatic, because it's restricted to final field. > >> wrapping the Throwable in a LinkageError seems wrong to me given that a calls to >> a BSM already does that, so getstatic can just declare "throws Throawble" like >> invoke and you have the same semantics. > > The point is that we are emulating the semantics of a getstatic instruction, > which only throws LEs. We don't want other stuff to leak out of the > implementation. Remember that "bytecode behavior" is a normative > specification, to use when applicable. It's applicable here. it's not the catch line 155 that bother me, it's the other line 165 (and 162). > > Again, I could go either way on this one. > > Thanks, > ? John R?mi From paul.sandoz at oracle.com Tue Nov 7 21:54:51 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Nov 2017 13:54:51 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: References: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> Message-ID: <64439AE0-931E-4FC6-ABCF-C17D6AC94DC9@oracle.com> > On 7 Nov 2017, at 12:59, John Rose wrote: > > Good comments! I can handle a couple of them? > > On Nov 7, 2017, at 11:33 AM, Remi Forax wrote: >> >> I fail to see the point of using validateClassAccess(), if the BSM is used through an indy, the type is created only if the caller class can create it, so the test seems redundant. > > That's true, but? > >> If it's not used by an indy, why do we need to test that ? Also, why it's not called in invoke ? > > ?Enum.valueOf doesn't do a security check; that is its choice. > This means that if you pass it an enum type that is not public > or not in a package exported to you, you can still peek at its > enum values. Meanwhile, when javac emits a reference to > an enum, it does so with getstatic. The getstatic bytecode > *does* perform access checks. The call to validateClassAccess > performs those checks, for alignment with the semantics > of getstatic. The internal use of Enum.valueOf is just a detail > of the emulation of getstatic in the case of an enum. > > (Note to self: Never use enums to implement a shared > secrets pattern.) > > For bootstrap methods I prefer to use the most restrictive > set of applicable access rules, handshaking with the lookup. > > In the case of enums it doesn't matter much, as you say, > because Enum.valueOf leaves the door open. > Yes, Brian and I noticed that so we punted on the access control. > I could go either way on this one. > For consistency with our conservative position on other BSMs we should probably perform the checks. I?ll update. >> There is also no reason to validate that the parameter type is the right one because the VM will validate the return type of the BSM is asTypable to the type sent as argument. > > For condy, having the BSM validate types is a code smell > for the reason you mention. If the BSM should only accept specific types it seems within its remit to reject thereby better associating the error with the dynamic constant entry. We are dealing here with known fixed types (Class and VarHandle). > Also, when primitives (and value > types) are in the mix, people usually code the validation > incorrectly, since Class.isInstance is the wrong tool, and > the right tool is non-obvious (MHs.identity.asType). > > Are you commenting on the return type adjustment in invoke? > That's just a minor optimization to avoid (un)boxing, which > should have no semantic effect. > >> Some methods use generics, so other don't. Given it's not useful to use generics if the methods is used as a BSM, i think the generics signature should be removed, otherwise, getstatic and invoke should use generics. > > The generics are present to make normal calls from source > code type check. Use cases: Combinators, test code. > >> to remove the @SuppressWarnings, type should be declared as a Class>. > > Paul explained this one to me when I made the same objection. Turns > out that the class literal "Class.class" (which is required to call that > BSM from source code) can only have a raw type. Yuck. So we > declare the formal with a matching amount of raw-ness. > >> Why not using getstatic to retrieve the field Type of the wrapper instead ? > > Because the descriptor is a more compact notation for a primitive type. > Primitive type references will be common and we want them to be small. > Yes, i forgot to mention the size aspect. >> If you have invoke(), you do not need enumConstant because you can cook a constant method handle Enum.valueOf and send it to invoke. The methods that returns VarHandles are trickier because you need a Lookup object. > > The set is minimal, but not that minimal. We *could* express *everything* > using invoke but that would be grotesquely verbose and opaque. > The "extra" API points are thought to be helpful in reducing class file size, > and also clarifying the intentions of the affected constants. > Yes. >> getstatic should be renamed to getConstant because this is what it does. > > (I could go either way; since the JVM has ConstantValue attrs, "Constant" > is a Thing. If it's getstatic I prefer getStatic, for alignment with pre-existing > names in jli.) > +1 on getStatic alignment with jli. getConstant is too general for this case IMO. The naming convention we chose was to append Constant if the prefix was a keyword such as null or enum. Paul. >> wrapping the Throwable in a LinkageError seems wrong to me given that a calls to a BSM already does that, so getstatic can just declare "throws Throawble" like invoke and you have the same semantics. > > The point is that we are emulating the semantics of a getstatic instruction, > which only throws LEs. We don't want other stuff to leak out of the > implementation. Remember that "bytecode behavior" is a normative > specification, to use when applicable. It's applicable here. > > Again, I could go either way on this one. > > Thanks, > ? John From paul.sandoz at oracle.com Tue Nov 7 22:00:23 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Nov 2017 14:00:23 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <64439AE0-931E-4FC6-ABCF-C17D6AC94DC9@oracle.com> References: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> <64439AE0-931E-4FC6-ABCF-C17D6AC94DC9@oracle.com> Message-ID: > On 7 Nov 2017, at 13:54, Paul Sandoz wrote: >> >>> If it's not used by an indy, why do we need to test that ? Also, why it's not called in invoke ? >> >> ?Enum.valueOf doesn't do a security check; that is its choice. >> This means that if you pass it an enum type that is not public >> or not in a package exported to you, you can still peek at its >> enum values. Meanwhile, when javac emits a reference to >> an enum, it does so with getstatic. The getstatic bytecode >> *does* perform access checks. The call to validateClassAccess >> performs those checks, for alignment with the semantics >> of getstatic. The internal use of Enum.valueOf is just a detail >> of the emulation of getstatic in the case of an enum. >> >> (Note to self: Never use enums to implement a shared >> secrets pattern.) >> >> For bootstrap methods I prefer to use the most restrictive >> set of applicable access rules, handshaking with the lookup. >> >> In the case of enums it doesn't matter much, as you say, >> because Enum.valueOf leaves the door open. >> > > Yes, Brian and I noticed that so we punted on the access control. > Hold on? no we didn?t, we included the explicit access control check. Paul. From forax at univ-mlv.fr Tue Nov 7 22:18:15 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 7 Nov 2017 23:18:15 +0100 (CET) Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: References: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> Message-ID: <1693333239.1128109.1510093095542.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > ?: "Remi Forax" > Cc: "core-libs-dev" , "hotspot-dev" > Envoy?: Mardi 7 Novembre 2017 21:54:06 > Objet: Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants > Hi Remi, > > You are asking a lot of the same questions we went through a number of times > before landing where we are :-) > > >> On 7 Nov 2017, at 11:33, Remi Forax wrote: >> >> Hi Paul, >> >> You have an import static requireNonNull but it is only used once in >> nullConstant, all other methods use Objects.requireNonNull. >> > > Fixed. > > >> The test that checks that lookup, name and type are null or not is different in >> each method, >> so by example in primitiveClass, if type equals null, you get an IAE. >> > > Fixed. > > >> I fail to see the point of using validateClassAccess(), if the BSM is used >> through an indy, the type is created only if the caller class can create it, so >> the test seems redundant. If it's not used by an indy, why do we need to test >> that ? > > We are being deliberately conservative ensuring the lookup is consistent with > the type in case nefarious byte code spinners punch a hole (not proven a hole > can be punched, just being conservative). > > >> Also, why it's not called in invoke ? >> > > What ?it? are you referring to? validateClassAccess. > > >> There is also no reason to validate that the parameter type is the right one >> because the VM will validate the return type of the BSM is asTypable to the >> type sent as argument. >> > > Yes, but we prefer that the BSM reject thereby better signalling the source of > the error. the method returns a Class in its signature, so it can not be something else if not call by a condy and if the type is wrong in the bytecode, the VM will throw a CCE with the same info than your IAE. i still think it's unnecessary. > > >> Some methods use generics, so other don't. Given it's not useful to use generics >> if the methods is used as a BSM, i think the generics signature should be >> removed, otherwise, getstatic and invoke should use generics. >> > > I updated the nullConstant method and removed the type variable. > > In general we try to be consistent with the explicit erasure unless it causes > some contortion in the implementation as is the case for Enum. > > >> In nullConstant, you do not need a requireNonNull here, getting you call >> isPrimitive() just after. >> > > We decided to be explicit rather than implicit for all null checks. > > >> In primitiveClass, the second test is equivalent to name.length() != 1, to >> remove the @SuppressWarnings, type should be declared as a Class>. Why >> not using getstatic to retrieve the field Type of the wrapper instead ? >> > > Try passing Class.class to it. To be honest this is somewhat motivated by > testing when called explicitly. see my answer to John. > > >> If you have invoke(), you do not need enumConstant because you can cook a >> constant method handle Enum.valueOf and send it to invoke. > > It?s also possible to support via getStatic as well, as is the case for > primitive class. > > We went back and forth on the generic and specific axis. For cases where we > considered constants are ?honorary" members of the constant pool we provide > explicit BSMs. > > >> The methods that returns VarHandles are trickier because you need a Lookup >> object. >> >> getstatic should be renamed to getConstant because this is what it does. > > No, we want to stick closely with the notion of what the BSM does, there is a > close connection also with MethodHandle getStatic, it?s performing a static > field access. ?getConstant? is too vague, notionally all the BSMs return > constants. > > >> wrapping the Throwable in a LinkageError seems wrong to me given that a calls to >> a BSM already does that, so getstatic can just declare "throws Throawble" like >> invoke and you have the same semantics. >> > > We don?t want to declare Throwable for the API in this case. This try/catch is > just ceremony since a getstatic MH in the implementation can only throw a VM > error e.g. related to out of memory or stack overflow. I can add some comments > in the code. but you do that in invoke(). > > Note that reflective exceptions are mapped to their equivalent errors. Although > the BSM has been linked it is being asked to perform what can be considered > further linkage. > > >> in arrayVarHandle, the doc said that lookup is not used but lookup is used. >> > > Fixed. > > >> in validateClassAccess, the return can be moved at the end of the method. >> >> and as a minor issue, all the ifs should be followed by curly braces per the >> coding convention. >> > > I expanded to curly braces. > > Paul. R?mi From john.r.rose at oracle.com Tue Nov 7 22:20:01 2017 From: john.r.rose at oracle.com (John Rose) Date: Tue, 7 Nov 2017 14:20:01 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <1693333239.1128109.1510093095542.JavaMail.zimbra@u-pem.fr> References: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> <1693333239.1128109.1510093095542.JavaMail.zimbra@u-pem.fr> Message-ID: <4AE7F5C4-E98C-464D-903A-0A43C83B38C0@oracle.com> On Nov 7, 2017, at 2:18 PM, forax at univ-mlv.fr wrote: > >>> >>> Also, why it's not called in invoke ? >>> >> >> What ?it? are you referring to? > > validateClassAccess. Because having a MH means you have already been granted access to invoke it. Having a Class does *not* mean you have been granted access to its members; that is a further step. ? John From forax at univ-mlv.fr Tue Nov 7 22:25:40 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 7 Nov 2017 23:25:40 +0100 (CET) Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <4AE7F5C4-E98C-464D-903A-0A43C83B38C0@oracle.com> References: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> <1693333239.1128109.1510093095542.JavaMail.zimbra@u-pem.fr> <4AE7F5C4-E98C-464D-903A-0A43C83B38C0@oracle.com> Message-ID: <2125890785.1128598.1510093540787.JavaMail.zimbra@u-pem.fr> > De: "John Rose" > ?: "R?mi Forax" > Cc: "Paul Sandoz" , "hotspot-dev" > , "core-libs-dev" > > Envoy?: Mardi 7 Novembre 2017 23:20:01 > Objet: Re: RFR 8187742 Minimal set of bootstrap methods for dynamic constants > On Nov 7, 2017, at 2:18 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] > wrote: >>>> Also, why it's not called in invoke ? >>> What ?it? are you referring to? >> validateClassAccess. > Because having a MH means you have already been granted > access to invoke it. Having a Class does *not* mean you have > been granted access to its members; that is a further step. but here you are using the class to change the mh, so you can have access to the mh and still have no access to the Class if you do not call the BSM with a condy, which is the purpose of validateClassAccess, no ? > ? John R?mi From paul.sandoz at oracle.com Tue Nov 7 22:37:03 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Nov 2017 14:37:03 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <1693333239.1128109.1510093095542.JavaMail.zimbra@u-pem.fr> References: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> <1693333239.1128109.1510093095542.JavaMail.zimbra@u-pem.fr> Message-ID: > On 7 Nov 2017, at 14:18, forax at univ-mlv.fr wrote: >> >> Try passing Class.class to it. To be honest this is somewhat motivated by >> testing when called explicitly. > > see my answer to John. > Fair point, i?ll go with Class. It?s the less smelly option. Updated along with other changes: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ >> >> >>> If you have invoke(), you do not need enumConstant because you can cook a >>> constant method handle Enum.valueOf and send it to invoke. >> >> It?s also possible to support via getStatic as well, as is the case for >> primitive class. >> >> We went back and forth on the generic and specific axis. For cases where we >> considered constants are ?honorary" members of the constant pool we provide >> explicit BSMs. >> >> >>> The methods that returns VarHandles are trickier because you need a Lookup >>> object. >>> >>> getstatic should be renamed to getConstant because this is what it does. >> >> No, we want to stick closely with the notion of what the BSM does, there is a >> close connection also with MethodHandle getStatic, it?s performing a static >> field access. ?getConstant? is too vague, notionally all the BSMs return >> constants. >> >> >>> wrapping the Throwable in a LinkageError seems wrong to me given that a calls to >>> a BSM already does that, so getstatic can just declare "throws Throawble" like >>> invoke and you have the same semantics. >>> >> >> We don?t want to declare Throwable for the API in this case. This try/catch is >> just ceremony since a getstatic MH in the implementation can only throw a VM >> error e.g. related to out of memory or stack overflow. I can add some comments >> in the code. > > but you do that in invoke(). > There is no choice when Invoking a method handle that is passed to us. In the case of getStatic the use of a MH can be considered an implementation detail (we could use reflection) and we know what the j.l.invoke implementation does. In this case i believe only VM errors can be produced. Paul. From paul.sandoz at oracle.com Tue Nov 7 22:47:16 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Nov 2017 14:47:16 -0800 Subject: [10] RFR 8186046 Minimal ConstantDynamic support In-Reply-To: <22E25545-9DEA-4B3F-9735-8B34D9E69B2E@oracle.com> References: <8D52F736-587E-48A2-BD9C-003A690187DD@oracle.com> <3205F35B-0262-4BEE-B645-6D02021757D2@oracle.com> <22E25545-9DEA-4B3F-9735-8B34D9E69B2E@oracle.com> Message-ID: <8F7AE06B-34A0-43A7-8861-24BE952A5532@oracle.com> > On 7 Nov 2017, at 12:04, Karen Kinnear wrote: > > Paul, > > Thank you for the explanations. Asking for your help in some test case construction at the end here: > >>> 3. java/lang/invoke/package-info.java 128-134 >>> Error handling could be clearer. >>> My understanding is that if a LinkageError or subclass is thrown, this will be rethrown >>> for all subsequent attempts. Other errors, e.g. VMError may retry resolution > I was WRONG here - this does match the JVMS. Apologies for the confusion. >>> >>> 9. test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java >>> How would I write an ldc CONSTANT_Dynamic which referred to a bootstrap method that >>> was not ACC_STATIC? >> >> https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.7.23 >> >> See the note under bootstrap_method_ref. The kind of method handle is constrained because of the arguments that are pushed on the stack before invocation. I believe it?s possible to have a constructor, but the declaring class would need to be a subtype of CallSite in the case of indy, and a subtype of the constant value type in the case of condy. >> >> >>> Or was not ACC_PUBLIC? >> >> That?s dependent on the accessibility between the lookup class the the BSM declaring class. >> >> >>> Or was >>> Or did I read the invoke dynamic method incorrectly? >>> >> >> By default, and for convenience, the InstructionHelper assumes the BSM is declared by the lookup class. I recently modified that to support the BSM being declared on another class, to test the minimal set of BSMs for condy (separate issue [1]). Note it?s always possible to use the bytecode API more directly. >> >> So we can easily add more -ve tests for non-accessible or non-static BSMs. I am wrong, i forgot i updated the API to remove the declaration of the BSM kind, and it only supports static BSMs. > Thank you - that is what we were trying to do - test BSM declared in another class, test in-accessible > BSM and test non static method. > The latter (access to a BSM in another class) is easy now using the high-level construct of InstructionHelper.ldcDynamicConstant (see patch for the condy BSMs, which is also in the amber repo in the condy branch). > Could you help us figure out how to > 1) invoke a constructor? > 2) invoke a virtual method? How do you pass the receiver? > I think for these you will need to use ASM tools to massage the MH for the BSM e.g. develop for a class with a static BSM then adjust the constant pool entry for the associated MH. Paul. From paul.sandoz at oracle.com Wed Nov 8 00:16:46 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 7 Nov 2017 16:16:46 -0800 Subject: RFR 8190887 Stub code marking missing from some x86 generated stub routines Message-ID: <3DB3315C-740D-44B1-9F7A-9DEC5FC2326B@oracle.com> Hi, Please review this patch to ensure all generated stub code is printed when -XX:+PrintStubCode is set. Some generators were not participating and their code was not printed out. http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190887-stub-code-marking/webrev/ I eyeballed the x86_64 output. I dunno if there are some explicit sanity tests. Is it worth updating the generators for x86_32? (more awkward to eyeball). Thanks, Paul. From coleen.phillimore at oracle.com Wed Nov 8 00:38:48 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 7 Nov 2017 19:38:48 -0500 Subject: RFR (S) 8190891: Clean up G1 barrier code in compiler interface (ci) Message-ID: <608846ee-75ed-0858-c0e9-14bb2e533c30@oracle.com> Summary: consolidate gc barrier code in ci See bug and comments for more details. Tested with mach5 tier1-5 on linux x64 and iwndows x64.? Also tested StressRedefineWithoutBytecodeModification in test/jdk/java/lang/instrument which fails without the g1 barriers. open webrev at http://cr.openjdk.java.net/~coleenp/8190891.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8190891 Thanks, Coleen From igor.ignatyev at oracle.com Wed Nov 8 00:56:34 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 7 Nov 2017 16:56:34 -0800 Subject: RFR(XS) : 8190890 : remove hotspot_tier1_{compiler,gc}_closed groups Message-ID: <63C6D6E6-6368-45D3-83A2-A68BD95F4082@oracle.com> http://cr.openjdk.java.net/~iignatyev//8190890/webrev.00/index.html > 9 lines changed: 0 ins; 9 del; Hi all, could you please review this tiny patch which removes unneeded jtreg test groups? webrev: http://cr.openjdk.java.net/~iignatyev//8190890/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8190890 Thanks, -- Igor From vladimir.kozlov at oracle.com Wed Nov 8 01:16:34 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Nov 2017 17:16:34 -0800 Subject: RFR 8190887 Stub code marking missing from some x86 generated stub routines In-Reply-To: <3DB3315C-740D-44B1-9F7A-9DEC5FC2326B@oracle.com> References: <3DB3315C-740D-44B1-9F7A-9DEC5FC2326B@oracle.com> Message-ID: Good. Thanks, Vladimir On 11/7/17 4:16 PM, Paul Sandoz wrote: > Hi, > > Please review this patch to ensure all generated stub code is printed when -XX:+PrintStubCode is set. Some generators were not participating and their code was not printed out. > > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190887-stub-code-marking/webrev/ > > I eyeballed the x86_64 output. I dunno if there are some explicit sanity tests. > > Is it worth updating the generators for x86_32? (more awkward to eyeball). > > Thanks, > Paul. > From david.holmes at oracle.com Wed Nov 8 02:04:04 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Nov 2017 12:04:04 +1000 Subject: RFR(xs): JDK-8190865 - Require jtreg 4.2 b10 In-Reply-To: References: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> Message-ID: On 8/11/2017 3:05 AM, jesper.wilhelmsson at oracle.com wrote: > Including build-dev. > >> On 7 Nov 2017, at 17:56, jesper.wilhelmsson at oracle.com wrote: >> >> Hi, >> >> Please review this minor change to use the latest jtreg version in HotSpot testing. >> This should get rid of the SocketTimeoutExceptions that we currently see in the HotSpot nightly. More importantly it fixes the java/time TCK test failures caused by jtreg b09! But that fix needs to go into jdk/jdk not jdk/hs as CI is broken since the hs integration! David >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190865 >> >> Patch: >> >> diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js >> --- a/make/conf/jib-profiles.js >> +++ b/make/conf/jib-profiles.js >> @@ -1060,7 +1060,7 @@ >> jtreg: { >> server: "javare", >> revision: "4.2", >> - build_number: "b09", >> + build_number: "b10", >> checksum_file: "MD5_VALUES", >> file: "jtreg_bin-4.2.zip", >> environment_name: "JT_HOME", >> >> Thanks, >> /Jesper >> > From david.holmes at oracle.com Wed Nov 8 02:19:44 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Nov 2017 12:19:44 +1000 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> Message-ID: <08248c0d-9041-071b-9a51-8032da9fb403@oracle.com> Hi Jini, > On 11/7/17 4:16 AM, Jini George wrote: >> Thank you very much, Coleen, for the review. My answers inline: >> >> On 11/2/2017 5:09 PM, coleen.phillimore at oracle.com wrote: >>> >>> http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/src/hotspot/share/runtime/stackValue.hpp.udiff.html >>> >>> >>> + return (*(int *)&_integer_value == *(int *)&value->_integer_value); >>> >>> >>> I don't think the *(int*) casts for _integer_value are needed in >>> these files.? Can you remove them? >> >> [Jini] I think since _integer_value is of type intptr_t (which could >> be 8 or 4 bytes long depending on the data model), the removal of the >> casts could result in an incorrect comparison (mostly for the 64 bit >> environment). Let me know if you disagree. You're comparing two _integer_value fields that are both intptr_t. The important part you've overlooked is the comment preceding this: // [phh] compare only low addressed portions of intptr_t slots - return (*(int *)&_i == *(int *)&value->_i); + return (*(int *)&_integer_value == *(int *)&value->_integer_value); For some we reason although intptr_t we're only interested in the lower 32-bits. I have no idea why, nor why we would truncate the value when printing. David ----- From muthusamy.chinnathambi at oracle.com Wed Nov 8 05:53:56 2017 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Tue, 7 Nov 2017 21:53:56 -0800 (PST) Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist In-Reply-To: References: <811da80f-e107-4d0c-903b-c109b592176e@default> Message-ID: <6e7c7f30-599d-4558-8c84-0360f0535cf4@default> Hi Thomas, ? > ?the webrev link seems to be dead. Sorry for the trouble. Please find the corrected link below http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ ? Somehow the line following the link got appended to the previous one leading to a dead link. ? Regards, Muthusamy C ? From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Tuesday, November 7, 2017 8:12 PM To: Muthusamy Chinnathambi Cc: HotSpot Open Source Developers ; Mikael Gerdin Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist ? Hi Muthusamy, ? the webrev link seems to be dead. ? ..Thomas ? On Tue, Nov 7, 2017 at 10:05 AM, Muthusamy Chinnathambi wrote: Hi, Please review the backport of bug: "JDK-8170395: Metaspace initialization queries the wrong chunk freelist" to jdk8u-dev Please note that this is not a clean backport due to new entries in debug.cpp and copyright changes. Webrev: HYPERLINK "http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9"http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8170395 Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e971a72675a Test:? Had run jtreg and jprt hotspot testsets. Regards, Muthusamy C ? From jini.george at oracle.com Wed Nov 8 06:28:12 2017 From: jini.george at oracle.com (Jini George) Date: Wed, 8 Nov 2017 11:58:12 +0530 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: <08248c0d-9041-071b-9a51-8032da9fb403@oracle.com> References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> <08248c0d-9041-071b-9a51-8032da9fb403@oracle.com> Message-ID: <380ff1c1-21d8-1b08-fbb6-733e42864e13@oracle.com> Hi David, If we don't retain the cast, wouldn't that mean that we would be comparing 2 64 bit values in a 64 bit environment which would not be the intended comparison ? Thanks, Jini. On 11/8/2017 7:49 AM, David Holmes wrote: > Hi Jini, > >> On 11/7/17 4:16 AM, Jini George wrote: >>> Thank you very much, Coleen, for the review. My answers inline: >>> >>> On 11/2/2017 5:09 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/src/hotspot/share/runtime/stackValue.hpp.udiff.html >>>> >>>> >>>> + return (*(int *)&_integer_value == *(int *)&value->_integer_value); >>>> >>>> >>>> I don't think the *(int*) casts for _integer_value are needed in >>>> these files.? Can you remove them? >>> >>> [Jini] I think since _integer_value is of type intptr_t (which could >>> be 8 or 4 bytes long depending on the data model), the removal of the >>> casts could result in an incorrect comparison (mostly for the 64 bit >>> environment). Let me know if you disagree. > > You're comparing two _integer_value fields that are both intptr_t. The > important part you've overlooked is the comment preceding this: > > ?????? // [phh] compare only low addressed portions of intptr_t slots > -????? return (*(int *)&_i == *(int *)&value->_i); > +????? return (*(int *)&_integer_value == *(int *)&value->_integer_value); > > For some we reason although intptr_t we're only interested in the lower > 32-bits. I have no idea why, nor why we would truncate the value when > printing. > > David > ----- From david.holmes at oracle.com Wed Nov 8 06:30:35 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Nov 2017 16:30:35 +1000 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: <380ff1c1-21d8-1b08-fbb6-733e42864e13@oracle.com> References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> <08248c0d-9041-071b-9a51-8032da9fb403@oracle.com> <380ff1c1-21d8-1b08-fbb6-733e42864e13@oracle.com> Message-ID: <6be4c85e-7bd2-9ec2-85a3-63266ae935b4@oracle.com> Hi Jini, On 8/11/2017 4:28 PM, Jini George wrote: > Hi David, > > If we don't retain the cast, wouldn't that mean that we would be > comparing 2 64 bit values in a 64 bit environment which would not be the > intended comparison ? Yes. I was pointing out the reason for the cast. David > Thanks, > Jini. > > On 11/8/2017 7:49 AM, David Holmes wrote: >> Hi Jini, >> >>> On 11/7/17 4:16 AM, Jini George wrote: >>>> Thank you very much, Coleen, for the review. My answers inline: >>>> >>>> On 11/2/2017 5:09 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/src/hotspot/share/runtime/stackValue.hpp.udiff.html >>>>> >>>>> >>>>> + return (*(int *)&_integer_value == *(int *)&value->_integer_value); >>>>> >>>>> >>>>> I don't think the *(int*) casts for _integer_value are needed in >>>>> these files.? Can you remove them? >>>> >>>> [Jini] I think since _integer_value is of type intptr_t (which could >>>> be 8 or 4 bytes long depending on the data model), the removal of >>>> the casts could result in an incorrect comparison (mostly for the 64 >>>> bit environment). Let me know if you disagree. >> >> You're comparing two _integer_value fields that are both intptr_t. The >> important part you've overlooked is the comment preceding this: >> >> ??????? // [phh] compare only low addressed portions of intptr_t slots >> -????? return (*(int *)&_i == *(int *)&value->_i); >> +????? return (*(int *)&_integer_value == *(int >> *)&value->_integer_value); >> >> For some we reason although intptr_t we're only interested in the >> lower 32-bits. I have no idea why, nor why we would truncate the value >> when printing. >> >> David >> ----- From jini.george at oracle.com Wed Nov 8 06:31:50 2017 From: jini.george at oracle.com (Jini George) Date: Wed, 8 Nov 2017 12:01:50 +0530 Subject: RFR: SA: JDK-8189798: SA cleanup - part 1 In-Reply-To: <6be4c85e-7bd2-9ec2-85a3-63266ae935b4@oracle.com> References: <18501902-23db-de6c-b83d-640cd33df836@oracle.com> <691d8166-5395-906a-4256-ef0ab2e2773a@oracle.com> <6b40cba4-fc4e-dc54-a506-62f64599331e@oracle.com> <08248c0d-9041-071b-9a51-8032da9fb403@oracle.com> <380ff1c1-21d8-1b08-fbb6-733e42864e13@oracle.com> <6be4c85e-7bd2-9ec2-85a3-63266ae935b4@oracle.com> Message-ID: <8c72f3af-062d-d19c-8144-5b91cc4b3a59@oracle.com> Ok, Thank you! -Jini. On 11/8/2017 12:00 PM, David Holmes wrote: > Hi Jini, > > On 8/11/2017 4:28 PM, Jini George wrote: >> Hi David, >> >> If we don't retain the cast, wouldn't that mean that we would be >> comparing 2 64 bit values in a 64 bit environment which would not be >> the intended comparison ? > > Yes. I was pointing out the reason for the cast. > > David > >> Thanks, >> Jini. >> >> On 11/8/2017 7:49 AM, David Holmes wrote: >>> Hi Jini, >>> >>>> On 11/7/17 4:16 AM, Jini George wrote: >>>>> Thank you very much, Coleen, for the review. My answers inline: >>>>> >>>>> On 11/2/2017 5:09 PM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> http://cr.openjdk.java.net/~jgeorge/8189798/webrev.00/src/hotspot/share/runtime/stackValue.hpp.udiff.html >>>>>> >>>>>> >>>>>> + return (*(int *)&_integer_value == *(int *)&value->_integer_value); >>>>>> >>>>>> >>>>>> I don't think the *(int*) casts for _integer_value are needed in >>>>>> these files.? Can you remove them? >>>>> >>>>> [Jini] I think since _integer_value is of type intptr_t (which >>>>> could be 8 or 4 bytes long depending on the data model), the >>>>> removal of the casts could result in an incorrect comparison >>>>> (mostly for the 64 bit environment). Let me know if you disagree. >>> >>> You're comparing two _integer_value fields that are both intptr_t. >>> The important part you've overlooked is the comment preceding this: >>> >>> ??????? // [phh] compare only low addressed portions of intptr_t slots >>> -????? return (*(int *)&_i == *(int *)&value->_i); >>> +????? return (*(int *)&_integer_value == *(int >>> *)&value->_integer_value); >>> >>> For some we reason although intptr_t we're only interested in the >>> lower 32-bits. I have no idea why, nor why we would truncate the >>> value when printing. >>> >>> David >>> ----- From erik.osterlund at oracle.com Wed Nov 8 16:26:02 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 8 Nov 2017 17:26:02 +0100 Subject: RFR (S) 8190891: Clean up G1 barrier code in compiler interface (ci) In-Reply-To: <608846ee-75ed-0858-c0e9-14bb2e533c30@oracle.com> References: <608846ee-75ed-0858-c0e9-14bb2e533c30@oracle.com> Message-ID: <5A03301A.1020707@oracle.com> Hi Coleen, Looks fantastic. Thanks, /Erik On 2017-11-08 01:38, coleen.phillimore at oracle.com wrote: > Summary: consolidate gc barrier code in ci > > See bug and comments for more details. > > Tested with mach5 tier1-5 on linux x64 and iwndows x64. Also tested > StressRedefineWithoutBytecodeModification in > test/jdk/java/lang/instrument which fails without the g1 barriers. > > open webrev at http://cr.openjdk.java.net/~coleenp/8190891.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8190891 > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Nov 8 16:44:03 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 8 Nov 2017 11:44:03 -0500 Subject: RFR (S) 8190891: Clean up G1 barrier code in compiler interface (ci) In-Reply-To: <5A03301A.1020707@oracle.com> References: <608846ee-75ed-0858-c0e9-14bb2e533c30@oracle.com> <5A03301A.1020707@oracle.com> Message-ID: <00b399fe-288b-b639-0458-bbb17b72e8f0@oracle.com> Thank you Erik! Coleen On 11/8/17 11:26 AM, Erik ?sterlund wrote: > Hi Coleen, > > Looks fantastic. > > Thanks, > /Erik > > On 2017-11-08 01:38, coleen.phillimore at oracle.com wrote: >> Summary: consolidate gc barrier code in ci >> >> See bug and comments for more details. >> >> Tested with mach5 tier1-5 on linux x64 and iwndows x64.? Also tested >> StressRedefineWithoutBytecodeModification in >> test/jdk/java/lang/instrument which fails without the g1 barriers. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8190891.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8190891 >> >> Thanks, >> Coleen > From john.r.rose at oracle.com Wed Nov 8 16:59:40 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 8 Nov 2017 08:59:40 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <876381003.1124033.1510090506277.JavaMail.zimbra@u-pem.fr> References: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> <876381003.1124033.1510090506277.JavaMail.zimbra@u-pem.fr> Message-ID: <458D86E4-51CC-48E8-A3D3-4AEE737FD558@oracle.com> On Nov 7, 2017, at 1:35 PM, forax at univ-mlv.fr wrote: > > perhaps getFinalStatic, because it's restricted to final field. The restriction to final field is because we are expecting the method to be used from condy, where it seems to be a syntax error to sample a constant from a non-constant variable. That said, I too would prefer to make it explicit (even in the name) that the BSM applies only to static final fields. So +1 for getStaticFinal instead of getStatic. We also discussed this internally back and forth. Your comment pushed me over the edge. ("getFinalStatic" is wrong BTW because "Final" is an extra constraint after "getStatic", and because "static final" is the usual written order for the corresponding modifiers, not "final static", at least in the relevant source bases.) ? John From paul.sandoz at oracle.com Wed Nov 8 17:03:11 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 8 Nov 2017 09:03:11 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <458D86E4-51CC-48E8-A3D3-4AEE737FD558@oracle.com> References: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> <876381003.1124033.1510090506277.JavaMail.zimbra@u-pem.fr> <458D86E4-51CC-48E8-A3D3-4AEE737FD558@oracle.com> Message-ID: <4043E2D6-B8F3-4AA2-A8B3-C952CEE4F945@oracle.com> > On 8 Nov 2017, at 08:59, John Rose wrote: > > On Nov 7, 2017, at 1:35 PM, forax at univ-mlv.fr wrote: >> >> perhaps getFinalStatic, because it's restricted to final field. > > The restriction to final field is because we are expecting the > method to be used from condy, where it seems to be a syntax > error to sample a constant from a non-constant variable. > > That said, I too would prefer to make it explicit (even in the name) > that the BSM applies only to static final fields. > > So +1 for getStaticFinal instead of getStatic. We also discussed > this internally back and forth. Your comment pushed me over > the edge. > Updated the CSR to reflect this. I will update the webrev soon. > ("getFinalStatic" is wrong BTW because "Final" is an extra > constraint after "getStatic", and because "static final" is the > usual written order for the corresponding modifiers, not > "final static", at least in the relevant source bases.) > +1 Paul. From erik.helin at oracle.com Wed Nov 8 17:16:45 2017 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 8 Nov 2017 18:16:45 +0100 Subject: RFR(XS) : 8190890 : remove hotspot_tier1_{compiler,gc}_closed groups In-Reply-To: <63C6D6E6-6368-45D3-83A2-A68BD95F4082@oracle.com> References: <63C6D6E6-6368-45D3-83A2-A68BD95F4082@oracle.com> Message-ID: On 11/08/2017 01:56 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8190890/webrev.00/index.html >> 9 lines changed: 0 ins; 9 del; > > Hi all, > > could you please review this tiny patch which removes unneeded jtreg test groups? > > webrev: http://cr.openjdk.java.net/~iignatyev//8190890/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8190890 Looks good, Reviewed. I would say that this change classifies as trivial, so you only need one Reviewer. Thanks for cleaning this up. Thanks, Erik > Thanks, > -- Igor > From igor.ignatyev at oracle.com Wed Nov 8 18:18:36 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 8 Nov 2017 10:18:36 -0800 Subject: RFR(XS) : 8190890 : remove hotspot_tier1_{compiler,gc}_closed groups In-Reply-To: References: <63C6D6E6-6368-45D3-83A2-A68BD95F4082@oracle.com> Message-ID: <99456499-0FEB-4DDF-8788-93EDF355258F@oracle.com> Thanks Erik. -- Igor > On Nov 8, 2017, at 9:16 AM, Erik Helin wrote: > > On 11/08/2017 01:56 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8190890/webrev.00/index.html >>> 9 lines changed: 0 ins; 9 del; >> Hi all, >> could you please review this tiny patch which removes unneeded jtreg test groups? >> webrev: http://cr.openjdk.java.net/~iignatyev//8190890/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8190890 > > Looks good, Reviewed. I would say that this change classifies as trivial, so you only need one Reviewer. Thanks for cleaning this up. > > Thanks, > Erik > >> Thanks, >> -- Igor From kim.barrett at oracle.com Wed Nov 8 19:28:12 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 8 Nov 2017 14:28:12 -0500 Subject: RFR (S) 8190891: Clean up G1 barrier code in compiler interface (ci) In-Reply-To: <608846ee-75ed-0858-c0e9-14bb2e533c30@oracle.com> References: <608846ee-75ed-0858-c0e9-14bb2e533c30@oracle.com> Message-ID: <60F0F1A3-9D70-4F00-B108-3E8D48DA2DFC@oracle.com> > On Nov 7, 2017, at 7:38 PM, coleen.phillimore at oracle.com wrote: > > Summary: consolidate gc barrier code in ci > > See bug and comments for more details. > > Tested with mach5 tier1-5 on linux x64 and iwndows x64. Also tested StressRedefineWithoutBytecodeModification in test/jdk/java/lang/instrument which fails without the g1 barriers. > > open webrev at http://cr.openjdk.java.net/~coleenp/8190891.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8190891 > > Thanks, > Coleen ------------------------------------------------------------------------------ src/hotspot/share/ci/ciInstanceKlass.cpp 55 static void ensure_metadata_alive(oop metadata_holder) { ... 60 if (metadata_holder != NULL) { When would we ever get a ciInstanceKlass for a Klass with a NULL holder? That seems like a situation that shouldn't ever happen, and this should be an assert instead. And there is an assert here 75 assert(get_instanceKlass()->is_loaded(), "must be at least loaded"); that dominates the ensure_metadata_alive call that is similarly suggestive. Though I'm not sure whether is_loaded can be true if the klass was loaded and then later had its holder die and be cleared. And can the call to get_object at line 99 cope with a NULL holder? Basically I'm questioning whether the ik->klass_holder() on line 91 can ever legitimately return NULL. ------------------------------------------------------------------------------ From coleen.phillimore at oracle.com Wed Nov 8 19:58:35 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 8 Nov 2017 14:58:35 -0500 Subject: RFR (S) 8190891: Clean up G1 barrier code in compiler interface (ci) In-Reply-To: <60F0F1A3-9D70-4F00-B108-3E8D48DA2DFC@oracle.com> References: <608846ee-75ed-0858-c0e9-14bb2e533c30@oracle.com> <60F0F1A3-9D70-4F00-B108-3E8D48DA2DFC@oracle.com> Message-ID: Kim, Thank you for revewing. On 11/8/17 2:28 PM, Kim Barrett wrote: >> On Nov 7, 2017, at 7:38 PM, coleen.phillimore at oracle.com wrote: >> >> Summary: consolidate gc barrier code in ci >> >> See bug and comments for more details. >> >> Tested with mach5 tier1-5 on linux x64 and iwndows x64. Also tested StressRedefineWithoutBytecodeModification in test/jdk/java/lang/instrument which fails without the g1 barriers. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8190891.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8190891 >> >> Thanks, >> Coleen > ------------------------------------------------------------------------------ > src/hotspot/share/ci/ciInstanceKlass.cpp > 55 static void ensure_metadata_alive(oop metadata_holder) { > ... > 60 if (metadata_holder != NULL) { > > When would we ever get a ciInstanceKlass for a Klass with a NULL > holder? That seems like a situation that shouldn't ever happen, and > this should be an assert instead. And there is an assert here When it's the NULL class loader, associated with ClassLoaderData::the_null_class_loader_data().?? This class loader is never unloaded. > > 75 assert(get_instanceKlass()->is_loaded(), "must be at least loaded"); > > that dominates the ensure_metadata_alive call that is similarly > suggestive. Though I'm not sure whether is_loaded can be true if the > klass was loaded and then later had its holder die and be cleared. Not sure I understand this comment.? The InstanceKlass must be in the "loaded" _init_state to get to this code, but the marking for ensure_metadata_alive and creating an object prevents it from being unloaded after this point. > > And can the call to get_object at line 99 cope with a NULL holder? No anonymous class's holders are the mirror which cannot be null.? I can add this before line 99: ??? assert(holder != NULL, "holder of anonymous class is the mirror which is never null"); > > Basically I'm questioning whether the ik->klass_holder() on line 91 > can ever legitimately return NULL. Yes it can and does. Thanks, Coleen > > ------------------------------------------------------------------------------ > From glaubitz at physik.fu-berlin.de Wed Nov 8 20:14:01 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 8 Nov 2017 21:14:01 +0100 Subject: [RFR]: 8190570: Zero fails to build on linux-sparc due undefined reference In-Reply-To: <782165f4-3b22-fc61-0e80-d480e4d349ae@physik.fu-berlin.de> References: <782165f4-3b22-fc61-0e80-d480e4d349ae@physik.fu-berlin.de> Message-ID: <0225ef98-10fe-99a4-43b1-4c84e5215573@physik.fu-berlin.de> Hi! Anyone could review this change for me? Adrian On 11/06/2017 07:50 PM, John Paul Adrian Glaubitz wrote: > Hi! > > Trying to build Zero on linux-sparc currently fails with: > > === Output from failing command(s) repeated here === > /usr/bin/printf "* For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:\n" > * For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: > (/bin/grep -v -e "^Note: including file:" < > /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log > || true) | /usr/bin/head -n 12 > /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/init.o: In function `init_globals()': > /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/init.cpp:120: undefined reference to `g1_barrier_stubs_init()' > collect2: error: ld returned 1 exit status > if test `/usr/bin/wc -l < > /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log` > -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi > /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:\n" > * For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link: > (/bin/grep -v -e "^Note: including file:" < > /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log || true) | > /usr/bin/head -n 12 > /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/init.o: In function `init_globals()': > /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/init.cpp:120: undefined reference to `g1_barrier_stubs_init()' > collect2: error: ld returned 1 exit status > if test `/usr/bin/wc -l < > /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log` -gt 12; then > /bin/echo " ... (rest of output omitted)" ; fi > /usr/bin/printf "\n* All command lines available in /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.\n" > > * All command lines available in /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs. > /usr/bin/printf "=== End of repeated output ===\n" > === End of repeated output === > > This happens because of this snippet of code in src/hotspot/share/runtime/init.cpp: > > #if INCLUDE_ALL_GCS > // depends on universe_init, must be before interpreter_init (currently only on SPARC) > void g1_barrier_stubs_init() NOT_SPARC({}); > #endif > > I have submitted a possible fix to webrev in [1]. Please review. > > Thanks, > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8190570/webrev.00/ > -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From coleen.phillimore at oracle.com Wed Nov 8 20:41:49 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 8 Nov 2017 15:41:49 -0500 Subject: [RFR]: 8190570: Zero fails to build on linux-sparc due undefined reference In-Reply-To: <0225ef98-10fe-99a4-43b1-4c84e5215573@physik.fu-berlin.de> References: <782165f4-3b22-fc61-0e80-d480e4d349ae@physik.fu-berlin.de> <0225ef98-10fe-99a4-43b1-4c84e5215573@physik.fu-berlin.de> Message-ID: Seems trivial enough.? I'll check it in for you. Coleen On 11/8/17 3:14 PM, John Paul Adrian Glaubitz wrote: > Hi! > > Anyone could review this change for me? > > Adrian > > On 11/06/2017 07:50 PM, John Paul Adrian Glaubitz wrote: >> Hi! >> >> Trying to build Zero on linux-sparc currently fails with: >> >> === Output from failing command(s) repeated here === >> /usr/bin/printf "* For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:\n" >> * For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: >> (/bin/grep -v -e "^Note: including file:" < >> /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log >> || true) | /usr/bin/head -n 12 >> /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/init.o: In function `init_globals()': >> /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/init.cpp:120: undefined reference to `g1_barrier_stubs_init()' >> collect2: error: ld returned 1 exit status >> if test `/usr/bin/wc -l < >> /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log` >> -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi >> /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:\n" >> * For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link: >> (/bin/grep -v -e "^Note: including file:" < >> /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log || true) | >> /usr/bin/head -n 12 >> /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/init.o: In function `init_globals()': >> /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/init.cpp:120: undefined reference to `g1_barrier_stubs_init()' >> collect2: error: ld returned 1 exit status >> if test `/usr/bin/wc -l < >> /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log` -gt 12; then >> /bin/echo " ... (rest of output omitted)" ; fi >> /usr/bin/printf "\n* All command lines available in /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.\n" >> >> * All command lines available in /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs. >> /usr/bin/printf "=== End of repeated output ===\n" >> === End of repeated output === >> >> This happens because of this snippet of code in src/hotspot/share/runtime/init.cpp: >> >> #if INCLUDE_ALL_GCS >> // depends on universe_init, must be before interpreter_init (currently only on SPARC) >> void g1_barrier_stubs_init() NOT_SPARC({}); >> #endif >> >> I have submitted a possible fix to webrev in [1]. Please review. >> >> Thanks, >> Adrian >> >>> [1] http://cr.openjdk.java.net/~glaubitz/8190570/webrev.00/ > From robbin.ehn at oracle.com Wed Nov 8 20:48:42 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 8 Nov 2017 21:48:42 +0100 Subject: RFR: 8187809: UseMembar should be set true and deprecate the flag Message-ID: <5762f365-c12d-ac8e-2256-460b2008ce50@oracle.com> Hi all, please review! This patch set the default technique for reading thread state to memory barriers instead of using the asymmetric dekker synchronization on all platforms. We also deprecate the option and starting the removal process. There have been discussion with people involved in all platforms and we will have another discussion before obsoleting the flag to make sure no issue have been found. More info in CSR: https://bugs.openjdk.java.net/browse/JDK-8187812 Bug: https://bugs.openjdk.java.net/browse/JDK-8187809 Code: http://cr.openjdk.java.net/~rehn/8187809/webrev/ Thanks, Robbin From robbin.ehn at oracle.com Wed Nov 8 20:52:58 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 8 Nov 2017 21:52:58 +0100 Subject: RFR: 8187809: UseMembar should be set true and deprecate the flag In-Reply-To: <5762f365-c12d-ac8e-2256-460b2008ce50@oracle.com> References: <5762f365-c12d-ac8e-2256-460b2008ce50@oracle.com> Message-ID: Hi, I forgot to say, UseMembar have been tested heavily on our supported platforms. This particular changeset just passed sanity test of tier 1-2. Thanks, Robbin On 2017-11-08 21:48, Robbin Ehn wrote: > Hi all, please review! > > This patch set the default technique for reading thread state to memory barriers instead of using the asymmetric dekker > synchronization on all platforms. We also deprecate the option and starting the removal process. There have been > discussion with people involved in all platforms and we will have another discussion before obsoleting the flag to make > sure no issue have been found. > > More info in CSR: > https://bugs.openjdk.java.net/browse/JDK-8187812 > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8187809 > > Code: > http://cr.openjdk.java.net/~rehn/8187809/webrev/ > > Thanks, Robbin From daniel.daugherty at oracle.com Wed Nov 8 21:16:15 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 Nov 2017 16:16:15 -0500 Subject: RFR: 8187809: UseMembar should be set true and deprecate the flag In-Reply-To: References: <5762f365-c12d-ac8e-2256-460b2008ce50@oracle.com> Message-ID: <8a760679-08f1-1626-e7f4-f49666cf4b8c@oracle.com> On 11/8/17 3:52 PM, Robbin Ehn wrote: > Hi, > > I forgot to say, UseMembar have been tested heavily on our supported > platforms. > This particular changeset just passed sanity test of tier 1-2. > > Thanks, Robbin > > On 2017-11-08 21:48, Robbin Ehn wrote: >> Hi all, please review! >> >> This patch set the default technique for reading thread state to >> memory barriers instead of using the asymmetric dekker >> synchronization on all platforms. We also deprecate the option and >> starting the removal process. There have been discussion with people >> involved in all platforms and we will have another discussion before >> obsoleting the flag to make sure no issue have been found. >> >> More info in CSR: >> https://bugs.openjdk.java.net/browse/JDK-8187812 >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8187809 >> >> Code: >> http://cr.openjdk.java.net/~rehn/8187809/webrev/ src/hotspot/cpu/ppc/globals_ppc.hpp src/hotspot/cpu/s390/globals_s390.hpp src/hotspot/cpu/sparc/globals_sparc.hpp src/hotspot/cpu/x86/globals_x86.hpp ??? No comments. src/hotspot/share/runtime/arguments.cpp ??? No comments on your change. ??? The existing inconsistent indents in those columns are annoying. Thumbs up. Dan >> >> Thanks, Robbin From robbin.ehn at oracle.com Wed Nov 8 21:47:23 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 8 Nov 2017 22:47:23 +0100 Subject: RFR: 8187809: UseMembar should be set true and deprecate the flag In-Reply-To: <8a760679-08f1-1626-e7f4-f49666cf4b8c@oracle.com> References: <5762f365-c12d-ac8e-2256-460b2008ce50@oracle.com> <8a760679-08f1-1626-e7f4-f49666cf4b8c@oracle.com> Message-ID: <287cdc5e-ec60-53c9-f4fc-38e413f6bcc7@oracle.com> Thanks Dan! /Robbin On 2017-11-08 22:16, Daniel D. Daugherty wrote: > On 11/8/17 3:52 PM, Robbin Ehn wrote: >> Hi, >> >> I forgot to say, UseMembar have been tested heavily on our supported platforms. >> This particular changeset just passed sanity test of tier 1-2. >> >> Thanks, Robbin >> >> On 2017-11-08 21:48, Robbin Ehn wrote: >>> Hi all, please review! >>> >>> This patch set the default technique for reading thread state to memory barriers instead of using the asymmetric >>> dekker synchronization on all platforms. We also deprecate the option and starting the removal process. There have >>> been discussion with people involved in all platforms and we will have another discussion before obsoleting the flag >>> to make sure no issue have been found. >>> >>> More info in CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8187812 >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8187809 >>> >>> Code: >>> http://cr.openjdk.java.net/~rehn/8187809/webrev/ > > src/hotspot/cpu/ppc/globals_ppc.hpp > src/hotspot/cpu/s390/globals_s390.hpp > src/hotspot/cpu/sparc/globals_sparc.hpp > src/hotspot/cpu/x86/globals_x86.hpp > ??? No comments. > > src/hotspot/share/runtime/arguments.cpp > ??? No comments on your change. > ??? The existing inconsistent indents in those columns are annoying. > > Thumbs up. > > Dan > > >>> >>> Thanks, Robbin > From john.r.rose at oracle.com Thu Nov 9 00:01:20 2017 From: john.r.rose at oracle.com (John Rose) Date: Wed, 8 Nov 2017 16:01:20 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: References: <1268371279.1064647.1510083191133.JavaMail.zimbra@u-pem.fr> Message-ID: On Nov 7, 2017, at 12:59 PM, John Rose wrote: > > For condy, having the BSM validate types is a code smell > for the reason you mention. Also, when primitives (and value > types) are in the mix, people usually code the validation > incorrectly, since Class.isInstance is the wrong tool, and > the right tool is non-obvious (MHs.identity.asType). For the record, here is a method that performs the correct conversions: https://bugs.openjdk.java.net/browse/JDK-8190982 The bug suggests that it be called Class::convert. The code itself is simple enough to cut-n-paste into your own BSMs. ? John From serguei.spitsyn at oracle.com Thu Nov 9 00:45:40 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 8 Nov 2017 16:45:40 -0800 Subject: [RFR]: 8190570: Zero fails to build on linux-sparc due undefined reference In-Reply-To: <0225ef98-10fe-99a4-43b1-4c84e5215573@physik.fu-berlin.de> References: <782165f4-3b22-fc61-0e80-d480e4d349ae@physik.fu-berlin.de> <0225ef98-10fe-99a4-43b1-4c84e5215573@physik.fu-berlin.de> Message-ID: Hi Adrian, Looks good. Thanks, Serguei On 11/8/17 12:14, John Paul Adrian Glaubitz wrote: > Hi! > > Anyone could review this change for me? > > Adrian > > On 11/06/2017 07:50 PM, John Paul Adrian Glaubitz wrote: >> Hi! >> >> Trying to build Zero on linux-sparc currently fails with: >> >> === Output from failing command(s) repeated here === >> /usr/bin/printf "* For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link:\n" >> * For target hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link: >> (/bin/grep -v -e "^Note: including file:" < >> /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log >> || true) | /usr/bin/head -n 12 >> /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/init.o: In function `init_globals()': >> /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/init.cpp:120: undefined reference to `g1_barrier_stubs_init()' >> collect2: error: ld returned 1 exit status >> if test `/usr/bin/wc -l < >> /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_link.log` >> -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi >> /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link:\n" >> * For target hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link: >> (/bin/grep -v -e "^Note: including file:" < >> /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log || true) | >> /usr/bin/head -n 12 >> /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/hotspot/variant-zero/libjvm/objs/init.o: In function `init_globals()': >> /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/init.cpp:120: undefined reference to `g1_barrier_stubs_init()' >> collect2: error: ld returned 1 exit status >> if test `/usr/bin/wc -l < >> /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_BUILD_LIBJVM_link.log` -gt 12; then >> /bin/echo " ... (rest of output omitted)" ; fi >> /usr/bin/printf "\n* All command lines available in /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.\n" >> >> * All command lines available in /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs. >> /usr/bin/printf "=== End of repeated output ===\n" >> === End of repeated output === >> >> This happens because of this snippet of code in src/hotspot/share/runtime/init.cpp: >> >> #if INCLUDE_ALL_GCS >> // depends on universe_init, must be before interpreter_init (currently only on SPARC) >> void g1_barrier_stubs_init() NOT_SPARC({}); >> #endif >> >> I have submitted a possible fix to webrev in [1]. Please review. >> >> Thanks, >> Adrian >> >>> [1] http://cr.openjdk.java.net/~glaubitz/8190570/webrev.00/ > From serguei.spitsyn at oracle.com Thu Nov 9 00:50:12 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 8 Nov 2017 16:50:12 -0800 Subject: RFR: 8187809: UseMembar should be set true and deprecate the flag In-Reply-To: References: <5762f365-c12d-ac8e-2256-460b2008ce50@oracle.com> Message-ID: <31cd5e02-d79a-01cd-998d-e31bf135917c@oracle.com> Hi Robbin, Looks good. Thanks, Serguei On 11/8/17 12:52, Robbin Ehn wrote: > Hi, > > I forgot to say, UseMembar have been tested heavily on our supported > platforms. > This particular changeset just passed sanity test of tier 1-2. > > Thanks, Robbin > > On 2017-11-08 21:48, Robbin Ehn wrote: >> Hi all, please review! >> >> This patch set the default technique for reading thread state to >> memory barriers instead of using the asymmetric dekker >> synchronization on all platforms. We also deprecate the option and >> starting the removal process. There have been discussion with people >> involved in all platforms and we will have another discussion before >> obsoleting the flag to make sure no issue have been found. >> >> More info in CSR: >> https://bugs.openjdk.java.net/browse/JDK-8187812 >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8187809 >> >> Code: >> http://cr.openjdk.java.net/~rehn/8187809/webrev/ >> >> Thanks, Robbin From david.holmes at oracle.com Thu Nov 9 01:48:31 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Nov 2017 11:48:31 +1000 Subject: RFR: 8187809: UseMembar should be set true and deprecate the flag In-Reply-To: <5762f365-c12d-ac8e-2256-460b2008ce50@oracle.com> References: <5762f365-c12d-ac8e-2256-460b2008ce50@oracle.com> Message-ID: <56971c14-fc74-076e-db99-2f353874682a@oracle.com> Looks good. One nit below ... On 9/11/2017 6:48 AM, Robbin Ehn wrote: > Hi all, please review! > > This patch set the default technique for reading thread state to memory > barriers instead of using the asymmetric dekker synchronization on all > platforms. That's not quite an accurate description. The option is to use platform memory barriers (+UseMembar) or the memory-serialization-page "simulated" memory barrier. We still employ asymmetric Dekker synchronization. Thanks, David > We also deprecate the option and starting the removal > process. There have been discussion with people involved in all > platforms and we will have another discussion before obsoleting the flag > to make sure no issue have been found. > > More info in CSR: > https://bugs.openjdk.java.net/browse/JDK-8187812 > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8187809 > > Code: > http://cr.openjdk.java.net/~rehn/8187809/webrev/ > > Thanks, Robbin From robbin.ehn at oracle.com Thu Nov 9 06:46:15 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 9 Nov 2017 07:46:15 +0100 Subject: RFR: 8187809: UseMembar should be set true and deprecate the flag In-Reply-To: <31cd5e02-d79a-01cd-998d-e31bf135917c@oracle.com> References: <5762f365-c12d-ac8e-2256-460b2008ce50@oracle.com> <31cd5e02-d79a-01cd-998d-e31bf135917c@oracle.com> Message-ID: Thanks Serguei! /Robbin On 11/09/2017 01:50 AM, serguei.spitsyn at oracle.com wrote: > Hi Robbin, > > Looks good. > > Thanks, > Serguei > > On 11/8/17 12:52, Robbin Ehn wrote: >> Hi, >> >> I forgot to say, UseMembar have been tested heavily on our supported platforms. >> This particular changeset just passed sanity test of tier 1-2. >> >> Thanks, Robbin >> >> On 2017-11-08 21:48, Robbin Ehn wrote: >>> Hi all, please review! >>> >>> This patch set the default technique for reading thread state to memory >>> barriers instead of using the asymmetric dekker synchronization on all >>> platforms. We also deprecate the option and starting the removal process. >>> There have been discussion with people involved in all platforms and we will >>> have another discussion before obsoleting the flag to make sure no issue have >>> been found. >>> >>> More info in CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8187812 >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8187809 >>> >>> Code: >>> http://cr.openjdk.java.net/~rehn/8187809/webrev/ >>> >>> Thanks, Robbin > From robbin.ehn at oracle.com Thu Nov 9 06:47:57 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 9 Nov 2017 07:47:57 +0100 Subject: RFR: 8187809: UseMembar should be set true and deprecate the flag In-Reply-To: <56971c14-fc74-076e-db99-2f353874682a@oracle.com> References: <5762f365-c12d-ac8e-2256-460b2008ce50@oracle.com> <56971c14-fc74-076e-db99-2f353874682a@oracle.com> Message-ID: <77156889-177e-3c15-536b-f24401a7feea@oracle.com> Thanks David! /Robbin On 11/09/2017 02:48 AM, David Holmes wrote: > Looks good. > > One nit below ... > > On 9/11/2017 6:48 AM, Robbin Ehn wrote: >> Hi all, please review! >> >> This patch set the default technique for reading thread state to memory >> barriers instead of using the asymmetric dekker synchronization on all platforms. > > That's not quite an accurate description. The option is to use platform memory > barriers (+UseMembar) or the memory-serialization-page "simulated" memory > barrier. We still employ asymmetric Dekker synchronization. > > Thanks, > David > >> We also deprecate the option and starting the removal process. There have been >> discussion with people involved in all platforms and we will have another >> discussion before obsoleting the flag to make sure no issue have been found. >> >> More info in CSR: >> https://bugs.openjdk.java.net/browse/JDK-8187812 >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8187809 >> >> Code: >> http://cr.openjdk.java.net/~rehn/8187809/webrev/ >> >> Thanks, Robbin From stanislav.lukyanov at oracle.com Thu Nov 9 08:24:38 2017 From: stanislav.lukyanov at oracle.com (stanislav lukyanov) Date: Thu, 9 Nov 2017 13:54:38 +0530 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: References: Message-ID: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> Hi Paul, How about changing the name of the class to ConstantFactory to align with its two siblings - LambdaMetafactory and StringConcatFactory? Other comments are purely about the spec text (should I be posting them in the CSR issue instead?) The class-level javadoc could use more text to describe the contents (e.g. "Methods to facilitate creation of common kinds of dynamic constants...", similar to other bootstrap factories) and motivation for having this class. I think giving the motivation here is important - it might be not obvious why, for example, nullConstant is needed when there is aconst_null. Maybe an example of an invokedynamic using static arguments that are dynamic constants (repeat the last six words together BTW!) could also be there (javap- or jasm-style pseudocode for that?) Also, @author and @since are missing. All methods repeat the same NPE condition ??? @throws NullPointerException if any used argument is {@code null} which looks especially strange in methods with one used parameter (e.g. nullConstant) or with no unused parameters (e.g. getStaticFinal). I'd suggest to instead go with the commonly used shortcut of declaring the NPE in the class-level Javadoc, e.g. ??? "Passing a null argument to a method in this class will cause of NullPointerException to be thrown, ????? unless the argument is specified to be unused, or unless otherwise noted". The VarHandle methods have ??? @param type unused; must be {@code Class} Looks like the "unused;" part should be removed. Thanks, Stas On 08.11.2017 0:08, Paul Sandoz wrote: > Hi, > > Please review the patch that adds a minimal set of bootstrap methods can be be used for producing dynamic constants: > > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ > > The aim is to provide a small but common set of BSMs that are likely useful with ldc or as BSM arguments, filling in the gaps for constants that cannot be currently represented, such as null, primitive classes and VarHandles. It?s possible to get more sophisticated regarding say factories but that is something to consider later on. > > This patch is based off the minimal dynamic constant support (still in review): > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html > > Paul. > From stanislav.lukyanov at oracle.com Thu Nov 9 08:42:02 2017 From: stanislav.lukyanov at oracle.com (stanislav lukyanov) Date: Thu, 9 Nov 2017 14:12:02 +0530 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> References: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> Message-ID: I also noticed that Class::isPrimitive now says the following: ??? "These objects may only be accessed via the following public static final variables, and are the only Class objects for which this method returns true." (the fields its talking about are the .TYPE) Should this text be tweaked? Thanks, Stas On 09.11.2017 13:54, stanislav lukyanov wrote: > Hi Paul, > > How about changing the name of the class to ConstantFactory to align > with its two siblings - LambdaMetafactory and StringConcatFactory? > > Other comments are purely about the spec text (should I be posting > them in the CSR issue instead?) > > The class-level javadoc could use more text to describe the contents > (e.g. "Methods to facilitate creation of common kinds of dynamic > constants...", similar to other bootstrap factories) > and motivation for having this class. I think giving the motivation > here is important - it might be not obvious why, for example, > nullConstant is needed when there is aconst_null. > Maybe an example of an invokedynamic using static arguments that are > dynamic constants (repeat the last six words together BTW!) > could also be there (javap- or jasm-style pseudocode for that?) > Also, @author and @since are missing. > > All methods repeat the same NPE condition > ??? @throws NullPointerException if any used argument is {@code null} > which looks especially strange in methods with one used parameter > (e.g. nullConstant) > or with no unused parameters (e.g. getStaticFinal). > I'd suggest to instead go with the commonly used shortcut of declaring > the NPE in the class-level Javadoc, e.g. > ??? "Passing a null argument to a method in this class will cause of > NullPointerException to be thrown, > ????? unless the argument is specified to be unused, or unless > otherwise noted". > > The VarHandle methods have > ??? @param type unused; must be {@code Class} > Looks like the "unused;" part should be removed. > > Thanks, > Stas > > On 08.11.2017 0:08, Paul Sandoz wrote: >> Hi, >> >> Please review the patch that adds a minimal set of bootstrap methods >> can be be used for producing dynamic constants: >> >> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ >> >> >> >> The aim is to provide a small but common set of BSMs that are likely >> useful with ldc or as BSM arguments, filling in the gaps for >> constants that cannot be currently represented, such as null, >> primitive classes and VarHandles. It?s possible to get more >> sophisticated regarding say factories but that is something to >> consider later on. >> >> This patch is based off the minimal dynamic constant support (still >> in review): >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html >> >> >> >> Paul. >> > From volker.simonis at gmail.com Thu Nov 9 09:01:16 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 9 Nov 2017 10:01:16 +0100 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> References: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> Message-ID: Hi Paul, just some quick process-related questions. Is this intended to be targeted for jdk 10? Is the current implementation already available in a separate repository and/or branch? I've read in the RFR for 8186046 that some parts are currently being refined in the amber repository. Or is the complete implementation already available there? If I want to port this to ppc64, what's the best way to start and what do I need? Is it just the two webrevs for 8187742 and 8186046 on top of the jdk hs repo? Or is it a branch of the amber repo? You may know that there's currently a discussion going on about what is a JEP and what's the right way to implement and integrate a JEP into the mainline. The general idea is that only 'finished' JEPs will be targeted and integrated into the always feature complete main line. So is this and the review for 8186046 about the integration into the jdk repo (which shouldn't happen before the JEP is not targeted for jdk10) or is it just the review before the JEP can actually be targeted? This is important because there's not much time before the jdk10 repos will enter Rampdown phase 1 and we would still have to port this to ppc (and also ARM/SPARC) if it will be targeted for jdk 10. I don't want to question the merits and quality of the current implementation which I'm sure are great. For me as an external observer its just hard to oversee the current status of the implementation. Thanks, Volker On Thu, Nov 9, 2017 at 9:24 AM, stanislav lukyanov wrote: > Hi Paul, > > How about changing the name of the class to ConstantFactory to align > with its two siblings - LambdaMetafactory and StringConcatFactory? > > Other comments are purely about the spec text (should I be posting them in > the CSR issue instead?) > > The class-level javadoc could use more text to describe the contents > (e.g. "Methods to facilitate creation of common kinds of dynamic > constants...", similar to other bootstrap factories) > and motivation for having this class. I think giving the motivation here is > important - it might be not obvious why, for example, > nullConstant is needed when there is aconst_null. > Maybe an example of an invokedynamic using static arguments that are dynamic > constants (repeat the last six words together BTW!) > could also be there (javap- or jasm-style pseudocode for that?) > Also, @author and @since are missing. > > All methods repeat the same NPE condition > @throws NullPointerException if any used argument is {@code null} > which looks especially strange in methods with one used parameter (e.g. > nullConstant) > or with no unused parameters (e.g. getStaticFinal). > I'd suggest to instead go with the commonly used shortcut of declaring the > NPE in the class-level Javadoc, e.g. > "Passing a null argument to a method in this class will cause of > NullPointerException to be thrown, > unless the argument is specified to be unused, or unless otherwise > noted". > > The VarHandle methods have > @param type unused; must be {@code Class} > Looks like the "unused;" part should be removed. > > Thanks, > Stas > > > On 08.11.2017 0:08, Paul Sandoz wrote: >> >> Hi, >> >> Please review the patch that adds a minimal set of bootstrap methods can >> be be used for producing dynamic constants: >> >> >> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ >> >> >> The aim is to provide a small but common set of BSMs that are likely >> useful with ldc or as BSM arguments, filling in the gaps for constants that >> cannot be currently represented, such as null, primitive classes and >> VarHandles. It?s possible to get more sophisticated regarding say factories >> but that is something to consider later on. >> >> This patch is based off the minimal dynamic constant support (still in >> review): >> >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.html >> >> >> Paul. >> > From erik.osterlund at oracle.com Thu Nov 9 17:00:03 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 9 Nov 2017 18:00:03 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics Message-ID: <5A048993.2000002@oracle.com> Hi, In an effort to remove explicit calls to GC barriers (and other orthogonal forms of barriers, like encoding/decoding oops for compressed oops and fencing for memory ordering), I have built an API that I call "Access". Its purpose is to perform accesses with declarative semantics, to handle multiple orthogonal concerns that affect how an access is performed, including memory ordering, compressed oops, GC barriers for marking, reference strength, etc, and as a result making GCs more modular, and as a result allow new concurrently compacting GC schemes utilizing load barriers to live in harmony in hotspot without everyone going crazy manually inserting barriers if UseBlahGC is enabled. CR: https://bugs.openjdk.java.net/browse/JDK-8189871 Webrev: http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ So there are three views of this I suppose: 1) The frontend: how this is actually used in shared code 2) The backends: how anyone writing a GC sticks their required barriers in there 3) The internals: how accesses find their way from the frontend to the corresponding backend == Frontend == Let's start with the frontend. I hope I made this fairly simple! You can find it in runtime/access.hpp Each access annotates its declarative semantics with a set of "decorators", which is the name of the attributes/properties affecting how an access is performed. There is an Access API that makes the declarative semantics possible. For example, if I want to perform a load acquire of an oop in the heap that has "weak" strength, I would do something like: oop result = Access::oop_load_at(obj, offset); The Access API would then send the access through some GC backend, that overrides the whole access and tells it to perform a "raw" load acquire, and then possibly keep it alive if necessary (G1 SATB enqueue barriers). To make life easier, there are some helpers for the most common access patterns that merely add some default decorator for the involved type of access. For example, there is a RawAccess for performing AS_RAW accesses (that bypasses runtime checks and GC barriers), HeapAccess sets the IN_HEAP decorator and RootAccess sets the IN_ROOT decorator for accessing root oops. So for the previous call, I could simply do: oop result = HeapAccess::oop_load_at(obj, offset); The access.hpp file introduces each decorator (belonging to some category) with an explanation what it is for. It also introduces all operations you can make with access (loads, stores, cmpxchg, xchg, arraycopy and clone). This changeset mostly introduces the Access API but is not complete in annotating the code more than where it gets very awkward if I don't. == Backend == For a GC maintainer, the BarrierSet::AccessBarrier is the top level backend that provides basic accesses that may be overridden. By default, it just performs raw accesses without any GC barriers, that handle things like compressed oops and memory ordering only. The ModRef barrier set introduces the notion of pre/post write barriers, that can be overridden for each GC. The CardTableModRef barrier set overrides the post write barrier to mark cards, and G1 overrides it to mark cards slightly differently and do some SATB enqueueing. G1 also overrides loads to see if we need to perform SATB enqueue on weak references. The raw accesses go to the RawAccessBarrier (living in accessBackend.hpp) that performs the actual accesses. It connects to Atomic and OrderAccess for accesses that require that. == Internals == Internally, the accesses go through a number of stages in access.inline.hpp as documented at the top. 1) set default decorators and get rid of CV qualifiers etc. Sanity checking also happens here: we check that the decorators make sense for the access being performed, and that the passed in types are not bogus. 2) reduce types so if we have a different type of the address and value, then either it is not allowed or it implies we use compressed oops and remember that we know something about whether compressed oops are used or not, before erasing address type 3) pre-runtime dispatch: figure out if all runtime checks can be bypassed into a raw access 4) runtime dispatch: send the access through a function pointer that upon the first invocation resolves the intended GC AccessBarrier accessor on the BarrierSet that handles this access, as well as figures out whether we are using compressed oops or not while we are at it, and then calls it through the post-runtime dispatch 5) post-runtime dispatch: fix some erased types that were not known at compile time such as whether the address is a narrowOop* or oop* depending on whether compressed oops was selected at runtime or not, and call the resolved BarrierSet::AccessBarrier accessor (load/store/etc) with all the call-site build-time and run-time resolved decorators and type information that describes the access. Testing: mach5 tier1-5 Thanks, /Erik From paul.sandoz at oracle.com Thu Nov 9 18:43:28 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 9 Nov 2017 10:43:28 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> References: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> Message-ID: <26336F4F-0A21-4A08-AFA3-23CA972CAD93@oracle.com> Hi, > On 9 Nov 2017, at 00:24, stanislav lukyanov wrote: > > Hi Paul, > > How about changing the name of the class to ConstantFactory to align > with its two siblings - LambdaMetafactory and StringConcatFactory? > I would prefer to keep it as is. It is intended to cover many forms of BSMs producing dynamic constants. LMF and SCF are very focused and there is some precedent that they may be called explicitly as factories where as for dynamic constants there is less motivation for this. > Other comments are purely about the spec text (should I be posting them in the CSR issue instead?) > > The class-level javadoc could use more text to describe the contents > (e.g. "Methods to facilitate creation of common kinds of dynamic constants...", similar to other bootstrap factories) > and motivation for having this class. I think giving the motivation here is important - it might be not obvious why, for example, > nullConstant is needed when there is aconst_null. > Maybe an example of an invokedynamic using static arguments that are dynamic constants (repeat the last six words together BTW!) > could also be there (javap- or jasm-style pseudocode for that?) I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don?t want that to side-track the review for the moment (including guidance on what forms of computed constants are acceptable). > Also, @author We don?t add @author. > and @since are missing. > Added. > All methods repeat the same NPE condition > @throws NullPointerException if any used argument is {@code null} > which looks especially strange in methods with one used parameter (e.g. nullConstant) > or with no unused parameters (e.g. getStaticFinal). > I'd suggest to instead go with the commonly used shortcut of declaring the NPE in the class-level Javadoc, e.g. > "Passing a null argument to a method in this class will cause of NullPointerException to be thrown, > unless the argument is specified to be unused, or unless otherwise noted?. I like that: *

The bootstrap methods in this class will throw a * {@code NullPointerException} for any reference argument that is {@code null}, * unless the argument is specified to be unused or specified to accept a * {@code null} value. And adjusted the invoke method: * @param args the arguments to pass to the method handle, as if with * {@link MethodHandle#invokeWithArguments}. Each argument may be * {@code null}. ... * @throws NullPointerException if {@code args} is {@code null} * (each argument of {@code args} may be {@code null}). We have been fleshing out the NPE behaviour because we know you will log bugs against us later on if we don?t :-) > The VarHandle methods have > @param type unused; must be {@code Class} > Looks like the "unused;" part should be removed. > Updated to: * @param type the required result type (must be {@code Class}) and added the null check. > On 9 Nov 2017, at 00:42, stanislav lukyanov wrote: > > I also noticed that Class::isPrimitive now says the following: > "These objects may only be accessed via the following public static final variables, and are the only Class objects for which this method returns true." > (the fields its talking about are the .TYPE) > Should this text be tweaked? I think it would be a distraction for most developers. The BSM is doing nothing special in regard to what isPrimitive specifies it just dynamically returns the value of the associated static field. Paul. From paul.sandoz at oracle.com Thu Nov 9 19:06:00 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 9 Nov 2017 11:06:00 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: References: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> Message-ID: Hi Volker, > On 9 Nov 2017, at 01:01, Volker Simonis wrote: > > Hi Paul, > > just some quick process-related questions. > > Is this intended to be targeted for jdk 10? > Yes, that?s what we are aiming for. I am front loading reviews ahead of a propose to target (which should hopefully happen soon) to make better use of time given the shorter cycles, thus increasing the quality and giving heads up to other developers like yourself who are responsible for other platforms. > Is the current implementation already available in a separate > repository and/or branch? I've read in the RFR for 8186046 that some > parts are currently being refined in the amber repository. Or is the > complete implementation already available there? > A super set of functionality is present in the amber repo under the condy branch. We pealed a sub-set of that off and created patches for the idk/hs repo tracked in: Minimal ConstantDynamic support https://bugs.openjdk.java.net/browse/JDK-8186046 Tool support for ConstantDynamic https://bugs.openjdk.java.net/browse/JDK-8186209 http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ Minimal set of bootstrap methods for dynamic constants https://bugs.openjdk.java.net/browse/JDK-8187742 http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ While these are under review they might diverge a little from the condy branch in the amber repo but i will sync back up in batches. > If I want to port this to ppc64, what's the best way to start and what > do I need? Is it just the two webrevs for 8187742 and 8186046 on top > of the jdk hs repo? Or is it a branch of the amber repo? > Yes, and focus on the following applied to the jdk/hs repo: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ There are tests in that patch that are currently targeted to run only on x86 that would otherwise tickle failures on other platforms. > You may know that there's currently a discussion going on about what > is a JEP and what's the right way to implement and integrate a JEP > into the mainline. The general idea is that only 'finished' JEPs will > be targeted and integrated into the always feature complete main line. > So is this and the review for 8186046 about the integration into the > jdk repo (which shouldn't happen before the JEP is not targeted for > jdk10) or is it just the review before the JEP can actually be > targeted? This is important because there's not much time before the > jdk10 repos will enter Rampdown phase 1 and we would still have to > port this to ppc (and also ARM/SPARC) if it will be targeted for jdk > 10. > > I don't want to question the merits and quality of the current > implementation which I'm sure are great. For me as an external > observer its just hard to oversee the current status of the > implementation. > I hear you, thanks for your patience. Is it a little clearer now? From my own perspective this is the first flight over the new release cycle territory, the ride might be a little bumpy while we learn to pilot this better :-) Paul. From chris.plummer at oracle.com Thu Nov 9 20:29:49 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 9 Nov 2017 12:29:49 -0800 Subject: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source Message-ID: <8a608fa8-eece-3aeb-1866-5ba75719c09b@oracle.com> Hi, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8191049 diff --git a/src/hotspot/share/utilities/debug.cpp b/src/hotspot/share/utilities/debug.cpp --- a/src/hotspot/share/utilities/debug.cpp +++ b/src/hotspot/share/utilities/debug.cpp @@ -631,6 +631,24 @@ ?? VMError::print_native_stack(tty, fr, t, buf, sizeof(buf)); ?} +// +// This version of pns() will not work when called from the debugger, but is +// useful when called from within hotspot code. The advantages over pns() +// are not having to pass in any arguments, and it will work on Windows/x64. +// +extern "C" void pns2() { // print native stack +? Command c("pns2"); +? static char buf[O_BUFLEN]; +? if (os::platform_print_native_stack(tty, NULL, buf, sizeof(buf))) { +??? // We have printed the native stack in platform-specific code, +??? // so nothing else to do in this case. +? } else { +??? Thread* t = Thread::current_or_null(); +??? frame fr = os::current_frame(); +??? VMError::print_native_stack(tty, fr, t, buf, sizeof(buf)); +? } +} + ?#endif // !PRODUCT There is also a pre-existing thread with some discussion: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html thanks, Chris From thomas.stuefe at gmail.com Fri Nov 10 08:11:04 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 10 Nov 2017 09:11:04 +0100 Subject: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source In-Reply-To: <8a608fa8-eece-3aeb-1866-5ba75719c09b@oracle.com> References: <8a608fa8-eece-3aeb-1866-5ba75719c09b@oracle.com> Message-ID: Hi Chris, looks fine as a debugging aid. But it occurred to me that it may be a bit dangerous to call this from non-errorhandler settings. I recall seeing quite a few secondary crashes in VMError::print_native_stack() in hs-err files over time. Especially for native non-java threads. Usually this did not matter that much because these crashes are handled by secondary error handling when printing the hs-err file. But if we call it outside of error handling, we are on our own. So. IMHO, to use this functions as a debugging aid is fine, if one can accept a slight risk of crashing the VM. If this is not acceptable, may we need some more tests for this function? Kind Regards, Thomas On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer wrote: > Hi, > > Please review the following: > > https://bugs.openjdk.java.net/browse/JDK-8191049 > > diff --git a/src/hotspot/share/utilities/debug.cpp > b/src/hotspot/share/utilities/debug.cpp > --- a/src/hotspot/share/utilities/debug.cpp > +++ b/src/hotspot/share/utilities/debug.cpp > @@ -631,6 +631,24 @@ > VMError::print_native_stack(tty, fr, t, buf, sizeof(buf)); > } > > +// > +// This version of pns() will not work when called from the debugger, but > is > +// useful when called from within hotspot code. The advantages over pns() > +// are not having to pass in any arguments, and it will work on > Windows/x64. > +// > +extern "C" void pns2() { // print native stack > + Command c("pns2"); > + static char buf[O_BUFLEN]; > + if (os::platform_print_native_stack(tty, NULL, buf, sizeof(buf))) { > + // We have printed the native stack in platform-specific code, > + // so nothing else to do in this case. > + } else { > + Thread* t = Thread::current_or_null(); > + frame fr = os::current_frame(); > + VMError::print_native_stack(tty, fr, t, buf, sizeof(buf)); > + } > +} > + > #endif // !PRODUCT > > There is also a pre-existing thread with some discussion: > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2 > 017-November/025134.html > > thanks, > > Chris > > From glaubitz at physik.fu-berlin.de Fri Nov 10 08:20:20 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 10 Nov 2017 09:20:20 +0100 Subject: Chasing changing repository locations Message-ID: <949df99d-f606-d0b1-c774-a8eb9f874030@physik.fu-berlin.de> Hello! I just noticed that the main development repository for OpenJDK has moved again from [1] to [2]. Can someone explain me what happened and why the repository was moved? I was a bit confused because I submitted a changeset, it got accepted and merged but my change didn't show up the old repository [1]. Then I searched around and found out it ended up in [2]. This is mildly annoying since I will now have to check out the repository again which takes quite some time on some of the development machines I use (not all of them are mine and some have a slower internet connection than others) and there is also the risk that I miss important changes and my changes conflict with changes already submitted in the moved repository. Is there a system behind the repositories moving around? And is there a way to track this easily, e.g. does Mercurial have any commands that are particularly useful in these situations? Is there maybe a way to add the new repository as a new remote in Mercurial similar to what can be done in git with "git remote" and then just fetch the changes from the new repository? Sorry if my questions seem a bit stupid, I'm just trying to understand the workflow behind the current systems :-). Thanks, Adrian > [1] http://hg.openjdk.java.net/jdk10/hs/ > [2] http://hg.openjdk.java.net/jdk/hs/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From per.liden at oracle.com Fri Nov 10 08:25:57 2017 From: per.liden at oracle.com (Per Liden) Date: Fri, 10 Nov 2017 09:25:57 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A048993.2000002@oracle.com> References: <5A048993.2000002@oracle.com> Message-ID: <2f2714c8-be17-d276-3592-4fb4621ed475@oracle.com> Looks good! Awesome work Erik! (I pre-reviewed this before Erik sent it out, so all my comments have already been taken care of) cheers, Per On 2017-11-09 18:00, Erik ?sterlund wrote: > Hi, > > In an effort to remove explicit calls to GC barriers (and other > orthogonal forms of barriers, like encoding/decoding oops for compressed > oops and fencing for memory ordering), I have built an API that I call > "Access". Its purpose is to perform accesses with declarative semantics, > to handle multiple orthogonal concerns that affect how an access is > performed, including memory ordering, compressed oops, GC barriers for > marking, reference strength, etc, and as a result making GCs more > modular, and as a result allow new concurrently compacting GC schemes > utilizing load barriers to live in harmony in hotspot without everyone > going crazy manually inserting barriers if UseBlahGC is enabled. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8189871 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ > > So there are three views of this I suppose: > > 1) The frontend: how this is actually used in shared code > 2) The backends: how anyone writing a GC sticks their required barriers > in there > 3) The internals: how accesses find their way from the frontend to the > corresponding backend > > == Frontend == > > Let's start with the frontend. I hope I made this fairly simple! You can > find it in runtime/access.hpp > Each access annotates its declarative semantics with a set of > "decorators", which is the name of the attributes/properties affecting > how an access is performed. > There is an Access API that makes the declarative semantics > possible. > > For example, if I want to perform a load acquire of an oop in the heap > that has "weak" strength, I would do something like: > oop result = Access ON_WEAK_OOP_REF>::oop_load_at(obj, offset); > > The Access API would then send the access through some GC backend, that > overrides the whole access and tells it to perform a "raw" load acquire, > and then possibly keep it alive if necessary (G1 SATB enqueue barriers). > > To make life easier, there are some helpers for the most common access > patterns that merely add some default decorator for the involved type of > access. For example, there is a RawAccess for performing AS_RAW accesses > (that bypasses runtime checks and GC barriers), HeapAccess sets the > IN_HEAP decorator and RootAccess sets the IN_ROOT decorator for > accessing root oops. So for the previous call, I could simply do: > > oop result = HeapAccess::oop_load_at(obj, > offset); > > The access.hpp file introduces each decorator (belonging to some > category) with an explanation what it is for. It also introduces all > operations you can make with access (loads, stores, cmpxchg, xchg, > arraycopy and clone). > > This changeset mostly introduces the Access API but is not complete in > annotating the code more than where it gets very awkward if I don't. > > == Backend == > > For a GC maintainer, the BarrierSet::AccessBarrier is the top level > backend that provides basic accesses that may be overridden. By default, > it just performs raw accesses without any GC barriers, that handle > things like compressed oops and memory ordering only. The ModRef barrier > set introduces the notion of pre/post write barriers, that can be > overridden for each GC. The CardTableModRef barrier set overrides the > post write barrier to mark cards, and G1 overrides it to mark cards > slightly differently and do some SATB enqueueing. G1 also overrides > loads to see if we need to perform SATB enqueue on weak references. > > The raw accesses go to the RawAccessBarrier (living in > accessBackend.hpp) that performs the actual accesses. It connects to > Atomic and OrderAccess for accesses that require that. > > == Internals == > > Internally, the accesses go through a number of stages in > access.inline.hpp as documented at the top. > > 1) set default decorators and get rid of CV qualifiers etc. Sanity > checking also happens here: we check that the decorators make sense for > the access being performed, and that the passed in types are not bogus. > 2) reduce types so if we have a different type of the address and value, > then either it is not allowed or it implies we use compressed oops and > remember that we know something about whether compressed oops are used > or not, before erasing address type > 3) pre-runtime dispatch: figure out if all runtime checks can be > bypassed into a raw access > 4) runtime dispatch: send the access through a function pointer that > upon the first invocation resolves the intended GC AccessBarrier > accessor on the BarrierSet that handles this access, as well as figures > out whether we are using compressed oops or not while we are at it, and > then calls it through the post-runtime dispatch > 5) post-runtime dispatch: fix some erased types that were not known at > compile time such as whether the address is a narrowOop* or oop* > depending on whether compressed oops was selected at runtime or not, and > call the resolved BarrierSet::AccessBarrier accessor (load/store/etc) > with all the call-site build-time and run-time resolved decorators and > type information that describes the access. > > Testing: mach5 tier1-5 > > Thanks, > /Erik From erik.osterlund at oracle.com Fri Nov 10 08:33:58 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 10 Nov 2017 09:33:58 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <2f2714c8-be17-d276-3592-4fb4621ed475@oracle.com> References: <5A048993.2000002@oracle.com> <2f2714c8-be17-d276-3592-4fb4621ed475@oracle.com> Message-ID: <5A056476.9050505@oracle.com> Hi Per, Thank you. :) /Erik On 2017-11-10 09:25, Per Liden wrote: > Looks good! Awesome work Erik! > > (I pre-reviewed this before Erik sent it out, so all my comments have > already been taken care of) > > cheers, > Per > > On 2017-11-09 18:00, Erik ?sterlund wrote: >> Hi, >> >> In an effort to remove explicit calls to GC barriers (and other >> orthogonal forms of barriers, like encoding/decoding oops for compressed >> oops and fencing for memory ordering), I have built an API that I call >> "Access". Its purpose is to perform accesses with declarative semantics, >> to handle multiple orthogonal concerns that affect how an access is >> performed, including memory ordering, compressed oops, GC barriers for >> marking, reference strength, etc, and as a result making GCs more >> modular, and as a result allow new concurrently compacting GC schemes >> utilizing load barriers to live in harmony in hotspot without everyone >> going crazy manually inserting barriers if UseBlahGC is enabled. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8189871 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ >> >> So there are three views of this I suppose: >> >> 1) The frontend: how this is actually used in shared code >> 2) The backends: how anyone writing a GC sticks their required barriers >> in there >> 3) The internals: how accesses find their way from the frontend to the >> corresponding backend >> >> == Frontend == >> >> Let's start with the frontend. I hope I made this fairly simple! You can >> find it in runtime/access.hpp >> Each access annotates its declarative semantics with a set of >> "decorators", which is the name of the attributes/properties affecting >> how an access is performed. >> There is an Access API that makes the declarative semantics >> possible. >> >> For example, if I want to perform a load acquire of an oop in the heap >> that has "weak" strength, I would do something like: >> oop result = Access> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >> >> The Access API would then send the access through some GC backend, that >> overrides the whole access and tells it to perform a "raw" load acquire, >> and then possibly keep it alive if necessary (G1 SATB enqueue barriers). >> >> To make life easier, there are some helpers for the most common access >> patterns that merely add some default decorator for the involved type of >> access. For example, there is a RawAccess for performing AS_RAW accesses >> (that bypasses runtime checks and GC barriers), HeapAccess sets the >> IN_HEAP decorator and RootAccess sets the IN_ROOT decorator for >> accessing root oops. So for the previous call, I could simply do: >> >> oop result = HeapAccess::oop_load_at(obj, >> offset); >> >> The access.hpp file introduces each decorator (belonging to some >> category) with an explanation what it is for. It also introduces all >> operations you can make with access (loads, stores, cmpxchg, xchg, >> arraycopy and clone). >> >> This changeset mostly introduces the Access API but is not complete in >> annotating the code more than where it gets very awkward if I don't. >> >> == Backend == >> >> For a GC maintainer, the BarrierSet::AccessBarrier is the top level >> backend that provides basic accesses that may be overridden. By default, >> it just performs raw accesses without any GC barriers, that handle >> things like compressed oops and memory ordering only. The ModRef barrier >> set introduces the notion of pre/post write barriers, that can be >> overridden for each GC. The CardTableModRef barrier set overrides the >> post write barrier to mark cards, and G1 overrides it to mark cards >> slightly differently and do some SATB enqueueing. G1 also overrides >> loads to see if we need to perform SATB enqueue on weak references. >> >> The raw accesses go to the RawAccessBarrier (living in >> accessBackend.hpp) that performs the actual accesses. It connects to >> Atomic and OrderAccess for accesses that require that. >> >> == Internals == >> >> Internally, the accesses go through a number of stages in >> access.inline.hpp as documented at the top. >> >> 1) set default decorators and get rid of CV qualifiers etc. Sanity >> checking also happens here: we check that the decorators make sense for >> the access being performed, and that the passed in types are not bogus. >> 2) reduce types so if we have a different type of the address and value, >> then either it is not allowed or it implies we use compressed oops and >> remember that we know something about whether compressed oops are used >> or not, before erasing address type >> 3) pre-runtime dispatch: figure out if all runtime checks can be >> bypassed into a raw access >> 4) runtime dispatch: send the access through a function pointer that >> upon the first invocation resolves the intended GC AccessBarrier >> accessor on the BarrierSet that handles this access, as well as figures >> out whether we are using compressed oops or not while we are at it, and >> then calls it through the post-runtime dispatch >> 5) post-runtime dispatch: fix some erased types that were not known at >> compile time such as whether the address is a narrowOop* or oop* >> depending on whether compressed oops was selected at runtime or not, and >> call the resolved BarrierSet::AccessBarrier accessor (load/store/etc) >> with all the call-site build-time and run-time resolved decorators and >> type information that describes the access. >> >> Testing: mach5 tier1-5 >> >> Thanks, >> /Erik From sgehwolf at redhat.com Fri Nov 10 09:05:23 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 10 Nov 2017 10:05:23 +0100 Subject: Chasing changing repository locations In-Reply-To: <949df99d-f606-d0b1-c774-a8eb9f874030@physik.fu-berlin.de> References: <949df99d-f606-d0b1-c774-a8eb9f874030@physik.fu-berlin.de> Message-ID: <1510304723.3910.3.camel@redhat.com> On Fri, 2017-11-10 at 09:20 +0100, John Paul Adrian Glaubitz wrote: > Hello! > > I just noticed that the main development repository for OpenJDK has moved > again from [1] to [2]. Can someone explain me what happened and why the > repository was moved? There was an effort to go from Mercurial forests to one consolidated repo: http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-June/000371.html http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000455.html [1] might have been a temporary place, I'm losing track :( [2] is the new place for new hotspot, AFAIK. It looks like [1] and [2] have the same layout. You might be able to add the new location via a new path by changing '.hg/hgrc'. Confirm with hg paths. $ hg paths default = http://hg.openjdk.java.net/jdk/hs HTH, Severin > I was a bit confused because I submitted a changeset, it got accepted and > merged but my change didn't show up the old repository [1]. Then I searched > around and found out it ended up in [2]. > > This is mildly annoying since I will now have to check out the repository > again which takes quite some time on some of the development machines I use > (not all of them are mine and some have a slower internet connection than > ?others) and there is also the risk that I miss important changes and my > changes conflict with changes already submitted in the moved repository. > > Is there a system behind the repositories moving around? And is there a way > to track this easily, e.g. does Mercurial have any commands that are particularly > useful in these situations? Is there maybe a way to add the new repository as > a new remote in Mercurial similar to what can be done in git with "git remote" > and then just fetch the changes from the new repository? > > Sorry if my questions seem a bit stupid, I'm just trying to understand the > workflow behind the current systems :-). > > Thanks, > Adrian > > > [1] http://hg.openjdk.java.net/jdk10/hs/ > > [2] http://hg.openjdk.java.net/jdk/hs/ > > From claes.redestad at oracle.com Fri Nov 10 09:16:30 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 10 Nov 2017 10:16:30 +0100 Subject: Chasing changing repository locations In-Reply-To: <1510304723.3910.3.camel@redhat.com> References: <949df99d-f606-d0b1-c774-a8eb9f874030@physik.fu-berlin.de> <1510304723.3910.3.camel@redhat.com> Message-ID: On 2017-11-10 10:05, Severin Gehwolf wrote: > On Fri, 2017-11-10 at 09:20 +0100, John Paul Adrian Glaubitz wrote: >> Hello! >> >> I just noticed that the main development repository for OpenJDK has moved >> again from [1] to [2]. Can someone explain me what happened and why the >> repository was moved? > There was an effort to go from Mercurial forests to one consolidated > repo: > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-June/000371.html > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-September/000455.html > > [1] might have been a temporary place, I'm losing track :( Somewhat orthogonal to the repo consolidation, the JDK 10 project has been replaced with the JDK project, and the new repository locations are (hopefully) permanent: http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-October/000551.html > > [2] is the new place for new hotspot, AFAIK. It looks like [1] and [2] > have the same layout. You might be able to add the new location via a > new path by changing '.hg/hgrc'. Confirm with hg paths. > > $ hg paths > default = http://hg.openjdk.java.net/jdk/hs Yes, changing .hg/hgrc worked fine for me. /Claes From stanislav.lukyanov at oracle.com Fri Nov 10 09:36:51 2017 From: stanislav.lukyanov at oracle.com (stanislav lukyanov) Date: Fri, 10 Nov 2017 15:06:51 +0530 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <26336F4F-0A21-4A08-AFA3-23CA972CAD93@oracle.com> References: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> <26336F4F-0A21-4A08-AFA3-23CA972CAD93@oracle.com> Message-ID: On 10.11.2017 0:13, Paul Sandoz wrote: > <...> > I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don?t want that to side-track the review for the moment (including guidance on what forms of computed constants are acceptable). Fair. Does it make sense to add a sub-task for this to JDK-8185992 to keep it on the radar? > <...> > > And adjusted the invoke method: > > * @param args the arguments to pass to the method handle, as if with > * {@link MethodHandle#invokeWithArguments}. Each argument may be > * {@code null}. > ... > * @throws NullPointerException if {@code args} is {@code null} > * (each argument of {@code args} may be {@code null}). I think the `@throws NPE` is not needed, at least not from the normative perspective. The class-level text about NPE doesn't assume anything about the contents of objects passed to the methods, and the second part of the `@param args` already clarifies the behavior for this particular case. Arguably having this `@throws` might improve clarity, but I would rather remove it. > > We have been fleshing out the NPE behaviour because we know you will log bugs against us later on if we don?t :-) Yep, that's sounds familiar :) <...> Thanks for the updates! Also, javac isn't going to use `::primitiveClass` instead of `getstatic Integer.TYPE` to load int.class, right? If it is, int.class probably needs to be changed to Integer.TYPE in sun.invoke.util.Wrapper to avoid cycles. Stas From muthusamy.chinnathambi at oracle.com Fri Nov 10 09:57:06 2017 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Fri, 10 Nov 2017 01:57:06 -0800 (PST) Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist In-Reply-To: <6e7c7f30-599d-4558-8c84-0360f0535cf4@default> References: <811da80f-e107-4d0c-903b-c109b592176e@default> <6e7c7f30-599d-4558-8c84-0360f0535cf4@default> Message-ID: <9e7f3290-8dd3-4ca0-a445-fd50ff389642@default> Hi, Can someone please review this. Thanks! Muthusamy C -----Original Message----- From: Muthusamy Chinnathambi Sent: Wednesday, November 8, 2017 11:24 AM To: Thomas St?fe Cc: Mikael Gerdin ; HotSpot Open Source Developers Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist Hi Thomas, ? > ?the webrev link seems to be dead. Sorry for the trouble. Please find the corrected link below http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ ? Somehow the line following the link got appended to the previous one leading to a dead link. ? Regards, Muthusamy C ? From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Tuesday, November 7, 2017 8:12 PM To: Muthusamy Chinnathambi Cc: HotSpot Open Source Developers ; Mikael Gerdin Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist ? Hi Muthusamy, ? the webrev link seems to be dead. ? ..Thomas ? On Tue, Nov 7, 2017 at 10:05 AM, Muthusamy Chinnathambi wrote: Hi, Please review the backport of bug: "JDK-8170395: Metaspace initialization queries the wrong chunk freelist" to jdk8u-dev Please note that this is not a clean backport due to new entries in debug.cpp and copyright changes. Webrev: HYPERLINK "http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9"http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8170395 Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e971a72675a Test:? Had run jtreg and jprt hotspot testsets. Regards, Muthusamy C ? From volker.simonis at gmail.com Fri Nov 10 10:37:43 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 10 Nov 2017 11:37:43 +0100 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: References: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> Message-ID: On Thu, Nov 9, 2017 at 8:06 PM, Paul Sandoz wrote: > Hi Volker, > >> On 9 Nov 2017, at 01:01, Volker Simonis wrote: >> >> Hi Paul, >> >> just some quick process-related questions. >> >> Is this intended to be targeted for jdk 10? >> > > Yes, that?s what we are aiming for. I am front loading reviews ahead of a propose to target (which should hopefully happen soon) to make better use of time given the shorter cycles, thus increasing the quality and giving heads up to other developers like yourself who are responsible for other platforms. > > >> Is the current implementation already available in a separate >> repository and/or branch? I've read in the RFR for 8186046 that some >> parts are currently being refined in the amber repository. Or is the >> complete implementation already available there? >> > > A super set of functionality is present in the amber repo under the condy branch. We pealed a sub-set of that off and created patches for the idk/hs repo tracked in: > > Minimal ConstantDynamic support > https://bugs.openjdk.java.net/browse/JDK-8186046 > Tool support for ConstantDynamic > https://bugs.openjdk.java.net/browse/JDK-8186209 > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ > > Minimal set of bootstrap methods for dynamic constants > https://bugs.openjdk.java.net/browse/JDK-8187742 > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webrev/ > > While these are under review they might diverge a little from the condy branch in the amber repo but i will sync back up in batches. > > >> If I want to port this to ppc64, what's the best way to start and what >> do I need? Is it just the two webrevs for 8187742 and 8186046 on top >> of the jdk hs repo? Or is it a branch of the amber repo? >> > > Yes, and focus on the following applied to the jdk/hs repo: > > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ > > There are tests in that patch that are currently targeted to run only on x86 that would otherwise tickle failures on other platforms. > > >> You may know that there's currently a discussion going on about what >> is a JEP and what's the right way to implement and integrate a JEP >> into the mainline. The general idea is that only 'finished' JEPs will >> be targeted and integrated into the always feature complete main line. >> So is this and the review for 8186046 about the integration into the >> jdk repo (which shouldn't happen before the JEP is not targeted for >> jdk10) or is it just the review before the JEP can actually be >> targeted? This is important because there's not much time before the >> jdk10 repos will enter Rampdown phase 1 and we would still have to >> port this to ppc (and also ARM/SPARC) if it will be targeted for jdk >> 10. >> >> I don't want to question the merits and quality of the current >> implementation which I'm sure are great. For me as an external >> observer its just hard to oversee the current status of the >> implementation. >> > > I hear you, thanks for your patience. Is it a little clearer now? > Thanks Paul! Things are much clearer now. I'll start looking at the changes required for ppc/s390. Regards, Volker > From my own perspective this is the first flight over the new release cycle territory, the ride might be a little bumpy while we learn to pilot this better :-) > > Paul. From david.holmes at oracle.com Fri Nov 10 12:08:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 Nov 2017 22:08:20 +1000 Subject: Chasing changing repository locations In-Reply-To: <949df99d-f606-d0b1-c774-a8eb9f874030@physik.fu-berlin.de> References: <949df99d-f606-d0b1-c774-a8eb9f874030@physik.fu-berlin.de> Message-ID: <5d0ad9a5-01aa-3529-5af1-ded1ae9d30ab@oracle.com> Hi Adrian, You need to make sure you're subscribed to the project email lists - it was jdk10-dev and now just jdk-dev at openjdk.java.net. Then you would have seen about all the changes to the repos. Check the archives for discussion: http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000087.html In theory they should never need to change again. ;-) Cheers, David On 10/11/2017 6:20 PM, John Paul Adrian Glaubitz wrote: > Hello! > > I just noticed that the main development repository for OpenJDK has moved > again from [1] to [2]. Can someone explain me what happened and why the > repository was moved? > > I was a bit confused because I submitted a changeset, it got accepted and > merged but my change didn't show up the old repository [1]. Then I searched > around and found out it ended up in [2]. > > This is mildly annoying since I will now have to check out the repository > again which takes quite some time on some of the development machines I use > (not all of them are mine and some have a slower internet connection than > others) and there is also the risk that I miss important changes and my > changes conflict with changes already submitted in the moved repository. > > Is there a system behind the repositories moving around? And is there a way > to track this easily, e.g. does Mercurial have any commands that are particularly > useful in these situations? Is there maybe a way to add the new repository as > a new remote in Mercurial similar to what can be done in git with "git remote" > and then just fetch the changes from the new repository? > > Sorry if my questions seem a bit stupid, I'm just trying to understand the > workflow behind the current systems :-). > > Thanks, > Adrian > >> [1] http://hg.openjdk.java.net/jdk10/hs/ >> [2] http://hg.openjdk.java.net/jdk/hs/ > From rkennke at redhat.com Fri Nov 10 15:01:12 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 10 Nov 2017 16:01:12 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A048993.2000002@oracle.com> References: <5A048993.2000002@oracle.com> Message-ID: <63c96b68-88a6-5104-c9fb-5105a77d3440@redhat.com> Hi Erik, This looks very good to me. It is likely that we'll need to extend it a little bit for Shenandoah, but I haven't got around to try that out yet, and will propose it when this patch percolated down to the Shenandoah project. Questions (I know I've asked some of it before in private discussions): - A BarrierSet needs to declare an AccessBarrier inner class. How does this get 'registered' with the Access dispatcher? - I see you use namespace. I haven't seen them anywhere else in Hotspot, so this looks quite unusual :-) Not that I am against it (I would probably advocate for using more of it), but have you considered alternatives that look more common Hotspot-style (e.g. declaring an all-static AccessInternal class)? - The dispatching machinery looks a bit over the top, and from the outskirts like a manual re-invention of virtual method dispatch. Couldn't we do the same stuff with the usual public interface / concrete implementation idioms? I am worried that adding just one method to the interface turns into a nightmare of wiring up stuff and adding tons of boilerplate to get it going. Not to mention the learning curve involved trying to make sense of what goes where. Other than that, I very much like what I see. Roman > Hi, > > In an effort to remove explicit calls to GC barriers (and other > orthogonal forms of barriers, like encoding/decoding oops for > compressed oops and fencing for memory ordering), I have built an API > that I call "Access". Its purpose is to perform accesses with > declarative semantics, to handle multiple orthogonal concerns that > affect how an access is performed, including memory ordering, > compressed oops, GC barriers for marking, reference strength, etc, and > as a result making GCs more modular, and as a result allow new > concurrently compacting GC schemes utilizing load barriers to live in > harmony in hotspot without everyone going crazy manually inserting > barriers if UseBlahGC is enabled. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8189871 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ > > So there are three views of this I suppose: > > 1) The frontend: how this is actually used in shared code > 2) The backends: how anyone writing a GC sticks their required > barriers in there > 3) The internals: how accesses find their way from the frontend to the > corresponding backend > > == Frontend == > > Let's start with the frontend. I hope I made this fairly simple! You > can find it in runtime/access.hpp > Each access annotates its declarative semantics with a set of > "decorators", which is the name of the attributes/properties affecting > how an access is performed. > There is an Access API that makes the declarative semantics > possible. > > For example, if I want to perform a load acquire of an oop in the heap > that has "weak" strength, I would do something like: > oop result = Access ON_WEAK_OOP_REF>::oop_load_at(obj, offset); > > The Access API would then send the access through some GC backend, > that overrides the whole access and tells it to perform a "raw" load > acquire, and then possibly keep it alive if necessary (G1 SATB enqueue > barriers). > > To make life easier, there are some helpers for the most common access > patterns that merely add some default decorator for the involved type > of access. For example, there is a RawAccess for performing AS_RAW > accesses (that bypasses runtime checks and GC barriers), HeapAccess > sets the IN_HEAP decorator and RootAccess sets the IN_ROOT decorator > for accessing root oops. So for the previous call, I could simply do: > > oop result = HeapAccess ON_WEAK_OOP_REF>::oop_load_at(obj, offset); > > The access.hpp file introduces each decorator (belonging to some > category) with an explanation what it is for. It also introduces all > operations you can make with access (loads, stores, cmpxchg, xchg, > arraycopy and clone). > > This changeset mostly introduces the Access API but is not complete in > annotating the code more than where it gets very awkward if I don't. > > == Backend == > > For a GC maintainer, the BarrierSet::AccessBarrier is the top level > backend that provides basic accesses that may be overridden. By > default, it just performs raw accesses without any GC barriers, that > handle things like compressed oops and memory ordering only. The > ModRef barrier set introduces the notion of pre/post write barriers, > that can be overridden for each GC. The CardTableModRef barrier set > overrides the post write barrier to mark cards, and G1 overrides it to > mark cards slightly differently and do some SATB enqueueing. G1 also > overrides loads to see if we need to perform SATB enqueue on weak > references. > > The raw accesses go to the RawAccessBarrier (living in > accessBackend.hpp) that performs the actual accesses. It connects to > Atomic and OrderAccess for accesses that require that. > > == Internals == > > Internally, the accesses go through a number of stages in > access.inline.hpp as documented at the top. > > 1) set default decorators and get rid of CV qualifiers etc. Sanity > checking also happens here: we check that the decorators make sense > for the access being performed, and that the passed in types are not > bogus. > 2) reduce types so if we have a different type of the address and > value, then either it is not allowed or it implies we use compressed > oops and remember that we know something about whether compressed oops > are used or not, before erasing address type > 3) pre-runtime dispatch: figure out if all runtime checks can be > bypassed into a raw access > 4) runtime dispatch: send the access through a function pointer that > upon the first invocation resolves the intended GC AccessBarrier > accessor on the BarrierSet that handles this access, as well as > figures out whether we are using compressed oops or not while we are > at it, and then calls it through the post-runtime dispatch > 5) post-runtime dispatch: fix some erased types that were not known at > compile time such as whether the address is a narrowOop* or oop* > depending on whether compressed oops was selected at runtime or not, > and call the resolved BarrierSet::AccessBarrier accessor > (load/store/etc) with all the call-site build-time and run-time > resolved decorators and type information that describes the access. > > Testing: mach5 tier1-5 > > Thanks, > /Erik From erik.osterlund at oracle.com Fri Nov 10 16:29:04 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 10 Nov 2017 17:29:04 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <63c96b68-88a6-5104-c9fb-5105a77d3440@redhat.com> References: <5A048993.2000002@oracle.com> <63c96b68-88a6-5104-c9fb-5105a77d3440@redhat.com> Message-ID: <5A05D3D0.9040707@oracle.com> Hi Roman, On 2017-11-10 16:01, Roman Kennke wrote: > Hi Erik, > > This looks very good to me. It is likely that we'll need to extend it > a little bit for Shenandoah, but I haven't got around to try that out > yet, and will propose it when this patch percolated down to the > Shenandoah project. Yes. The framework should be quite flexible, and of course I will work with you on anything that needs to be updated. > Questions (I know I've asked some of it before in private discussions): > - A BarrierSet needs to declare an AccessBarrier inner class. How does > this get 'registered' with the Access dispatcher? Good question. Each new GC is tied together at one single point. The Access API picks up GCs from the gc/shared/barrierSetConfig.hpp and .inline.hpp files. So to register a new GC, such as Shenandoah, you have to: 1) Make sure you have a BarrierSet enum value which is added to the list of FOR_EACH_BARRIER_SET_DO as well as FOR_EACH_CONCRETE_BARRIER_SET_DO in barrierSetConfig.hpp. The first of said lists contains all barrier sets that are known to exist at build time, and the second of said lists crucially contains concrete barrier sets that have an AccessBarrier to resolve. 2) You also need to make sure in the barrierSetConfig.inline.hpp file that you #include your shenandoah BarrierSet inline.hpp file. 3) You have to provide a specialization for the BarrierSet::GetName and BarrierSet::GetType metafunctions that provide an enum value for a barrier set type, and vice versa. 4) Since you probably want primitive accesses in the heap to also resolve into the barrier set in a build that includes Shenandoah, you should #define SUPPORT_BARRIER_ON_PRIMITIVES in the barrierSetConfig.hpp file when building with Shenandoah. This will flick on the INTERNAL_BT_BARRIER_ON_PRIMITIVES decorator to each access so that the Access framework understands that even primitive accesses must be resolved at run-time in the barrier set. So this is a build-time switch for turning on run-time resolution of primitive accesses in the heap. And now you should be set: your new ShenandoahBarrierSet::AccessBarrier will be called for each access, including primitives. It works the following way: 1) The barrier resolver loads the current barrier set, and checks the "name" of it (the enum value). 2) Each "name" for concrete barriers that you listed in barrierSetConfig.hpp is asked for... 3) ...the BarrierSet::GetType of that enum "name", and... 4) The AccessBarrier of that resulting BarrierSet (your ShenandoahBarrierSet) will be called. Hope that makes sense. > - I see you use namespace. I haven't seen them anywhere else in > Hotspot, so this looks quite unusual :-) Not that I am against it (I > would probably advocate for using more of it), but have you considered > alternatives that look more common Hotspot-style (e.g. declaring an > all-static AccessInternal class)? We do not have any platform that has problems with namespaces. So I would prefer this basic namespace usage to a bunch of AllStatic classes. I hope nobody minds that. > - The dispatching machinery looks a bit over the top, and from the > outskirts like a manual re-invention of virtual method dispatch. > Couldn't we do the same stuff with the usual public interface / > concrete implementation idioms? I am worried that adding just one > method to the interface turns into a nightmare of wiring up stuff and > adding tons of boilerplate to get it going. Not to mention the > learning curve involved trying to make sense of what goes where. It's not quite like a normal virtual call though. It's a virtual dispatch that carries template parameters through the runtime dispatch. The template parameters are required for 1) remembering the decorators (semantics of the access), and 2) the type information of the operands for the access. In my experience, when you need to drag template parameters through some form of virtual dispatch, it is easiest to use function pointers and not virtual calls. I understand it might look a bit complicated, but I hope that is okay. > Other than that, I very much like what I see. I'm glad to hear it! Thanks, /Erik > Roman > >> Hi, >> >> In an effort to remove explicit calls to GC barriers (and other >> orthogonal forms of barriers, like encoding/decoding oops for >> compressed oops and fencing for memory ordering), I have built an API >> that I call "Access". Its purpose is to perform accesses with >> declarative semantics, to handle multiple orthogonal concerns that >> affect how an access is performed, including memory ordering, >> compressed oops, GC barriers for marking, reference strength, etc, >> and as a result making GCs more modular, and as a result allow new >> concurrently compacting GC schemes utilizing load barriers to live in >> harmony in hotspot without everyone going crazy manually inserting >> barriers if UseBlahGC is enabled. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8189871 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ >> >> So there are three views of this I suppose: >> >> 1) The frontend: how this is actually used in shared code >> 2) The backends: how anyone writing a GC sticks their required >> barriers in there >> 3) The internals: how accesses find their way from the frontend to >> the corresponding backend >> >> == Frontend == >> >> Let's start with the frontend. I hope I made this fairly simple! You >> can find it in runtime/access.hpp >> Each access annotates its declarative semantics with a set of >> "decorators", which is the name of the attributes/properties >> affecting how an access is performed. >> There is an Access API that makes the declarative >> semantics possible. >> >> For example, if I want to perform a load acquire of an oop in the >> heap that has "weak" strength, I would do something like: >> oop result = Access> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >> >> The Access API would then send the access through some GC backend, >> that overrides the whole access and tells it to perform a "raw" load >> acquire, and then possibly keep it alive if necessary (G1 SATB >> enqueue barriers). >> >> To make life easier, there are some helpers for the most common >> access patterns that merely add some default decorator for the >> involved type of access. For example, there is a RawAccess for >> performing AS_RAW accesses (that bypasses runtime checks and GC >> barriers), HeapAccess sets the IN_HEAP decorator and RootAccess sets >> the IN_ROOT decorator for accessing root oops. So for the previous >> call, I could simply do: >> >> oop result = HeapAccess> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >> >> The access.hpp file introduces each decorator (belonging to some >> category) with an explanation what it is for. It also introduces all >> operations you can make with access (loads, stores, cmpxchg, xchg, >> arraycopy and clone). >> >> This changeset mostly introduces the Access API but is not complete >> in annotating the code more than where it gets very awkward if I don't. >> >> == Backend == >> >> For a GC maintainer, the BarrierSet::AccessBarrier is the top level >> backend that provides basic accesses that may be overridden. By >> default, it just performs raw accesses without any GC barriers, that >> handle things like compressed oops and memory ordering only. The >> ModRef barrier set introduces the notion of pre/post write barriers, >> that can be overridden for each GC. The CardTableModRef barrier set >> overrides the post write barrier to mark cards, and G1 overrides it >> to mark cards slightly differently and do some SATB enqueueing. G1 >> also overrides loads to see if we need to perform SATB enqueue on >> weak references. >> >> The raw accesses go to the RawAccessBarrier (living in >> accessBackend.hpp) that performs the actual accesses. It connects to >> Atomic and OrderAccess for accesses that require that. >> >> == Internals == >> >> Internally, the accesses go through a number of stages in >> access.inline.hpp as documented at the top. >> >> 1) set default decorators and get rid of CV qualifiers etc. Sanity >> checking also happens here: we check that the decorators make sense >> for the access being performed, and that the passed in types are not >> bogus. >> 2) reduce types so if we have a different type of the address and >> value, then either it is not allowed or it implies we use compressed >> oops and remember that we know something about whether compressed >> oops are used or not, before erasing address type >> 3) pre-runtime dispatch: figure out if all runtime checks can be >> bypassed into a raw access >> 4) runtime dispatch: send the access through a function pointer that >> upon the first invocation resolves the intended GC AccessBarrier >> accessor on the BarrierSet that handles this access, as well as >> figures out whether we are using compressed oops or not while we are >> at it, and then calls it through the post-runtime dispatch >> 5) post-runtime dispatch: fix some erased types that were not known >> at compile time such as whether the address is a narrowOop* or oop* >> depending on whether compressed oops was selected at runtime or not, >> and call the resolved BarrierSet::AccessBarrier accessor >> (load/store/etc) with all the call-site build-time and run-time >> resolved decorators and type information that describes the access. >> >> Testing: mach5 tier1-5 >> >> Thanks, >> /Erik > > From gnormington at pivotal.io Fri Nov 10 17:06:11 2017 From: gnormington at pivotal.io (Glyn Normington) Date: Fri, 10 Nov 2017 17:06:11 +0000 Subject: Determining "GC" memory area size Message-ID: tl;dr: How is the size of the "GC" memory area (as reported by NMT) determined? The open source project I work on is running Java applications in Linux containers which result in processes being killed when the container's defined memory size, essentially in terms of pages of RAM, is exceeded. When this happens, users don't get any reasonable feedback to know whether the heap, metaspace, etc. is the problem and what to do about it. We have two components which attempt to help with this situation: 1. Java memory calculator ( https://github.com/cloudfoundry/java-buildpack-memory-calculator) This takes the container memory size together with an estimate of the number of loaded classes and threads consumed by the application and sets various JVM memory settings such as heap, metaspace, etc. The goal is to prevent the JVM from using more memory than the container has available, so that container OOM does not occur and if the JVM runs out of memory, it does so in a diagnosable way. 2. jvmkill JVMTI agent (https://github.com/cloudfoundry/jvmkill) When the JVM hits a resource exhaustion event, due either to lack of memory or threads, this agent prints various diagnostics to help the user decide what needs to be done to avoid the problem in future. If a threshold is exceeded, the agent then kills the JVM, otherwise the agent returns to the JVM and allows OutOfMemoryError to be thrown. One of our users recently found (see [1] below for details) that the memory calculator is not taking the "GC" memory area into account. Consequently, a JVM can exceed the container's memory size which means the user doesn't get any helpful diagnostics from either jvmkill or an OutOfMemoryError. Using NMT, the user observed that "GC" memory seems to be about 5% of the heap size for heaps of a few GB in size. Can anyone here tell me how the GC memory area size is determined? If there is documentation, so much the better as we'd prefer not to depend on code details that might flux arbitrarily. -- Regards, Glyn PS. Apologies for cross-posting this from hotspot-gc-use - got no reply there. From shade at redhat.com Fri Nov 10 18:39:40 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 Nov 2017 19:39:40 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A05D3D0.9040707@oracle.com> References: <5A048993.2000002@oracle.com> <63c96b68-88a6-5104-c9fb-5105a77d3440@redhat.com> <5A05D3D0.9040707@oracle.com> Message-ID: <21439be5-f96e-29af-98ba-adc40156bcba@redhat.com> On 11/10/2017 05:29 PM, Erik ?sterlund wrote: > 1) The barrier resolver loads the current barrier set, and checks the "name" of it (the enum value). > 2) Each "name" for concrete barriers that you listed in barrierSetConfig.hpp is asked for... > 3) ...the BarrierSet::GetType of that enum "name", and... > 4) The AccessBarrier of that resulting BarrierSet (your ShenandoahBarrierSet) will be called. So, I tried a simpler exercise with Epsilon, and it seems to work: http://cr.openjdk.java.net/~shade/epsilon/gc-barriers-declarative.patch A few comments from that exercise: *) After the recent BS cleanup, the EpsilonBarrierSet has only a few leftovers [1]. With current patch, write_ref_field_work seems to be gone. But write_ref_array_work and write_region_work are still used. This removal is deliberately not handled in current patch, right? *) What is the meaning of AccesssBarrier::Raw like these? typedef BarrierSet::AccessBarrier Raw; I am asking because it is not unclear if BS should typedef this. Epsilon seems to work fine without the declaration. G1SATBCardTableLoggingModRefBS::AccessBarrier has it, but CardTableModRefBS::AccessBarrier has not. Thanks, -Aleksey [1] http://hg.openjdk.java.net/jdk/sandbox/file/b2b4df384c83/src/hotspot/share/gc/epsilon/epsilonBarrierSet.hpp From shade at redhat.com Fri Nov 10 18:47:11 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 Nov 2017 19:47:11 +0100 Subject: Determining "GC" memory area size In-Reply-To: References: Message-ID: On 11/10/2017 06:06 PM, Glyn Normington wrote: > Can anyone here tell me how the GC memory area size is determined? If there > is documentation, so much the better as we'd prefer not to depend on code > details that might flux arbitrarily. NMT reports all allocations from GC code (with mtGC tag) as "GC". This includes, notably, Java heap itself, and all auxiliary GC data structures. If you grep the OpenJDK source for "mtGC", you can get the idea what allocations are tagged. Also, "detailed" NMT mode would give you allocation stacks, which can also give some insight what those particular allocated bits are coming from. The size of GC data structures is dependent on GC in question (and, quite probably, depends on GC implementation *version*, with swings back and forth), and thus is not trivially deducible. For simpler collectors, like Serial and Parallel, it would probably be dominated by Card Table (1/512-th of heap size). In G1, it is most probably mark bitmaps (2/64-th of heap size), plus other fine-grained remembered sets (which might get large, but maybe there is a high bound?). Etc. Thanks, -Aleksey From zgu at redhat.com Fri Nov 10 19:05:48 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 10 Nov 2017 14:05:48 -0500 Subject: Determining "GC" memory area size In-Reply-To: References: Message-ID: <2785c077-d8a6-b22b-19ef-a6f0e82d025c@redhat.com> Hi Glyn, > > Can anyone here tell me how the GC memory area size is determined? If there > is documentation, so much the better as we'd prefer not to depend on code > details that might flux arbitrarily. > GC memory is mainly data structures used by GC runtime. It can be varied by collector used, size of the Java heap, the number of GC threads and etc. and, of course, the application itself. Some are *fixed* costs, which can be estimated. E.g. two marking bitmaps used by G1, each costs 1/64 of heap size (assuming default object alignment). Some are *semi-fixed*, e.g. taskqueue's fixed cost is about 1M for each queue on 64-bits VM, but it can overflow. And the number of task queues is proportional to the number of GC threads. Then there are factors from application itself, such as object mutation rate, inter-generation/region references, etc. I don't see a single formula for estimating GC memory size. If you are using G1, the biggest overhead comes from 2 bitmaps (1/32 * heap size). Thanks, -Zhengyu From zgu at redhat.com Fri Nov 10 19:11:21 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 10 Nov 2017 14:11:21 -0500 Subject: Determining "GC" memory area size In-Reply-To: References: Message-ID: On 11/10/2017 01:47 PM, Aleksey Shipilev wrote: > On 11/10/2017 06:06 PM, Glyn Normington wrote: >> Can anyone here tell me how the GC memory area size is determined? If there >> is documentation, so much the better as we'd prefer not to depend on code >> details that might flux arbitrarily. > > NMT reports all allocations from GC code (with mtGC tag) as "GC". This includes, notably, Java heap > itself, and all auxiliary GC data structures. If you grep the OpenJDK source for "mtGC", you can get > the idea what allocations are tagged. Also, "detailed" NMT mode would give you allocation stacks, > which can also give some insight what those particular allocated bits are coming from. Java heap actually is *not* tagged as GC memory, but Java heap. -Zhengyu > > The size of GC data structures is dependent on GC in question (and, quite probably, depends on GC > implementation *version*, with swings back and forth), and thus is not trivially deducible. For > simpler collectors, like Serial and Parallel, it would probably be dominated by Card Table (1/512-th > of heap size). In G1, it is most probably mark bitmaps (2/64-th of heap size), plus other > fine-grained remembered sets (which might get large, but maybe there is a high bound?). Etc. > > Thanks, > -Aleksey > > From shade at redhat.com Fri Nov 10 19:12:34 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 Nov 2017 20:12:34 +0100 Subject: Determining "GC" memory area size In-Reply-To: References: Message-ID: <0d389053-2f64-6c5a-a885-2c398bd3ceac@redhat.com> On 11/10/2017 08:11 PM, Zhengyu Gu wrote: > > > On 11/10/2017 01:47 PM, Aleksey Shipilev wrote: >> On 11/10/2017 06:06 PM, Glyn Normington wrote: >>> Can anyone here tell me how the GC memory area size is determined? If there >>> is documentation, so much the better as we'd prefer not to depend on code >>> details that might flux arbitrarily. >> >> NMT reports all allocations from GC code (with mtGC tag) as "GC". This includes, notably, Java heap >> itself, and all auxiliary GC data structures. If you grep the OpenJDK source for "mtGC", you can get >> the idea what allocations are tagged. Also, "detailed" NMT mode would give you allocation stacks, >> which can also give some insight what those particular allocated bits are coming from. > > Java heap actually is *not* tagged as GC memory, but Java heap. Right. Sorry for the confusion. -Aleksey From per.liden at oracle.com Fri Nov 10 21:22:53 2017 From: per.liden at oracle.com (Per Liden) Date: Fri, 10 Nov 2017 22:22:53 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <21439be5-f96e-29af-98ba-adc40156bcba@redhat.com> References: <5A048993.2000002@oracle.com> <63c96b68-88a6-5104-c9fb-5105a77d3440@redhat.com> <5A05D3D0.9040707@oracle.com> <21439be5-f96e-29af-98ba-adc40156bcba@redhat.com> Message-ID: <48c618bc-5637-e536-15cf-f8638a6d467e@oracle.com> On 11/10/2017 07:39 PM, Aleksey Shipilev wrote: > On 11/10/2017 05:29 PM, Erik ?sterlund wrote: >> 1) The barrier resolver loads the current barrier set, and checks the "name" of it (the enum value). >> 2) Each "name" for concrete barriers that you listed in barrierSetConfig.hpp is asked for... >> 3) ...the BarrierSet::GetType of that enum "name", and... >> 4) The AccessBarrier of that resulting BarrierSet (your ShenandoahBarrierSet) will be called. > > So, I tried a simpler exercise with Epsilon, and it seems to work: > http://cr.openjdk.java.net/~shade/epsilon/gc-barriers-declarative.patch > > A few comments from that exercise: > > *) After the recent BS cleanup, the EpsilonBarrierSet has only a few leftovers [1]. With current > patch, write_ref_field_work seems to be gone. But write_ref_array_work and write_region_work are > still used. This removal is deliberately not handled in current patch, right? Correct, those will be removed in one of Erik's later patches. > > *) What is the meaning of AccesssBarrier::Raw like these? > typedef BarrierSet::AccessBarrier Raw; That's a convenience typedef for use when you want to call the super class to do raw accesses (i.e. access without GC barriers, other than potentially encode/decode oops), which you'd typically do inside AccessBarrier functions for a specific BarrierSet, where those calls are sandwiched in-between the GC specific barrier logic. > > I am asking because it is not unclear if BS should typedef this. Epsilon seems to work fine > without the declaration. G1SATBCardTableLoggingModRefBS::AccessBarrier has it, but > CardTableModRefBS::AccessBarrier has not. In Epsilon you don't needed it since you have no barriers. All you are doing is just raw accesses which is the default behavior offered by the super class. cheers, Per > > Thanks, > -Aleksey > > [1] > http://hg.openjdk.java.net/jdk/sandbox/file/b2b4df384c83/src/hotspot/share/gc/epsilon/epsilonBarrierSet.hpp > From thomas.stuefe at gmail.com Fri Nov 10 21:27:37 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 10 Nov 2017 21:27:37 +0000 Subject: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source In-Reply-To: References: <8a608fa8-eece-3aeb-1866-5ba75719c09b@oracle.com> Message-ID: Hi Chris, Thank you. Yes, a comment may make sense, and/or restricting this function to not product. Otherwise the change is fine and useful, I?ll use it probably before long. Thanks, Thomas On Fri 10. Nov 2017 at 21:55, Chris Plummer wrote: > Hi Thomas, > > There's certainly no intent to leave in place any calls someone might add > to pns2(). It's meant as a temporary debugging aide only. So if it were to > fail for any reason, IMO that's no different than adding any other sort of > temporary debugging code that could possibly crash. You fix your mistake > and resume your debugging. If you want I can add comments that include such > a warning. > > thanks, > > Chris > > > > On 11/10/17 12:11 AM, Thomas St?fe wrote: > > Hi Chris, > > looks fine as a debugging aid. > > But it occurred to me that it may be a bit dangerous to call this from > non-errorhandler settings. I recall seeing quite a few secondary crashes in > VMError::print_native_stack() in hs-err files over time. Especially for > native non-java threads. Usually this did not matter that much because > these crashes are handled by secondary error handling when printing the > hs-err file. But if we call it outside of error handling, we are on our own. > > So. IMHO, to use this functions as a debugging aid is fine, if one can > accept a slight risk of crashing the VM. If this is not acceptable, may we > need some more tests for this function? > > Kind Regards, Thomas > > > > On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer > wrote: > >> Hi, >> >> Please review the following: >> >> https://bugs.openjdk.java.net/browse/JDK-8191049 >> >> diff --git a/src/hotspot/share/utilities/debug.cpp >> b/src/hotspot/share/utilities/debug.cpp >> --- a/src/hotspot/share/utilities/debug.cpp >> +++ b/src/hotspot/share/utilities/debug.cpp >> @@ -631,6 +631,24 @@ >> VMError::print_native_stack(tty, fr, t, buf, sizeof(buf)); >> } >> >> +// >> +// This version of pns() will not work when called from the debugger, >> but is >> +// useful when called from within hotspot code. The advantages over pns() >> +// are not having to pass in any arguments, and it will work on >> Windows/x64. >> +// >> +extern "C" void pns2() { // print native stack >> + Command c("pns2"); >> + static char buf[O_BUFLEN]; >> + if (os::platform_print_native_stack(tty, NULL, buf, sizeof(buf))) { >> + // We have printed the native stack in platform-specific code, >> + // so nothing else to do in this case. >> + } else { >> + Thread* t = Thread::current_or_null(); >> + frame fr = os::current_frame(); >> + VMError::print_native_stack(tty, fr, t, buf, sizeof(buf)); >> + } >> +} >> + >> #endif // !PRODUCT >> >> There is also a pre-existing thread with some discussion: >> >> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html >> >> thanks, >> >> Chris >> >> > > From me at md-5.net Fri Nov 10 21:30:05 2017 From: me at md-5.net (Michael Dardis) Date: Fri, 10 Nov 2017 21:30:05 +0000 Subject: RFR (M): 8188224: Generalize Atomic::load/store to use templates In-Reply-To: References: Message-ID: <0100015fa7d6fb8b-19f177b2-2399-4666-8633-f297a391338b-000000@email.amazonses.com> Hi Erik et al, Since this commit I am having trouble building the project on 64 bit Windows (though Linux works fine). I was wondering whether anyone else has experienced this issue, or on the contrary whether someone can report a success. The revision immediately preceding this builds fine, but the current tip does not. I have copied the relevant error below - looks like a missing implementation of 8 byte atomic store, but I cannot work the template magic to figure out if it really is missing or something else is going on. Thanks Michael c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): error C2027: use of undefined type 'Atomic::StoreImpl,void>' with [*** [lib/CompileGtest.gmk:67: /cygdrive/c/openjdk/OpenJDK/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/gtest/objs/BUILD_GTEST_LIBJVM_pch.obj] Error 1 T=ClassPathEntry *, D=ClassPathEntry * ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): note: see declaration of 'Atomic::StoreImpl,void>' with [make/Main.gmk:268: hotspot-server-libs] Error 2 [*** Waiting for unfinished jobs.... T=ClassPathEntry *, D=ClassPathEntry * ] c:\openjdk\OpenJDK\src\hotspot\share\classfile/classLoader.hpp(55): note: see reference to function template instantiation 'void OrderAccess::release_store(volatile D *,T)' being compiled with [ D=ClassPathEntry *, T=ClassPathEntry * ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): error C2027: use of undefined type 'Atomic::StoreImpl,void>' with [ T=MethodData *, D=MethodData * ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): note: see declaration of 'Atomic::StoreImpl,void>' with [ T=MethodData *, D=MethodData * ] c:\openjdk\OpenJDK\src\hotspot\share\oops/method.hpp(340): note: see reference to function template instantiation 'void OrderAccess::release_store(volatile D *,T)' being compiled with [ D=MethodData *, T=MethodData * ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): error C2027: use of undefined type 'Atomic::StoreImpl,void>' with [ T=ExceptionCache *, D=ExceptionCache * ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): note: see declaration of 'Atomic::StoreImpl,void>' with [ T=ExceptionCache *, D=ExceptionCache * ] c:\openjdk\OpenJDK\src\hotspot\share\code/compiledMethod.hpp(291): note: see reference to function template instantiation 'void OrderAccess::release_store(volatile D *,T)' being compiled with [ D=ExceptionCache *, T=ExceptionCache * ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): error C2027: use of undefined type 'Atomic::StoreImpl,void>' with [ T=markOop, D=markOop ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): note: see declaration of 'Atomic::StoreImpl,void>' with [ T=markOop, D=markOop ] c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(93): note: see reference to function template instantiation 'void OrderAccess::release_store(volatile D *,T)' being compiled with [ D=markOop, T=markOop ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): error C2027: use of undefined type 'Atomic::StoreImpl,void>' with [ T=Klass *, D=Klass * ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): note: see declaration of 'Atomic::StoreImpl,void>' with [ T=Klass *, D=Klass * ] c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(164): note: see reference to function template instantiation 'void OrderAccess::release_store(volatile D *,T)' being compiled with [ D=Klass *, T=Klass * ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): error C2027: use of undefined type 'Atomic::StoreImpl,void>' with [ T=oop, D=oop ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): note: see declaration of 'Atomic::StoreImpl,void>' with [ T=oop, D=oop ] c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(364): note: see reference to function template instantiation 'void OrderAccess::release_store(volatile D *,T)' being compiled with [ D=oop, T=oop ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): error C2027: use of undefined type 'Atomic::StoreImpl,void>' with [ T=Metadata *, D=Metadata * ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): note: see declaration of 'Atomic::StoreImpl,void>' with [ T=Metadata *, D=Metadata * ] c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(454): note: see reference to function template instantiation 'void OrderAccess::release_store(volatile D *,T)' being compiled with [ D=Metadata *, T=Metadata * ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): error C2027: use of undefined type 'Atomic::StoreImpl,void>' with [ T=address, D=address ] c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): note: see declaration of 'Atomic::StoreImpl,void>' with [ T=address, D=address ] c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(522): note: see reference to function template instantiation 'void OrderAccess::release_store(volatile D *,T)' being compiled with [ D=address, T=address ] From yumin.qi at gmail.com Fri Nov 10 21:45:46 2017 From: yumin.qi at gmail.com (yumin qi) Date: Fri, 10 Nov 2017 13:45:46 -0800 Subject: Determining "GC" memory area size In-Reply-To: References: Message-ID: Hi, Glyn http://openjdk.java.net/jeps/8182070 Upon its implementation, Java can get information of container and confiture its own parameters for running in the container, more container friendly. Yumin On Fri, Nov 10, 2017 at 11:11 AM, Zhengyu Gu wrote: > > > On 11/10/2017 01:47 PM, Aleksey Shipilev wrote: > >> On 11/10/2017 06:06 PM, Glyn Normington wrote: >> >>> Can anyone here tell me how the GC memory area size is determined? If >>> there >>> is documentation, so much the better as we'd prefer not to depend on code >>> details that might flux arbitrarily. >>> >> >> NMT reports all allocations from GC code (with mtGC tag) as "GC". This >> includes, notably, Java heap >> itself, and all auxiliary GC data structures. If you grep the OpenJDK >> source for "mtGC", you can get >> the idea what allocations are tagged. Also, "detailed" NMT mode would >> give you allocation stacks, >> which can also give some insight what those particular allocated bits are >> coming from. >> > > Java heap actually is *not* tagged as GC memory, but Java heap. > > -Zhengyu > > >> The size of GC data structures is dependent on GC in question (and, quite >> probably, depends on GC >> implementation *version*, with swings back and forth), and thus is not >> trivially deducible. For >> simpler collectors, like Serial and Parallel, it would probably be >> dominated by Card Table (1/512-th >> of heap size). In G1, it is most probably mark bitmaps (2/64-th of heap >> size), plus other >> fine-grained remembered sets (which might get large, but maybe there is a >> high bound?). Etc. >> >> Thanks, >> -Aleksey >> >> >> From david.holmes at oracle.com Sat Nov 11 00:02:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 11 Nov 2017 10:02:47 +1000 Subject: RFR (M): 8188224: Generalize Atomic::load/store to use templates In-Reply-To: <0100015fa7d6fb8b-19f177b2-2399-4666-8633-f297a391338b-000000@email.amazonses.com> References: <0100015fa7d6fb8b-19f177b2-2399-4666-8633-f297a391338b-000000@email.amazonses.com> Message-ID: <5ee78595-9639-2b6f-9d8f-656f09b42859@oracle.com> Hi Michael, On 11/11/2017 7:30 AM, Michael Dardis wrote: > Hi Erik et al, > > Since this commit I am having trouble building the project on 64 bit > Windows (though Linux works fine). > I was wondering whether anyone else has experienced this issue, or on the > contrary whether someone can report a success. We have no problems building on any of our supported platforms. :) What version of Visual Studio are you using? The supported build version is still VS2013-SP4 [1] David [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > The revision immediately preceding this builds fine, but the current tip > does not. > I have copied the relevant error below - looks like a missing > implementation of 8 byte atomic store, but I cannot work the template magic > to figure out if it really is missing or something else is going on. > > Thanks > Michael > > > > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [*** [lib/CompileGtest.gmk:67: > /cygdrive/c/openjdk/OpenJDK/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/gtest/objs/BUILD_GTEST_LIBJVM_pch.obj] > Error 1 > > T=ClassPathEntry *, > D=ClassPathEntry * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with [make/Main.gmk:268: hotspot-server-libs] Error 2 > > [*** Waiting for unfinished jobs.... > > T=ClassPathEntry *, > D=ClassPathEntry * > ] > c:\openjdk\OpenJDK\src\hotspot\share\classfile/classLoader.hpp(55): note: > see reference to function template instantiation 'void > OrderAccess::release_store(volatile D > *,T)' being compiled > with > [ > D=ClassPathEntry *, > T=ClassPathEntry * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=MethodData *, > D=MethodData * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=MethodData *, > D=MethodData * > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/method.hpp(340): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being > compiled > with > [ > D=MethodData *, > T=MethodData * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=ExceptionCache *, > D=ExceptionCache * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=ExceptionCache *, > D=ExceptionCache * > ] > c:\openjdk\OpenJDK\src\hotspot\share\code/compiledMethod.hpp(291): note: > see reference to function template instantiation 'void > OrderAccess::release_store(volatile D > *,T)' being compiled > with > [ > D=ExceptionCache *, > T=ExceptionCache * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=markOop, > D=markOop > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=markOop, > D=markOop > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(93): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being compiled > with > [ > D=markOop, > T=markOop > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=Klass *, > D=Klass * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=Klass *, > D=Klass * > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(164): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being compiled > with > [ > D=Klass *, > T=Klass * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=oop, > D=oop > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=oop, > D=oop > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(364): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being compiled > with > [ > D=oop, > T=oop > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=Metadata *, > D=Metadata * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=Metadata *, > D=Metadata * > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(454): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being > compiled > with > [ > D=Metadata *, > T=Metadata * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=address, > D=address > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=address, > D=address > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(522): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being compiled > with > [ > D=address, > T=address > ] > From me at md-5.net Sat Nov 11 00:59:04 2017 From: me at md-5.net (Michael Dardis) Date: Sat, 11 Nov 2017 00:59:04 +0000 Subject: RFR (M): 8188224: Generalize Atomic::load/store to use templates In-Reply-To: <5ee78595-9639-2b6f-9d8f-656f09b42859@oracle.com> References: <0100015fa7d6fb8b-19f177b2-2399-4666-8633-f297a391338b-000000@email.amazonses.com> <5ee78595-9639-2b6f-9d8f-656f09b42859@oracle.com> Message-ID: <0100015fa8965112-0755ef6b-9b0c-4a3f-9921-15c3d654c6cb-000000@email.amazonses.com> Hi David, Unfortunately I'm using VS2017 for a couple of reasons (64bit compiler in community edition, improved UWP support). Everything else works fine with a couple of very minor tweaks, but I'm having real trouble trying to deal with the templates here and figure out what's missing. Understand it's not a supported platform, but maybe someone has encountered this or has a hunch as to where the compiler is going wrong in the new templates. Going to have to update eventually and I think with the push for more open involvement in OpenJDK having at least the ability to build on more setups and compilers is a good thing. Thanks Michael On 11 Nov. 2017 11:02, "David Holmes" wrote: Hi Michael, On 11/11/2017 7:30 AM, Michael Dardis wrote: > Hi Erik et al, > > Since this commit I am having trouble building the project on 64 bit > Windows (though Linux works fine). > I was wondering whether anyone else has experienced this issue, or on the > contrary whether someone can report a success. > We have no problems building on any of our supported platforms. :) What version of Visual Studio are you using? The supported build version is still VS2013-SP4 [1] David [1] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms The revision immediately preceding this builds fine, but the current tip > does not. > I have copied the relevant error below - looks like a missing > implementation of 8 byte atomic store, but I cannot work the template magic > to figure out if it really is missing or something else is going on. > > Thanks > Michael > > > > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [*** [lib/CompileGtest.gmk:67: > /cygdrive/c/openjdk/OpenJDK/build/windows-x86_64-normal-serv > er-release/hotspot/variant-server/libjvm/gtest/objs/ > BUILD_GTEST_LIBJVM_pch.obj] > Error 1 > > T=ClassPathEntry *, > D=ClassPathEntry * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl ELEASE_X>,void>' > with [make/Main.gmk:268: hotspot-server-libs] Error 2 > > [*** Waiting for unfinished jobs.... > > T=ClassPathEntry *, > D=ClassPathEntry * > ] > c:\openjdk\OpenJDK\src\hotspot\share\classfile/classLoader.hpp(55): note: > see reference to function template instantiation 'void > OrderAccess::release_store(volatile D > *,T)' being compiled > with > [ > D=ClassPathEntry *, > T=ClassPathEntry * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=MethodData *, > D=MethodData * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=MethodData *, > D=MethodData * > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/method.hpp(340): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being > compiled > with > [ > D=MethodData *, > T=MethodData * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=ExceptionCache *, > D=ExceptionCache * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=ExceptionCache *, > D=ExceptionCache * > ] > c:\openjdk\OpenJDK\src\hotspot\share\code/compiledMethod.hpp(291): note: > see reference to function template instantiation 'void > OrderAccess::release_store(volatile D > *,T)' being compiled > with > [ > D=ExceptionCache *, > T=ExceptionCache * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=markOop, > D=markOop > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=markOop, > D=markOop > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(93): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being > compiled > with > [ > D=markOop, > T=markOop > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=Klass *, > D=Klass * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=Klass *, > D=Klass * > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(164): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being compiled > with > [ > D=Klass *, > T=Klass * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=oop, > D=oop > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=oop, > D=oop > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(364): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being compiled > with > [ > D=oop, > T=oop > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=Metadata *, > D=Metadata * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=Metadata *, > D=Metadata * > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(454): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being > compiled > with > [ > D=Metadata *, > T=Metadata * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=address, > D=address > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl ELEASE_X>,void>' > with > [ > T=address, > D=address > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(522): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being > compiled > with > [ > D=address, > T=address > ] > > From david.holmes at oracle.com Sat Nov 11 03:30:10 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 11 Nov 2017 13:30:10 +1000 Subject: RFR (M): 8188224: Generalize Atomic::load/store to use templates In-Reply-To: <0100015fa8965103-68bb6a23-3dcd-41ed-9097-47ec210339ec-000000@email.amazonses.com> References: <0100015fa7d6fb8b-19f177b2-2399-4666-8633-f297a391338b-000000@email.amazonses.com> <5ee78595-9639-2b6f-9d8f-656f09b42859@oracle.com> <0100015fa8965103-68bb6a23-3dcd-41ed-9097-47ec210339ec-000000@email.amazonses.com> Message-ID: <25c357b1-147c-62bb-3f2c-17accc3bd89f@oracle.com> Hi Mikael, On 11/11/2017 10:59 AM, Michael Dardis wrote: > Hi David, > > Unfortunately I'm using VS2017 for a couple of reasons (64bit compiler > in community edition, improved UWP support). Everything else works fine > with a couple of very minor tweaks, but I'm having real trouble trying > to deal with the templates here and figure out what's missing. I've cc'd our C++ guru Kim Barrett. > Understand it's not a supported platform, but maybe someone has > encountered this or has a hunch as to where the compiler is going wrong > in the new templates. Going to have to update eventually and I think > with the push for more open involvement in OpenJDK having at least the > ability to build on more setups and compilers is a good thing. Well you just joined the trailblazers in that department :) Cheers, David > Thanks > Michael > > > On 11 Nov. 2017 11:02, "David Holmes" > wrote: > > Hi Michael, > > > On 11/11/2017 7:30 AM, Michael Dardis wrote: > > Hi Erik et al, > > Since this commit I am having trouble building the project on 64 bit > Windows (though Linux works fine). > I was wondering whether anyone else has experienced this issue, > or on the > contrary whether someone can report a success. > > > We have no problems building on any of our supported platforms. :) > > What version of Visual Studio are you using? The supported build > version is still VS2013-SP4 [1] > > David > > [1] > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > > > The revision immediately preceding this builds fine, but the > current tip > does not. > I have copied the relevant error below - looks like a missing > implementation of 8 byte atomic store, but I cannot work the > template magic > to figure out if it really is missing or something else is going on. > > Thanks > Michael > > > > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [*** [lib/CompileGtest.gmk:67: > /cygdrive/c/openjdk/OpenJDK/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/gtest/objs/BUILD_GTEST_LIBJVM_pch.obj] > Error 1 > > T=ClassPathEntry *, > D=ClassPathEntry * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with [make/Main.gmk:268: hotspot-server-libs] Error 2 > > [*** Waiting for unfinished jobs.... > > T=ClassPathEntry *, > D=ClassPathEntry * > ] > c:\openjdk\OpenJDK\src\hotspot\share\classfile/classLoader.hpp(55): > note: > see reference to function template instantiation 'void > OrderAccess::release_store(volatile > D > *,T)' being compiled > with > [ > D=ClassPathEntry *, > T=ClassPathEntry * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=MethodData *, > D=MethodData * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=MethodData *, > D=MethodData * > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/method.hpp(340): note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D > *,T)' being > compiled > with > [ > D=MethodData *, > T=MethodData * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=ExceptionCache *, > D=ExceptionCache * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=ExceptionCache *, > D=ExceptionCache * > ] > c:\openjdk\OpenJDK\src\hotspot\share\code/compiledMethod.hpp(291): > note: > see reference to function template instantiation 'void > OrderAccess::release_store(volatile > D > *,T)' being compiled > with > [ > D=ExceptionCache *, > T=ExceptionCache * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=markOop, > D=markOop > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=markOop, > D=markOop > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(93): > note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' > being compiled > with > [ > D=markOop, > T=markOop > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=Klass *, > D=Klass * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=Klass *, > D=Klass * > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(164): > note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being > compiled > with > [ > D=Klass *, > T=Klass * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=oop, > D=oop > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=oop, > D=oop > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(364): > note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' being compiled > with > [ > D=oop, > T=oop > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=Metadata *, > D=Metadata * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=Metadata *, > D=Metadata * > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(454): > note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' > being > compiled > with > [ > D=Metadata *, > T=Metadata * > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > error C2027: use of undefined type > 'Atomic::StoreImpl,void>' > with > [ > T=address, > D=address > ] > c:\openjdk\OpenJDK\src\hotspot\share\runtime/orderAccess.inline.hpp(59): > note: see declaration of > 'Atomic::StoreImpl,void>' > with > [ > T=address, > D=address > ] > c:\openjdk\OpenJDK\src\hotspot\share\oops/oop.inline.hpp(522): > note: see > reference to function template instantiation 'void > OrderAccess::release_store(volatile D *,T)' > being compiled > with > [ > D=address, > T=address > ] > > From thomas.stuefe at gmail.com Sat Nov 11 07:35:22 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 11 Nov 2017 08:35:22 +0100 Subject: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source In-Reply-To: References: <8a608fa8-eece-3aeb-1866-5ba75719c09b@oracle.com> Message-ID: Oh, you are right, I should have seen this. Knowing this, forget my worries about stability. Sorry for the noise :) ..Thomas On Fri, Nov 10, 2017 at 11:47 PM, Chris Plummer wrote: > It's already restricted to non-product builds, but I'll add a comment also. > > thanks, > > Chris > > > On 11/10/17 1:27 PM, Thomas St?fe wrote: > > Hi Chris, > > Thank you. Yes, a comment may make sense, and/or restricting this function > to not product. Otherwise the change is fine and useful, I?ll use it > probably before long. > > Thanks, Thomas > > On Fri 10. Nov 2017 at 21:55, Chris Plummer > wrote: > >> Hi Thomas, >> >> There's certainly no intent to leave in place any calls someone might add >> to pns2(). It's meant as a temporary debugging aide only. So if it were to >> fail for any reason, IMO that's no different than adding any other sort of >> temporary debugging code that could possibly crash. You fix your mistake >> and resume your debugging. If you want I can add comments that include such >> a warning. >> >> thanks, >> >> Chris >> >> >> >> On 11/10/17 12:11 AM, Thomas St?fe wrote: >> >> Hi Chris, >> >> looks fine as a debugging aid. >> >> But it occurred to me that it may be a bit dangerous to call this from >> non-errorhandler settings. I recall seeing quite a few secondary crashes in >> VMError::print_native_stack() in hs-err files over time. Especially for >> native non-java threads. Usually this did not matter that much because >> these crashes are handled by secondary error handling when printing the >> hs-err file. But if we call it outside of error handling, we are on our own. >> >> So. IMHO, to use this functions as a debugging aid is fine, if one can >> accept a slight risk of crashing the VM. If this is not acceptable, may we >> need some more tests for this function? >> >> Kind Regards, Thomas >> >> >> >> On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer >> wrote: >> >>> Hi, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8191049 >>> >>> diff --git a/src/hotspot/share/utilities/debug.cpp >>> b/src/hotspot/share/utilities/debug.cpp >>> --- a/src/hotspot/share/utilities/debug.cpp >>> +++ b/src/hotspot/share/utilities/debug.cpp >>> @@ -631,6 +631,24 @@ >>> VMError::print_native_stack(tty, fr, t, buf, sizeof(buf)); >>> } >>> >>> +// >>> +// This version of pns() will not work when called from the debugger, >>> but is >>> +// useful when called from within hotspot code. The advantages over >>> pns() >>> +// are not having to pass in any arguments, and it will work on >>> Windows/x64. >>> +// >>> +extern "C" void pns2() { // print native stack >>> + Command c("pns2"); >>> + static char buf[O_BUFLEN]; >>> + if (os::platform_print_native_stack(tty, NULL, buf, sizeof(buf))) { >>> + // We have printed the native stack in platform-specific code, >>> + // so nothing else to do in this case. >>> + } else { >>> + Thread* t = Thread::current_or_null(); >>> + frame fr = os::current_frame(); >>> + VMError::print_native_stack(tty, fr, t, buf, sizeof(buf)); >>> + } >>> +} >>> + >>> #endif // !PRODUCT >>> >>> There is also a pre-existing thread with some discussion: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/ >>> 2017-November/025134.html >>> >>> thanks, >>> >>> Chris >>> >>> >> >> > From kim.barrett at oracle.com Sun Nov 12 04:47:07 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 11 Nov 2017 23:47:07 -0500 Subject: RFR (M): 8188224: Generalize Atomic::load/store to use templates In-Reply-To: <25c357b1-147c-62bb-3f2c-17accc3bd89f@oracle.com> References: <0100015fa7d6fb8b-19f177b2-2399-4666-8633-f297a391338b-000000@email.amazonses.com> <5ee78595-9639-2b6f-9d8f-656f09b42859@oracle.com> <0100015fa8965103-68bb6a23-3dcd-41ed-9097-47ec210339ec-000000@email.amazonses.com> <25c357b1-147c-62bb-3f2c-17accc3bd89f@oracle.com> Message-ID: <5D204048-E6A9-4795-B622-6FB46536E704@oracle.com> > On Nov 10, 2017, at 10:30 PM, David Holmes wrote: > > Hi Mikael, > > On 11/11/2017 10:59 AM, Michael Dardis wrote: >> Hi David, >> Unfortunately I'm using VS2017 for a couple of reasons (64bit compiler in community edition, improved UWP support). Everything else works fine with a couple of very minor tweaks, but I'm having real trouble trying to deal with the templates here and figure out what's missing. > > I've cc'd our C++ guru Kim Barrett. I saw this, but haven?t had a chance to seriously look at it yet. One thing I did notice, though, is that all the OrderAccess definitions (as opposed to declarations) are in orderAccess.inline.hpp. That doesn?t appear to be a change from the pre-templatization; all the pre-template definitions were in the inline.hpp file too. However, the offending call to OrderAccess::release_store is in a .hpp file (classLoader.hpp), which only includes orderAccess.hpp (and it shouldn?t include orderAccess.inline.hpp, because .hpp files are not supposed to include .inline.hpp files). Which means the call in classLoader.hpp might only see the declaration, and not the definition. That seems like a bug. I haven?t thought this through carefully, but this might be a two-phase name lookup issue. Note that VS2017 is the first version of VS that has two-phase name lookup. Other compilers (gcc & clang) have had two-phase lookup for a (very!) long time. Assuming this is the right area to be looking (and I?m not sure of that yet), it could be that VS2017 is being more strict than those other compilers (that aren?t complaining about this code but maybe should?), or that VS2017 has a bug in this new (to it) area. There is a pretty thorough discussion of the two-phase name lookup issue in VS here: https://blogs.msdn.microsoft.com/vcblog/2017/09/11/two-phase-name-lookup-support-comes-to-msvc/ It also discusses how to obtain the old behavior, using /Zc:twoPhase-. It would be interesting to know whether that made any difference for this problem. (I don?t have easy access to VS2017 or even have any familiarity with using it, or Windows for that matter.) From david.holmes at oracle.com Sun Nov 12 05:44:17 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 12 Nov 2017 15:44:17 +1000 Subject: RFR (M): 8188224: Generalize Atomic::load/store to use templates In-Reply-To: <5D204048-E6A9-4795-B622-6FB46536E704@oracle.com> References: <0100015fa7d6fb8b-19f177b2-2399-4666-8633-f297a391338b-000000@email.amazonses.com> <5ee78595-9639-2b6f-9d8f-656f09b42859@oracle.com> <0100015fa8965103-68bb6a23-3dcd-41ed-9097-47ec210339ec-000000@email.amazonses.com> <25c357b1-147c-62bb-3f2c-17accc3bd89f@oracle.com> <5D204048-E6A9-4795-B622-6FB46536E704@oracle.com> Message-ID: <7b243aaa-92b8-9e94-780e-6dc5033794c6@oracle.com> Hi Kim, Many thanks for taking a look. On 12/11/2017 2:47 PM, Kim Barrett wrote: >> On Nov 10, 2017, at 10:30 PM, David Holmes wrote: >> >> Hi Mikael, >> >> On 11/11/2017 10:59 AM, Michael Dardis wrote: >>> Hi David, >>> Unfortunately I'm using VS2017 for a couple of reasons (64bit compiler in community edition, improved UWP support). Everything else works fine with a couple of very minor tweaks, but I'm having real trouble trying to deal with the templates here and figure out what's missing. >> >> I've cc'd our C++ guru Kim Barrett. > > I saw this, but haven?t had a chance to seriously look at it yet. > > One thing I did notice, though, is that all the OrderAccess definitions (as opposed to declarations) are in > orderAccess.inline.hpp. That doesn?t appear to be a change from the pre-templatization; all the pre-template > definitions were in the inline.hpp file too. > > However, the offending call to OrderAccess::release_store is in a .hpp file (classLoader.hpp), which only > includes orderAccess.hpp (and it shouldn?t include orderAccess.inline.hpp, because .hpp files are not > supposed to include .inline.hpp files). Which means the call in classLoader.hpp might only see the > declaration, and not the definition. That seems like a bug. Yes that needs to be fixed. Though exact fix seems a little tricky if we still want the referring function to be inlined. > I haven?t thought this through carefully, but this might be a two-phase name lookup issue. Note that > VS2017 is the first version of VS that has two-phase name lookup. Other compilers (gcc & clang) > have had two-phase lookup for a (very!) long time. Assuming this is the right area to be looking (and > I?m not sure of that yet), it could be that VS2017 is being more strict than those other compilers (that > aren?t complaining about this code but maybe should?), or that VS2017 has a bug in this new (to it) > area. > > There is a pretty thorough discussion of the two-phase name lookup issue in VS here: > https://blogs.msdn.microsoft.com/vcblog/2017/09/11/two-phase-name-lookup-support-comes-to-msvc/ > It also discusses how to obtain the old behavior, using /Zc:twoPhase-. It would be interesting to know > whether that made any difference for this problem. (I don?t have easy access to VS2017 or even have > any familiarity with using it, or Windows for that matter.) Okay - so we may have a workaround pending the fix. Hopefully Michael can test this out. Thanks again. David From glaubitz at physik.fu-berlin.de Sun Nov 12 10:28:57 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sun, 12 Nov 2017 11:28:57 +0100 Subject: Chasing changing repository locations In-Reply-To: <5d0ad9a5-01aa-3529-5af1-ded1ae9d30ab@oracle.com> References: <949df99d-f606-d0b1-c774-a8eb9f874030@physik.fu-berlin.de> <5d0ad9a5-01aa-3529-5af1-ded1ae9d30ab@oracle.com> Message-ID: Hi David et al.! On 11/10/2017 01:08 PM, David Holmes wrote: > You need to make sure you're subscribed to the project email lists - it > was jdk10-dev and now just jdk-dev at openjdk.java.net. Then you would have seen about all > the changes to the repos. Check the archives for discussion: > > http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000087.html Thanks for the heads-up! I appreciate all the quick replies and input :-). > In theory they should never need to change again. ;-) Let's see what mathematical values of "never" we are talking about :-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Sun Nov 12 21:17:19 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Nov 2017 07:17:19 +1000 Subject: RFR (M): 8188224: Generalize Atomic::load/store to use templates In-Reply-To: <7b243aaa-92b8-9e94-780e-6dc5033794c6@oracle.com> References: <0100015fa7d6fb8b-19f177b2-2399-4666-8633-f297a391338b-000000@email.amazonses.com> <5ee78595-9639-2b6f-9d8f-656f09b42859@oracle.com> <0100015fa8965103-68bb6a23-3dcd-41ed-9097-47ec210339ec-000000@email.amazonses.com> <25c357b1-147c-62bb-3f2c-17accc3bd89f@oracle.com> <5D204048-E6A9-4795-B622-6FB46536E704@oracle.com> <7b243aaa-92b8-9e94-780e-6dc5033794c6@oracle.com> Message-ID: I've filed: https://bugs.openjdk.java.net/browse/JDK-8191102 for the include issue. But I don't think this is caused by two-phase-name-lookup as that is not yet enabled by default in VS2017. David On 12/11/2017 3:44 PM, David Holmes wrote: > Hi Kim, > > Many thanks for taking a look. > > On 12/11/2017 2:47 PM, Kim Barrett wrote: >>> On Nov 10, 2017, at 10:30 PM, David Holmes >>> wrote: >>> >>> Hi Mikael, >>> >>> On 11/11/2017 10:59 AM, Michael Dardis wrote: >>>> Hi David, >>>> Unfortunately I'm using VS2017 for a couple of reasons (64bit >>>> compiler in community edition, improved UWP support). Everything >>>> else works fine with a couple of very minor tweaks, but I'm having >>>> real trouble trying to deal with the templates here and figure out >>>> what's missing. >>> >>> I've cc'd our C++ guru Kim Barrett. >> >> I saw this, but haven?t had a chance to seriously look at it yet. >> >> One thing I did notice, though, is that all the OrderAccess >> definitions (as opposed to declarations) are in >> orderAccess.inline.hpp.? That doesn?t appear to be a change from the >> pre-templatization; all the pre-template >> definitions were in the inline.hpp file too. >> >> However, the offending call to OrderAccess::release_store is in a .hpp >> file (classLoader.hpp), which only >> includes orderAccess.hpp (and it shouldn?t include >> orderAccess.inline.hpp, because .hpp files are not >> supposed to include .inline.hpp files).? Which means the call in >> classLoader.hpp might only see the >> declaration, and not the definition.? That seems like a bug. > > Yes that needs to be fixed. Though exact fix seems a little tricky if we > still want the referring function to be inlined. > >> I haven?t thought this through carefully, but this might be a >> two-phase name lookup issue.? Note that >> VS2017 is the first version of VS that has two-phase name lookup. >> Other compilers (gcc & clang) >> have had two-phase lookup for a (very!) long time.? Assuming this is >> the right area to be looking (and >> I?m not sure of that yet), it could be that VS2017 is being more >> strict than those other compilers (that >> aren?t complaining about this code but maybe should?), or that VS2017 >> has a bug in this new (to it) >> area. >> >> There is a pretty thorough discussion of the two-phase name lookup >> issue in VS here: >> https://blogs.msdn.microsoft.com/vcblog/2017/09/11/two-phase-name-lookup-support-comes-to-msvc/ >> >> It also discusses how to obtain the old behavior, using >> /Zc:twoPhase-.? It would be interesting to know >> whether that made any difference for this problem.? (I don?t have easy >> access to VS2017 or even have >> any familiarity with using it, or Windows for that matter.) > > Okay - so we may have a workaround pending the fix. Hopefully Michael > can test this out. > > Thanks again. > David > From me at md-5.net Sun Nov 12 21:19:28 2017 From: me at md-5.net (Michael Dardis) Date: Sun, 12 Nov 2017 21:19:28 +0000 Subject: RFR (M): 8188224: Generalize Atomic::load/store to use templates In-Reply-To: <7b243aaa-92b8-9e94-780e-6dc5033794c6@oracle.com> References: <0100015fa7d6fb8b-19f177b2-2399-4666-8633-f297a391338b-000000@email.amazonses.com> <5ee78595-9639-2b6f-9d8f-656f09b42859@oracle.com> <0100015fa8965103-68bb6a23-3dcd-41ed-9097-47ec210339ec-000000@email.amazonses.com> <25c357b1-147c-62bb-3f2c-17accc3bd89f@oracle.com> <5D204048-E6A9-4795-B622-6FB46536E704@oracle.com> <7b243aaa-92b8-9e94-780e-6dc5033794c6@oracle.com> Message-ID: <0100015fb219fe67-22e21596-ef01-46f6-aef6-97f91c33aa2b-000000@email.amazonses.com> Thanks, I will try both of these today. Michael On 12 Nov. 2017 16:44, "David Holmes" wrote: > Hi Kim, > > Many thanks for taking a look. > > On 12/11/2017 2:47 PM, Kim Barrett wrote: > >> On Nov 10, 2017, at 10:30 PM, David Holmes >>> wrote: >>> >>> Hi Mikael, >>> >>> On 11/11/2017 10:59 AM, Michael Dardis wrote: >>> >>>> Hi David, >>>> Unfortunately I'm using VS2017 for a couple of reasons (64bit compiler >>>> in community edition, improved UWP support). Everything else works fine >>>> with a couple of very minor tweaks, but I'm having real trouble trying to >>>> deal with the templates here and figure out what's missing. >>>> >>> >>> I've cc'd our C++ guru Kim Barrett. >>> >> >> I saw this, but haven?t had a chance to seriously look at it yet. >> >> One thing I did notice, though, is that all the OrderAccess definitions >> (as opposed to declarations) are in >> orderAccess.inline.hpp. That doesn?t appear to be a change from the >> pre-templatization; all the pre-template >> definitions were in the inline.hpp file too. >> >> However, the offending call to OrderAccess::release_store is in a .hpp >> file (classLoader.hpp), which only >> includes orderAccess.hpp (and it shouldn?t include >> orderAccess.inline.hpp, because .hpp files are not >> supposed to include .inline.hpp files). Which means the call in >> classLoader.hpp might only see the >> declaration, and not the definition. That seems like a bug. >> > > Yes that needs to be fixed. Though exact fix seems a little tricky if we > still want the referring function to be inlined. > > I haven?t thought this through carefully, but this might be a two-phase >> name lookup issue. Note that >> VS2017 is the first version of VS that has two-phase name lookup. Other >> compilers (gcc & clang) >> have had two-phase lookup for a (very!) long time. Assuming this is the >> right area to be looking (and >> I?m not sure of that yet), it could be that VS2017 is being more strict >> than those other compilers (that >> aren?t complaining about this code but maybe should?), or that VS2017 has >> a bug in this new (to it) >> area. >> >> There is a pretty thorough discussion of the two-phase name lookup issue >> in VS here: >> https://blogs.msdn.microsoft.com/vcblog/2017/09/11/two-phase >> -name-lookup-support-comes-to-msvc/ >> It also discusses how to obtain the old behavior, using /Zc:twoPhase-. >> It would be interesting to know >> whether that made any difference for this problem. (I don?t have easy >> access to VS2017 or even have >> any familiarity with using it, or Windows for that matter.) >> > > Okay - so we may have a workaround pending the fix. Hopefully Michael can > test this out. > > Thanks again. > David > > From me at md-5.net Sun Nov 12 23:13:00 2017 From: me at md-5.net (Michael Dardis) Date: Sun, 12 Nov 2017 23:13:00 +0000 Subject: RFR (M): 8188224: Generalize Atomic::load/store to use templates In-Reply-To: References: <0100015fa7d6fb8b-19f177b2-2399-4666-8633-f297a391338b-000000@email.amazonses.com> <5ee78595-9639-2b6f-9d8f-656f09b42859@oracle.com> <0100015fa8965103-68bb6a23-3dcd-41ed-9097-47ec210339ec-000000@email.amazonses.com> <25c357b1-147c-62bb-3f2c-17accc3bd89f@oracle.com> <5D204048-E6A9-4795-B622-6FB46536E704@oracle.com> <7b243aaa-92b8-9e94-780e-6dc5033794c6@oracle.com> Message-ID: <0100015fb281ec63-cffed03b-29ad-4546-9224-cbf1e5049a87-000000@email.amazonses.com> Hi Again all, /Zc:twoPhase- doesn't change the result. I tried also putting #include "orderAccess.inline.hpp" At the bottom of orderAccess.hpp as a quick way of testing the other theory, but this produced no change. The errors are actually coming from within the header files themselves, rather than usage in files depending on them. c:\openjdk\openjdk-test\src\hotspot\share\runtime\orderAccess.inline.hpp(59): error C2027: use of undefined type 'Atomic::StoreImpl,void>' with [ T=ClassPathEntry *, D=ClassPathEntry * ] etc etc Below this message I have also included a copy of the failing command line, with a VS community 2017 install and fixing of paths it should reproduce the failure without mucking around with build machinery. I will also include the header include tree below that. Thanks Michael /cygdrive/c/openjdk/OpenJDK-test/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe -c /cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1411~1.255/bin/hostx64/x64/cl -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D_WINDOWS -DWIN32 -D_JNI_IMPLEMENTATION_ -nologo -W3 -MD -MP -DVM_LITTLE_ENDIAN -D_LP64=1 -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP -DTARGET_COMPILER_visCPP -DAMD64 -DHOTSPOT_LIB_ARCH='"amd64"' -DCOMPILER1 -DCOMPILER2 -DINCLUDE_AOT -I/cygdrive/c/openjdk/OpenJDK-test/src/hotspot/share -I/cygdrive/c/openjdk/OpenJDK-test/src/hotspot/os/windows -I/cygdrive/c/openjdk/OpenJDK-test/src/hotspot/cpu/x86 -I/cygdrive/c/openjdk/OpenJDK-test/src/hotspot/os_cpu/windows_x86 -I/cygdrive/c/openjdk/OpenJDK-test/build/windows-x86_64-normal-server-release/hotspot/variant-server/gensrc -I/cygdrive/c/openjdk/OpenJDK-test/src/hotspot/share/precompiled -I/cygdrive/c/openjdk/OpenJDK-test/src/hotspot/share/prims -I/cygdrive/c/openjdk/OpenJDK-test/src/java.base/share/native/include /Zc:sizedDealloc- -I/cygdrive/c/openjdk/OpenJDK-test/test/fmw/gtest -I/cygdrive/c/openjdk/OpenJDK-test/test/fmw/gtest/include -I/cygdrive/c/openjdk/OpenJDK-test/test/hotspot/gtest -EHsc -EHsc -Z7 -d2Zi+ -I/cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1411~1.255/atlmfc/include -I/cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1411~1.255/include -I/cygdrive/c/progra~2/wi3cf2~1/netfxsdk/46d346~1.1/include/um -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100162~1.0/ucrt -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100162~1.0/shared -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100162~1.0/um -I/cygdrive/c/progra~2/wi3cf2~1/10/include/100162~1.0/winrt -Fp/cygdrive/c/openjdk/OpenJDK-test/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/gtest/objs/BUILD_GTEST_LIBJVM.pch -Ycprecompiled.hpp -O2 -Oy- -c -showIncludes -Fd/cygdrive/c/openjdk/OpenJDK-test/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/gtest/objs/pdb/BUILD_GTEST_LIBJVM_pch.pdb -Fo/cygdrive/c/openjdk/OpenJDK-test/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/gtest/objs/BUILD_GTEST_LIBJVM_pch.obj /cygdrive/c/openjdk/OpenJDK-test/build/windows-x86_64-normal-server-release/hotspot/variant-server/libjvm/gtest/objs/BUILD_GTEST_LIBJVM_pch.cpp $ bash build/windows-x86_64-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_gtest_objs_BUILD_GTEST_LIBJVM_pch.obj.cmdline BUILD_GTEST_LIBJVM_pch.cpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\precompiled\precompiled.hpp Note: including file: c:\openjdk\OpenJDK-test\src\java.base\share\native\include\jni.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\stdio.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vcruntime.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\sal.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\concurrencysal.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vadefs.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_wstdio.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_stdio_config.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\stdarg.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vcruntime.h Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\prims\jni_md.h Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/macros.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\jni_x86.h Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\asm/assembler.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\asm/codeBuffer.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/oopRecorder.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/universe.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/array.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/allocation.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/globals.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/align.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/globalDefinitions.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/compilerWarnings.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/debug.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/breakpoint.hpp Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\stddef.h Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/globalDefinitions_visCPP.hpp Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\ctype.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_wctype.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\string.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_memory.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_memcpy_s.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\errno.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vcruntime_string.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vcruntime.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_wstring.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\stdlib.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_malloc.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_search.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_wstdlib.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\limits.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vcruntime.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\io.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_io.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_share.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_wio.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\float.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\time.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_wtime.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\fcntl.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\math.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_math.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_math_defines.h Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\globalDefinitions_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\globals_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os\windows\globals_windows.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os_cpu\windows_x86\globals_windows_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\c1_globals_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os\windows\c1_globals_windows.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\c2_globals_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os\windows\c2_globals_windows.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/globals_ext.hpp Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\new Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\exception Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\type_traits Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\xstddef Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\cstddef Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\xtr1common Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\yvals.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\xkeycheck.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\crtdefs.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vcruntime.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\use_ansi.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\cstdlib Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\math.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\initializer_list Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\malloc.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vcruntime_exception.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\eh.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_terminate.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vcruntime_new.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vcruntime.h Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/allocation.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/atomic.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\metaprogramming/conditional.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\metaprogramming/enableIf.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\metaprogramming/isIntegral.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\metaprogramming/integralConstant.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\metaprogramming/isSigned.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\metaprogramming/removeCV.hpp Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\limits Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\ymath.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\cfloat Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\climits Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\cmath Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\xtgmath.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\cwchar Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\wchar.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_wconio.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_wdirect.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\corecrt_wprocess.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\sys/stat.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\ucrt\sys/types.h Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\metaprogramming/isPointer.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\metaprogramming/isSame.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\metaprogramming/primitiveConversions.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\metaprogramming/isFloatingPoint.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\metaprogramming/isRegisteredEnum.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\metaprogramming/removePointer.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os_cpu\windows_x86\atomic_windows_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/os.hpp Note: including file: c:\openjdk\OpenJDK-test\build\windows-x86_64-normal-server-release\hotspot\variant-server\gensrc\jvmtifiles/jvmti.h Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\prims/jvm.h Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os\windows\jvm_windows.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\windows.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\winapifamily.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\winpackagefamily.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\sdkddkver.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\excpt.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vcruntime.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\windef.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\minwindef.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\specstrings.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\specstrings_strict.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\specstrings_undef.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\driverspecs.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\sdv_driverspecs.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winnt.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\kernelspecs.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\basetsd.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\guiddef.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\pshpack4.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack4.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\pshpack4.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\pshpack2.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\poppack.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\pshpack2.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack2.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\poppack.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\pshpack8.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\poppack.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\pshpack1.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\poppack.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\pshpack1.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\poppack.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\apiset.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\ktmtypes.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winbase.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\apisetcconv.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\minwinbase.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\processenv.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\fileapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\debugapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\utilapiset.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\handleapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\errhandlingapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\fibersapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\namedpipeapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\profileapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\heapapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\ioapiset.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\synchapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\interlockedapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\processthreadsapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\sysinfoapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\memoryapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\enclaveapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\threadpoollegacyapiset.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\threadpoolapiset.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\jobapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\jobapi2.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\wow64apiset.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\libloaderapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\securitybaseapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\namespaceapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\systemtopologyapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\processtopologyapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\securityappcontainer.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\realtimeapiset.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\winerror.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\timezoneapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\wingdi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack1.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack2.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack2.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack4.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack4.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winuser.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack2.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\tvout.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winnls.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\datetimeapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\stringapiset.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winnls.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\wincon.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\consoleapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winver.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\verrsrc.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winreg.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\reason.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winnetwk.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\wnnc.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\cderr.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\dde.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\ddeml.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\dlgs.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\lzexpand.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mmsystem.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mmsyscom.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack1.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack1.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mciapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mmsyscom.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mmiscapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mmsyscom.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mmiscapi2.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mmsyscom.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\playsoundapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mmsyscom.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mmeapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mmsyscom.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\timeapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mmsyscom.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\joystickapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mmsyscom.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\nb30.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\rpc.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack8.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\rpcdce.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\rpcdcep.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\rpcnsi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\rpcnterr.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\rpcasync.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack8.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\shellapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winperf.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack8.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winsock.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\inaddr.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\wincrypt.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\bcrypt.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\ncrypt.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\dpapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winefs.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winscard.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\wtypes.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\rpcndr.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack8.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\rpcnsip.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\rpcsal.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\wtypesbase.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\shared\guiddef.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winioctl.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack1.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack1.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack1.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack1.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack1.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack1.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack1.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\winsmcrd.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winspool.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\prsht.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack8.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\ole2.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack8.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\objbase.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack8.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\combaseapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack8.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\unknwnbase.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\objidlbase.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\guiddef.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\cguid.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\coml2api.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\objidl.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\um\unknwn.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\propidlbase.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\um\oaidl.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\urlmon.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\um\oleidl.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\um\servprov.h Note: including file: c:\program files (x86)\windows kits\10\include\10.0.16299.0\um\msxml.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\propidl.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\oleauto.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\pshpack8.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\poppack.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\commdlg.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\prsht.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\shared\stralign.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\winsvc.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\mcx.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\imm.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\ime_cmodes.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\Psapi.h Note: including file: c:\progra~2\wi3cf2~1\10\include\100162~1.0\um\Tlhelp32.h Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/extendedPC.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/handles.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/arena.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/oop.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/specialized_oop_closures.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/g1_specialized_oop_closures.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/iterator.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/memRegion.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/oopsHierarchy.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/metadata.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/exceptions.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/ostream.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/timer.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/sizes.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/os_ext.hpp Note: including file: c:\openjdk\openjdk-test\src\hotspot\os_cpu\windows_x86\os_windows_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os\windows\os_windows.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\services/memTracker.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\services/nmtCommon.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/nativeCallStack.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/threadCritical.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\services/mallocTracker.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\services/virtualMemoryTracker.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/metaspace.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/metaspaceChunkFreeListSummary.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/virtualspace.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\services/allocationSite.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/linkedlist.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/orderAccess.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/growableArray.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/relocInfo.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\relocInfo_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\codeBuffer_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\asm/register.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\register_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\asm/register.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/vm_version.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\vm_version_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/globals_extension.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/g1_globals.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\jvmci/jvmci_globals.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\c1/c1_globals.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/c2_globals.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/vm_version.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\assembler_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\asm/assembler.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\assembler_x86.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\asm/assembler.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/codeCache.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/codeBlob.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\compiler/compilerDefinitions.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\compiler/oopMap.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/compressedStream.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/vmreg.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/adlcVMDeps.hpp Note: including file: c:\openjdk\openjdk-test\src\hotspot\cpu\x86\vmreg_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/frame.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/method.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/vmSymbols.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/moduleEntry.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/classLoaderData.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/metaspaceCounters.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/oopHandle.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/mutex.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/histogram.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\trace/traceMacros.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/ticks.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/vmSymbols.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/symbol.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/utf8.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/jniHandles.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/mutexLocker.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/hashtable.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/vmSymbols_ext.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\jvmci/vmSymbols_jvmci.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/invocationCounter.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/annotations.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/constantPool.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/arrayOop.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/universe.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/cpCache.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/bytecodes.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/constantTag.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/objArrayOop.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/typeArrayOop.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/typeArrayKlass.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/arrayKlass.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/klass.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/accessFlags.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/orderAccess.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os_cpu\windows_x86\orderAccess_windows_x86.inline.hpp Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\intrin.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\intrin0.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vcruntime.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\setjmp.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\vcruntime.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\immintrin.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\wmmintrin.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\nmmintrin.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\smmintrin.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\tmmintrin.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\pmmintrin.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\emmintrin.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\xmmintrin.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\mmintrin.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\zmmintrin.h Note: including file: c:\progra~2\micros~1\2017\commun~1\vc\tools\msvc\1411~1.255\include\ammintrin.h Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/bytes.hpp Note: including file: c:\openjdk\openjdk-test\src\hotspot\cpu\x86\bytes_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os_cpu\windows_x86\bytes_windows_x86.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/methodCounters.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\compiler/compilerOracle.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/arguments.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\logging/logLevel.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\logging/logTag.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\logging/logTag_ext.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/java.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/perfData.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/perfMemory.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/instanceKlass.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/classLoader.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/jimage.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/packageEntry.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/referenceType.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/constMethod.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/fieldInfo.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/instanceOop.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/klassVtable.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/basicLock.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/markOop.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/monitorChunk.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/synchronizer.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/padded.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/registerMap.hpp Note: including file: c:\openjdk\openjdk-test\src\hotspot\cpu\x86\registerMap_x86.hpp Note: including file: c:\openjdk\openjdk-test\src\hotspot\cpu\x86\frame_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/nmethod.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/compiledMethod.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/pcDesc.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/heap.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciArray.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciArrayKlass.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciKlass.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciType.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciMetadata.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciBaseObject.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciClassList.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciConstant.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciNullObject.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciObject.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciUtilities.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciEnv.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciObjectFactory.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/systemDictionary.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/systemDictionary_ext.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\jvmci/systemDictionary_jvmci.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/reflectionUtils.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/handles.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/thread.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/os.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os\windows\os_windows.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/thread.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/threadLocalAllocBuffer.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/gcUtil.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\prims/jvmtiExport.hpp Note: including file: c:\openjdk\OpenJDK-test\src\java.base\share\native\include\jvmticmlr.h Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/javaFrameAnchor.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\javaFrameAnchor_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/osThread.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/objectMonitor.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/park.hpp Note: including file: c:\openjdk\openjdk-test\src\hotspot\os\windows\osThread_windows.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/safepoint.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/stubRoutines.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/stubCodeGenerator.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\stubRoutines_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/threadLocalStorage.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/thread_ext.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/unhandledOops.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\trace/traceBackend.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\trace/traceTime.hpp Note: including file: c:\openjdk\OpenJDK-test\build\windows-x86_64-normal-server-release\hotspot\variant-server\gensrc\tracefiles/traceEventIds.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\trace/traceDataTypes.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/dirtyCardQueue.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/ptrQueue.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/satbMarkQueue.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os_cpu\windows_x86\thread_windows_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/reflection.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/fieldDescriptor.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/fieldType.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/hashtable.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/dtrace.hpp Note: including file: c:\openjdk\openjdk-test\src\hotspot\share\utilities\dtrace_disabled.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/debugInfoRec.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciInstanceKlass.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciConstantPoolCache.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/resourceArea.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciFlags.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciSymbol.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciMethod.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciSignature.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\compiler/methodLiveness.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/bitMap.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\prims/methodHandles.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/javaClasses.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/frame.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/compiledMethod.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/nativeInst.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\nativeInst_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/icache.hpp Note: including file: c:\openjdk\openjdk-test\src\hotspot\cpu\x86\icache_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/bytecodeInterpreter.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/methodData.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/bytecodeInterpreter.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/interpreter.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/stubs.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/cppInterpreter.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/abstractInterpreter.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\asm/macroAssembler.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\macroAssembler_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/rtmLocking.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/vmThread.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/vm_operations.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/templateInterpreter.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/templateTable.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\templateTable_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/signature.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\frame_x86.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/vmreg.inline.hpp Note: including file: c:\openjdk\openjdk-test\src\hotspot\cpu\x86\vmreg_x86.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/interfaceSupport.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/gcLocker.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/collectedHeap.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/gcCause.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/gcWhen.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/events.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/formatBuffer.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/vmError.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/genCollectedHeap.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/adaptiveSizePolicy.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\logging/log.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\logging/logPrefix.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/gcId.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\logging/logTagSet.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\logging/logDecorators.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\logging/logOutputList.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/collectorPolicy.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/barrierSet.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/fakeRttiSupport.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/cardTableRS.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/cardTableModRefBSForCTRS.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/cardTableModRefBS.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/modRefBarrierSet.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/generationSpec.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/generation.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/collectorCounters.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/referenceProcessor.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/referencePolicy.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/referenceProcessorPhaseTimes.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/referenceProcessorStats.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/workerDataArray.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/workerDataArray.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/instanceRefKlass.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/preserveException.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\methodHandles_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\trace/tracing.hpp Note: including file: c:\openjdk\OpenJDK-test\build\windows-x86_64-normal-server-release\hotspot\variant-server\gensrc\tracefiles/traceEventClasses.hpp Note: including file: c:\openjdk\OpenJDK-test\build\windows-x86_64-normal-server-release\hotspot\variant-server\gensrc\tracefiles/traceTypes.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\trace/traceEvent.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\trace/traceStream.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/debugInfo.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/location.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/stackValue.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/dependencies.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciCallSite.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciInstance.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciMethodHandle.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\code/exceptionHandlerTable.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciExceptionHandler.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciField.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciObjArrayKlass.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciStreams.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/bytecode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciTypeArrayKlass.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/compilerInterface.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciCallProfile.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciObjArray.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciTypeArray.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/classFileParser.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/classFileStream.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/modules.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\classfile/symbolTable.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\compiler/disassembler.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\disassembler_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/cms/allocationStats.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/cms/gSpaceCounters.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/generationCounters.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/immutableSpace.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/mutableSpace.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/copy.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\copy_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os_cpu\windows_x86\copy_windows_x86.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/spaceCounters.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/serial/cSpaceCounters.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/space.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/blockOffsetTable.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/memset_with_concurrent_readers.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/workgroup.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/serial/defNewGeneration.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/ageTable.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/copyFailedInfo.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/preservedMarks.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/stack.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/gcStats.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/spaceDecorator.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/taskqueue.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/bytecodeHistogram.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/bytecodeTracer.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/interp_masm.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\interp_masm_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\asm/macroAssembler.inline.hpp Note: including file: c:\openjdk\openjdk-test\src\hotspot\cpu\x86\macroAssembler_x86.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\interpreter/linkResolver.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/oopFactory.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/objArrayKlass.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/markOop.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/oop.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/barrierSet.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/collectedHeap.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/allocTracer.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/threadLocalAllocBuffer.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/oop.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/sharedRuntime.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\services/lowMemoryDetector.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\services/memoryPool.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\services/memoryUsage.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\services/memoryService.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/klass.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\oops/markOop.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/deoptimization.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/init.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/javaCalls.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\jniTypes_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/prefetch.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/prefetch.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\os_cpu\windows_x86\prefetch_windows_x86.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/stackValueCollection.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/vframe.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\services/memBaseline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\services/mallocSiteTable.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\services/memReporter.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/bitMap.inline.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/numberSeq.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\libadt/dict.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\libadt/set.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\libadt/vectset.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/ad.hpp Note: including file: c:\openjdk\OpenJDK-test\build\windows-x86_64-normal-server-release\hotspot\variant-server\gensrc\adfiles/ad_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/machnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/callnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/connode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/node.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/compile.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\compiler/compileBroker.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\compiler/abstractCompiler.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\compiler/compilerDirectives.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\compiler/methodMatcher.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\compiler/compileTask.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\compiler/compileLog.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\utilities/xmlstream.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\jvmci/jvmciCompiler.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\jvmci/jvmciEnv.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/idealGraphPrinter.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/phasetype.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/phase.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/regmask.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/optoreg.hpp Note: including file: c:\openjdk\OpenJDK-test\build\windows-x86_64-normal-server-release\hotspot\variant-server\gensrc\adfiles/adGlobals_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/timerTrace.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/type.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/opcodes.hpp Note: including file: c:\openjdk\openjdk-test\src\hotspot\share\opto\classes.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/mulnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/multnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/phaseX.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/memnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/replacednodes.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/matcher.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/regalloc.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/block.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/subnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/vectornode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/addnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/castnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/cfgnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/convertnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/countbitsnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/intrinsicnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/loopnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/movenode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/narrowptrnode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/opaquenode.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\opto/runtime.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\runtime/biasedLocking.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\c1/c1_Compilation.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\ci/ciMethodData.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\c1/c1_Defs.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\c1_Defs_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\c1/c1_FrameMap.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\c1/c1_LIR.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\c1/c1_ValueType.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\c1_FrameMap_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\c1/c1_MacroAssembler.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\cpu\x86\c1_MacroAssembler_x86.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/cms/compactibleFreeListSpace.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/cms/adaptiveFreeList.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/freeList.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/cms/promotionInfo.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/cms/freeChunk.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\memory/binaryTreeDictionary.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/cms/concurrentMarkSweepGeneration.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/cms/cmsOopClosures.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/genOopClosures.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/cms/yieldingWorkgroup.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/cardGeneration.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/gcHeapSummary.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/cms/parOopClosures.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/g1BlockOffsetTable.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/g1RegionToSpaceMapper.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/g1PageBasedVirtualSpace.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/g1OopClosures.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/g1InCSetState.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/g1BiasedArray.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/heapRegion.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/g1AllocationContext.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/g1HeapRegionTraceType.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/heapRegionTracer.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/heapRegionType.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/g1/survRateGroup.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/gcAdaptivePolicyCounters.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/gcPolicyCounters.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/objectStartArray.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/psVirtualspace.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/parMarkBitMap.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/parallelScavengeHeap.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/generationSizer.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/psGCAdaptivePolicyCounters.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/psAdaptiveSizePolicy.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/psOldGen.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/psGenerationCounters.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/psYoungGen.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/strongRootsScope.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/parallel/psCompactionManager.hpp Note: including file: c:\openjdk\OpenJDK-test\src\hotspot\share\gc/shared/plab.hpp On 13 November 2017 at 08:17, David Holmes wrote: > I've filed: > > https://bugs.openjdk.java.net/browse/JDK-8191102 > > for the include issue. > > But I don't think this is caused by two-phase-name-lookup as that is not yet > enabled by default in VS2017. > > David > > On 12/11/2017 3:44 PM, David Holmes wrote: >> >> Hi Kim, >> >> Many thanks for taking a look. >> >> On 12/11/2017 2:47 PM, Kim Barrett wrote: >>>> >>>> On Nov 10, 2017, at 10:30 PM, David Holmes >>>> wrote: >>>> >>>> Hi Mikael, >>>> >>>> On 11/11/2017 10:59 AM, Michael Dardis wrote: >>>>> >>>>> Hi David, >>>>> Unfortunately I'm using VS2017 for a couple of reasons (64bit compiler >>>>> in community edition, improved UWP support). Everything else works fine with >>>>> a couple of very minor tweaks, but I'm having real trouble trying to deal >>>>> with the templates here and figure out what's missing. >>>> >>>> >>>> I've cc'd our C++ guru Kim Barrett. >>> >>> >>> I saw this, but haven?t had a chance to seriously look at it yet. >>> >>> One thing I did notice, though, is that all the OrderAccess definitions >>> (as opposed to declarations) are in >>> orderAccess.inline.hpp. That doesn?t appear to be a change from the >>> pre-templatization; all the pre-template >>> definitions were in the inline.hpp file too. >>> >>> However, the offending call to OrderAccess::release_store is in a .hpp >>> file (classLoader.hpp), which only >>> includes orderAccess.hpp (and it shouldn?t include >>> orderAccess.inline.hpp, because .hpp files are not >>> supposed to include .inline.hpp files). Which means the call in >>> classLoader.hpp might only see the >>> declaration, and not the definition. That seems like a bug. >> >> >> Yes that needs to be fixed. Though exact fix seems a little tricky if we >> still want the referring function to be inlined. >> >>> I haven?t thought this through carefully, but this might be a two-phase >>> name lookup issue. Note that >>> VS2017 is the first version of VS that has two-phase name lookup. Other >>> compilers (gcc & clang) >>> have had two-phase lookup for a (very!) long time. Assuming this is the >>> right area to be looking (and >>> I?m not sure of that yet), it could be that VS2017 is being more strict >>> than those other compilers (that >>> aren?t complaining about this code but maybe should?), or that VS2017 has >>> a bug in this new (to it) >>> area. >>> >>> There is a pretty thorough discussion of the two-phase name lookup issue >>> in VS here: >>> >>> https://blogs.msdn.microsoft.com/vcblog/2017/09/11/two-phase-name-lookup-support-comes-to-msvc/ >>> It also discusses how to obtain the old behavior, using /Zc:twoPhase-. >>> It would be interesting to know >>> whether that made any difference for this problem. (I don?t have easy >>> access to VS2017 or even have >>> any familiarity with using it, or Windows for that matter.) >> >> >> Okay - so we may have a workaround pending the fix. Hopefully Michael can >> test this out. >> >> Thanks again. >> David >> > From gnormington at pivotal.io Mon Nov 13 09:15:57 2017 From: gnormington at pivotal.io (Glyn Normington) Date: Mon, 13 Nov 2017 09:15:57 +0000 Subject: Determining "GC" memory area size In-Reply-To: References: Message-ID: Thanks Aleksey, Zhenghu, and Yumin: that's very helpful. I'll start another thread on what I believe is an additional requirement for JEPS 8182070. Regards, Glyn On Fri, Nov 10, 2017 at 9:45 PM, yumin qi wrote: > Hi, Glyn > http://openjdk.java.net/jeps/8182070 > Upon its implementation, Java can get information of container and > confiture its own parameters for running in the container, more container > friendly. > > Yumin > > On Fri, Nov 10, 2017 at 11:11 AM, Zhengyu Gu wrote: > >> >> >> On 11/10/2017 01:47 PM, Aleksey Shipilev wrote: >> >>> On 11/10/2017 06:06 PM, Glyn Normington wrote: >>> >>>> Can anyone here tell me how the GC memory area size is determined? If >>>> there >>>> is documentation, so much the better as we'd prefer not to depend on >>>> code >>>> details that might flux arbitrarily. >>>> >>> >>> NMT reports all allocations from GC code (with mtGC tag) as "GC". This >>> includes, notably, Java heap >>> itself, and all auxiliary GC data structures. If you grep the OpenJDK >>> source for "mtGC", you can get >>> the idea what allocations are tagged. Also, "detailed" NMT mode would >>> give you allocation stacks, >>> which can also give some insight what those particular allocated bits >>> are coming from. >>> >> >> Java heap actually is *not* tagged as GC memory, but Java heap. >> >> -Zhengyu >> >> >>> The size of GC data structures is dependent on GC in question (and, >>> quite probably, depends on GC >>> implementation *version*, with swings back and forth), and thus is not >>> trivially deducible. For >>> simpler collectors, like Serial and Parallel, it would probably be >>> dominated by Card Table (1/512-th >>> of heap size). In G1, it is most probably mark bitmaps (2/64-th of heap >>> size), plus other >>> fine-grained remembered sets (which might get large, but maybe there is >>> a high bound?). Etc. >>> >>> Thanks, >>> -Aleksey >>> >>> >>> > -- Regards, Glyn From gnormington at pivotal.io Mon Nov 13 09:30:05 2017 From: gnormington at pivotal.io (Glyn Normington) Date: Mon, 13 Nov 2017 09:30:05 +0000 Subject: Additional JEPS 8182070 requirement: avoiding container OOM Message-ID: I would like to mention an additional requirement for JEPS 8182070 ( http://openjdk.java.net/jeps/8182070): avoid the JVM hitting container OOM by strictly bounding the amount of (physical) memory that the JVM consumes. This may be implicit in the document, but I think it should be made an explicit goal. If a java application hits container OOM, no detailed diagnostics, such as those associated with an OutOfMemoryError or a JVMTI resource exhaustion event, are presented to the user, so the user finds it very difficult to know how to fix the problem. The Cloud Foundry OSS project has done quite a bit of work on this problem and provides a couple of utilities which help when running a JVM in a container: * Java memory calculator ([1], [2]) to determine JVM memory settings, * jvmkill JVMTI agent ([3]) to report detailed diagnostics on a resource exhaustion event. Regards, Glyn [1] https://github.com/cloudfoundry/java-buildpack-memory-calculator [2] Design doc: https://docs.google.com/document/d/1vlXBiwRIjwiVcbvUGYMrxx2Aw1RVAtxq3iuZ3UK2vXA/edit#heading=h.uy41ishpv9zc [3] https://github.com/cloudfoundry/jvmkill From robbin.ehn at oracle.com Mon Nov 13 13:33:22 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 13 Nov 2017 14:33:22 +0100 Subject: RFR: 8190925: Deprecate FastTLABRefill and set default off Message-ID: <27bd5099-c40b-ff24-d597-e9de5c549f83@oracle.com> Hi all, please review. The option FastTLABRefill work only in C1 (interpreter and c2 don't use this option) when using either SerialGC or ParrallelGC (and deprecated CMS). Both the newly integrated Memory-Leak Profiler and upcoming Low Overhead Profiler don't work when FastTLABRefill is enabled. For more info please see CSR: https://bugs.openjdk.java.net/browse/JDK-8190926 Issue: https://bugs.openjdk.java.net/browse/JDK-8190925 Code below, thanks Robbin! diff -r cf127be65014 src/hotspot/share/runtime/arguments.cpp --- a/src/hotspot/share/runtime/arguments.cpp Sat Nov 11 01:21:09 2017 +0100 +++ b/src/hotspot/share/runtime/arguments.cpp Mon Nov 13 14:26:27 2017 +0100 @@ -385,2 +385,3 @@ { "UseMembar", JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) }, + { "FastTLABRefill", JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) }, { "IgnoreUnverifiableClassesDuringDump", JDK_Version::jdk(10), JDK_Version::undefined(), JDK_Version::undefined() }, diff -r cf127be65014 src/hotspot/share/runtime/globals.hpp --- a/src/hotspot/share/runtime/globals.hpp Sat Nov 11 01:21:09 2017 +0100 +++ b/src/hotspot/share/runtime/globals.hpp Mon Nov 13 14:26:27 2017 +0100 @@ -2015,4 +2015,4 @@ \ - product(bool, FastTLABRefill, true, \ - "Use fast TLAB refill code") \ + product(bool, FastTLABRefill, false, \ + "(Deprecated) Use fast TLAB refill code") \ \ From matcdac at gmail.com Mon Nov 13 15:27:14 2017 From: matcdac at gmail.com (Prakhar Makhija) Date: Mon, 13 Nov 2017 20:57:14 +0530 Subject: Require some insight regarding Objects Message-ID: *json* {"subCategory":"European","bornLocation":"Pondicherry","name":"Goldi Heathers","someSocialStatus":"Active","prefferedCategory":"Within City","dateOfBeingBorn":"16/11/1987","interestedActivity":"Business","personalEarnings":500000.0,"matchfulDesiredEarnings":1000000.0,"identificationNumber":"X582TQ0170TF47002UTD087X74","prefferedClass":"Private","addressState":"Andaman and Nicobar Islands","someAddress":"House Number 143, Near Pie Beach, Port Blair, Andaman and Nicobar Islands, India - 744101","interestedActivityCode":72681.0,"emailId":"munchymuffin at gmail.com"} *class definition* public class MyClass { private String identificationNumber; private String name; private String someAddress; private String addressState; private String bornLocation; private String someSocialStatus; private String prefferedClass; private String prefferedCategory; private String subCategory; private String dateOfBeingBorn; private String interestedActivity; private Double interestedActivityCode; private Double personalEarnings; private Double matchfulDesiredEarnings; private String emailId; // getters & setters // constructors } *code block* import com.fasterxml.jackson.databind.ObjectMapper; ObjectMapper objectMapper = new ObjectMapper(); MyClass myClassObj = objectMapper.readValue(currentLine.getBytes(), MyClass.class); *topic* Likewise having 1.5 million json files Total size which they are occupying on disk is 940 Mega Bytes My first doubt is when I load all these json, to make objects out of them, will they occupy the same space in the memory? My second doubt is about what is going on internally in the JVM's memory, when I am making 1.5 million objects of MyClass. Lets pick one identifier 'identificationNumber', it has 20 characters. So just this field 'identificationNumber' is going to occupy 40 bytes only, or (40 * 1,500,000) = 60,000,000 bytes = 57.22 MB ???? PS : I am not aware which mailing list should be concerned with this kind of query, could you direct me to them, if you are not aware of what I am asking. From stefanocristalli at gmail.com Mon Nov 13 15:37:38 2017 From: stefanocristalli at gmail.com (Stefano Cristalli) Date: Mon, 13 Nov 2017 16:37:38 +0100 Subject: Logging all method calls by modifying OpenJDK Message-ID: Hello everyone, please pardon the duplicated request (https://stackoverflow.com/questions/47267178/logging-all-method-calls-by-modifying-openjdk) from StackOverflow, but I thought I'd also post here considering how specific the questions are. I'm trying to modify the OpenJDK 9 in order to log every method called by a Java program, in particular I'm experimenting with a very simple class with a main that calls one of its own static methods that prints a line on stdout once every two seconds (waiting done with Thread.sleep) After reading a blog post (https://gbenson.net/?p=118), I've put logging code inside javaCalls::call. It works, logging lots of calls from the JVM start up to the call to Myclass.main, then it stops (my program keeps printing). After exiting the program with CTRL^C, the logging resumes and logs methods such as Thread.exit. I then tried another way: to instrument hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp at every bytecode for invoke. Worse than before, this doesn't print anything. At first I was relying on the new JDK 9 logging feature, but then I decided to append directly to file to exclude the possibility that the log was disabled at some point. I have two questions: - Have I misinterpreted the cited blog? Shouldn't my first attempt be enough to log everything? - Do you have any suggestion for a point where I have better chances of accomplishing my goal? Am I missing something? Thank you in advance for your time. Best regards. Stefano Cristalli From rkennke at redhat.com Mon Nov 13 17:10:06 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 13 Nov 2017 18:10:06 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A05D3D0.9040707@oracle.com> References: <5A048993.2000002@oracle.com> <63c96b68-88a6-5104-c9fb-5105a77d3440@redhat.com> <5A05D3D0.9040707@oracle.com> Message-ID: <48b77dfa-fa76-154a-87d6-e84dd816d1ea@redhat.com> Hi Erik, > Hi Roman, > > On 2017-11-10 16:01, Roman Kennke wrote: >> Hi Erik, >> >> This looks very good to me. It is likely that we'll need to extend it >> a little bit for Shenandoah, but I haven't got around to try that out >> yet, and will propose it when this patch percolated down to the >> Shenandoah project. > > Yes. The framework should be quite flexible, and of course I will work > with you on anything that needs to be updated. Perfect! >> Questions (I know I've asked some of it before in private discussions): >> - A BarrierSet needs to declare an AccessBarrier inner class. How >> does this get 'registered' with the Access dispatcher? > > Good question. Each new GC is tied together at one single point. The > Access API picks up GCs from the gc/shared/barrierSetConfig.hpp and > .inline.hpp files. > > So to register a new GC, such as Shenandoah, you have to: > > 1) Make sure you have a BarrierSet enum value which is added to the > list of FOR_EACH_BARRIER_SET_DO as well as > FOR_EACH_CONCRETE_BARRIER_SET_DO in barrierSetConfig.hpp. > > The first of said lists contains all barrier sets that are known to > exist at build time, and the second of said lists crucially contains > concrete barrier sets that have an AccessBarrier to resolve. > > 2) You also need to make sure in the barrierSetConfig.inline.hpp file > that you #include your shenandoah BarrierSet inline.hpp file. > > 3) You have to provide a specialization for the BarrierSet::GetName > and BarrierSet::GetType metafunctions that provide an enum value for a > barrier set type, and vice versa. > > 4) Since you probably want primitive accesses in the heap to also > resolve into the barrier set in a build that includes Shenandoah, you > should #define SUPPORT_BARRIER_ON_PRIMITIVES in the > barrierSetConfig.hpp file when building with Shenandoah. This will > flick on the INTERNAL_BT_BARRIER_ON_PRIMITIVES decorator to each > access so that the Access framework understands that even primitive > accesses must be resolved at run-time in the barrier set. So this is a > build-time switch for turning on run-time resolution of primitive > accesses in the heap. > > And now you should be set: your new > ShenandoahBarrierSet::AccessBarrier will be called for each access, > including primitives. > > It works the following way: > > 1) The barrier resolver loads the current barrier set, and checks the > "name" of it (the enum value). > 2) Each "name" for concrete barriers that you listed in > barrierSetConfig.hpp is asked for... > 3) ...the BarrierSet::GetType of that enum "name", and... > 4) The AccessBarrier of that resulting BarrierSet (your > ShenandoahBarrierSet) will be called. > > Hope that makes sense. > It is ok. But just so. ;-) The problem is that it is a bit mystical how stuff is set up, and I'd prefer a more explicit way to do it. Maybe add the above explanations (how to make new GC barriers) in a comment somewhere? >> - I see you use namespace. I haven't seen them anywhere else in >> Hotspot, so this looks quite unusual :-) Not that I am against it (I >> would probably advocate for using more of it), but have you >> considered alternatives that look more common Hotspot-style (e.g. >> declaring an all-static AccessInternal class)? > > We do not have any platform that has problems with namespaces. So I > would prefer this basic namespace usage to a bunch of AllStatic > classes. I hope nobody minds that. > I am ok with it. >> - The dispatching machinery looks a bit over the top, and from the >> outskirts like a manual re-invention of virtual method dispatch. >> Couldn't we do the same stuff with the usual public interface / >> concrete implementation idioms? I am worried that adding just one >> method to the interface turns into a nightmare of wiring up stuff and >> adding tons of boilerplate to get it going. Not to mention the >> learning curve involved trying to make sense of what goes where. > > It's not quite like a normal virtual call though. It's a virtual > dispatch that carries template parameters through the runtime > dispatch. The template parameters are required for 1) remembering the > decorators (semantics of the access), and 2) the type information of > the operands for the access. > > In my experience, when you need to drag template parameters through > some form of virtual dispatch, it is easiest to use function pointers > and not virtual calls. > I understand it might look a bit complicated, but I hope that is okay. Right. Templates and virtual doesn't play well (or at all) together. I've seen that the GC interface JEP just went to 'targeted' so I guess you can push it (probably needs more review?) Roman From david.holmes at oracle.com Mon Nov 13 21:30:08 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Nov 2017 07:30:08 +1000 Subject: RFR: 8190925: Deprecate FastTLABRefill and set default off In-Reply-To: <27bd5099-c40b-ff24-d597-e9de5c549f83@oracle.com> References: <27bd5099-c40b-ff24-d597-e9de5c549f83@oracle.com> Message-ID: <1cb363fc-3910-02e2-94d0-3edfadfd7ca9@oracle.com> Looks good! Thanks, David On 13/11/2017 11:33 PM, Robbin Ehn wrote: > Hi all, please review. > > The option FastTLABRefill work only in C1 (interpreter and c2 don't use > this option) when using either SerialGC or ParrallelGC (and deprecated > CMS). Both the newly integrated Memory-Leak Profiler and upcoming Low > Overhead Profiler don't work when FastTLABRefill is enabled. > > For more info please see CSR: > https://bugs.openjdk.java.net/browse/JDK-8190926 > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8190925 > > Code below, thanks Robbin! > > diff -r cf127be65014 src/hotspot/share/runtime/arguments.cpp > --- a/src/hotspot/share/runtime/arguments.cpp??? Sat Nov 11 01:21:09 > 2017 +0100 > +++ b/src/hotspot/share/runtime/arguments.cpp??? Mon Nov 13 14:26:27 > 2017 +0100 > @@ -385,2 +385,3 @@ > ?? { "UseMembar",??????????????????? JDK_Version::jdk(10), > JDK_Version::jdk(11), JDK_Version::jdk(12) }, > +? { "FastTLABRefill",?????????????? JDK_Version::jdk(10), > JDK_Version::jdk(11), JDK_Version::jdk(12) }, > ?? { "IgnoreUnverifiableClassesDuringDump", JDK_Version::jdk(10), > JDK_Version::undefined(), JDK_Version::undefined() }, > diff -r cf127be65014 src/hotspot/share/runtime/globals.hpp > --- a/src/hotspot/share/runtime/globals.hpp??? Sat Nov 11 01:21:09 2017 > +0100 > +++ b/src/hotspot/share/runtime/globals.hpp??? Mon Nov 13 14:26:27 2017 > +0100 > @@ -2015,4 +2015,4 @@ > ???????????????????????????????????????????????????????????????????????????? \ > -? product(bool, FastTLABRefill, > true,?????????????????????????????????????? \ > -????????? "Use fast TLAB refill > code")????????????????????????????????????? \ > +? product(bool, FastTLABRefill, > false,????????????????????????????????????? \ > +????????? "(Deprecated) Use fast TLAB refill > code")???????????????????????? \ > ???????????????????????????????????????????????????????????????????????????? \ From david.holmes at oracle.com Mon Nov 13 21:36:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 Nov 2017 07:36:27 +1000 Subject: Logging all method calls by modifying OpenJDK In-Reply-To: References: Message-ID: <9f1b9862-7347-4abf-27d6-33d1550ab8f1@oracle.com> Hi Stefano, It sounds like javaCalls::call is used primarily on interpreted code paths, so once code has been running long enough and gets compiled you no longer go through your logging code. If you run with -Xint you should see all logging; if you run with -Xcomp you should see much less. Modifying the JIT compiler to include the additional logging is probably quite complicated - and that's not even taking inlining into account. David On 14/11/2017 1:37 AM, Stefano Cristalli wrote: > Hello everyone, > > please pardon the duplicated request > (https://stackoverflow.com/questions/47267178/logging-all-method-calls-by-modifying-openjdk) > from StackOverflow, but I thought I'd also post here considering how > specific the questions are. > > I'm trying to modify the OpenJDK 9 in order to log every method called > by a Java program, in particular I'm experimenting with a very simple > class with a main that calls one of its own static methods that prints > a line on stdout once every two seconds (waiting done with > Thread.sleep) After reading a blog post (https://gbenson.net/?p=118), > I've put logging code inside javaCalls::call. It works, logging lots > of calls from the JVM start up to the call to Myclass.main, then it > stops (my program keeps printing). After exiting the program with > CTRL^C, the logging resumes and logs methods such as Thread.exit. I > then tried another way: to instrument > hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp at every > bytecode for invoke. Worse than before, this doesn't print anything. > > At first I was relying on the new JDK 9 logging feature, but then I > decided to append directly to file to exclude the possibility that the > log was disabled at some point. > > I have two questions: > > - Have I misinterpreted the cited blog? Shouldn't my first attempt be > enough to log everything? > - Do you have any suggestion for a point where I have better chances > of accomplishing my goal? > > Am I missing something? > Thank you in advance for your time. > > Best regards. > > Stefano Cristalli > From coleen.phillimore at oracle.com Tue Nov 14 01:34:49 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 13 Nov 2017 20:34:49 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A048993.2000002@oracle.com> References: <5A048993.2000002@oracle.com> Message-ID: <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/src/hotspot/share/classfile/javaClasses.cpp.udiff.html + assert(!is_reference || InstanceKlass::cast(obj->klass())->is_subclass_of(SystemDictionary::Reference_klass()), "sanity"); Can you do something like this instead of all the InstanceKlass::cast. + InstanceKlass* k = InstanceKlass::cast(obj->klass()); + bool is_reference = k->reference_type() != REF_NONE; + assert(!is_reference || k->is_subclass_of(SystemDictionary::Reference_klass()), "sanity"); + return is_reference; +} And do you know that this is an instance rather than array instance?? InstanceKlass::cast() has an assert that is_instance_klass(). http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/src/hotspot/share/oops/klass.cpp.udiff.html Revert file with only one line removed. http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/src/hotspot/share/runtime/access.hpp.html 240 template 241 struct OopOrNarrowOopInternal: AllStatic { 242 typedef oop type; 243 }; 244 245 template <> 246 struct OopOrNarrowOopInternal: AllStatic { 247 typedef narrowOop type; 248 }; 249 Kim and I agree that we should not have the default template definition for oop and have two specializations instead.? Mostly I agree because this is confusing. 240 template 241 struct OopOrNarrowOopInternal; 240 template <> 241 struct OopOrNarrowOopInternal: AllStatic { 242 typedef oop type; 243 }; 244 245 template <> 246 struct OopOrNarrowOopInternal: AllStatic { 247 typedef narrowOop type; 248 }; 249 We were also trying to figure out how the runtime would know whether to use IN_CONCURRENT_ROOT vs IN_ROOT decorator, since it probably varies for GCs.? And requires runtime code to know whether the root is scanned concurrently or not, which we don't know. This is all I have for now but I'm going to download the patch and have more of a look tomorrow. Thanks, Coleen On 11/9/17 12:00 PM, Erik ?sterlund wrote: > Hi, > > In an effort to remove explicit calls to GC barriers (and other > orthogonal forms of barriers, like encoding/decoding oops for > compressed oops and fencing for memory ordering), I have built an API > that I call "Access". Its purpose is to perform accesses with > declarative semantics, to handle multiple orthogonal concerns that > affect how an access is performed, including memory ordering, > compressed oops, GC barriers for marking, reference strength, etc, and > as a result making GCs more modular, and as a result allow new > concurrently compacting GC schemes utilizing load barriers to live in > harmony in hotspot without everyone going crazy manually inserting > barriers if UseBlahGC is enabled. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8189871 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ > > So there are three views of this I suppose: > > 1) The frontend: how this is actually used in shared code > 2) The backends: how anyone writing a GC sticks their required > barriers in there > 3) The internals: how accesses find their way from the frontend to the > corresponding backend > > == Frontend == > > Let's start with the frontend. I hope I made this fairly simple! You > can find it in runtime/access.hpp > Each access annotates its declarative semantics with a set of > "decorators", which is the name of the attributes/properties affecting > how an access is performed. > There is an Access API that makes the declarative semantics > possible. > > For example, if I want to perform a load acquire of an oop in the heap > that has "weak" strength, I would do something like: > oop result = Access ON_WEAK_OOP_REF>::oop_load_at(obj, offset); > > The Access API would then send the access through some GC backend, > that overrides the whole access and tells it to perform a "raw" load > acquire, and then possibly keep it alive if necessary (G1 SATB enqueue > barriers). > > To make life easier, there are some helpers for the most common access > patterns that merely add some default decorator for the involved type > of access. For example, there is a RawAccess for performing AS_RAW > accesses (that bypasses runtime checks and GC barriers), HeapAccess > sets the IN_HEAP decorator and RootAccess sets the IN_ROOT decorator > for accessing root oops. So for the previous call, I could simply do: > > oop result = HeapAccess ON_WEAK_OOP_REF>::oop_load_at(obj, offset); > > The access.hpp file introduces each decorator (belonging to some > category) with an explanation what it is for. It also introduces all > operations you can make with access (loads, stores, cmpxchg, xchg, > arraycopy and clone). > > This changeset mostly introduces the Access API but is not complete in > annotating the code more than where it gets very awkward if I don't. > > == Backend == > > For a GC maintainer, the BarrierSet::AccessBarrier is the top level > backend that provides basic accesses that may be overridden. By > default, it just performs raw accesses without any GC barriers, that > handle things like compressed oops and memory ordering only. The > ModRef barrier set introduces the notion of pre/post write barriers, > that can be overridden for each GC. The CardTableModRef barrier set > overrides the post write barrier to mark cards, and G1 overrides it to > mark cards slightly differently and do some SATB enqueueing. G1 also > overrides loads to see if we need to perform SATB enqueue on weak > references. > > The raw accesses go to the RawAccessBarrier (living in > accessBackend.hpp) that performs the actual accesses. It connects to > Atomic and OrderAccess for accesses that require that. > > == Internals == > > Internally, the accesses go through a number of stages in > access.inline.hpp as documented at the top. > > 1) set default decorators and get rid of CV qualifiers etc. Sanity > checking also happens here: we check that the decorators make sense > for the access being performed, and that the passed in types are not > bogus. > 2) reduce types so if we have a different type of the address and > value, then either it is not allowed or it implies we use compressed > oops and remember that we know something about whether compressed oops > are used or not, before erasing address type > 3) pre-runtime dispatch: figure out if all runtime checks can be > bypassed into a raw access > 4) runtime dispatch: send the access through a function pointer that > upon the first invocation resolves the intended GC AccessBarrier > accessor on the BarrierSet that handles this access, as well as > figures out whether we are using compressed oops or not while we are > at it, and then calls it through the post-runtime dispatch > 5) post-runtime dispatch: fix some erased types that were not known at > compile time such as whether the address is a narrowOop* or oop* > depending on whether compressed oops was selected at runtime or not, > and call the resolved BarrierSet::AccessBarrier accessor > (load/store/etc) with all the call-site build-time and run-time > resolved decorators and type information that describes the access. > > Testing: mach5 tier1-5 > > Thanks, > /Erik From kim.barrett at oracle.com Tue Nov 14 04:24:24 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 13 Nov 2017 23:24:24 -0500 Subject: RFR (S) 8190891: Clean up G1 barrier code in compiler interface (ci) In-Reply-To: References: <608846ee-75ed-0858-c0e9-14bb2e533c30@oracle.com> <60F0F1A3-9D70-4F00-B108-3E8D48DA2DFC@oracle.com> Message-ID: > On Nov 8, 2017, at 2:58 PM, coleen.phillimore at oracle.com wrote: > > > Kim, > > Thank you for revewing. > > On 11/8/17 2:28 PM, Kim Barrett wrote: >>> On Nov 7, 2017, at 7:38 PM, coleen.phillimore at oracle.com wrote: >>> >>> Summary: consolidate gc barrier code in ci >>> >>> See bug and comments for more details. >>> >>> Tested with mach5 tier1-5 on linux x64 and iwndows x64. Also tested StressRedefineWithoutBytecodeModification in test/jdk/java/lang/instrument which fails without the g1 barriers. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8190891.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8190891 >>> >>> Thanks, >>> Coleen >> ------------------------------------------------------------------------------ >> src/hotspot/share/ci/ciInstanceKlass.cpp >> 55 static void ensure_metadata_alive(oop metadata_holder) { >> ... >> 60 if (metadata_holder != NULL) { >> >> When would we ever get a ciInstanceKlass for a Klass with a NULL >> holder? That seems like a situation that shouldn't ever happen, and >> this should be an assert instead. And there is an assert here > > When it's the NULL class loader, associated with ClassLoaderData::the_null_class_loader_data(). This class loader is never unloaded. >> >> 75 assert(get_instanceKlass()->is_loaded(), "must be at least loaded"); >> >> that dominates the ensure_metadata_alive call that is similarly >> suggestive. Though I'm not sure whether is_loaded can be true if the >> klass was loaded and then later had its holder die and be cleared. > > Not sure I understand this comment. The InstanceKlass must be in the "loaded" _init_state to get to this code, but the marking for ensure_metadata_alive and creating an object prevents it from being unloaded after this point. >> >> And can the call to get_object at line 99 cope with a NULL holder? > > No anonymous class's holders are the mirror which cannot be null. I can add this before line 99: > > assert(holder != NULL, "holder of anonymous class is the mirror which is never null"); > >> >> Basically I'm questioning whether the ik->klass_holder() on line 91 >> can ever legitimately return NULL. > > Yes it can and does. I see; I was confused by some potential future changes that we've discussed. There may need to be further changes in this area later, but those changes are likely made easier by this one, and in the meantime this looks good. From robbin.ehn at oracle.com Tue Nov 14 08:56:53 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 14 Nov 2017 09:56:53 +0100 Subject: RFR: 8190925: Deprecate FastTLABRefill and set default off In-Reply-To: <1cb363fc-3910-02e2-94d0-3edfadfd7ca9@oracle.com> References: <27bd5099-c40b-ff24-d597-e9de5c549f83@oracle.com> <1cb363fc-3910-02e2-94d0-3edfadfd7ca9@oracle.com> Message-ID: <3d3529a1-c9bc-d455-2059-dabc612a8739@oracle.com> Thanks! /Robbin On 11/13/2017 10:30 PM, David Holmes wrote: > Looks good! > > Thanks, > David > > On 13/11/2017 11:33 PM, Robbin Ehn wrote: >> Hi all, please review. >> >> The option FastTLABRefill work only in C1 (interpreter and c2 don't use this >> option) when using either SerialGC or ParrallelGC (and deprecated CMS). Both >> the newly integrated Memory-Leak Profiler and upcoming Low Overhead Profiler >> don't work when FastTLABRefill is enabled. >> >> For more info please see CSR: >> https://bugs.openjdk.java.net/browse/JDK-8190926 >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8190925 >> >> Code below, thanks Robbin! >> >> diff -r cf127be65014 src/hotspot/share/runtime/arguments.cpp >> --- a/src/hotspot/share/runtime/arguments.cpp??? Sat Nov 11 01:21:09 2017 +0100 >> +++ b/src/hotspot/share/runtime/arguments.cpp??? Mon Nov 13 14:26:27 2017 +0100 >> @@ -385,2 +385,3 @@ >> ??? { "UseMembar",??????????????????? JDK_Version::jdk(10), >> JDK_Version::jdk(11), JDK_Version::jdk(12) }, >> +? { "FastTLABRefill",?????????????? JDK_Version::jdk(10), >> JDK_Version::jdk(11), JDK_Version::jdk(12) }, >> ??? { "IgnoreUnverifiableClassesDuringDump", JDK_Version::jdk(10), >> JDK_Version::undefined(), JDK_Version::undefined() }, >> diff -r cf127be65014 src/hotspot/share/runtime/globals.hpp >> --- a/src/hotspot/share/runtime/globals.hpp??? Sat Nov 11 01:21:09 2017 +0100 >> +++ b/src/hotspot/share/runtime/globals.hpp??? Mon Nov 13 14:26:27 2017 +0100 >> @@ -2015,4 +2015,4 @@ >> ????????????????????????????????????????????????????????????????????????????? \ >> -? product(bool, FastTLABRefill, true,?????????????????????????????????????? \ >> -????????? "Use fast TLAB refill code")????????????????????????????????????? \ >> +? product(bool, FastTLABRefill, false,????????????????????????????????????? \ >> +????????? "(Deprecated) Use fast TLAB refill code")???????????????????????? \ >> ????????????????????????????????????????????????????????????????????????????? \ From marcus.larsson at oracle.com Tue Nov 14 08:57:21 2017 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 14 Nov 2017 09:57:21 +0100 Subject: RFR: 8190925: Deprecate FastTLABRefill and set default off In-Reply-To: <27bd5099-c40b-ff24-d597-e9de5c549f83@oracle.com> References: <27bd5099-c40b-ff24-d597-e9de5c549f83@oracle.com> Message-ID: <2ca31399-803e-5858-8788-0b6ee56738d0@oracle.com> Looks good! Thanks, Marcus On 2017-11-13 14:33, Robbin Ehn wrote: > Hi all, please review. > > The option FastTLABRefill work only in C1 (interpreter and c2 don't > use this option) when using either SerialGC or ParrallelGC (and > deprecated CMS). Both the newly integrated Memory-Leak Profiler and > upcoming Low Overhead Profiler don't work when FastTLABRefill is enabled. > > For more info please see CSR: > https://bugs.openjdk.java.net/browse/JDK-8190926 > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8190925 > > Code below, thanks Robbin! > > diff -r cf127be65014 src/hotspot/share/runtime/arguments.cpp > --- a/src/hotspot/share/runtime/arguments.cpp??? Sat Nov 11 01:21:09 > 2017 +0100 > +++ b/src/hotspot/share/runtime/arguments.cpp??? Mon Nov 13 14:26:27 > 2017 +0100 > @@ -385,2 +385,3 @@ > ?? { "UseMembar",??????????????????? JDK_Version::jdk(10), > JDK_Version::jdk(11), JDK_Version::jdk(12) }, > +? { "FastTLABRefill",?????????????? JDK_Version::jdk(10), > JDK_Version::jdk(11), JDK_Version::jdk(12) }, > ?? { "IgnoreUnverifiableClassesDuringDump", JDK_Version::jdk(10), > JDK_Version::undefined(), JDK_Version::undefined() }, > diff -r cf127be65014 src/hotspot/share/runtime/globals.hpp > --- a/src/hotspot/share/runtime/globals.hpp??? Sat Nov 11 01:21:09 > 2017 +0100 > +++ b/src/hotspot/share/runtime/globals.hpp??? Mon Nov 13 14:26:27 > 2017 +0100 > @@ -2015,4 +2015,4 @@ > \ > -? product(bool, FastTLABRefill, > true,?????????????????????????????????????? \ > -????????? "Use fast TLAB refill > code")????????????????????????????????????? \ > +? product(bool, FastTLABRefill, > false,????????????????????????????????????? \ > +????????? "(Deprecated) Use fast TLAB refill > code")???????????????????????? \ > \ From robbin.ehn at oracle.com Tue Nov 14 09:08:46 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 14 Nov 2017 10:08:46 +0100 Subject: RFR: 8190925: Deprecate FastTLABRefill and set default off In-Reply-To: <2ca31399-803e-5858-8788-0b6ee56738d0@oracle.com> References: <27bd5099-c40b-ff24-d597-e9de5c549f83@oracle.com> <2ca31399-803e-5858-8788-0b6ee56738d0@oracle.com> Message-ID: <2b726463-0618-62e6-7b25-8f000f0341ab@oracle.com> Thanks Marcus! /Robbin On 11/14/2017 09:57 AM, Marcus Larsson wrote: > Looks good! > > Thanks, > Marcus > > > On 2017-11-13 14:33, Robbin Ehn wrote: >> Hi all, please review. >> >> The option FastTLABRefill work only in C1 (interpreter and c2 don't use this >> option) when using either SerialGC or ParrallelGC (and deprecated CMS). Both >> the newly integrated Memory-Leak Profiler and upcoming Low Overhead Profiler >> don't work when FastTLABRefill is enabled. >> >> For more info please see CSR: >> https://bugs.openjdk.java.net/browse/JDK-8190926 >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8190925 >> >> Code below, thanks Robbin! >> >> diff -r cf127be65014 src/hotspot/share/runtime/arguments.cpp >> --- a/src/hotspot/share/runtime/arguments.cpp??? Sat Nov 11 01:21:09 2017 +0100 >> +++ b/src/hotspot/share/runtime/arguments.cpp??? Mon Nov 13 14:26:27 2017 +0100 >> @@ -385,2 +385,3 @@ >> ?? { "UseMembar",??????????????????? JDK_Version::jdk(10), >> JDK_Version::jdk(11), JDK_Version::jdk(12) }, >> +? { "FastTLABRefill",?????????????? JDK_Version::jdk(10), >> JDK_Version::jdk(11), JDK_Version::jdk(12) }, >> ?? { "IgnoreUnverifiableClassesDuringDump", JDK_Version::jdk(10), >> JDK_Version::undefined(), JDK_Version::undefined() }, >> diff -r cf127be65014 src/hotspot/share/runtime/globals.hpp >> --- a/src/hotspot/share/runtime/globals.hpp??? Sat Nov 11 01:21:09 2017 +0100 >> +++ b/src/hotspot/share/runtime/globals.hpp??? Mon Nov 13 14:26:27 2017 +0100 >> @@ -2015,4 +2015,4 @@ >> \ >> -? product(bool, FastTLABRefill, true,?????????????????????????????????????? \ >> -????????? "Use fast TLAB refill code")????????????????????????????????????? \ >> +? product(bool, FastTLABRefill, false,????????????????????????????????????? \ >> +????????? "(Deprecated) Use fast TLAB refill code")???????????????????????? \ >> \ > From adinn at redhat.com Tue Nov 14 09:39:31 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 14 Nov 2017 09:39:31 +0000 Subject: Logging all method calls by modifying OpenJDK In-Reply-To: References: Message-ID: <5dce6059-7e82-3a99-0ebd-f04fdf946f73@redhat.com> On 13/11/17 15:37, Stefano Cristalli wrote: > I'm trying to modify the OpenJDK 9 in order to log every method called > by a Java program, in particular I'm experimenting with a very simple > class with a main that calls one of its own static methods that prints > a line on stdout once every two seconds (waiting done with > Thread.sleep) After reading a blog post (https://gbenson.net/?p=118), > I've put logging code inside javaCalls::call. It works, logging lots > of calls from the JVM start up to the call to Myclass.main, then it > stops (my program keeps printing). After exiting the program with > CTRL^C, the logging resumes and logs methods such as Thread.exit. I > then tried another way: to instrument > hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp at every > bytecode for invoke. Worse than before, this doesn't print anything. I am very sceptical of your claim here. Is this really all you have changed. I say that because (as Gary's post notes) JavaCalls::call is the C++ method which performs a transition into Java from C++. That happens at least once in a Java thread lifetime when the thread is started (so, for example, at the transition into your main class's main method). It may also be called recursively in the same thread, but only if that thread calls out to a C++ method of the JVM and the JVM then calls back into Java. However, that is the rare case not the normal case. For example, it might happen because, say, execution of a Java method triggers a class load. In that case JVM code may be invoked to create and resolve the class and the JVM may re-enter Java to run the class static initializer. Normal Java to Java calls will *not* go via JavaCalls::call either in interpreted code or in compiled code. So, logging from this point will only show you a *very* partial subset of the Java execution tree. > I have two questions: > > - Have I misinterpreted the cited blog? Shouldn't my first attempt be > enough to log everything? No, it should not. > - Do you have any suggestion for a point where I have better chances > of accomplishing my goal? Run in interpreted mode (-Xint) and add tracing to the template interpreter snippets that handles method invocation and method return. It's complicated code so expect to spend quite some time understanding how it works. Also, much of the code is architecture-specific so as well as looking at the generic code in hotspot/src/share/vm/interpreter/*.[ch]pp you may need to make changes to code in hotspot/src/cpu/xxx/vm/*.[ch]pp where xxx is your preferred cpu (probably x86 but you never know :-). Start looking at files with the word 'template' in then. The'template' interpreter is the one currently in use. The alternative 'bytecode' interpreter is a legacy interpreter written mostly in C++ so changing it will not help you. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From magnus.ihse.bursie at oracle.com Tue Nov 14 13:06:12 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 14 Nov 2017 14:06:12 +0100 Subject: RFR: JDK-8190418 Stop generating jvmtiEnvStub and jvmtiEnvRecommended Message-ID: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> During hotspot gensrc, we create two files, jvmtiEnvStub and jvmtiEnvRecommended, which later on are explicitly excluded from the build. We should just stop generating them. I have built hotspot with and without this patch, and used the build comparison script (compare.sh) to verify that it has not changed. Bug: https://bugs.openjdk.java.net/browse/JDK-8190418 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8190418-stop-generating-unneeded-jvmti-files/webrev.01 /Magnus From coleen.phillimore at oracle.com Tue Nov 14 13:57:02 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 14 Nov 2017 08:57:02 -0500 Subject: RFR (S) 8190891: Clean up G1 barrier code in compiler interface (ci) In-Reply-To: References: <608846ee-75ed-0858-c0e9-14bb2e533c30@oracle.com> <60F0F1A3-9D70-4F00-B108-3E8D48DA2DFC@oracle.com> Message-ID: <02a6ab23-6d16-4242-95a4-52cd2934b703@oracle.com> Thanks Kim! Coleen On 11/13/17 11:24 PM, Kim Barrett wrote: >> On Nov 8, 2017, at 2:58 PM, coleen.phillimore at oracle.com wrote: >> >> >> Kim, >> >> Thank you for revewing. >> >> On 11/8/17 2:28 PM, Kim Barrett wrote: >>>> On Nov 7, 2017, at 7:38 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> Summary: consolidate gc barrier code in ci >>>> >>>> See bug and comments for more details. >>>> >>>> Tested with mach5 tier1-5 on linux x64 and iwndows x64. Also tested StressRedefineWithoutBytecodeModification in test/jdk/java/lang/instrument which fails without the g1 barriers. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8190891.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8190891 >>>> >>>> Thanks, >>>> Coleen >>> ------------------------------------------------------------------------------ >>> src/hotspot/share/ci/ciInstanceKlass.cpp >>> 55 static void ensure_metadata_alive(oop metadata_holder) { >>> ... >>> 60 if (metadata_holder != NULL) { >>> >>> When would we ever get a ciInstanceKlass for a Klass with a NULL >>> holder? That seems like a situation that shouldn't ever happen, and >>> this should be an assert instead. And there is an assert here >> When it's the NULL class loader, associated with ClassLoaderData::the_null_class_loader_data(). This class loader is never unloaded. >>> 75 assert(get_instanceKlass()->is_loaded(), "must be at least loaded"); >>> >>> that dominates the ensure_metadata_alive call that is similarly >>> suggestive. Though I'm not sure whether is_loaded can be true if the >>> klass was loaded and then later had its holder die and be cleared. >> Not sure I understand this comment. The InstanceKlass must be in the "loaded" _init_state to get to this code, but the marking for ensure_metadata_alive and creating an object prevents it from being unloaded after this point. >>> And can the call to get_object at line 99 cope with a NULL holder? >> No anonymous class's holders are the mirror which cannot be null. I can add this before line 99: >> >> assert(holder != NULL, "holder of anonymous class is the mirror which is never null"); >> >>> Basically I'm questioning whether the ik->klass_holder() on line 91 >>> can ever legitimately return NULL. >> Yes it can and does. > I see; I was confused by some potential future changes that we've > discussed. There may need to be further changes in this area later, > but those changes are likely made easier by this one, and in the > meantime this looks good. > From erik.joelsson at oracle.com Tue Nov 14 18:22:45 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Nov 2017 10:22:45 -0800 Subject: RFR: JDK-8190418 Stop generating jvmtiEnvStub and jvmtiEnvRecommended In-Reply-To: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> References: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> Message-ID: <044a3b25-44c3-12d2-530f-3e7aef2f5e32@oracle.com> Fantastic build logic. Looks good. /Erik On 2017-11-14 05:06, Magnus Ihse Bursie wrote: > During hotspot gensrc, we create two files, jvmtiEnvStub and > jvmtiEnvRecommended, which later on are explicitly excluded from the > build. We should just stop generating them. > > I have built hotspot with and without this patch, and used the build > comparison script (compare.sh) to verify that it has not changed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190418 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8190418-stop-generating-unneeded-jvmti-files/webrev.01 > > /Magnus > From tim.bell at oracle.com Tue Nov 14 17:57:12 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 14 Nov 2017 09:57:12 -0800 Subject: RFR: JDK-8190418 Stop generating jvmtiEnvStub and jvmtiEnvRecommended In-Reply-To: <044a3b25-44c3-12d2-530f-3e7aef2f5e32@oracle.com> References: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> <044a3b25-44c3-12d2-530f-3e7aef2f5e32@oracle.com> Message-ID: <5A0B2E78.7060606@oracle.com> Looks good to me as well. That is much cleaner. Tim On 11/14/17 10:22, Erik Joelsson wrote: > Fantastic build logic. Looks good. > > /Erik > > > On 2017-11-14 05:06, Magnus Ihse Bursie wrote: >> During hotspot gensrc, we create two files, jvmtiEnvStub and >> jvmtiEnvRecommended, which later on are explicitly excluded from the >> build. We should just stop generating them. >> >> I have built hotspot with and without this patch, and used the build >> comparison script (compare.sh) to verify that it has not changed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190418 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8190418-stop-generating-unneeded-jvmti-files/webrev.01 >> >> >> /Magnus >> > From chris.plummer at oracle.com Tue Nov 14 20:44:16 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 14 Nov 2017 12:44:16 -0800 Subject: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source In-Reply-To: References: <8a608fa8-eece-3aeb-1866-5ba75719c09b@oracle.com> Message-ID: <47ac2091-626c-97ea-f34e-8fee092e3315@oracle.com> [Resending. Didn't seem to get posted first time.] Hi Thomas, Thanks for the review. Can I get one more reviewer please? thanks, Chris On 11/10/17 11:35 PM, Thomas St?fe wrote: > Oh, you are right, I should have seen this. Knowing this, forget my > worries about stability. Sorry for the noise :) > > ..Thomas > > On Fri, Nov 10, 2017 at 11:47 PM, Chris Plummer > > wrote: > > It's already restricted to non-product builds, but I'll add a > comment also. > > thanks, > > Chris > > > On 11/10/17 1:27 PM, Thomas St?fe wrote: >> Hi Chris, >> >> Thank you. Yes, a comment may make sense, and/or restricting this >> function to not product. Otherwise the change is fine and useful, >> I?ll use it probably before long. >> >> Thanks, Thomas >> >> On Fri 10. Nov 2017 at 21:55, Chris Plummer >> > wrote: >> >> Hi Thomas, >> >> There's certainly no intent to leave in place any calls >> someone might add to pns2(). It's meant as a temporary >> debugging aide only. So if it were to fail for any reason, >> IMO that's no different than adding any other sort of >> temporary debugging code that could possibly crash. You fix >> your mistake and resume your debugging. If you want I can add >> comments that include such a warning. >> >> thanks, >> >> Chris >> >> >> >> On 11/10/17 12:11 AM, Thomas St?fe wrote: >>> Hi Chris, >>> >>> looks fine as a debugging aid. >>> >>> But it occurred to me that it may be a bit dangerous to call >>> this from non-errorhandler settings. I recall seeing quite a >>> few secondary crashes in VMError::print_native_stack() in >>> hs-err files over time. Especially for native non-java >>> threads. Usually this did not matter that much because these >>> crashes are handled by secondary error handling when >>> printing the hs-err file. But if we call it outside of error >>> handling, we are on our own. >>> >>> So. IMHO, to use this functions as a debugging aid is fine, >>> if one can accept a slight risk of crashing the VM. If this >>> is not acceptable, may we need some more tests for this >>> function? >>> >>> Kind Regards, Thomas >>> >>> >>> >>> On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer >>> > >>> wrote: >>> >>> Hi, >>> >>> Please review the following: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8191049 >>> >>> >>> diff --git a/src/hotspot/share/utilities/debug.cpp >>> b/src/hotspot/share/utilities/debug.cpp >>> --- a/src/hotspot/share/utilities/debug.cpp >>> +++ b/src/hotspot/share/utilities/debug.cpp >>> @@ -631,6 +631,24 @@ >>> ?? VMError::print_native_stack(tty, fr, t, buf, >>> sizeof(buf)); >>> ?} >>> >>> +// >>> +// This version of pns() will not work when called from >>> the debugger, but is >>> +// useful when called from within hotspot code. The >>> advantages over pns() >>> +// are not having to pass in any arguments, and it will >>> work on Windows/x64. >>> +// >>> +extern "C" void pns2() { // print native stack >>> +? Command c("pns2"); >>> +? static char buf[O_BUFLEN]; >>> +? if (os::platform_print_native_stack(tty, NULL, buf, >>> sizeof(buf))) { >>> +??? // We have printed the native stack in >>> platform-specific code, >>> +??? // so nothing else to do in this case. >>> +? } else { >>> +??? Thread* t = Thread::current_or_null(); >>> +??? frame fr = os::current_frame(); >>> + VMError::print_native_stack(tty, fr, t, buf, sizeof(buf)); >>> +? } >>> +} >>> + >>> ?#endif // !PRODUCT >>> >>> There is also a pre-existing thread with some discussion: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html >>> >>> >>> thanks, >>> >>> Chris >>> >>> >> > > From gerald.thornbrugh at oracle.com Tue Nov 14 20:57:09 2017 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Tue, 14 Nov 2017 13:57:09 -0700 Subject: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source In-Reply-To: <47ac2091-626c-97ea-f34e-8fee092e3315@oracle.com> References: <8a608fa8-eece-3aeb-1866-5ba75719c09b@oracle.com> <47ac2091-626c-97ea-f34e-8fee092e3315@oracle.com> Message-ID: <0D95A39D-08FF-4FA3-BF25-B5040DD6861A@oracle.com> Hi Chris, Your changes look good to me. Jerry > On Nov 14, 2017, at 1:44 PM, Chris Plummer wrote: > > [Resending. Didn't seem to get posted first time.] > > Hi Thomas, > > Thanks for the review. > > Can I get one more reviewer please? > > thanks, > > Chris > > On 11/10/17 11:35 PM, Thomas St?fe wrote: >> Oh, you are right, I should have seen this. Knowing this, forget my worries about stability. Sorry for the noise :) >> >> ..Thomas >> >> On Fri, Nov 10, 2017 at 11:47 PM, Chris Plummer > wrote: >> >> It's already restricted to non-product builds, but I'll add a >> comment also. >> >> thanks, >> >> Chris >> >> >> On 11/10/17 1:27 PM, Thomas St?fe wrote: >>> Hi Chris, >>> >>> Thank you. Yes, a comment may make sense, and/or restricting this >>> function to not product. Otherwise the change is fine and useful, >>> I?ll use it probably before long. >>> >>> Thanks, Thomas >>> >>> On Fri 10. Nov 2017 at 21:55, Chris Plummer >>> > wrote: >>> >>> Hi Thomas, >>> >>> There's certainly no intent to leave in place any calls >>> someone might add to pns2(). It's meant as a temporary >>> debugging aide only. So if it were to fail for any reason, >>> IMO that's no different than adding any other sort of >>> temporary debugging code that could possibly crash. You fix >>> your mistake and resume your debugging. If you want I can add >>> comments that include such a warning. >>> >>> thanks, >>> >>> Chris >>> >>> >>> >>> On 11/10/17 12:11 AM, Thomas St?fe wrote: >>>> Hi Chris, >>>> >>>> looks fine as a debugging aid. >>>> >>>> But it occurred to me that it may be a bit dangerous to call >>>> this from non-errorhandler settings. I recall seeing quite a >>>> few secondary crashes in VMError::print_native_stack() in >>>> hs-err files over time. Especially for native non-java >>>> threads. Usually this did not matter that much because these >>>> crashes are handled by secondary error handling when >>>> printing the hs-err file. But if we call it outside of error >>>> handling, we are on our own. >>>> >>>> So. IMHO, to use this functions as a debugging aid is fine, >>>> if one can accept a slight risk of crashing the VM. If this >>>> is not acceptable, may we need some more tests for this >>>> function? >>>> >>>> Kind Regards, Thomas >>>> >>>> >>>> >>>> On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer >>>> > >>>> wrote: >>>> >>>> Hi, >>>> >>>> Please review the following: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8191049 >>>> >>>> >>>> diff --git a/src/hotspot/share/utilities/debug.cpp >>>> b/src/hotspot/share/utilities/debug.cpp >>>> --- a/src/hotspot/share/utilities/debug.cpp >>>> +++ b/src/hotspot/share/utilities/debug.cpp >>>> @@ -631,6 +631,24 @@ >>>> VMError::print_native_stack(tty, fr, t, buf, >>>> sizeof(buf)); >>>> } >>>> >>>> +// >>>> +// This version of pns() will not work when called from >>>> the debugger, but is >>>> +// useful when called from within hotspot code. The >>>> advantages over pns() >>>> +// are not having to pass in any arguments, and it will >>>> work on Windows/x64. >>>> +// >>>> +extern "C" void pns2() { // print native stack >>>> + Command c("pns2"); >>>> + static char buf[O_BUFLEN]; >>>> + if (os::platform_print_native_stack(tty, NULL, buf, >>>> sizeof(buf))) { >>>> + // We have printed the native stack in >>>> platform-specific code, >>>> + // so nothing else to do in this case. >>>> + } else { >>>> + Thread* t = Thread::current_or_null(); >>>> + frame fr = os::current_frame(); >>>> + VMError::print_native_stack(tty, fr, t, buf, sizeof(buf)); >>>> + } >>>> +} >>>> + >>>> #endif // !PRODUCT >>>> >>>> There is also a pre-existing thread with some discussion: >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html >>>> >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >>> >> >> > > From chris.plummer at oracle.com Tue Nov 14 20:54:36 2017 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 14 Nov 2017 12:54:36 -0800 Subject: RFR(S): 8191049: Add alternate version of pns() that is callable from within hotspot source In-Reply-To: <0D95A39D-08FF-4FA3-BF25-B5040DD6861A@oracle.com> References: <8a608fa8-eece-3aeb-1866-5ba75719c09b@oracle.com> <47ac2091-626c-97ea-f34e-8fee092e3315@oracle.com> <0D95A39D-08FF-4FA3-BF25-B5040DD6861A@oracle.com> Message-ID: <619884e9-d0c0-7957-ee86-edad9b4dba04@oracle.com> Thanks Jerry! On 11/14/17 12:57 PM, Gerald Thornbrugh wrote: > Hi Chris, > > Your changes look good to me. > > Jerry > >> On Nov 14, 2017, at 1:44 PM, Chris Plummer wrote: >> >> [Resending. Didn't seem to get posted first time.] >> >> Hi Thomas, >> >> Thanks for the review. >> >> Can I get one more reviewer please? >> >> thanks, >> >> Chris >> >> On 11/10/17 11:35 PM, Thomas St?fe wrote: >>> Oh, you are right, I should have seen this. Knowing this, forget my worries about stability. Sorry for the noise :) >>> >>> ..Thomas >>> >>> On Fri, Nov 10, 2017 at 11:47 PM, Chris Plummer > wrote: >>> >>> It's already restricted to non-product builds, but I'll add a >>> comment also. >>> >>> thanks, >>> >>> Chris >>> >>> >>> On 11/10/17 1:27 PM, Thomas St?fe wrote: >>>> Hi Chris, >>>> >>>> Thank you. Yes, a comment may make sense, and/or restricting this >>>> function to not product. Otherwise the change is fine and useful, >>>> I?ll use it probably before long. >>>> >>>> Thanks, Thomas >>>> >>>> On Fri 10. Nov 2017 at 21:55, Chris Plummer >>>> > wrote: >>>> >>>> Hi Thomas, >>>> >>>> There's certainly no intent to leave in place any calls >>>> someone might add to pns2(). It's meant as a temporary >>>> debugging aide only. So if it were to fail for any reason, >>>> IMO that's no different than adding any other sort of >>>> temporary debugging code that could possibly crash. You fix >>>> your mistake and resume your debugging. If you want I can add >>>> comments that include such a warning. >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >>>> >>>> On 11/10/17 12:11 AM, Thomas St?fe wrote: >>>>> Hi Chris, >>>>> >>>>> looks fine as a debugging aid. >>>>> >>>>> But it occurred to me that it may be a bit dangerous to call >>>>> this from non-errorhandler settings. I recall seeing quite a >>>>> few secondary crashes in VMError::print_native_stack() in >>>>> hs-err files over time. Especially for native non-java >>>>> threads. Usually this did not matter that much because these >>>>> crashes are handled by secondary error handling when >>>>> printing the hs-err file. But if we call it outside of error >>>>> handling, we are on our own. >>>>> >>>>> So. IMHO, to use this functions as a debugging aid is fine, >>>>> if one can accept a slight risk of crashing the VM. If this >>>>> is not acceptable, may we need some more tests for this >>>>> function? >>>>> >>>>> Kind Regards, Thomas >>>>> >>>>> >>>>> >>>>> On Thu, Nov 9, 2017 at 9:29 PM, Chris Plummer >>>>> > >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Please review the following: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8191049 >>>>> >>>>> >>>>> diff --git a/src/hotspot/share/utilities/debug.cpp >>>>> b/src/hotspot/share/utilities/debug.cpp >>>>> --- a/src/hotspot/share/utilities/debug.cpp >>>>> +++ b/src/hotspot/share/utilities/debug.cpp >>>>> @@ -631,6 +631,24 @@ >>>>> VMError::print_native_stack(tty, fr, t, buf, >>>>> sizeof(buf)); >>>>> } >>>>> >>>>> +// >>>>> +// This version of pns() will not work when called from >>>>> the debugger, but is >>>>> +// useful when called from within hotspot code. The >>>>> advantages over pns() >>>>> +// are not having to pass in any arguments, and it will >>>>> work on Windows/x64. >>>>> +// >>>>> +extern "C" void pns2() { // print native stack >>>>> + Command c("pns2"); >>>>> + static char buf[O_BUFLEN]; >>>>> + if (os::platform_print_native_stack(tty, NULL, buf, >>>>> sizeof(buf))) { >>>>> + // We have printed the native stack in >>>>> platform-specific code, >>>>> + // so nothing else to do in this case. >>>>> + } else { >>>>> + Thread* t = Thread::current_or_null(); >>>>> + frame fr = os::current_frame(); >>>>> + VMError::print_native_stack(tty, fr, t, buf, sizeof(buf)); >>>>> + } >>>>> +} >>>>> + >>>>> #endif // !PRODUCT >>>>> >>>>> There is also a pre-existing thread with some discussion: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025134.html >>>>> >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> >>> >> From jesper.wilhelmsson at oracle.com Tue Nov 14 20:56:35 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 14 Nov 2017 21:56:35 +0100 Subject: Last day for pushing hs enhancements and P4-P5 bugs to JDK 10 Message-ID: <6CB9FC10-4D3F-45D5-89D1-DA0180E29AC6@oracle.com> Hi HotSpot developers, We are getting closer to the RDP1 milestone in the JDK 10 project. On December 14 the stabilisation repository for JDK 10 will be forked from jdk/jdk, and into this stabilisation repository we will only be pushing P1-P3 bug fixes. Push your RFEs and P4-P5 bugs before COB December 1st It takes some time for changes to propagate through the testing layers between jdk/hs and jdk/jdk, and we also want to have some buffer time to get the last bugs fixed. For this reason the last day to push a change to hs if you really need it to get into JDK 10 is December 1st. jdk/hs will remain open for any bug fixes P1-P5 and any RFEs. Integration from jdk/hs into jdk/jdk will continue even after this date given that our quality is good enough, so with any amount of luck even changes pushed a few days later might make it. But if you want to make sure to get your change into JDK 10, push it before COB December 1st. If you have a change that should NOT go in to JDK 10, please hold on to it until after December 14. Thanks, /Jesper From david.holmes at oracle.com Tue Nov 14 21:55:08 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Nov 2017 07:55:08 +1000 Subject: RFR: JDK-8190418 Stop generating jvmtiEnvStub and jvmtiEnvRecommended In-Reply-To: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> References: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> Message-ID: <475eb71c-d770-e0a3-a82e-943fadecb293@oracle.com> Hi Magnus, On 14/11/2017 11:06 PM, Magnus Ihse Bursie wrote: > During hotspot gensrc, we create two files, jvmtiEnvStub and > jvmtiEnvRecommended, which later on are explicitly excluded from the > build. We should just stop generating them. cc'd Dan: Need someone who knows to chime in with what these files are and why they exist. The stub is like a dummy implementation that may have been useful for testing against. No idea what the "recommended" file may represent. ?? > I have built hotspot with and without this patch, and used the build > comparison script (compare.sh) to verify that it has not changed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190418 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8190418-stop-generating-unneeded-jvmti-files/webrev.01 Change itself seems fine. Not sure if jvmtiEnv.xsl is now a dead file that can be removed (if so we'll file a hotspot bug for that). Thanks, David > > /Magnus > From daniel.daugherty at oracle.com Tue Nov 14 21:57:03 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 14 Nov 2017 16:57:03 -0500 Subject: RFR: JDK-8190418 Stop generating jvmtiEnvStub and jvmtiEnvRecommended In-Reply-To: <475eb71c-d770-e0a3-a82e-943fadecb293@oracle.com> References: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> <475eb71c-d770-e0a3-a82e-943fadecb293@oracle.com> Message-ID: <0b9e32bb-7bb9-3e68-9806-3fbfac95eff8@oracle.com> Adding Robert Field...? Those files were created before I started doing any work on JVM/TI... Dan On 11/14/17 4:55 PM, David Holmes wrote: > Hi Magnus, > > On 14/11/2017 11:06 PM, Magnus Ihse Bursie wrote: >> During hotspot gensrc, we create two files, jvmtiEnvStub and >> jvmtiEnvRecommended, which later on are explicitly excluded from the >> build. We should just stop generating them. > > cc'd Dan: Need someone who knows to chime in with what these files are > and why they exist. The stub is like a dummy implementation that may > have been useful for testing against. No idea what the "recommended" > file may represent. ?? > >> I have built hotspot with and without this patch, and used the build >> comparison script (compare.sh) to verify that it has not changed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190418 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8190418-stop-generating-unneeded-jvmti-files/webrev.01 > > > Change itself seems fine. Not sure if jvmtiEnv.xsl is now a dead file > that can be removed (if so we'll file a hotspot bug for that). > > Thanks, > David > >> >> /Magnus >> From erik.osterlund at oracle.com Tue Nov 14 22:08:09 2017 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Tue, 14 Nov 2017 23:08:09 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <48b77dfa-fa76-154a-87d6-e84dd816d1ea@redhat.com> References: <5A048993.2000002@oracle.com> <63c96b68-88a6-5104-c9fb-5105a77d3440@redhat.com> <5A05D3D0.9040707@oracle.com> <48b77dfa-fa76-154a-87d6-e84dd816d1ea@redhat.com> Message-ID: <0C43E7DF-1B2C-438A-96CD-981E9A0D02BF@oracle.com> Hi Roman, Thanks for having a look at this. > On 13 Nov 2017, at 18:10, Roman Kennke wrote: > > Hi Erik, > >> Hi Roman, >> >>> On 2017-11-10 16:01, Roman Kennke wrote: >>> Hi Erik, >>> >>> This looks very good to me. It is likely that we'll need to extend it a little bit for Shenandoah, but I haven't got around to try that out yet, and will propose it when this patch percolated down to the Shenandoah project. >> >> Yes. The framework should be quite flexible, and of course I will work with you on anything that needs to be updated. > Perfect! > >>> Questions (I know I've asked some of it before in private discussions): >>> - A BarrierSet needs to declare an AccessBarrier inner class. How does this get 'registered' with the Access dispatcher? >> >> Good question. Each new GC is tied together at one single point. The Access API picks up GCs from the gc/shared/barrierSetConfig.hpp and .inline.hpp files. >> >> So to register a new GC, such as Shenandoah, you have to: >> >> 1) Make sure you have a BarrierSet enum value which is added to the list of FOR_EACH_BARRIER_SET_DO as well as FOR_EACH_CONCRETE_BARRIER_SET_DO in barrierSetConfig.hpp. >> >> The first of said lists contains all barrier sets that are known to exist at build time, and the second of said lists crucially contains concrete barrier sets that have an AccessBarrier to resolve. >> >> 2) You also need to make sure in the barrierSetConfig.inline.hpp file that you #include your shenandoah BarrierSet inline.hpp file. >> >> 3) You have to provide a specialization for the BarrierSet::GetName and BarrierSet::GetType metafunctions that provide an enum value for a barrier set type, and vice versa. >> >> 4) Since you probably want primitive accesses in the heap to also resolve into the barrier set in a build that includes Shenandoah, you should #define SUPPORT_BARRIER_ON_PRIMITIVES in the barrierSetConfig.hpp file when building with Shenandoah. This will flick on the INTERNAL_BT_BARRIER_ON_PRIMITIVES decorator to each access so that the Access framework understands that even primitive accesses must be resolved at run-time in the barrier set. So this is a build-time switch for turning on run-time resolution of primitive accesses in the heap. >> >> And now you should be set: your new ShenandoahBarrierSet::AccessBarrier will be called for each access, including primitives. >> >> It works the following way: >> >> 1) The barrier resolver loads the current barrier set, and checks the "name" of it (the enum value). >> 2) Each "name" for concrete barriers that you listed in barrierSetConfig.hpp is asked for... >> 3) ...the BarrierSet::GetType of that enum "name", and... >> 4) The AccessBarrier of that resulting BarrierSet (your ShenandoahBarrierSet) will be called. >> >> Hope that makes sense. >> > > It is ok. But just so. ;-) > The problem is that it is a bit mystical how stuff is set up, and I'd prefer a more explicit way to do it. > Maybe add the above explanations (how to make new GC barriers) in a comment somewhere? Okay, will do! > >>> - I see you use namespace. I haven't seen them anywhere else in Hotspot, so this looks quite unusual :-) Not that I am against it (I would probably advocate for using more of it), but have you considered alternatives that look more common Hotspot-style (e.g. declaring an all-static AccessInternal class)? >> >> We do not have any platform that has problems with namespaces. So I would prefer this basic namespace usage to a bunch of AllStatic classes. I hope nobody minds that. >> > I am ok with it. Good, thank you. > >>> - The dispatching machinery looks a bit over the top, and from the outskirts like a manual re-invention of virtual method dispatch. Couldn't we do the same stuff with the usual public interface / concrete implementation idioms? I am worried that adding just one method to the interface turns into a nightmare of wiring up stuff and adding tons of boilerplate to get it going. Not to mention the learning curve involved trying to make sense of what goes where. >> >> It's not quite like a normal virtual call though. It's a virtual dispatch that carries template parameters through the runtime dispatch. The template parameters are required for 1) remembering the decorators (semantics of the access), and 2) the type information of the operands for the access. >> >> In my experience, when you need to drag template parameters through some form of virtual dispatch, it is easiest to use function pointers and not virtual calls. >> I understand it might look a bit complicated, but I hope that is okay. > Right. Templates and virtual doesn't play well (or at all) together. Indeed. > I've seen that the GC interface JEP just went to 'targeted' so I guess you can push it (probably needs more review?) Yes, soon indeed. Thanks, /Erik > Roman From coleen.phillimore at oracle.com Wed Nov 15 00:37:52 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 14 Nov 2017 19:37:52 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A048993.2000002@oracle.com> References: <5A048993.2000002@oracle.com> Message-ID: Hi,? Meta-comment: I think the access API should be in oops rather than the runtime directory.?? This API is for accessing objects in the heap from other objects in the heap or in runtime code.?? So that seems like it belongs in the oops directory to me (even though metadata is there for historical reasons).?? The memory directory would be my second choice, and runtime third. I've been reading through much of the code with help and explanation of what these templates do from Kim.? They are pretty tricky but I can see why they are there and what they do.?? I'm going to suggest some comments in places when I've gotten through more of this. Thanks, Coleen On 11/9/17 12:00 PM, Erik ?sterlund wrote: > Hi, > > In an effort to remove explicit calls to GC barriers (and other > orthogonal forms of barriers, like encoding/decoding oops for > compressed oops and fencing for memory ordering), I have built an API > that I call "Access". Its purpose is to perform accesses with > declarative semantics, to handle multiple orthogonal concerns that > affect how an access is performed, including memory ordering, > compressed oops, GC barriers for marking, reference strength, etc, and > as a result making GCs more modular, and as a result allow new > concurrently compacting GC schemes utilizing load barriers to live in > harmony in hotspot without everyone going crazy manually inserting > barriers if UseBlahGC is enabled. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8189871 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ > > So there are three views of this I suppose: > > 1) The frontend: how this is actually used in shared code > 2) The backends: how anyone writing a GC sticks their required > barriers in there > 3) The internals: how accesses find their way from the frontend to the > corresponding backend > > == Frontend == > > Let's start with the frontend. I hope I made this fairly simple! You > can find it in runtime/access.hpp > Each access annotates its declarative semantics with a set of > "decorators", which is the name of the attributes/properties affecting > how an access is performed. > There is an Access API that makes the declarative semantics > possible. > > For example, if I want to perform a load acquire of an oop in the heap > that has "weak" strength, I would do something like: > oop result = Access ON_WEAK_OOP_REF>::oop_load_at(obj, offset); > > The Access API would then send the access through some GC backend, > that overrides the whole access and tells it to perform a "raw" load > acquire, and then possibly keep it alive if necessary (G1 SATB enqueue > barriers). > > To make life easier, there are some helpers for the most common access > patterns that merely add some default decorator for the involved type > of access. For example, there is a RawAccess for performing AS_RAW > accesses (that bypasses runtime checks and GC barriers), HeapAccess > sets the IN_HEAP decorator and RootAccess sets the IN_ROOT decorator > for accessing root oops. So for the previous call, I could simply do: > > oop result = HeapAccess ON_WEAK_OOP_REF>::oop_load_at(obj, offset); > > The access.hpp file introduces each decorator (belonging to some > category) with an explanation what it is for. It also introduces all > operations you can make with access (loads, stores, cmpxchg, xchg, > arraycopy and clone). > > This changeset mostly introduces the Access API but is not complete in > annotating the code more than where it gets very awkward if I don't. > > == Backend == > > For a GC maintainer, the BarrierSet::AccessBarrier is the top level > backend that provides basic accesses that may be overridden. By > default, it just performs raw accesses without any GC barriers, that > handle things like compressed oops and memory ordering only. The > ModRef barrier set introduces the notion of pre/post write barriers, > that can be overridden for each GC. The CardTableModRef barrier set > overrides the post write barrier to mark cards, and G1 overrides it to > mark cards slightly differently and do some SATB enqueueing. G1 also > overrides loads to see if we need to perform SATB enqueue on weak > references. > > The raw accesses go to the RawAccessBarrier (living in > accessBackend.hpp) that performs the actual accesses. It connects to > Atomic and OrderAccess for accesses that require that. > > == Internals == > > Internally, the accesses go through a number of stages in > access.inline.hpp as documented at the top. > > 1) set default decorators and get rid of CV qualifiers etc. Sanity > checking also happens here: we check that the decorators make sense > for the access being performed, and that the passed in types are not > bogus. > 2) reduce types so if we have a different type of the address and > value, then either it is not allowed or it implies we use compressed > oops and remember that we know something about whether compressed oops > are used or not, before erasing address type > 3) pre-runtime dispatch: figure out if all runtime checks can be > bypassed into a raw access > 4) runtime dispatch: send the access through a function pointer that > upon the first invocation resolves the intended GC AccessBarrier > accessor on the BarrierSet that handles this access, as well as > figures out whether we are using compressed oops or not while we are > at it, and then calls it through the post-runtime dispatch > 5) post-runtime dispatch: fix some erased types that were not known at > compile time such as whether the address is a narrowOop* or oop* > depending on whether compressed oops was selected at runtime or not, > and call the resolved BarrierSet::AccessBarrier accessor > (load/store/etc) with all the call-site build-time and run-time > resolved decorators and type information that describes the access. > > Testing: mach5 tier1-5 > > Thanks, > /Erik From paul.sandoz at oracle.com Wed Nov 15 00:49:45 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 14 Nov 2017 16:49:45 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: References: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> <26336F4F-0A21-4A08-AFA3-23CA972CAD93@oracle.com> Message-ID: <130F7E94-9408-4C49-9C23-840361B4B379@oracle.com> > On 10 Nov 2017, at 01:36, stanislav lukyanov wrote: > > On 10.11.2017 0:13, Paul Sandoz wrote: >> <...> >> I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don?t want that to side-track the review for the moment (including guidance on what forms of computed constants are acceptable). > Fair. Does it make sense to add a sub-task for this to JDK-8185992 to keep it on the radar? You would mind adding a sub-task with a tbd minor target? >> <...> >> >> And adjusted the invoke method: >> >> * @param args the arguments to pass to the method handle, as if with >> * {@link MethodHandle#invokeWithArguments}. Each argument may be >> * {@code null}. >> ... >> * @throws NullPointerException if {@code args} is {@code null} >> * (each argument of {@code args} may be {@code null}). > I think the `@throws NPE` is not needed, at least not from the normative perspective. > The class-level text about NPE doesn't assume anything about the contents of objects passed to the methods, > and the second part of the `@param args` already clarifies the behavior for this particular case. > Arguably having this `@throws` might improve clarity, but I would rather remove it. Ok, if you are fine with that i will remove it. >> >> We have been fleshing out the NPE behaviour because we know you will log bugs against us later on if we don?t :-) > Yep, that's sounds familiar :) > > <...> > > Thanks for the updates! > > Also, javac isn't going to use `::primitiveClass` instead of `getstatic Integer.TYPE` to load int.class, right? > If it is, int.class probably needs to be changed to Integer.TYPE in sun.invoke.util.Wrapper to avoid cycles. > Yes, i noticed that too :-) There are no plans in this patch to update javac code generation for primitive classes but if we do we may need to modify the wrapper implementation as you point out. There are might other areas within the base module (specifically in j.l.invoke) where referring to say int.class may cause class initialization issues early in the startup. That?s awkward (just like we cannot use lambda expressions in certain cases), we might need to retain the old translation strategy just for code within the base module or support a compilation error. Paul. From coleen.phillimore at oracle.com Wed Nov 15 00:51:48 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 14 Nov 2017 19:51:48 -0500 Subject: RFR (XS) 8179603: create a jtreg test group for hotspot tests excluding application testing Message-ID: <4d4137b4-dc88-c40e-6e17-5f878b73893c@oracle.com> This creates a group called hotspot_all_no_apps which runs all the hotspot tests without the application tests which take forever. With this, you can run all the tests on a local machine in something like 3 hours with the jtreg command: jtreg -nr -nativepath:$JAVA_HOME/../test/hotspot/jtreg/native -jdk:$JAVA_HOME -v:summary -ignore:quiet -retain:fail,"hs_err*" -server -agentvm -conc:5 -exclude:open/test/hotspot/jtreg/ProblemList.txt open/test/hotspot/jtreg:hotspot_all_no_apps This change also adds the only failing test to the ProblemList.txt file. open webrev at http://cr.openjdk.java.net/~coleenp/8179603.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8179603 Thanks, Coleen From david.holmes at oracle.com Wed Nov 15 01:20:06 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Nov 2017 11:20:06 +1000 Subject: RFR (XS) 8179603: create a jtreg test group for hotspot tests excluding application testing In-Reply-To: <4d4137b4-dc88-c40e-6e17-5f878b73893c@oracle.com> References: <4d4137b4-dc88-c40e-6e17-5f878b73893c@oracle.com> Message-ID: <44b0da5a-e929-c331-e26d-a1405fb9e95c@oracle.com> Hi Coleen, On 15/11/2017 10:51 AM, coleen.phillimore at oracle.com wrote: > This creates a group called hotspot_all_no_apps which runs all the > hotspot tests without the application tests which take forever. With > this, you can run all the tests on a local machine in something like 3 > hours with the jtreg command: > > jtreg -nr -nativepath:$JAVA_HOME/../test/hotspot/jtreg/native > -jdk:$JAVA_HOME -v:summary -ignore:quiet -retain:fail,"hs_err*" -server > -agentvm -conc:5 -exclude:open/test/hotspot/jtreg/ProblemList.txt > open/test/hotspot/jtreg:hotspot_all_no_apps Okay. > This change also adds the only failing test to the ProblemList.txt file. Has this tier3 test been failing in our tier3 testing? It would be cleaner to have a sub-task on 8191270 for this. No need to see a separate webrev, just commit under the sub-task id as a trivial fix. Thanks, David > open webrev at http://cr.openjdk.java.net/~coleenp/8179603.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8179603 > > Thanks, > Coleen From serguei.spitsyn at oracle.com Wed Nov 15 01:57:43 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 Nov 2017 17:57:43 -0800 Subject: RFR (XS) 8179603: create a jtreg test group for hotspot tests excluding application testing In-Reply-To: <4d4137b4-dc88-c40e-6e17-5f878b73893c@oracle.com> References: <4d4137b4-dc88-c40e-6e17-5f878b73893c@oracle.com> Message-ID: <98e41281-a7eb-1a52-7f6e-9178150378e8@oracle.com> Looks good. Thanks, Serguei On 11/14/17 16:51, coleen.phillimore at oracle.com wrote: > This creates a group called hotspot_all_no_apps which runs all the > hotspot tests without the application tests which take forever. With > this, you can run all the tests on a local machine in something like 3 > hours with the jtreg command: > > jtreg -nr -nativepath:$JAVA_HOME/../test/hotspot/jtreg/native > -jdk:$JAVA_HOME -v:summary -ignore:quiet -retain:fail,"hs_err*" > -server -agentvm -conc:5 > -exclude:open/test/hotspot/jtreg/ProblemList.txt > open/test/hotspot/jtreg:hotspot_all_no_apps > > This change also adds the only failing test to the ProblemList.txt file. > > open webrev at http://cr.openjdk.java.net/~coleenp/8179603.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8179603 > > Thanks, > Coleen From stanislav.lukyanov at oracle.com Wed Nov 15 04:48:53 2017 From: stanislav.lukyanov at oracle.com (stanislav lukyanov) Date: Wed, 15 Nov 2017 10:18:53 +0530 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: <130F7E94-9408-4C49-9C23-840361B4B379@oracle.com> References: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> <26336F4F-0A21-4A08-AFA3-23CA972CAD93@oracle.com> <130F7E94-9408-4C49-9C23-840361B4B379@oracle.com> Message-ID: On 15.11.2017 6:19, Paul Sandoz wrote: >> On 10 Nov 2017, at 01:36, stanislav lukyanov wrote: >> >> On 10.11.2017 0:13, Paul Sandoz wrote: >>> <...> >>> I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don?t want that to side-track the review for the moment (including guidance on what forms of computed constants are acceptable). >> Fair. Does it make sense to add a sub-task for this to JDK-8185992 to keep it on the radar? > You would mind adding a sub-task with a tbd minor target? TBD_Minor would mean an update release, right? I think it can't be a TBD_Minor then since it is technically a specification change and should happen in a Java SE release (maybe 11?), but maybe I'm wrong. Anyway, as long as that's logged and not completely forgotten, I'm happy :) Thanks, Stas > > >>> <...> >>> >>> And adjusted the invoke method: >>> >>> * @param args the arguments to pass to the method handle, as if with >>> * {@link MethodHandle#invokeWithArguments}. Each argument may be >>> * {@code null}. >>> ... >>> * @throws NullPointerException if {@code args} is {@code null} >>> * (each argument of {@code args} may be {@code null}). >> I think the `@throws NPE` is not needed, at least not from the normative perspective. >> The class-level text about NPE doesn't assume anything about the contents of objects passed to the methods, >> and the second part of the `@param args` already clarifies the behavior for this particular case. >> Arguably having this `@throws` might improve clarity, but I would rather remove it. > Ok, if you are fine with that i will remove it. > > >>> We have been fleshing out the NPE behaviour because we know you will log bugs against us later on if we don?t :-) >> Yep, that's sounds familiar :) >> >> <...> >> >> Thanks for the updates! >> >> Also, javac isn't going to use `::primitiveClass` instead of `getstatic Integer.TYPE` to load int.class, right? >> If it is, int.class probably needs to be changed to Integer.TYPE in sun.invoke.util.Wrapper to avoid cycles. >> > Yes, i noticed that too :-) > > There are no plans in this patch to update javac code generation for primitive classes but if we do we may need to modify the wrapper implementation as you point out. There are might other areas within the base module (specifically in j.l.invoke) where referring to say int.class may cause class initialization issues early in the startup. That?s awkward (just like we cannot use lambda expressions in certain cases), we might need to retain the old translation strategy just for code within the base module or support a compilation error. > > Paul. From david.holmes at oracle.com Wed Nov 15 07:47:23 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Nov 2017 17:47:23 +1000 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A048993.2000002@oracle.com> References: <5A048993.2000002@oracle.com> Message-ID: <9cee59e0-5aab-3d8b-9485-8edd5f27b941@oracle.com> Hi Erik, I really like the level of abstraction and encapsulation this provides. Can't comment on the GC specific details or the template mechanics directly, of course. :) A couple of comments: src/hotspot/share/oops/klass.hpp 412 // Is an oop/narrowOop null or subtype of this Klass? 413 template 414 bool is_covariant(T element); I find "is_covariant" a very obscure way to name this. It may be academically accurate but it's really just asking if the element is of a type that is a subclass of the current klass. The null handling complicates it, but it seems to me that: template bool Klass::is_instanceof_or_null(T element); would be more consistent with how we normally refer to things in the VM (though the _or_null can be dropped from the name). --- src/hotspot/share/oops/objArrayOop.cpp Klass* objArrayOopDesc::covariant_bound() There's that word again. :) If you really think you need to use covariance within these API's you really need to add some comments to the method declarations to explain them. Most of us probably have a minimal recollection of covariance and contravariance from discussing type-safety for method parameters and return types. :) --- src/hotspot/share/prims/unsafe.cpp The changes from jobjects to oops made me uneasy, but I'm assuming the places where MemoryAccess and GuardedMemoryAccess are used are affectively all leave routines with no chance of hitting anything that would respond to a safepoint request? Thanks, David ----- On 10/11/2017 3:00 AM, Erik ?sterlund wrote: > Hi, > > In an effort to remove explicit calls to GC barriers (and other > orthogonal forms of barriers, like encoding/decoding oops for compressed > oops and fencing for memory ordering), I have built an API that I call > "Access". Its purpose is to perform accesses with declarative semantics, > to handle multiple orthogonal concerns that affect how an access is > performed, including memory ordering, compressed oops, GC barriers for > marking, reference strength, etc, and as a result making GCs more > modular, and as a result allow new concurrently compacting GC schemes > utilizing load barriers to live in harmony in hotspot without everyone > going crazy manually inserting barriers if UseBlahGC is enabled. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8189871 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ > > So there are three views of this I suppose: > > 1) The frontend: how this is actually used in shared code > 2) The backends: how anyone writing a GC sticks their required barriers > in there > 3) The internals: how accesses find their way from the frontend to the > corresponding backend > > == Frontend == > > Let's start with the frontend. I hope I made this fairly simple! You can > find it in runtime/access.hpp > Each access annotates its declarative semantics with a set of > "decorators", which is the name of the attributes/properties affecting > how an access is performed. > There is an Access API that makes the declarative semantics > possible. > > For example, if I want to perform a load acquire of an oop in the heap > that has "weak" strength, I would do something like: > oop result = Access ON_WEAK_OOP_REF>::oop_load_at(obj, offset); > > The Access API would then send the access through some GC backend, that > overrides the whole access and tells it to perform a "raw" load acquire, > and then possibly keep it alive if necessary (G1 SATB enqueue barriers). > > To make life easier, there are some helpers for the most common access > patterns that merely add some default decorator for the involved type of > access. For example, there is a RawAccess for performing AS_RAW accesses > (that bypasses runtime checks and GC barriers), HeapAccess sets the > IN_HEAP decorator and RootAccess sets the IN_ROOT decorator for > accessing root oops. So for the previous call, I could simply do: > > oop result = HeapAccess::oop_load_at(obj, > offset); > > The access.hpp file introduces each decorator (belonging to some > category) with an explanation what it is for. It also introduces all > operations you can make with access (loads, stores, cmpxchg, xchg, > arraycopy and clone). > > This changeset mostly introduces the Access API but is not complete in > annotating the code more than where it gets very awkward if I don't. > > == Backend == > > For a GC maintainer, the BarrierSet::AccessBarrier is the top level > backend that provides basic accesses that may be overridden. By default, > it just performs raw accesses without any GC barriers, that handle > things like compressed oops and memory ordering only. The ModRef barrier > set introduces the notion of pre/post write barriers, that can be > overridden for each GC. The CardTableModRef barrier set overrides the > post write barrier to mark cards, and G1 overrides it to mark cards > slightly differently and do some SATB enqueueing. G1 also overrides > loads to see if we need to perform SATB enqueue on weak references. > > The raw accesses go to the RawAccessBarrier (living in > accessBackend.hpp) that performs the actual accesses. It connects to > Atomic and OrderAccess for accesses that require that. > > == Internals == > > Internally, the accesses go through a number of stages in > access.inline.hpp as documented at the top. > > 1) set default decorators and get rid of CV qualifiers etc. Sanity > checking also happens here: we check that the decorators make sense for > the access being performed, and that the passed in types are not bogus. > 2) reduce types so if we have a different type of the address and value, > then either it is not allowed or it implies we use compressed oops and > remember that we know something about whether compressed oops are used > or not, before erasing address type > 3) pre-runtime dispatch: figure out if all runtime checks can be > bypassed into a raw access > 4) runtime dispatch: send the access through a function pointer that > upon the first invocation resolves the intended GC AccessBarrier > accessor on the BarrierSet that handles this access, as well as figures > out whether we are using compressed oops or not while we are at it, and > then calls it through the post-runtime dispatch > 5) post-runtime dispatch: fix some erased types that were not known at > compile time such as whether the address is a narrowOop* or oop* > depending on whether compressed oops was selected at runtime or not, and > call the resolved BarrierSet::AccessBarrier accessor (load/store/etc) > with all the call-site build-time and run-time resolved decorators and > type information that describes the access. > > Testing: mach5 tier1-5 > > Thanks, > /Erik From muthusamy.chinnathambi at oracle.com Wed Nov 15 10:19:23 2017 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Wed, 15 Nov 2017 02:19:23 -0800 (PST) Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist In-Reply-To: <9e7f3290-8dd3-4ca0-a445-fd50ff389642@default> References: <811da80f-e107-4d0c-903b-c109b592176e@default> <6e7c7f30-599d-4558-8c84-0360f0535cf4@default> <9e7f3290-8dd3-4ca0-a445-fd50ff389642@default> Message-ID: Hi, Could someone please review this backport. Regards, Muthusamy C -----Original Message----- From: Muthusamy Chinnathambi Sent: Friday, November 10, 2017 3:27 PM To: HotSpot Open Source Developers Cc: Mikael Gerdin Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist Hi, Can someone please review this. Thanks! Muthusamy C -----Original Message----- From: Muthusamy Chinnathambi Sent: Wednesday, November 8, 2017 11:24 AM To: Thomas St?fe Cc: Mikael Gerdin ; HotSpot Open Source Developers Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist Hi Thomas, ? > ?the webrev link seems to be dead. Sorry for the trouble. Please find the corrected link below http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ ? Somehow the line following the link got appended to the previous one leading to a dead link. ? Regards, Muthusamy C ? From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Tuesday, November 7, 2017 8:12 PM To: Muthusamy Chinnathambi Cc: HotSpot Open Source Developers ; Mikael Gerdin Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist ? Hi Muthusamy, ? the webrev link seems to be dead. ? ..Thomas ? On Tue, Nov 7, 2017 at 10:05 AM, Muthusamy Chinnathambi wrote: Hi, Please review the backport of bug: "JDK-8170395: Metaspace initialization queries the wrong chunk freelist" to jdk8u-dev Please note that this is not a clean backport due to new entries in debug.cpp and copyright changes. Webrev: HYPERLINK "http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9"http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8170395 Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e971a72675a Test:? Had run jtreg and jprt hotspot testsets. Regards, Muthusamy C ? From coleen.phillimore at oracle.com Wed Nov 15 12:57:31 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Nov 2017 07:57:31 -0500 Subject: RFR (XS) 8179603: create a jtreg test group for hotspot tests excluding application testing In-Reply-To: <44b0da5a-e929-c331-e26d-a1405fb9e95c@oracle.com> References: <4d4137b4-dc88-c40e-6e17-5f878b73893c@oracle.com> <44b0da5a-e929-c331-e26d-a1405fb9e95c@oracle.com> Message-ID: On 11/14/17 8:20 PM, David Holmes wrote: > Hi Coleen, > > On 15/11/2017 10:51 AM, coleen.phillimore at oracle.com wrote: >> This creates a group called hotspot_all_no_apps which runs all the >> hotspot tests without the application tests which take forever. With >> this, you can run all the tests on a local machine in something like >> 3 hours with the jtreg command: >> >> jtreg -nr -nativepath:$JAVA_HOME/../test/hotspot/jtreg/native >> -jdk:$JAVA_HOME -v:summary -ignore:quiet -retain:fail,"hs_err*" >> -server -agentvm -conc:5 >> -exclude:open/test/hotspot/jtreg/ProblemList.txt >> open/test/hotspot/jtreg:hotspot_all_no_apps > > Okay. > >> This change also adds the only failing test to the ProblemList.txt file. > > Has this tier3 test been failing in our tier3 testing? It would be > cleaner to have a sub-task on 8191270 for this. No need to see a > separate webrev, just commit under the sub-task id as a trivial fix. I asked Jesper and I don't know why we don't see this with nightly testing.? I don't know how to navigate the pages in finite time. Okay, I can do that. Thanks, Coleen > > Thanks, > David > >> open webrev at http://cr.openjdk.java.net/~coleenp/8179603.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8179603 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Wed Nov 15 12:57:48 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Nov 2017 07:57:48 -0500 Subject: RFR (XS) 8179603: create a jtreg test group for hotspot tests excluding application testing In-Reply-To: <98e41281-a7eb-1a52-7f6e-9178150378e8@oracle.com> References: <4d4137b4-dc88-c40e-6e17-5f878b73893c@oracle.com> <98e41281-a7eb-1a52-7f6e-9178150378e8@oracle.com> Message-ID: Thanks Serguei! Coleen On 11/14/17 8:57 PM, serguei.spitsyn at oracle.com wrote: > Looks good. > > Thanks, > Serguei > > > On 11/14/17 16:51, coleen.phillimore at oracle.com wrote: >> This creates a group called hotspot_all_no_apps which runs all the >> hotspot tests without the application tests which take forever. With >> this, you can run all the tests on a local machine in something like >> 3 hours with the jtreg command: >> >> jtreg -nr -nativepath:$JAVA_HOME/../test/hotspot/jtreg/native >> -jdk:$JAVA_HOME -v:summary -ignore:quiet -retain:fail,"hs_err*" >> -server -agentvm -conc:5 >> -exclude:open/test/hotspot/jtreg/ProblemList.txt >> open/test/hotspot/jtreg:hotspot_all_no_apps >> >> This change also adds the only failing test to the ProblemList.txt file. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8179603.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8179603 >> >> Thanks, >> Coleen > From thomas.stuefe at gmail.com Wed Nov 15 12:59:31 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 15 Nov 2017 13:59:31 +0100 Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist In-Reply-To: References: <811da80f-e107-4d0c-903b-c109b592176e@default> <6e7c7f30-599d-4558-8c84-0360f0535cf4@default> <9e7f3290-8dd3-4ca0-a445-fd50ff389642@default> Message-ID: Hi Muthusamy, Looks okay. But are there gtests already in jdk8u? I thought gtests came with jdk9? http://openjdk.java.net/jeps/281 If not, how does http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html run or even compile? Thanks, Thomas On Wed, Nov 15, 2017 at 11:19 AM, Muthusamy Chinnathambi < muthusamy.chinnathambi at oracle.com> wrote: > Hi, > > Could someone please review this backport. > > Regards, > Muthusamy C > > -----Original Message----- > From: Muthusamy Chinnathambi > Sent: Friday, November 10, 2017 3:27 PM > To: HotSpot Open Source Developers > Cc: Mikael Gerdin > Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace > initialization queries the wrong chunk freelist > > Hi, > > Can someone please review this. > > Thanks! > Muthusamy C > > -----Original Message----- > From: Muthusamy Chinnathambi > Sent: Wednesday, November 8, 2017 11:24 AM > To: Thomas St?fe > Cc: Mikael Gerdin ; HotSpot Open Source > Developers > Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace > initialization queries the wrong chunk freelist > > Hi Thomas, > > > > > the webrev link seems to be dead. > > Sorry for the trouble. > > Please find the corrected link below > > http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ > > > > Somehow the line following the link got appended to the previous one > leading to a dead link. > > > > Regards, > > Muthusamy C > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Tuesday, November 7, 2017 8:12 PM > To: Muthusamy Chinnathambi > Cc: HotSpot Open Source Developers ; Mikael > Gerdin > Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace > initialization queries the wrong chunk freelist > > > > Hi Muthusamy, > > > > the webrev link seems to be dead. > > > > ..Thomas > > > > On Tue, Nov 7, 2017 at 10:05 AM, Muthusamy Chinnathambi muthusamy.chinnathambi at oracle.com"muthusamy.chinnathambi at oracle.com> > wrote: > > Hi, > > Please review the backport of bug: "JDK-8170395: Metaspace initialization > queries the wrong chunk freelist" to jdk8u-dev > > Please note that this is not a clean backport due to new entries in > debug.cpp and copyright changes. > > > Webrev: HYPERLINK "http://cr.openjdk.java.net/~ > mchinnathamb/8170395/webrev.00/jdk9"http://cr.openjdk. > java.net/~mchinnathamb/8170395/webrev.00/ > jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8170395 > Original patch pushed to jdk9: http://hg.openjdk.java.net/ > jdk9/jdk9/hotspot/rev/2e971a72675a > > Test: Had run jtreg and jprt hotspot testsets. > > Regards, > Muthusamy C > > > From coleen.phillimore at oracle.com Wed Nov 15 13:00:09 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Nov 2017 08:00:09 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <9cee59e0-5aab-3d8b-9485-8edd5f27b941@oracle.com> References: <5A048993.2000002@oracle.com> <9cee59e0-5aab-3d8b-9485-8edd5f27b941@oracle.com> Message-ID: <54781b01-886a-a09a-9b3f-ac5efa8d8294@oracle.com> On 11/15/17 2:47 AM, David Holmes wrote: > Hi Erik, > > I really like the level of abstraction and encapsulation this provides. > > Can't comment on the GC specific details or the template mechanics > directly, of course. :) > > A couple of comments: > > src/hotspot/share/oops/klass.hpp > > ?412?? // Is an oop/narrowOop null or subtype of this Klass? > ?413?? template > ?414?? bool is_covariant(T element); > > I find "is_covariant" a very obscure way to name this. It may be > academically accurate but it's really just asking if the element is of > a type that is a subclass of the current klass. The null handling > complicates it, but it seems to me that: > > template > bool Klass::is_instanceof_or_null(T element); > > would be more consistent with how we normally refer to things in the > VM (though the _or_null can be dropped from the name). > Hi,? I have to agree with David on the covariant name, and his suggested replacement. This name made me stop in my tracks while reading this. thanks, Coleen > --- > > src/hotspot/share/oops/objArrayOop.cpp > > Klass* objArrayOopDesc::covariant_bound() > > There's that word again. :) If you really think you need to use > covariance within these API's you really need to add some comments to > the method declarations to explain them. Most of us probably have a > minimal recollection of covariance and contravariance from discussing > type-safety for method parameters and return types. :) > > --- > > src/hotspot/share/prims/unsafe.cpp > > The changes from jobjects to oops made me uneasy, but I'm assuming the > places where MemoryAccess and GuardedMemoryAccess are used are > affectively all leave routines with no chance of hitting anything that > would respond to a safepoint request? > > Thanks, > David > ----- > > On 10/11/2017 3:00 AM, Erik ?sterlund wrote: >> Hi, >> >> In an effort to remove explicit calls to GC barriers (and other >> orthogonal forms of barriers, like encoding/decoding oops for >> compressed oops and fencing for memory ordering), I have built an API >> that I call "Access". Its purpose is to perform accesses with >> declarative semantics, to handle multiple orthogonal concerns that >> affect how an access is performed, including memory ordering, >> compressed oops, GC barriers for marking, reference strength, etc, >> and as a result making GCs more modular, and as a result allow new >> concurrently compacting GC schemes utilizing load barriers to live in >> harmony in hotspot without everyone going crazy manually inserting >> barriers if UseBlahGC is enabled. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8189871 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ >> >> So there are three views of this I suppose: >> >> 1) The frontend: how this is actually used in shared code >> 2) The backends: how anyone writing a GC sticks their required >> barriers in there >> 3) The internals: how accesses find their way from the frontend to >> the corresponding backend >> >> == Frontend == >> >> Let's start with the frontend. I hope I made this fairly simple! You >> can find it in runtime/access.hpp >> Each access annotates its declarative semantics with a set of >> "decorators", which is the name of the attributes/properties >> affecting how an access is performed. >> There is an Access API that makes the declarative >> semantics possible. >> >> For example, if I want to perform a load acquire of an oop in the >> heap that has "weak" strength, I would do something like: >> oop result = Access> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >> >> The Access API would then send the access through some GC backend, >> that overrides the whole access and tells it to perform a "raw" load >> acquire, and then possibly keep it alive if necessary (G1 SATB >> enqueue barriers). >> >> To make life easier, there are some helpers for the most common >> access patterns that merely add some default decorator for the >> involved type of access. For example, there is a RawAccess for >> performing AS_RAW accesses (that bypasses runtime checks and GC >> barriers), HeapAccess sets the IN_HEAP decorator and RootAccess sets >> the IN_ROOT decorator for accessing root oops. So for the previous >> call, I could simply do: >> >> oop result = HeapAccess> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >> >> The access.hpp file introduces each decorator (belonging to some >> category) with an explanation what it is for. It also introduces all >> operations you can make with access (loads, stores, cmpxchg, xchg, >> arraycopy and clone). >> >> This changeset mostly introduces the Access API but is not complete >> in annotating the code more than where it gets very awkward if I don't. >> >> == Backend == >> >> For a GC maintainer, the BarrierSet::AccessBarrier is the top level >> backend that provides basic accesses that may be overridden. By >> default, it just performs raw accesses without any GC barriers, that >> handle things like compressed oops and memory ordering only. The >> ModRef barrier set introduces the notion of pre/post write barriers, >> that can be overridden for each GC. The CardTableModRef barrier set >> overrides the post write barrier to mark cards, and G1 overrides it >> to mark cards slightly differently and do some SATB enqueueing. G1 >> also overrides loads to see if we need to perform SATB enqueue on >> weak references. >> >> The raw accesses go to the RawAccessBarrier (living in >> accessBackend.hpp) that performs the actual accesses. It connects to >> Atomic and OrderAccess for accesses that require that. >> >> == Internals == >> >> Internally, the accesses go through a number of stages in >> access.inline.hpp as documented at the top. >> >> 1) set default decorators and get rid of CV qualifiers etc. Sanity >> checking also happens here: we check that the decorators make sense >> for the access being performed, and that the passed in types are not >> bogus. >> 2) reduce types so if we have a different type of the address and >> value, then either it is not allowed or it implies we use compressed >> oops and remember that we know something about whether compressed >> oops are used or not, before erasing address type >> 3) pre-runtime dispatch: figure out if all runtime checks can be >> bypassed into a raw access >> 4) runtime dispatch: send the access through a function pointer that >> upon the first invocation resolves the intended GC AccessBarrier >> accessor on the BarrierSet that handles this access, as well as >> figures out whether we are using compressed oops or not while we are >> at it, and then calls it through the post-runtime dispatch >> 5) post-runtime dispatch: fix some erased types that were not known >> at compile time such as whether the address is a narrowOop* or oop* >> depending on whether compressed oops was selected at runtime or not, >> and call the resolved BarrierSet::AccessBarrier accessor >> (load/store/etc) with all the call-site build-time and run-time >> resolved decorators and type information that describes the access. >> >> Testing: mach5 tier1-5 >> >> Thanks, >> /Erik From glaubitz at physik.fu-berlin.de Wed Nov 15 13:50:05 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 15 Nov 2017 14:50:05 +0100 Subject: Zero broken again Message-ID: Hi! Anyone else already noticed that Zero recently broke again? I haven't filed a bug report yet as I just discovered it. === Output from failing command(s) repeated here === /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_bytecodeInterpreter.o:\n" * For target hotspot_variant-zero_libjvm_objs_bytecodeInterpreter.o: (/bin/grep -v -e "^Note: including file:" < /usr/src/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_bytecodeInterpreter.o.log || true) | /usr/bin/head -n 12 /usr/src/hs/src/hotspot/share/interpreter/bytecodeInterpreter.cpp: In static member function ?static void BytecodeInterpreter::run(interpreterState)?: /usr/src/hs/src/hotspot/share/interpreter/bytecodeInterpreter.cpp:107:51: error: ?static void SafepointSynchronize::block(JavaThread*)? is private within this context CALL_VM(SafepointSynchronize::block(THREAD), handle_exception); \ ^ /usr/src/hs/src/hotspot/share/interpreter/bytecodeInterpreter.cpp:418:9: note: in definition of macro ?CALL_VM_NAKED_LJF? func; \ ^~~~ /usr/src/hs/src/hotspot/share/interpreter/bytecodeInterpreter.cpp:436:11: note: in expansion of macro ?CALL_VM_NOCHECK? CALL_VM_NOCHECK(func); \ ^~~~~~~~~~~~~~~ /usr/src/hs/src/hotspot/share/interpreter/bytecodeInterpreter.cpp:107:9: note: in expansion of macro ?CALL_VM? CALL_VM(SafepointSynchronize::block(THREAD), handle_exception); \ if test `/usr/bin/wc -l < /usr/src/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_bytecodeInterpreter.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_bytecodeInterpreterWithChecks.o:\n" * For target hotspot_variant-zero_libjvm_objs_bytecodeInterpreterWithChecks.o: (/bin/grep -v -e "^Note: including file:" < /usr/src/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_bytecodeInterpreterWithChecks.o.log || true) | /usr/bin/head -n 12 In file included from /usr/src/hs/build/linux-x86_64-normal-zero-release/hotspot/variant-zero/gensrc/jvmtifiles/bytecodeInterpreterWithChecks.cpp:3:0: /usr/src/hs/src/hotspot/share/interpreter/bytecodeInterpreter.cpp: In static member function ?static void BytecodeInterpreter::runWithChecks(interpreterState)?: /usr/src/hs/src/hotspot/share/interpreter/bytecodeInterpreter.cpp:107:51: error: ?static void SafepointSynchronize::block(JavaThread*)? is private within this context CALL_VM(SafepointSynchronize::block(THREAD), handle_exception); \ ^ /usr/src/hs/src/hotspot/share/interpreter/bytecodeInterpreter.cpp:418:9: note: in definition of macro ?CALL_VM_NAKED_LJF? func; \ ^~~~ /usr/src/hs/src/hotspot/share/interpreter/bytecodeInterpreter.cpp:436:11: note: in expansion of macro ?CALL_VM_NOCHECK? CALL_VM_NOCHECK(func); \ ^~~~~~~~~~~~~~~ /usr/src/hs/src/hotspot/share/interpreter/bytecodeInterpreter.cpp:107:9: note: in expansion of macro ?CALL_VM? if test `/usr/bin/wc -l < /usr/src/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_bytecodeInterpreterWithChecks.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "\n* All command lines available in /usr/src/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs.\n" * All command lines available in /usr/src/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === if /bin/grep -q "recipe for target .* failed" /usr/src/hs/build/linux-x86_64-normal-zero-release/build.log 2> /dev/null; then /usr/bin/printf "\n=== Make failed targets repeated here ===\n" ; /bin/grep "recipe for target .* failed" /usr/src/hs/build/linux-x86_64-normal-zero-release/build.log ; /usr/bin/printf "=== End of repeated output ===\n" ; /usr/bin/printf "\nHint: Try searching the build log for the name of the first failed target.\n" ; else /usr/bin/printf "\nNo indication of failed target found.\n" ; /usr/bin/printf "Hint: Try searching the build log for '] Error'.\n" ; fi === Make failed targets repeated here === lib/CompileJvm.gmk:209: recipe for target '/usr/src/hs/build/linux-x86_64-normal-zero-release/hotspot/variant-zero/libjvm/objs/bytecodeInterpreter.o' failed lib/CompileJvm.gmk:209: recipe for target '/usr/src/hs/build/linux-x86_64-normal-zero-release/hotspot/variant-zero/libjvm/objs/bytecodeInterpreterWithChecks.o' failed make/Main.gmk:268: recipe for target 'hotspot-zero-libs' failed === End of repeated output === Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Wed Nov 15 13:57:40 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Nov 2017 13:57:40 +0000 Subject: Zero broken again In-Reply-To: References: Message-ID: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> On 15/11/17 13:50, John Paul Adrian Glaubitz wrote: > Anyone else already noticed that Zero recently broke again? > > I haven't filed a bug report yet as I just discovered it. > > === Output from failing command(s) repeated here === > /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_bytecodeInterpreter.o:\n" > * For target hotspot_variant-zero_libjvm_objs_bytecodeInterpreter.o: > (/bin/grep -v -e "^Note: including file:" < > /usr/src/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_bytecodeInterpreter.o.log || true) | /usr/bin/head > -n 12 > /usr/src/hs/src/hotspot/share/interpreter/bytecodeInterpreter.cpp: In static member function ?static void BytecodeInterpreter::run(interpreterState)?: > /usr/src/hs/src/hotspot/share/interpreter/bytecodeInterpreter.cpp:107:51: error: ?static void SafepointSynchronize::block(JavaThread*)? is private within this I'm looking at the JDK source, and SafepointSynchronize::block(JavaThread*) is public. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Wed Nov 15 14:03:05 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 15 Nov 2017 15:03:05 +0100 Subject: Zero broken again In-Reply-To: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> References: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> Message-ID: <60912f98-5f6d-a7d2-87cc-80310c6bf91a@physik.fu-berlin.de> On 11/15/2017 02:57 PM, Andrew Haley wrote: > I'm looking at the JDK source, and SafepointSynchronize::block(JavaThread*) > is public. No, definitely not. It's private in src/hotspot/share/runtime/safepoint.hpp. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Wed Nov 15 14:11:18 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 15 Nov 2017 15:11:18 +0100 Subject: Zero broken again In-Reply-To: <60912f98-5f6d-a7d2-87cc-80310c6bf91a@physik.fu-berlin.de> References: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> <60912f98-5f6d-a7d2-87cc-80310c6bf91a@physik.fu-berlin.de> Message-ID: On 11/15/2017 03:03 PM, John Paul Adrian Glaubitz wrote: > On 11/15/2017 02:57 PM, Andrew Haley wrote: >> I'm looking at the JDK source, and SafepointSynchronize::block(JavaThread*) >> is public. > > No, definitely not. It's private in src/hotspot/share/runtime/safepoint.hpp. See: http://hg.openjdk.java.net/jdk/hs/file/7092940fbaff/src/hotspot/share/runtime/safepoint.hpp#l168 Now I just need to figure out how "git blame" works in Mercurial :). -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From adinn at redhat.com Wed Nov 15 14:20:57 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 15 Nov 2017 14:20:57 +0000 Subject: Zero broken again In-Reply-To: References: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> <60912f98-5f6d-a7d2-87cc-80310c6bf91a@physik.fu-berlin.de> Message-ID: On 15/11/17 14:11, John Paul Adrian Glaubitz wrote: > Now I just need to figure out how "git blame" works in Mercurial :). Well, that's easy hg blame src/hotspot/share/runtime/safepoint.hpp regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From glaubitz at physik.fu-berlin.de Wed Nov 15 14:23:54 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 15 Nov 2017 15:23:54 +0100 Subject: Zero broken again In-Reply-To: References: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> <60912f98-5f6d-a7d2-87cc-80310c6bf91a@physik.fu-berlin.de> Message-ID: <9c7113b6-dbd3-db16-5df4-0b85a4985537@physik.fu-berlin.de> On 11/15/2017 03:20 PM, Andrew Dinn wrote: > On 15/11/17 14:11, John Paul Adrian Glaubitz wrote: >> Now I just need to figure out how "git blame" works in Mercurial :). > Well, that's easy > > hg blame src/hotspot/share/runtime/safepoint.hpp Yep, and it was broken in JDK-8189941: > http://hg.openjdk.java.net/jdk/hs/rev/0ce0ac68ace7#l57.16 We could set ccpInterpretor as a friend class. But that only fixes one case. It still fails with byteCodeInterpretor.cpp. Removing the "private" statement obviously fixes it but that's just to show what the problem is. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From forax at univ-mlv.fr Wed Nov 15 14:34:26 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 15 Nov 2017 15:34:26 +0100 (CET) Subject: Zero broken again In-Reply-To: References: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> <60912f98-5f6d-a7d2-87cc-80310c6bf91a@physik.fu-berlin.de> Message-ID: <1446930959.1509384.1510756466152.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "John Paul Adrian Glaubitz" > ?: "Andrew Haley" , "hotspot-dev" > Envoy?: Mercredi 15 Novembre 2017 15:11:18 > Objet: Re: Zero broken again > On 11/15/2017 03:03 PM, John Paul Adrian Glaubitz wrote: >> On 11/15/2017 02:57 PM, Andrew Haley wrote: >>> I'm looking at the JDK source, and SafepointSynchronize::block(JavaThread*) >>> is public. >> >> No, definitely not. It's private in src/hotspot/share/runtime/safepoint.hpp. > > See: > http://hg.openjdk.java.net/jdk/hs/file/7092940fbaff/src/hotspot/share/runtime/safepoint.hpp#l168 > > Now I just need to figure out how "git blame" works in Mercurial :). you mean svn blame i suppose :) > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 R?mi From gilles.m.duboscq at oracle.com Wed Nov 15 14:40:12 2017 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Wed, 15 Nov 2017 15:40:12 +0100 Subject: Zero broken again In-Reply-To: References: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> <60912f98-5f6d-a7d2-87cc-80310c6bf91a@physik.fu-berlin.de> Message-ID: On 15/11/17 15:11, John Paul Adrian Glaubitz wrote: > On 11/15/2017 03:03 PM, John Paul Adrian Glaubitz wrote: >> On 11/15/2017 02:57 PM, Andrew Haley wrote: >>> I'm looking at the JDK source, and SafepointSynchronize::block(JavaThread*) >>> is public. >> >> No, definitely not. It's private in src/hotspot/share/runtime/safepoint.hpp. > > See: > http://hg.openjdk.java.net/jdk/hs/file/7092940fbaff/src/hotspot/share/runtime/safepoint.hpp#l168 > > Now I just need to figure out how "git blame" works in Mercurial :). > It's hg annotate. Annotating this line [1] gives us rev 0ce0ac68ace7 [2] (8189941: Implementation JEP 312: Thread-local handshake) which made do_call_back and block private but didn't update bytecodeInterpreter. Gilles [1]: http://hg.openjdk.java.net/jdk/hs/annotate/7092940fbaff/src/hotspot/share/runtime/safepoint.hpp#l168 [2]: http://hg.openjdk.java.net/jdk/hs/rev/0ce0ac68ace7#l57.1 From glaubitz at physik.fu-berlin.de Wed Nov 15 14:43:53 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 15 Nov 2017 15:43:53 +0100 Subject: Zero broken again In-Reply-To: References: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> <60912f98-5f6d-a7d2-87cc-80310c6bf91a@physik.fu-berlin.de> Message-ID: <5330db35-c38a-7bd3-f0a9-763df17a4828@physik.fu-berlin.de> On 11/15/2017 03:40 PM, Gilles Duboscq wrote: > It's hg annotate. > Annotating this line [1] gives us rev 0ce0ac68ace7 [2] (8189941: Implementation > JEP 312: Thread-local handshake) which made do_call_back and block private but didn't update bytecodeInterpreter. Yes, I already found that. I haven't come up with a solution yet though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From robbin.ehn at oracle.com Wed Nov 15 14:45:50 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 15 Nov 2017 15:45:50 +0100 Subject: Zero broken again In-Reply-To: <5330db35-c38a-7bd3-f0a9-763df17a4828@physik.fu-berlin.de> References: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> <60912f98-5f6d-a7d2-87cc-80310c6bf91a@physik.fu-berlin.de> <5330db35-c38a-7bd3-f0a9-763df17a4828@physik.fu-berlin.de> Message-ID: <6d56da6c-3f89-904e-9d3e-6c14b15210fc@oracle.com> Hi sorry about that. I think we want: SafepointMechanism::block_if_requested(thread); /Robbin On 11/15/2017 03:43 PM, John Paul Adrian Glaubitz wrote: > On 11/15/2017 03:40 PM, Gilles Duboscq wrote: >> It's hg annotate. >> Annotating this line [1] gives us rev 0ce0ac68ace7 [2] (8189941: Implementation >> JEP 312: Thread-local handshake) which made do_call_back and block private but didn't update bytecodeInterpreter. > > Yes, I already found that. I haven't come up with a solution yet though. > > Adrian > From glaubitz at physik.fu-berlin.de Wed Nov 15 14:50:00 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 15 Nov 2017 15:50:00 +0100 Subject: Zero broken again In-Reply-To: <6d56da6c-3f89-904e-9d3e-6c14b15210fc@oracle.com> References: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> <60912f98-5f6d-a7d2-87cc-80310c6bf91a@physik.fu-berlin.de> <5330db35-c38a-7bd3-f0a9-763df17a4828@physik.fu-berlin.de> <6d56da6c-3f89-904e-9d3e-6c14b15210fc@oracle.com> Message-ID: On 11/15/2017 03:45 PM, Robbin Ehn wrote: > I think we want: > > SafepointMechanism::block_if_requested(thread); Yes, that helps. However, we still need to take care of do_call_back(): (/bin/grep -v -e "^Note: including file:" < /usr/src/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_cppInterpreter_zero.o.log || true) | /usr/bin/head -n 12 /usr/src/hs/src/hotspot/cpu/zero/cppInterpreter_zero.cpp: In static member function ?static int CppInterpreter::native_entry(Method*, intptr_t, Thread*)?: /usr/src/hs/src/hotspot/cpu/zero/cppInterpreter_zero.cpp:382:42: error: ?static bool SafepointSynchronize::do_call_back()? is private within this context if (SafepointSynchronize::do_call_back() || Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From robbin.ehn at oracle.com Wed Nov 15 14:52:12 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 15 Nov 2017 15:52:12 +0100 Subject: Zero broken again In-Reply-To: References: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> <60912f98-5f6d-a7d2-87cc-80310c6bf91a@physik.fu-berlin.de> <5330db35-c38a-7bd3-f0a9-763df17a4828@physik.fu-berlin.de> <6d56da6c-3f89-904e-9d3e-6c14b15210fc@oracle.com> Message-ID: <45fa0157-a000-2078-19f4-53376a0240ca@oracle.com> Hi, Yes that should be: SafepointMechanism::poll(Thread* thread) /Robbin On 11/15/2017 03:50 PM, John Paul Adrian Glaubitz wrote: > On 11/15/2017 03:45 PM, Robbin Ehn wrote: >> I think we want: >> >> SafepointMechanism::block_if_requested(thread); > > Yes, that helps. > > However, we still need to take care of do_call_back(): > > (/bin/grep -v -e "^Note: including file:" < > /usr/src/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_cppInterpreter_zero.o.log > || true) | /usr/bin/head -n 12 > /usr/src/hs/src/hotspot/cpu/zero/cppInterpreter_zero.cpp: In static > member function ?static int CppInterpreter::native_entry(Method*, > intptr_t, Thread*)?: > /usr/src/hs/src/hotspot/cpu/zero/cppInterpreter_zero.cpp:382:42: error: > ?static bool SafepointSynchronize::do_call_back()? is private within > this context > if (SafepointSynchronize::do_call_back() || > > Adrian > From glaubitz at physik.fu-berlin.de Wed Nov 15 14:54:44 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 15 Nov 2017 15:54:44 +0100 Subject: Zero broken again In-Reply-To: <45fa0157-a000-2078-19f4-53376a0240ca@oracle.com> References: <69fd45c6-156c-6300-d7ce-404aa5ca80e2@redhat.com> <60912f98-5f6d-a7d2-87cc-80310c6bf91a@physik.fu-berlin.de> <5330db35-c38a-7bd3-f0a9-763df17a4828@physik.fu-berlin.de> <6d56da6c-3f89-904e-9d3e-6c14b15210fc@oracle.com> <45fa0157-a000-2078-19f4-53376a0240ca@oracle.com> Message-ID: <41c5dafb-3e4b-6685-251a-367c6bda52f3@physik.fu-berlin.de> On 11/15/2017 03:52 PM, Robbin Ehn wrote: > Yes that should be: > SafepointMechanism::poll(Thread* thread) Thanks. Testing now. Will push a RFR in a few minutes if no one objects. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Wed Nov 15 15:07:47 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 15 Nov 2017 16:07:47 +0100 Subject: RFR: 8191333: Zero variant broken after 8189941 Message-ID: Hi! Please review this change [1] which fixes Zero which got broken after 8189941 [2]. Thanks to Robbin Ehn for the quick help with this! Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8191333/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8191333 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From coleen.phillimore at oracle.com Wed Nov 15 15:48:22 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Nov 2017 10:48:22 -0500 Subject: RFR: 8191333: Zero variant broken after 8189941 In-Reply-To: References: Message-ID: Looks good! Coleen On 11/15/17 10:07 AM, John Paul Adrian Glaubitz wrote: > Hi! > > Please review this change [1] which fixes Zero which got broken > after 8189941 [2]. > > Thanks to Robbin Ehn for the quick help with this! > > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8191333/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8191333 From robbin.ehn at oracle.com Wed Nov 15 15:56:28 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 15 Nov 2017 16:56:28 +0100 Subject: RFR: 8191333: Zero variant broken after 8189941 In-Reply-To: References: Message-ID: <45b48263-c82e-7c5f-5cf3-25c74cdfb0be@oracle.com> Hi looks good, but: 101 #define SAFEPOINT \ 102 if ( SafepointSynchronize::is_synchronizing()) { \ 103 { \ You should not need to call SafepointSynchronize::is_synchronizing(). SafepointMechanism::block_if_requested(THREAD) takes care of everything. And if you ever plan to add thread-local handshake support to zero that won't work. If you want push code as is, that is fine. /Robbin On 11/15/2017 04:07 PM, John Paul Adrian Glaubitz wrote: > Hi! > > Please review this change [1] which fixes Zero which got broken > after 8189941 [2]. > > Thanks to Robbin Ehn for the quick help with this! > > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8191333/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8191333 > From glaubitz at physik.fu-berlin.de Wed Nov 15 16:04:03 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 15 Nov 2017 17:04:03 +0100 Subject: RFR: 8191333: Zero variant broken after 8189941 In-Reply-To: <45b48263-c82e-7c5f-5cf3-25c74cdfb0be@oracle.com> References: <45b48263-c82e-7c5f-5cf3-25c74cdfb0be@oracle.com> Message-ID: Hi Robbin! On 11/15/2017 04:56 PM, Robbin Ehn wrote: > Hi looks good, but: > > 101 #define SAFEPOINT ????? \ > ?102???? if ( SafepointSynchronize::is_synchronizing()) { ??????? \ > ?103???????? { ??????? \ > > You should not need to call SafepointSynchronize::is_synchronizing(). > SafepointMechanism::block_if_requested(THREAD) takes care of everything. What about the handles? > And if you ever plan to add thread-local handshake support to zero that > won't work. You mean, it won't work with the above code? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From erik.osterlund at oracle.com Wed Nov 15 16:42:48 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 15 Nov 2017 17:42:48 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <9cee59e0-5aab-3d8b-9485-8edd5f27b941@oracle.com> References: <5A048993.2000002@oracle.com> <9cee59e0-5aab-3d8b-9485-8edd5f27b941@oracle.com> Message-ID: <5A0C6E88.7010209@oracle.com> Hi David, Thank you for the review. On 2017-11-15 08:47, David Holmes wrote: > Hi Erik, > > I really like the level of abstraction and encapsulation this provides. Glad to hear it! > Can't comment on the GC specific details or the template mechanics > directly, of course. :) > > A couple of comments: > > src/hotspot/share/oops/klass.hpp > > 412 // Is an oop/narrowOop null or subtype of this Klass? > 413 template > 414 bool is_covariant(T element); > > I find "is_covariant" a very obscure way to name this. It may be > academically accurate but it's really just asking if the element is of > a type that is a subclass of the current klass. The null handling > complicates it, but it seems to me that: > > template > bool Klass::is_instanceof_or_null(T element); > > would be more consistent with how we normally refer to things in the > VM (though the _or_null can be dropped from the name). Hmm, I see your point. I have renamed covariant/contravariant accordingly to fit better into our current notions. The ARRAYCOPY_CONTRAVARIANT decorator has been renamed ARRAYCOPY_CHECKCAST. The is_covariant check has been renamed is_instanceof_or_null as you proposed. The covariant_bound() method has been renamed to element_klass(). > --- > > src/hotspot/share/oops/objArrayOop.cpp > > Klass* objArrayOopDesc::covariant_bound() > > There's that word again. :) If you really think you need to use > covariance within these API's you really need to add some comments to > the method declarations to explain them. Most of us probably have a > minimal recollection of covariance and contravariance from discussing > type-safety for method parameters and return types. :) Fixed as mentioned above. > > --- > > src/hotspot/share/prims/unsafe.cpp > > The changes from jobjects to oops made me uneasy, but I'm assuming the > places where MemoryAccess and GuardedMemoryAccess are used are > affectively all leave routines with no chance of hitting anything that > would respond to a safepoint request? Yes, that is correct. There are no thread transitions in those paths. Here is a new full webrev: http://cr.openjdk.java.net/~eosterlund/8189871/webrev.01/ Incremental: http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00_01/ Thanks, /Erik > Thanks, > David > ----- > > On 10/11/2017 3:00 AM, Erik ?sterlund wrote: >> Hi, >> >> In an effort to remove explicit calls to GC barriers (and other >> orthogonal forms of barriers, like encoding/decoding oops for >> compressed oops and fencing for memory ordering), I have built an API >> that I call "Access". Its purpose is to perform accesses with >> declarative semantics, to handle multiple orthogonal concerns that >> affect how an access is performed, including memory ordering, >> compressed oops, GC barriers for marking, reference strength, etc, >> and as a result making GCs more modular, and as a result allow new >> concurrently compacting GC schemes utilizing load barriers to live in >> harmony in hotspot without everyone going crazy manually inserting >> barriers if UseBlahGC is enabled. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8189871 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ >> >> So there are three views of this I suppose: >> >> 1) The frontend: how this is actually used in shared code >> 2) The backends: how anyone writing a GC sticks their required >> barriers in there >> 3) The internals: how accesses find their way from the frontend to >> the corresponding backend >> >> == Frontend == >> >> Let's start with the frontend. I hope I made this fairly simple! You >> can find it in runtime/access.hpp >> Each access annotates its declarative semantics with a set of >> "decorators", which is the name of the attributes/properties >> affecting how an access is performed. >> There is an Access API that makes the declarative >> semantics possible. >> >> For example, if I want to perform a load acquire of an oop in the >> heap that has "weak" strength, I would do something like: >> oop result = Access> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >> >> The Access API would then send the access through some GC backend, >> that overrides the whole access and tells it to perform a "raw" load >> acquire, and then possibly keep it alive if necessary (G1 SATB >> enqueue barriers). >> >> To make life easier, there are some helpers for the most common >> access patterns that merely add some default decorator for the >> involved type of access. For example, there is a RawAccess for >> performing AS_RAW accesses (that bypasses runtime checks and GC >> barriers), HeapAccess sets the IN_HEAP decorator and RootAccess sets >> the IN_ROOT decorator for accessing root oops. So for the previous >> call, I could simply do: >> >> oop result = HeapAccess> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >> >> The access.hpp file introduces each decorator (belonging to some >> category) with an explanation what it is for. It also introduces all >> operations you can make with access (loads, stores, cmpxchg, xchg, >> arraycopy and clone). >> >> This changeset mostly introduces the Access API but is not complete >> in annotating the code more than where it gets very awkward if I don't. >> >> == Backend == >> >> For a GC maintainer, the BarrierSet::AccessBarrier is the top level >> backend that provides basic accesses that may be overridden. By >> default, it just performs raw accesses without any GC barriers, that >> handle things like compressed oops and memory ordering only. The >> ModRef barrier set introduces the notion of pre/post write barriers, >> that can be overridden for each GC. The CardTableModRef barrier set >> overrides the post write barrier to mark cards, and G1 overrides it >> to mark cards slightly differently and do some SATB enqueueing. G1 >> also overrides loads to see if we need to perform SATB enqueue on >> weak references. >> >> The raw accesses go to the RawAccessBarrier (living in >> accessBackend.hpp) that performs the actual accesses. It connects to >> Atomic and OrderAccess for accesses that require that. >> >> == Internals == >> >> Internally, the accesses go through a number of stages in >> access.inline.hpp as documented at the top. >> >> 1) set default decorators and get rid of CV qualifiers etc. Sanity >> checking also happens here: we check that the decorators make sense >> for the access being performed, and that the passed in types are not >> bogus. >> 2) reduce types so if we have a different type of the address and >> value, then either it is not allowed or it implies we use compressed >> oops and remember that we know something about whether compressed >> oops are used or not, before erasing address type >> 3) pre-runtime dispatch: figure out if all runtime checks can be >> bypassed into a raw access >> 4) runtime dispatch: send the access through a function pointer that >> upon the first invocation resolves the intended GC AccessBarrier >> accessor on the BarrierSet that handles this access, as well as >> figures out whether we are using compressed oops or not while we are >> at it, and then calls it through the post-runtime dispatch >> 5) post-runtime dispatch: fix some erased types that were not known >> at compile time such as whether the address is a narrowOop* or oop* >> depending on whether compressed oops was selected at runtime or not, >> and call the resolved BarrierSet::AccessBarrier accessor >> (load/store/etc) with all the call-site build-time and run-time >> resolved decorators and type information that describes the access. >> >> Testing: mach5 tier1-5 >> >> Thanks, >> /Erik From coleen.phillimore at oracle.com Wed Nov 15 16:48:56 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Nov 2017 11:48:56 -0500 Subject: RFR: 8191333: Zero variant broken after 8189941 In-Reply-To: References: <45b48263-c82e-7c5f-5cf3-25c74cdfb0be@oracle.com> Message-ID: <75061560-ea00-d955-bb5a-84eaa8f3600e@oracle.com> On 11/15/17 11:04 AM, John Paul Adrian Glaubitz wrote: > Hi Robbin! > > On 11/15/2017 04:56 PM, Robbin Ehn wrote: >> Hi looks good, but: >> >> 101 #define SAFEPOINT ????? \ >> ?102???? if ( SafepointSynchronize::is_synchronizing()) { ??????? \ >> ?103???????? { ??????? \ >> >> You should not need to call SafepointSynchronize::is_synchronizing(). >> SafepointMechanism::block_if_requested(THREAD) takes care of everything. > What about the handles? Honestly, after looking at it, I have no idea.? It seems like something you should remove and see if that works.? The comment says that there should be no active handles.? Maybe have a NoHandleMark unconditionally? then SafepointMechanism::block_if_requested(THREAD) so that the comment is actually an assertion.? Sorry for too quick review. Coleen > >> And if you ever plan to add thread-local handshake support to zero that >> won't work. > You mean, it won't work with the above code? > > Adrian > From erik.osterlund at oracle.com Wed Nov 15 16:55:38 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 15 Nov 2017 17:55:38 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> Message-ID: <5A0C718A.5080401@oracle.com> Hi Coleen, On 2017-11-14 02:34, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/src/hotspot/share/classfile/javaClasses.cpp.udiff.html > > > + assert(!is_reference || > InstanceKlass::cast(obj->klass())->is_subclass_of(SystemDictionary::Reference_klass()), > "sanity"); > > > Can you do something like this instead of all the InstanceKlass::cast. > > + InstanceKlass* k = InstanceKlass::cast(obj->klass()); > + bool is_reference = k->reference_type() != REF_NONE; > + assert(!is_reference || > k->is_subclass_of(SystemDictionary::Reference_klass()), "sanity"); > + return is_reference; > +} > Yes, sure. Fixed in latest webrev in this thread (http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00_01/) > And do you know that this is an instance rather than array instance? > InstanceKlass::cast() has an assert that is_instance_klass(). The code previously assumed it is_instance_klass(), and I did not question its correctness. But now that you mention it, it does seem safer to explicitly check. So I added an explicit check for that. > > http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/src/hotspot/share/oops/klass.cpp.udiff.html > > > Revert file with only one line removed. > Fixed. > > http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/src/hotspot/share/runtime/access.hpp.html > > > 240 template > 241 struct OopOrNarrowOopInternal: AllStatic { > 242 typedef oop type; > 243 }; > 244 > 245 template <> > 246 struct OopOrNarrowOopInternal: AllStatic { > 247 typedef narrowOop type; > 248 }; > 249 > > Kim and I agree that we should not have the default template > definition for oop and have two specializations instead. Mostly I > agree because this is confusing. > > 240 template > 241 struct OopOrNarrowOopInternal; > > 240 template <> > 241 struct OopOrNarrowOopInternal: AllStatic { > 242 typedef oop type; > 243 }; > 244 > 245 template <> > 246 struct OopOrNarrowOopInternal: AllStatic { > 247 typedef narrowOop type; > 248 }; > 249 > This choice is actually deliberate. The reason is that we pass in things that is-an oop but is not exactly oop, like for example arrayOop or oopDesc* and the whole subclass tree if oop. An earlier incarnation of the Access API used a new IsDerived metafunction to determine whether a type is-an oop. However, in order to keep the solution simpler and introduce less type dependencies, I instead use this OopOrNarrowOop thing to pass oop-like things through it and narrow it down to oop or narrowOop. If a narrowOop is passed in, then it becomes narrowOop, if you pass in oopDesc*, arrayOop, oop, instanceOop, or whatever, then it results in an oop, and tries to implicitly convert whatever was passed in to oop. That will act as if the overload was "oop" in the way that you can pass in anything that is implicitly convertible to exactly oop or narrowOop, and once you make it past that layer, it will be treated only as oop or narrowOop. Sorry for any resulting confusion. > > We were also trying to figure out how the runtime would know whether > to use IN_CONCURRENT_ROOT vs IN_ROOT decorator, since it probably > varies for GCs. And requires runtime code to know whether the root is > scanned concurrently or not, which we don't know. > The Access API needs to know whether this is scanned concurrently or not (because we *have* to perform different barriers then). So whatever data structure the access is performed on, needs to make sure this is known. > This is all I have for now but I'm going to download the patch and > have more of a look tomorrow. Thank you for the review and thank you for taking the time to look at this. Thanks, /Erik > Thanks, > Coleen > > > On 11/9/17 12:00 PM, Erik ?sterlund wrote: >> Hi, >> >> In an effort to remove explicit calls to GC barriers (and other >> orthogonal forms of barriers, like encoding/decoding oops for >> compressed oops and fencing for memory ordering), I have built an API >> that I call "Access". Its purpose is to perform accesses with >> declarative semantics, to handle multiple orthogonal concerns that >> affect how an access is performed, including memory ordering, >> compressed oops, GC barriers for marking, reference strength, etc, >> and as a result making GCs more modular, and as a result allow new >> concurrently compacting GC schemes utilizing load barriers to live in >> harmony in hotspot without everyone going crazy manually inserting >> barriers if UseBlahGC is enabled. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8189871 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ >> >> So there are three views of this I suppose: >> >> 1) The frontend: how this is actually used in shared code >> 2) The backends: how anyone writing a GC sticks their required >> barriers in there >> 3) The internals: how accesses find their way from the frontend to >> the corresponding backend >> >> == Frontend == >> >> Let's start with the frontend. I hope I made this fairly simple! You >> can find it in runtime/access.hpp >> Each access annotates its declarative semantics with a set of >> "decorators", which is the name of the attributes/properties >> affecting how an access is performed. >> There is an Access API that makes the declarative >> semantics possible. >> >> For example, if I want to perform a load acquire of an oop in the >> heap that has "weak" strength, I would do something like: >> oop result = Access> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >> >> The Access API would then send the access through some GC backend, >> that overrides the whole access and tells it to perform a "raw" load >> acquire, and then possibly keep it alive if necessary (G1 SATB >> enqueue barriers). >> >> To make life easier, there are some helpers for the most common >> access patterns that merely add some default decorator for the >> involved type of access. For example, there is a RawAccess for >> performing AS_RAW accesses (that bypasses runtime checks and GC >> barriers), HeapAccess sets the IN_HEAP decorator and RootAccess sets >> the IN_ROOT decorator for accessing root oops. So for the previous >> call, I could simply do: >> >> oop result = HeapAccess> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >> >> The access.hpp file introduces each decorator (belonging to some >> category) with an explanation what it is for. It also introduces all >> operations you can make with access (loads, stores, cmpxchg, xchg, >> arraycopy and clone). >> >> This changeset mostly introduces the Access API but is not complete >> in annotating the code more than where it gets very awkward if I don't. >> >> == Backend == >> >> For a GC maintainer, the BarrierSet::AccessBarrier is the top level >> backend that provides basic accesses that may be overridden. By >> default, it just performs raw accesses without any GC barriers, that >> handle things like compressed oops and memory ordering only. The >> ModRef barrier set introduces the notion of pre/post write barriers, >> that can be overridden for each GC. The CardTableModRef barrier set >> overrides the post write barrier to mark cards, and G1 overrides it >> to mark cards slightly differently and do some SATB enqueueing. G1 >> also overrides loads to see if we need to perform SATB enqueue on >> weak references. >> >> The raw accesses go to the RawAccessBarrier (living in >> accessBackend.hpp) that performs the actual accesses. It connects to >> Atomic and OrderAccess for accesses that require that. >> >> == Internals == >> >> Internally, the accesses go through a number of stages in >> access.inline.hpp as documented at the top. >> >> 1) set default decorators and get rid of CV qualifiers etc. Sanity >> checking also happens here: we check that the decorators make sense >> for the access being performed, and that the passed in types are not >> bogus. >> 2) reduce types so if we have a different type of the address and >> value, then either it is not allowed or it implies we use compressed >> oops and remember that we know something about whether compressed >> oops are used or not, before erasing address type >> 3) pre-runtime dispatch: figure out if all runtime checks can be >> bypassed into a raw access >> 4) runtime dispatch: send the access through a function pointer that >> upon the first invocation resolves the intended GC AccessBarrier >> accessor on the BarrierSet that handles this access, as well as >> figures out whether we are using compressed oops or not while we are >> at it, and then calls it through the post-runtime dispatch >> 5) post-runtime dispatch: fix some erased types that were not known >> at compile time such as whether the address is a narrowOop* or oop* >> depending on whether compressed oops was selected at runtime or not, >> and call the resolved BarrierSet::AccessBarrier accessor >> (load/store/etc) with all the call-site build-time and run-time >> resolved decorators and type information that describes the access. >> >> Testing: mach5 tier1-5 >> >> Thanks, >> /Erik > From paul.sandoz at oracle.com Wed Nov 15 17:03:29 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 15 Nov 2017 09:03:29 -0800 Subject: RFR 8187742 Minimal set of bootstrap methods for dynamic constants In-Reply-To: References: <7fecd36b-61b3-fe75-44ba-9c58f73d4da6@oracle.com> <26336F4F-0A21-4A08-AFA3-23CA972CAD93@oracle.com> <130F7E94-9408-4C49-9C23-840361B4B379@oracle.com> Message-ID: > On 14 Nov 2017, at 20:48, stanislav lukyanov wrote: > > On 15.11.2017 6:19, Paul Sandoz wrote: >>> On 10 Nov 2017, at 01:36, stanislav lukyanov wrote: >>> >>> On 10.11.2017 0:13, Paul Sandoz wrote: >>>> <...> >>>> I would prefer to follow up later on with more non-normative explanatory text. It will take some careful crafting and i don?t want that to side-track the review for the moment (including guidance on what forms of computed constants are acceptable). >>> Fair. Does it make sense to add a sub-task for this to JDK-8185992 to keep it on the radar? >> You would mind adding a sub-task with a tbd minor target? > TBD_Minor would mean an update release, right? > I think it can't be a TBD_Minor then since it is technically a specification change and should happen in a Java SE release (maybe 11?), but maybe I'm wrong. I was thinking this issue would be just for non-normative text in an @apiNote. Whether that maps to tbd_x or not with the new release process i dunno. Let?s just use tbd_major for now. Paul. > Anyway, as long as that's logged and not completely forgotten, I'm happy :) > > Thanks, > Stas From erik.osterlund at oracle.com Wed Nov 15 17:04:44 2017 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Wed, 15 Nov 2017 18:04:44 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <54781b01-886a-a09a-9b3f-ac5efa8d8294@oracle.com> References: <5A048993.2000002@oracle.com> <9cee59e0-5aab-3d8b-9485-8edd5f27b941@oracle.com> <54781b01-886a-a09a-9b3f-ac5efa8d8294@oracle.com> Message-ID: Hi Coleen, > On 15 Nov 2017, at 14:00, coleen.phillimore at oracle.com wrote: > > > >> On 11/15/17 2:47 AM, David Holmes wrote: >> Hi Erik, >> >> I really like the level of abstraction and encapsulation this provides. >> >> Can't comment on the GC specific details or the template mechanics directly, of course. :) >> >> A couple of comments: >> >> src/hotspot/share/oops/klass.hpp >> >> 412 // Is an oop/narrowOop null or subtype of this Klass? >> 413 template >> 414 bool is_covariant(T element); >> >> I find "is_covariant" a very obscure way to name this. It may be academically accurate but it's really just asking if the element is of a type that is a subclass of the current klass. The null handling complicates it, but it seems to me that: >> >> template >> bool Klass::is_instanceof_or_null(T element); >> >> would be more consistent with how we normally refer to things in the VM (though the _or_null can be dropped from the name). >> > > Hi, I have to agree with David on the covariant name, and his suggested replacement. > > This name made me stop in my tracks while reading this. Fixed. Thanks, /Erik > thanks, > Coleen >> --- >> >> src/hotspot/share/oops/objArrayOop.cpp >> >> Klass* objArrayOopDesc::covariant_bound() >> >> There's that word again. :) If you really think you need to use covariance within these API's you really need to add some comments to the method declarations to explain them. Most of us probably have a minimal recollection of covariance and contravariance from discussing type-safety for method parameters and return types. :) >> >> --- >> >> src/hotspot/share/prims/unsafe.cpp >> >> The changes from jobjects to oops made me uneasy, but I'm assuming the places where MemoryAccess and GuardedMemoryAccess are used are affectively all leave routines with no chance of hitting anything that would respond to a safepoint request? >> >> Thanks, >> David >> ----- >> >>> On 10/11/2017 3:00 AM, Erik ?sterlund wrote: >>> Hi, >>> >>> In an effort to remove explicit calls to GC barriers (and other orthogonal forms of barriers, like encoding/decoding oops for compressed oops and fencing for memory ordering), I have built an API that I call "Access". Its purpose is to perform accesses with declarative semantics, to handle multiple orthogonal concerns that affect how an access is performed, including memory ordering, compressed oops, GC barriers for marking, reference strength, etc, and as a result making GCs more modular, and as a result allow new concurrently compacting GC schemes utilizing load barriers to live in harmony in hotspot without everyone going crazy manually inserting barriers if UseBlahGC is enabled. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8189871 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ >>> >>> So there are three views of this I suppose: >>> >>> 1) The frontend: how this is actually used in shared code >>> 2) The backends: how anyone writing a GC sticks their required barriers in there >>> 3) The internals: how accesses find their way from the frontend to the corresponding backend >>> >>> == Frontend == >>> >>> Let's start with the frontend. I hope I made this fairly simple! You can find it in runtime/access.hpp >>> Each access annotates its declarative semantics with a set of "decorators", which is the name of the attributes/properties affecting how an access is performed. >>> There is an Access API that makes the declarative semantics possible. >>> >>> For example, if I want to perform a load acquire of an oop in the heap that has "weak" strength, I would do something like: >>> oop result = Access::oop_load_at(obj, offset); >>> >>> The Access API would then send the access through some GC backend, that overrides the whole access and tells it to perform a "raw" load acquire, and then possibly keep it alive if necessary (G1 SATB enqueue barriers). >>> >>> To make life easier, there are some helpers for the most common access patterns that merely add some default decorator for the involved type of access. For example, there is a RawAccess for performing AS_RAW accesses (that bypasses runtime checks and GC barriers), HeapAccess sets the IN_HEAP decorator and RootAccess sets the IN_ROOT decorator for accessing root oops. So for the previous call, I could simply do: >>> >>> oop result = HeapAccess::oop_load_at(obj, offset); >>> >>> The access.hpp file introduces each decorator (belonging to some category) with an explanation what it is for. It also introduces all operations you can make with access (loads, stores, cmpxchg, xchg, arraycopy and clone). >>> >>> This changeset mostly introduces the Access API but is not complete in annotating the code more than where it gets very awkward if I don't. >>> >>> == Backend == >>> >>> For a GC maintainer, the BarrierSet::AccessBarrier is the top level backend that provides basic accesses that may be overridden. By default, it just performs raw accesses without any GC barriers, that handle things like compressed oops and memory ordering only. The ModRef barrier set introduces the notion of pre/post write barriers, that can be overridden for each GC. The CardTableModRef barrier set overrides the post write barrier to mark cards, and G1 overrides it to mark cards slightly differently and do some SATB enqueueing. G1 also overrides loads to see if we need to perform SATB enqueue on weak references. >>> >>> The raw accesses go to the RawAccessBarrier (living in accessBackend.hpp) that performs the actual accesses. It connects to Atomic and OrderAccess for accesses that require that. >>> >>> == Internals == >>> >>> Internally, the accesses go through a number of stages in access.inline.hpp as documented at the top. >>> >>> 1) set default decorators and get rid of CV qualifiers etc. Sanity checking also happens here: we check that the decorators make sense for the access being performed, and that the passed in types are not bogus. >>> 2) reduce types so if we have a different type of the address and value, then either it is not allowed or it implies we use compressed oops and remember that we know something about whether compressed oops are used or not, before erasing address type >>> 3) pre-runtime dispatch: figure out if all runtime checks can be bypassed into a raw access >>> 4) runtime dispatch: send the access through a function pointer that upon the first invocation resolves the intended GC AccessBarrier accessor on the BarrierSet that handles this access, as well as figures out whether we are using compressed oops or not while we are at it, and then calls it through the post-runtime dispatch >>> 5) post-runtime dispatch: fix some erased types that were not known at compile time such as whether the address is a narrowOop* or oop* depending on whether compressed oops was selected at runtime or not, and call the resolved BarrierSet::AccessBarrier accessor (load/store/etc) with all the call-site build-time and run-time resolved decorators and type information that describes the access. >>> >>> Testing: mach5 tier1-5 >>> >>> Thanks, >>> /Erik > From alexander.harlap at oracle.com Wed Nov 15 18:28:58 2017 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Wed, 15 Nov 2017 13:28:58 -0500 Subject: Request for review JDK-8187819 gc/TestFullGCALot.java fails on jdk10 started with "-XX:-UseCompressedOops" option In-Reply-To: <1508324906.4435.15.camel@oracle.com> References: <1508324906.4435.15.camel@oracle.com> Message-ID: <6abe26c6-b3e4-119d-dbfa-2b4689f21635@oracle.com> Hi Thomas, I added 8187819 to @bug tag of the TestFullGCALot test. New revision of change is located at http://cr.openjdk.java.net/~aharlap/8187819/webrev.01/ Alex On 10/18/2017 7:08 AM, Thomas Schatzl wrote: > Hi, > > On Tue, 2017-10-03 at 14:44 -0400, Alexander Harlap wrote: >> Please review change for JDK-8187819 >> >> gc/TestFullGCALot.java fails on jdk10 started with >> "-XX:-UseCompressedOops" option. >> >> Change is located at http://cr.openjdk.java.net/~aharlap/8187819/webr >> ev.00/ >> >> Initialized metaspace performance counters before their potential >> use. >> >> Tested - JPRT >> > - I think you should add the 8187819 number to the TestFullGCALot > test at the @bug tag > > Looks good otherwise. > > Thanks, > Thomas From glaubitz at physik.fu-berlin.de Wed Nov 15 18:44:24 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 15 Nov 2017 19:44:24 +0100 Subject: RFR: 8191333: Zero variant broken after 8189941 In-Reply-To: <75061560-ea00-d955-bb5a-84eaa8f3600e@oracle.com> References: <45b48263-c82e-7c5f-5cf3-25c74cdfb0be@oracle.com> <75061560-ea00-d955-bb5a-84eaa8f3600e@oracle.com> Message-ID: <4a9a8dc4-9153-abf6-08cb-c5a4ca937fab@physik.fu-berlin.de> On 11/15/2017 05:48 PM, coleen.phillimore at oracle.com wrote: >> What about the handles? > > Honestly, after looking at it, I have no idea.? It seems like something you should remove and see if that works.? The comment says that there should be no > active handles.? Maybe have a NoHandleMark unconditionally? then SafepointMechanism::block_if_requested(THREAD) so that the comment is actually an assertion.? > Sorry for too quick review. I just tested that. This builds fine. Whether it's the way to go, I'm not sure. Maybe Robbin can make a statement regarding this. The freshly JVM is run during the build if I remember correctly, so I assume it works with this particular change. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From coleen.phillimore at oracle.com Wed Nov 15 21:21:25 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Nov 2017 16:21:25 -0500 Subject: RFR (XS) 8191370: Add serviceability agent tests to tier1 Message-ID: open webrev at http://cr.openjdk.java.net/~coleenp/8191370.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8191370 Ran mach5 tier1 with and without change and checked the time (and that they ran with my change).? See bug for more information. Christian suggested this change after my last breakage. thanks, Coleen From george.triantafillou at oracle.com Wed Nov 15 21:33:31 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 15 Nov 2017 16:33:31 -0500 Subject: RFR (XS) 8191370: Add serviceability agent tests to tier1 In-Reply-To: References: Message-ID: <3eea4540-b9fd-7658-ece0-2c503b543493@oracle.com> Hi Coleen, Looks good. -George On 11/15/2017 4:21 PM, coleen.phillimore at oracle.com wrote: > open webrev at http://cr.openjdk.java.net/~coleenp/8191370.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8191370 > > Ran mach5 tier1 with and without change and checked the time (and that > they ran with my change).? See bug for more information. > > Christian suggested this change after my last breakage. > > thanks, > Coleen From daniel.daugherty at oracle.com Wed Nov 15 21:34:34 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 15 Nov 2017 16:34:34 -0500 Subject: RFR (XS) 8191370: Add serviceability agent tests to tier1 In-Reply-To: References: Message-ID: <448ee334-498f-0302-4d3c-b3e190aa8abd@oracle.com> On 11/15/17 4:21 PM, coleen.phillimore at oracle.com wrote: > open webrev at http://cr.openjdk.java.net/~coleenp/8191370.01/webrev test/hotspot/jtreg/TEST.groups ??? No comments. Thumbs up! Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8191370 > > Ran mach5 tier1 with and without change and checked the time (and that > they ran with my change).? See bug for more information. > > Christian suggested this change after my last breakage. > > thanks, > Coleen From coleen.phillimore at oracle.com Wed Nov 15 21:46:15 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Nov 2017 16:46:15 -0500 Subject: RFR (XS) 8191370: Add serviceability agent tests to tier1 In-Reply-To: <448ee334-498f-0302-4d3c-b3e190aa8abd@oracle.com> References: <448ee334-498f-0302-4d3c-b3e190aa8abd@oracle.com> Message-ID: <42bd27c5-cd98-468d-5c24-19d9f51487cc@oracle.com> Thanks George and Dan! Coleen On 11/15/17 4:34 PM, Daniel D. Daugherty wrote: > On 11/15/17 4:21 PM, coleen.phillimore at oracle.com wrote: >> open webrev at http://cr.openjdk.java.net/~coleenp/8191370.01/webrev > > test/hotspot/jtreg/TEST.groups > ??? No comments. > > Thumbs up! > > Dan > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8191370 >> >> Ran mach5 tier1 with and without change and checked the time (and >> that they ran with my change).? See bug for more information. >> >> Christian suggested this change after my last breakage. >> >> thanks, >> Coleen > From david.holmes at oracle.com Thu Nov 16 01:51:05 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 Nov 2017 11:51:05 +1000 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A0C6E88.7010209@oracle.com> References: <5A048993.2000002@oracle.com> <9cee59e0-5aab-3d8b-9485-8edd5f27b941@oracle.com> <5A0C6E88.7010209@oracle.com> Message-ID: On 16/11/2017 2:42 AM, Erik ?sterlund wrote: > Hi David, > > Thank you for the review. > > On 2017-11-15 08:47, David Holmes wrote: >> Hi Erik, >> >> I really like the level of abstraction and encapsulation this provides. > > Glad to hear it! > >> Can't comment on the GC specific details or the template mechanics >> directly, of course. :) >> >> A couple of comments: >> >> src/hotspot/share/oops/klass.hpp >> >> ?412?? // Is an oop/narrowOop null or subtype of this Klass? >> ?413?? template >> ?414?? bool is_covariant(T element); >> >> I find "is_covariant" a very obscure way to name this. It may be >> academically accurate but it's really just asking if the element is of >> a type that is a subclass of the current klass. The null handling >> complicates it, but it seems to me that: >> >> template >> bool Klass::is_instanceof_or_null(T element); >> >> would be more consistent with how we normally refer to things in the >> VM (though the _or_null can be dropped from the name). > > Hmm, I see your point. I have renamed covariant/contravariant > accordingly to fit better into our current notions. > > The ARRAYCOPY_CONTRAVARIANT decorator has been renamed ARRAYCOPY_CHECKCAST. > The is_covariant check has been renamed is_instanceof_or_null as you > proposed. > The covariant_bound() method has been renamed to element_klass(). I completely missed contravariant in there :) These changes look good. Thanks. David ----- >> --- >> >> src/hotspot/share/oops/objArrayOop.cpp >> >> Klass* objArrayOopDesc::covariant_bound() >> >> There's that word again. :) If you really think you need to use >> covariance within these API's you really need to add some comments to >> the method declarations to explain them. Most of us probably have a >> minimal recollection of covariance and contravariance from discussing >> type-safety for method parameters and return types. :) > > Fixed as mentioned above. > >> >> --- >> >> src/hotspot/share/prims/unsafe.cpp >> >> The changes from jobjects to oops made me uneasy, but I'm assuming the >> places where MemoryAccess and GuardedMemoryAccess are used are >> affectively all leave routines with no chance of hitting anything that >> would respond to a safepoint request? > > Yes, that is correct. There are no thread transitions in those paths. > > Here is a new full webrev: > http://cr.openjdk.java.net/~eosterlund/8189871/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00_01/ > > Thanks, > /Erik > >> Thanks, >> David >> ----- >> >> On 10/11/2017 3:00 AM, Erik ?sterlund wrote: >>> Hi, >>> >>> In an effort to remove explicit calls to GC barriers (and other >>> orthogonal forms of barriers, like encoding/decoding oops for >>> compressed oops and fencing for memory ordering), I have built an API >>> that I call "Access". Its purpose is to perform accesses with >>> declarative semantics, to handle multiple orthogonal concerns that >>> affect how an access is performed, including memory ordering, >>> compressed oops, GC barriers for marking, reference strength, etc, >>> and as a result making GCs more modular, and as a result allow new >>> concurrently compacting GC schemes utilizing load barriers to live in >>> harmony in hotspot without everyone going crazy manually inserting >>> barriers if UseBlahGC is enabled. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8189871 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ >>> >>> So there are three views of this I suppose: >>> >>> 1) The frontend: how this is actually used in shared code >>> 2) The backends: how anyone writing a GC sticks their required >>> barriers in there >>> 3) The internals: how accesses find their way from the frontend to >>> the corresponding backend >>> >>> == Frontend == >>> >>> Let's start with the frontend. I hope I made this fairly simple! You >>> can find it in runtime/access.hpp >>> Each access annotates its declarative semantics with a set of >>> "decorators", which is the name of the attributes/properties >>> affecting how an access is performed. >>> There is an Access API that makes the declarative >>> semantics possible. >>> >>> For example, if I want to perform a load acquire of an oop in the >>> heap that has "weak" strength, I would do something like: >>> oop result = Access>> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >>> >>> The Access API would then send the access through some GC backend, >>> that overrides the whole access and tells it to perform a "raw" load >>> acquire, and then possibly keep it alive if necessary (G1 SATB >>> enqueue barriers). >>> >>> To make life easier, there are some helpers for the most common >>> access patterns that merely add some default decorator for the >>> involved type of access. For example, there is a RawAccess for >>> performing AS_RAW accesses (that bypasses runtime checks and GC >>> barriers), HeapAccess sets the IN_HEAP decorator and RootAccess sets >>> the IN_ROOT decorator for accessing root oops. So for the previous >>> call, I could simply do: >>> >>> oop result = HeapAccess>> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >>> >>> The access.hpp file introduces each decorator (belonging to some >>> category) with an explanation what it is for. It also introduces all >>> operations you can make with access (loads, stores, cmpxchg, xchg, >>> arraycopy and clone). >>> >>> This changeset mostly introduces the Access API but is not complete >>> in annotating the code more than where it gets very awkward if I don't. >>> >>> == Backend == >>> >>> For a GC maintainer, the BarrierSet::AccessBarrier is the top level >>> backend that provides basic accesses that may be overridden. By >>> default, it just performs raw accesses without any GC barriers, that >>> handle things like compressed oops and memory ordering only. The >>> ModRef barrier set introduces the notion of pre/post write barriers, >>> that can be overridden for each GC. The CardTableModRef barrier set >>> overrides the post write barrier to mark cards, and G1 overrides it >>> to mark cards slightly differently and do some SATB enqueueing. G1 >>> also overrides loads to see if we need to perform SATB enqueue on >>> weak references. >>> >>> The raw accesses go to the RawAccessBarrier (living in >>> accessBackend.hpp) that performs the actual accesses. It connects to >>> Atomic and OrderAccess for accesses that require that. >>> >>> == Internals == >>> >>> Internally, the accesses go through a number of stages in >>> access.inline.hpp as documented at the top. >>> >>> 1) set default decorators and get rid of CV qualifiers etc. Sanity >>> checking also happens here: we check that the decorators make sense >>> for the access being performed, and that the passed in types are not >>> bogus. >>> 2) reduce types so if we have a different type of the address and >>> value, then either it is not allowed or it implies we use compressed >>> oops and remember that we know something about whether compressed >>> oops are used or not, before erasing address type >>> 3) pre-runtime dispatch: figure out if all runtime checks can be >>> bypassed into a raw access >>> 4) runtime dispatch: send the access through a function pointer that >>> upon the first invocation resolves the intended GC AccessBarrier >>> accessor on the BarrierSet that handles this access, as well as >>> figures out whether we are using compressed oops or not while we are >>> at it, and then calls it through the post-runtime dispatch >>> 5) post-runtime dispatch: fix some erased types that were not known >>> at compile time such as whether the address is a narrowOop* or oop* >>> depending on whether compressed oops was selected at runtime or not, >>> and call the resolved BarrierSet::AccessBarrier accessor >>> (load/store/etc) with all the call-site build-time and run-time >>> resolved decorators and type information that describes the access. >>> >>> Testing: mach5 tier1-5 >>> >>> Thanks, >>> /Erik > From erik.osterlund at oracle.com Thu Nov 16 07:28:23 2017 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 16 Nov 2017 08:28:23 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: References: <5A048993.2000002@oracle.com> <9cee59e0-5aab-3d8b-9485-8edd5f27b941@oracle.com> <5A0C6E88.7010209@oracle.com> Message-ID: Hi David, Thank you for the review. /Erik > On 16 Nov 2017, at 02:51, David Holmes wrote: > >> On 16/11/2017 2:42 AM, Erik ?sterlund wrote: >> Hi David, >> Thank you for the review. >>> On 2017-11-15 08:47, David Holmes wrote: >>> Hi Erik, >>> >>> I really like the level of abstraction and encapsulation this provides. >> Glad to hear it! >>> Can't comment on the GC specific details or the template mechanics directly, of course. :) >>> >>> A couple of comments: >>> >>> src/hotspot/share/oops/klass.hpp >>> >>> 412 // Is an oop/narrowOop null or subtype of this Klass? >>> 413 template >>> 414 bool is_covariant(T element); >>> >>> I find "is_covariant" a very obscure way to name this. It may be academically accurate but it's really just asking if the element is of a type that is a subclass of the current klass. The null handling complicates it, but it seems to me that: >>> >>> template >>> bool Klass::is_instanceof_or_null(T element); >>> >>> would be more consistent with how we normally refer to things in the VM (though the _or_null can be dropped from the name). >> Hmm, I see your point. I have renamed covariant/contravariant accordingly to fit better into our current notions. >> The ARRAYCOPY_CONTRAVARIANT decorator has been renamed ARRAYCOPY_CHECKCAST. >> The is_covariant check has been renamed is_instanceof_or_null as you proposed. >> The covariant_bound() method has been renamed to element_klass(). > > I completely missed contravariant in there :) > > These changes look good. > > Thanks. > > David > ----- > >>> --- >>> >>> src/hotspot/share/oops/objArrayOop.cpp >>> >>> Klass* objArrayOopDesc::covariant_bound() >>> >>> There's that word again. :) If you really think you need to use covariance within these API's you really need to add some comments to the method declarations to explain them. Most of us probably have a minimal recollection of covariance and contravariance from discussing type-safety for method parameters and return types. :) >> Fixed as mentioned above. >>> >>> --- >>> >>> src/hotspot/share/prims/unsafe.cpp >>> >>> The changes from jobjects to oops made me uneasy, but I'm assuming the places where MemoryAccess and GuardedMemoryAccess are used are affectively all leave routines with no chance of hitting anything that would respond to a safepoint request? >> Yes, that is correct. There are no thread transitions in those paths. >> Here is a new full webrev: >> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.01/ >> Incremental: >> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00_01/ >> Thanks, >> /Erik >>> Thanks, >>> David >>> ----- >>> >>>> On 10/11/2017 3:00 AM, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> In an effort to remove explicit calls to GC barriers (and other orthogonal forms of barriers, like encoding/decoding oops for compressed oops and fencing for memory ordering), I have built an API that I call "Access". Its purpose is to perform accesses with declarative semantics, to handle multiple orthogonal concerns that affect how an access is performed, including memory ordering, compressed oops, GC barriers for marking, reference strength, etc, and as a result making GCs more modular, and as a result allow new concurrently compacting GC schemes utilizing load barriers to live in harmony in hotspot without everyone going crazy manually inserting barriers if UseBlahGC is enabled. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8189871 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ >>>> >>>> So there are three views of this I suppose: >>>> >>>> 1) The frontend: how this is actually used in shared code >>>> 2) The backends: how anyone writing a GC sticks their required barriers in there >>>> 3) The internals: how accesses find their way from the frontend to the corresponding backend >>>> >>>> == Frontend == >>>> >>>> Let's start with the frontend. I hope I made this fairly simple! You can find it in runtime/access.hpp >>>> Each access annotates its declarative semantics with a set of "decorators", which is the name of the attributes/properties affecting how an access is performed. >>>> There is an Access API that makes the declarative semantics possible. >>>> >>>> For example, if I want to perform a load acquire of an oop in the heap that has "weak" strength, I would do something like: >>>> oop result = Access::oop_load_at(obj, offset); >>>> >>>> The Access API would then send the access through some GC backend, that overrides the whole access and tells it to perform a "raw" load acquire, and then possibly keep it alive if necessary (G1 SATB enqueue barriers). >>>> >>>> To make life easier, there are some helpers for the most common access patterns that merely add some default decorator for the involved type of access. For example, there is a RawAccess for performing AS_RAW accesses (that bypasses runtime checks and GC barriers), HeapAccess sets the IN_HEAP decorator and RootAccess sets the IN_ROOT decorator for accessing root oops. So for the previous call, I could simply do: >>>> >>>> oop result = HeapAccess::oop_load_at(obj, offset); >>>> >>>> The access.hpp file introduces each decorator (belonging to some category) with an explanation what it is for. It also introduces all operations you can make with access (loads, stores, cmpxchg, xchg, arraycopy and clone). >>>> >>>> This changeset mostly introduces the Access API but is not complete in annotating the code more than where it gets very awkward if I don't. >>>> >>>> == Backend == >>>> >>>> For a GC maintainer, the BarrierSet::AccessBarrier is the top level backend that provides basic accesses that may be overridden. By default, it just performs raw accesses without any GC barriers, that handle things like compressed oops and memory ordering only. The ModRef barrier set introduces the notion of pre/post write barriers, that can be overridden for each GC. The CardTableModRef barrier set overrides the post write barrier to mark cards, and G1 overrides it to mark cards slightly differently and do some SATB enqueueing. G1 also overrides loads to see if we need to perform SATB enqueue on weak references. >>>> >>>> The raw accesses go to the RawAccessBarrier (living in accessBackend.hpp) that performs the actual accesses. It connects to Atomic and OrderAccess for accesses that require that. >>>> >>>> == Internals == >>>> >>>> Internally, the accesses go through a number of stages in access.inline.hpp as documented at the top. >>>> >>>> 1) set default decorators and get rid of CV qualifiers etc. Sanity checking also happens here: we check that the decorators make sense for the access being performed, and that the passed in types are not bogus. >>>> 2) reduce types so if we have a different type of the address and value, then either it is not allowed or it implies we use compressed oops and remember that we know something about whether compressed oops are used or not, before erasing address type >>>> 3) pre-runtime dispatch: figure out if all runtime checks can be bypassed into a raw access >>>> 4) runtime dispatch: send the access through a function pointer that upon the first invocation resolves the intended GC AccessBarrier accessor on the BarrierSet that handles this access, as well as figures out whether we are using compressed oops or not while we are at it, and then calls it through the post-runtime dispatch >>>> 5) post-runtime dispatch: fix some erased types that were not known at compile time such as whether the address is a narrowOop* or oop* depending on whether compressed oops was selected at runtime or not, and call the resolved BarrierSet::AccessBarrier accessor (load/store/etc) with all the call-site build-time and run-time resolved decorators and type information that describes the access. >>>> >>>> Testing: mach5 tier1-5 >>>> >>>> Thanks, >>>> /Erik From robbin.ehn at oracle.com Thu Nov 16 07:46:32 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 16 Nov 2017 08:46:32 +0100 Subject: RFR: 8191333: Zero variant broken after 8189941 In-Reply-To: <4a9a8dc4-9153-abf6-08cb-c5a4ca937fab@physik.fu-berlin.de> References: <45b48263-c82e-7c5f-5cf3-25c74cdfb0be@oracle.com> <75061560-ea00-d955-bb5a-84eaa8f3600e@oracle.com> <4a9a8dc4-9153-abf6-08cb-c5a4ca937fab@physik.fu-berlin.de> Message-ID: Hi On 2017-11-15 19:44, John Paul Adrian Glaubitz wrote: > On 11/15/2017 05:48 PM, coleen.phillimore at oracle.com wrote: >>> What about the handles? >> >> Honestly, after looking at it, I have no idea.? It seems like something you should remove and see if that works.? The comment says that there should be no >> active handles.? Maybe have a NoHandleMark unconditionally? then SafepointMechanism::block_if_requested(THREAD) so that the comment is actually an assertion. >> Sorry for too quick review. > > I just tested that. This builds fine. Whether it's the way to go, I'm > not sure. Maybe Robbin can make a statement regarding this. Depending on how much testing you have time for, if little time keep Handle, e.g something like: 101 #define SAFEPOINT \ 103 { \ 104 /* zap freed handles rather than GC'ing them */ \ 105 HandleMarkCleaner __hmc(THREAD); \ 106 } \ 107 CALL_VM(SafepointMechanism::block_if_requested(THREAD), handle_exception); If this is the only places that zero does safepoints poll, thread-local handshake should actually work with above. I can test it if/when I get time. > > The freshly JVM is run during the build if I remember correctly, so I > assume it works with this particular change. If you build the image, yes. /Robbin > > Adrian > From glaubitz at physik.fu-berlin.de Thu Nov 16 07:49:02 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 16 Nov 2017 08:49:02 +0100 Subject: RFR: 8191333: Zero variant broken after 8189941 In-Reply-To: References: <45b48263-c82e-7c5f-5cf3-25c74cdfb0be@oracle.com> <75061560-ea00-d955-bb5a-84eaa8f3600e@oracle.com> <4a9a8dc4-9153-abf6-08cb-c5a4ca937fab@physik.fu-berlin.de> Message-ID: <9c2662ed-19c7-28ba-45df-596ae4a95fa8@physik.fu-berlin.de> On 11/16/2017 08:46 AM, Robbin Ehn wrote: >>> Honestly, after looking at it, I have no idea.? It seems like something you should remove and see if that works.? The comment says that there should be no >>> active handles.? Maybe have a NoHandleMark unconditionally? then SafepointMechanism::block_if_requested(THREAD) so that the comment is actually an assertion. >>> Sorry for too quick review. >> >> I just tested that. This builds fine. Whether it's the way to go, I'm >> not sure. Maybe Robbin can make a statement regarding this. > > Depending on how much testing you have time for, if little time keep Handle, e.g something like: It's not so much a matter of time but rather that I unfortunately still haven't understood how to run the testsuite in OpenJDK. It's apparently not as simple as running "make check" but involves configuring external programs. > ?101 #define SAFEPOINT??????????????????????????????????????????????????????????????? \ > ?103?????? {????????????????????????????????????????????????????????????????????????? \ > ?104???????? /* zap freed handles rather than GC'ing them */????????????????????????? \ > ?105???????? HandleMarkCleaner __hmc(THREAD);???????????????????????????????????????? \ > ?106?????? }????????????????????????????????????????????????????????????????????????? \ > ?107?????? CALL_VM(SafepointMechanism::block_if_requested(THREAD), handle_exception); > Yep. That's what I did. Shall we just go with this approach? > If this is the only places that zero does safepoints poll, thread-local handshake should actually work with above. > I can test it if/when I get time. > >> >> The freshly JVM is run during the build if I remember correctly, so I >> assume it works with this particular change. > > If you build the image, yes. Yes, that's what I did. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.schatzl at oracle.com Thu Nov 16 08:28:28 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 16 Nov 2017 09:28:28 +0100 Subject: Request for review JDK-8187819 gc/TestFullGCALot.java fails on jdk10 started with "-XX:-UseCompressedOops" option In-Reply-To: <6abe26c6-b3e4-119d-dbfa-2b4689f21635@oracle.com> References: <1508324906.4435.15.camel@oracle.com> <6abe26c6-b3e4-119d-dbfa-2b4689f21635@oracle.com> Message-ID: <1510820908.5332.0.camel@oracle.com> Hi, On Wed, 2017-11-15 at 13:28 -0500, Alexander Harlap wrote: > Hi Thomas, > > I added 8187819 to @bug tag of the TestFullGCALot test. > > New revision of change is located at > > http://cr.openjdk.java.net/~aharlap/8187819/webrev.01/ > looks good. Thomas From stefan.johansson at oracle.com Thu Nov 16 08:40:36 2017 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 16 Nov 2017 09:40:36 +0100 Subject: Request for review JDK-8187819 gc/TestFullGCALot.java fails on jdk10 started with "-XX:-UseCompressedOops" option In-Reply-To: <1510820908.5332.0.camel@oracle.com> References: <1508324906.4435.15.camel@oracle.com> <6abe26c6-b3e4-119d-dbfa-2b4689f21635@oracle.com> <1510820908.5332.0.camel@oracle.com> Message-ID: <3a2b0d0b-724b-5375-a414-2fe955fae64a@oracle.com> Hi Alex, On 2017-11-16 09:28, Thomas Schatzl wrote: > Hi, > > On Wed, 2017-11-15 at 13:28 -0500, Alexander Harlap wrote: >> Hi Thomas, >> >> I added 8187819 to @bug tag of the TestFullGCALot test. >> >> New revision of change is located at >> >> http://cr.openjdk.java.net/~aharlap/8187819/webrev.01/ >> > looks good. Looks good, StefanJ > > Thomas From muthusamy.chinnathambi at oracle.com Thu Nov 16 09:08:31 2017 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Thu, 16 Nov 2017 01:08:31 -0800 (PST) Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist In-Reply-To: References: <811da80f-e107-4d0c-903b-c109b592176e@default> <6e7c7f30-599d-4558-8c84-0360f0535cf4@default> <9e7f3290-8dd3-4ca0-a445-fd50ff389642@default> Message-ID: <1c305b2e-ae87-4161-b094-c5407e9f389e@default> Hi Thomas, ? Thanks for the review. ? > But are there gtests already in jdk8u? I thought gtests came with jdk9? > http://openjdk.java.net/jeps/281 > If not, how does http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html run or even compile? Yes, you are right. "test_spaceManager.cpp" should not have been included here. Please find the updated webrev at http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.01/? . ? Regards, Muthusamy C From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Wednesday, November 15, 2017 6:30 PM To: Muthusamy Chinnathambi Cc: HotSpot Open Source Developers ; Mikael Gerdin ; Per Liden ; Stefan Karlsson ; Stephen Fitch Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist ? Hi Muthusamy, Looks okay. But are there gtests already in jdk8u? I thought gtests came with jdk9? http://openjdk.java.net/jeps/281 If not, how does http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html run or even compile? Thanks, Thomas ? On Wed, Nov 15, 2017 at 11:19 AM, Muthusamy Chinnathambi wrote: Hi, Could someone please review this backport. Regards, Muthusamy C -----Original Message----- From: Muthusamy Chinnathambi Sent: Friday, November 10, 2017 3:27 PM To: HotSpot Open Source Developers Cc: Mikael Gerdin Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist Hi, Can someone please review this. Thanks! Muthusamy C -----Original Message----- From: Muthusamy Chinnathambi Sent: Wednesday, November 8, 2017 11:24 AM To: Thomas St?fe Cc: Mikael Gerdin ; HotSpot Open Source Developers Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist Hi Thomas, ? > ?the webrev link seems to be dead. Sorry for the trouble. Please find the corrected link below http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ ? Somehow the line following the link got appended to the previous one leading to a dead link. ? Regards, Muthusamy C ? From: Thomas St?fe [mailto:HYPERLINK "mailto:thomas.stuefe at gmail.com"thomas.stuefe at gmail.com] Sent: Tuesday, November 7, 2017 8:12 PM To: Muthusamy Chinnathambi Cc: HotSpot Open Source Developers ; Mikael Gerdin Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist ? Hi Muthusamy, ? the webrev link seems to be dead. ? ..Thomas ? On Tue, Nov 7, 2017 at 10:05 AM, Muthusamy Chinnathambi wrote: Hi, Please review the backport of bug: "JDK-8170395: Metaspace initialization queries the wrong chunk freelist" to jdk8u-dev Please note that this is not a clean backport due to new entries in debug.cpp and copyright changes. Webrev: HYPERLINK "http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9"HYPERLINK "http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9"http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8170395 Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e971a72675a Test:? Had run jtreg and jprt hotspot testsets. Regards, Muthusamy C ? ? From sgehwolf at redhat.com Thu Nov 16 09:12:46 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 16 Nov 2017 10:12:46 +0100 Subject: RFR: 8191333: Zero variant broken after 8189941 In-Reply-To: <9c2662ed-19c7-28ba-45df-596ae4a95fa8@physik.fu-berlin.de> References: <45b48263-c82e-7c5f-5cf3-25c74cdfb0be@oracle.com> <75061560-ea00-d955-bb5a-84eaa8f3600e@oracle.com> <4a9a8dc4-9153-abf6-08cb-c5a4ca937fab@physik.fu-berlin.de> <9c2662ed-19c7-28ba-45df-596ae4a95fa8@physik.fu-berlin.de> Message-ID: <1510823566.3968.1.camel@redhat.com> On Thu, 2017-11-16 at 08:49 +0100, John Paul Adrian Glaubitz wrote: > On 11/16/2017 08:46 AM, Robbin Ehn wrote: > > > > Honestly, after looking at it, I have no idea.? It seems like > > > > something you should remove and see if that works.? The comment > > > > says that there should be no > > > > active handles.? Maybe have a NoHandleMark unconditionally? > > > > then SafepointMechanism::block_if_requested(THREAD) so that the > > > > comment is actually an assertion. > > > > Sorry for too quick review. > > > > > > I just tested that. This builds fine. Whether it's the way to go, I'm > > > not sure. Maybe Robbin can make a statement regarding this. > > > > Depending on how much testing you have time for, if little time > > keep Handle, e.g something like: > > It's not so much a matter of time but rather that I unfortunately still haven't understood > how to run the testsuite in OpenJDK. It's apparently not as simple as running "make check" > but involves configuring external programs. Add to that, that most basic tests usually expect a client/server JVM for which Zero is an odd ball. Also, due to it's weaker performance many tests time out and fail rather than conditionally setting longer timeout values. It's a rather large and cumbersome process to make the whole test suite Zero compatible. It's more of a case of going through every test one by one and figuring out whether a "failure" is a test issue, a Zero issue, or an environmental issue. Thanks, Severin From glaubitz at physik.fu-berlin.de Thu Nov 16 10:14:54 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 16 Nov 2017 11:14:54 +0100 Subject: RFR: 8191333: Zero variant broken after 8189941 In-Reply-To: <1510823566.3968.1.camel@redhat.com> References: <45b48263-c82e-7c5f-5cf3-25c74cdfb0be@oracle.com> <75061560-ea00-d955-bb5a-84eaa8f3600e@oracle.com> <4a9a8dc4-9153-abf6-08cb-c5a4ca937fab@physik.fu-berlin.de> <9c2662ed-19c7-28ba-45df-596ae4a95fa8@physik.fu-berlin.de> <1510823566.3968.1.camel@redhat.com> Message-ID: On 11/16/2017 10:12 AM, Severin Gehwolf wrote: > Add to that, that most basic tests usually expect a client/server JVM > for which Zero is an odd ball. Also, due to it's weaker performance > many tests time out and fail rather than conditionally setting longer > timeout values. It's a rather large and cumbersome process to make the > whole test suite Zero compatible. Thanks for the explanation! > It's more of a case of going through every test one by one and figuring > out whether a "failure" is a test issue, a Zero issue, or an > environmental issue. So, after all the helpful input from everyone, I have modified my change to kill the handles unconditionally as previously suggested [1]. I would like to have the change applied as in [1] if everyone agrees and if I run into future issues with Zero, I will report them here anyway. Thanks for all the input! Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8191333/webrev.01/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From kim.barrett at oracle.com Thu Nov 16 19:43:35 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 16 Nov 2017 14:43:35 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A0C718A.5080401@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> Message-ID: <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> > On Nov 15, 2017, at 11:55 AM, Erik ?sterlund wrote: >> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/src/hotspot/share/runtime/access.hpp.html >> >> 240 template >> 241 struct OopOrNarrowOopInternal: AllStatic { >> 242 typedef oop type; >> 243 }; >> 244 >> 245 template <> >> 246 struct OopOrNarrowOopInternal: AllStatic { >> 247 typedef narrowOop type; >> 248 }; >> 249 >> >> Kim and I agree that we should not have the default template definition for oop and have two specializations instead. Mostly I agree because this is confusing. >> >> 240 template >> 241 struct OopOrNarrowOopInternal; >> >> 240 template <> >> 241 struct OopOrNarrowOopInternal: AllStatic { >> 242 typedef oop type; >> 243 }; >> 244 >> 245 template <> >> 246 struct OopOrNarrowOopInternal: AllStatic { >> 247 typedef narrowOop type; >> 248 }; >> 249 >> > > This choice is actually deliberate. The reason is that we pass in things that is-an oop but is not exactly oop, like for example arrayOop or oopDesc* and the whole subclass tree if oop. An earlier incarnation of the Access API used a new IsDerived metafunction to determine whether a type is-an oop. > However, in order to keep the solution simpler and introduce less type dependencies, I instead use this OopOrNarrowOop thing to pass oop-like things through it and narrow it down to oop or narrowOop. If a narrowOop is passed in, then it becomes narrowOop, if you pass in oopDesc*, arrayOop, oop, instanceOop, or whatever, then it results in an oop, and tries to implicitly convert whatever was passed in to oop. That will act as if the overload was "oop" in the way that you can pass in anything that is implicitly convertible to exactly oop or narrowOop, and once you make it past that layer, it will be treated only as oop or narrowOop. > > Sorry for any resulting confusion. Thanks for the explanation. That wasn?t at all obvious. It might be useful to add a comment that the default case handles all variants of oop and treats them all as oop. >> We were also trying to figure out how the runtime would know whether to use IN_CONCURRENT_ROOT vs IN_ROOT decorator, since it probably varies for GCs. And requires runtime code to know whether the root is scanned concurrently or not, which we don't know. >> > > The Access API needs to know whether this is scanned concurrently or not (because we *have* to perform different barriers then). So whatever data structure the access is performed on, needs to make sure this is known. The person writing the access call cannot be expected to accurately know whether or not the associated location will be scanned concurrently. Even ignoring some of those people not being GC experts, there is the problem that the answer might not be knowable until runtime, because it may (will) depend on which GC is selected, and possibly other considerations as well. Does IN_CONCURRENT_ROOT really mean the location *might* be concurrently processed, and using that tag is a conservative choice that won't actually be wrong, but may be suboptimal? (E.g. it should really be called IS_POSSIBLY_CONCURRENT_ROOT?) Or are the choices between these really exclusive? I'm guessing the former, but I'm not certain of that, and the descriptions are no help. Nor do I know how bad such suboptimal behavior might be. (If they really are exclusive, then I don't see how to use these at all.) When we discussed this problem previously, we talked about having specific names associated with categories of off-heap references that might be handled differently by different collectors. Some specific examples that came up in that discussion were JNI global (and weak) handles, and interned strings. Even if we really expect all of our concurrent collectors to eventually process all of these concurrently, such features might be added on different schedules for different collectors. Without such a naming scheme, e.g. with only a generic IS_CONCURRENT_ROOT, different collectors may pay the cost for being conservative for different categories. That might be acceptable if being conservative is cheap. But then I would expect the possibly concurrent case to be pretty much the default, to be used nearly everywhere, since it is unreasonable to expect non-GC experts to stay up to date on which roots are never ever scanned concurrently by any collector. From coleen.phillimore at oracle.com Thu Nov 16 19:48:04 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 16 Nov 2017 14:48:04 -0500 Subject: RFR: 8191333: Zero variant broken after 8189941 In-Reply-To: References: <45b48263-c82e-7c5f-5cf3-25c74cdfb0be@oracle.com> <75061560-ea00-d955-bb5a-84eaa8f3600e@oracle.com> <4a9a8dc4-9153-abf6-08cb-c5a4ca937fab@physik.fu-berlin.de> <9c2662ed-19c7-28ba-45df-596ae4a95fa8@physik.fu-berlin.de> <1510823566.3968.1.camel@redhat.com> Message-ID: On 11/16/17 5:14 AM, John Paul Adrian Glaubitz wrote: > On 11/16/2017 10:12 AM, Severin Gehwolf wrote: >> Add to that, that most basic tests usually expect a client/server JVM >> for which Zero is an odd ball. Also, due to it's weaker performance >> many tests time out and fail rather than conditionally setting longer >> timeout values. It's a rather large and cumbersome process to make the >> whole test suite Zero compatible. > Thanks for the explanation! > >> It's more of a case of going through every test one by one and figuring >> out whether a "failure" is a test issue, a Zero issue, or an >> environmental issue. > So, after all the helpful input from everyone, I have modified my change > to kill the handles unconditionally as previously suggested [1]. > > I would like to have the change applied as in [1] if everyone agrees and > if I run into future issues with Zero, I will report them here anyway. Okay, this looks fine.? I just had a look at HandleMarkCleaner and this seems to be what the code expects to be able to do at this point. This makes me really want to remove the whole HandleMark mechanism and make Handles have destructors. Thanks, Coleen > > Thanks for all the input! > > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8191333/webrev.01/ From coleen.phillimore at oracle.com Thu Nov 16 23:48:40 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 16 Nov 2017 18:48:40 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> Message-ID: <92136b21-3d1f-8b18-2bc0-9f83e4ef096e@oracle.com> On 11/16/17 2:43 PM, Kim Barrett wrote: >> On Nov 15, 2017, at 11:55 AM, Erik ?sterlund wrote: >>> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/src/hotspot/share/runtime/access.hpp.html >>> >>> 240 template >>> 241 struct OopOrNarrowOopInternal: AllStatic { >>> 242 typedef oop type; >>> 243 }; >>> 244 >>> 245 template <> >>> 246 struct OopOrNarrowOopInternal: AllStatic { >>> 247 typedef narrowOop type; >>> 248 }; >>> 249 >>> >>> Kim and I agree that we should not have the default template definition for oop and have two specializations instead. Mostly I agree because this is confusing. >>> >>> 240 template >>> 241 struct OopOrNarrowOopInternal; >>> >>> 240 template <> >>> 241 struct OopOrNarrowOopInternal: AllStatic { >>> 242 typedef oop type; >>> 243 }; >>> 244 >>> 245 template <> >>> 246 struct OopOrNarrowOopInternal: AllStatic { >>> 247 typedef narrowOop type; >>> 248 }; >>> 249 >>> >> This choice is actually deliberate. The reason is that we pass in things that is-an oop but is not exactly oop, like for example arrayOop or oopDesc* and the whole subclass tree if oop. An earlier incarnation of the Access API used a new IsDerived metafunction to determine whether a type is-an oop. >> However, in order to keep the solution simpler and introduce less type dependencies, I instead use this OopOrNarrowOop thing to pass oop-like things through it and narrow it down to oop or narrowOop. If a narrowOop is passed in, then it becomes narrowOop, if you pass in oopDesc*, arrayOop, oop, instanceOop, or whatever, then it results in an oop, and tries to implicitly convert whatever was passed in to oop. That will act as if the overload was "oop" in the way that you can pass in anything that is implicitly convertible to exactly oop or narrowOop, and once you make it past that layer, it will be treated only as oop or narrowOop. >> >> Sorry for any resulting confusion. > Thanks for the explanation. That wasn?t at all obvious. It might be useful to add a comment that the default case handles all variants of oop and treats them all as oop. Please add this comment! > >>> We were also trying to figure out how the runtime would know whether to use IN_CONCURRENT_ROOT vs IN_ROOT decorator, since it probably varies for GCs. And requires runtime code to know whether the root is scanned concurrently or not, which we don't know. >>> >> The Access API needs to know whether this is scanned concurrently or not (because we *have* to perform different barriers then). So whatever data structure the access is performed on, needs to make sure this is known. > The person writing the access call cannot be expected to accurately > know whether or not the associated location will be scanned > concurrently. Even ignoring some of those people not being GC > experts, there is the problem that the answer might not be knowable > until runtime, because it may (will) depend on which GC is selected, > and possibly other considerations as well. So, yeah, this is pretty confusing.? The RootAccess() assumes that using it will have a barrier because it's *possibly* scanned concurrently by the GC.? The roots that are scanned at a safepoint, like the thread stacks, can't one assume that they do not need an access decoration?? I can't imagine that you are going to add the Access API to the interpreter code for the bytecodes that push objects to the stack for example. So I have this in OopHandle::resolve() which is eventually going to be scanned concurrently by some GCs but probably not others: oop OopHandle::resolve() const { ? return _obj == NULL ? NULL : RootAccess<>(_obj); } And a WeakHandle from the vm perspective, will have access like: oop WeakHandle::resolve() const { ? oop obj = RootAccess(_obj); ? // does this:? ensure_obj_alive(obj); ? return obj; } Nowhere do I know or care that these are accessed concurrently, or rather I assume it could be accessed concurrently so not taking any chances.? I don't think we want a different decorator. Thanks, Coleen > > Does IN_CONCURRENT_ROOT really mean the location *might* be > concurrently processed, and using that tag is a conservative choice > that won't actually be wrong, but may be suboptimal? (E.g. it should > really be called IS_POSSIBLY_CONCURRENT_ROOT?) Or are the choices > between these really exclusive? I'm guessing the former, but I'm not > certain of that, and the descriptions are no help. Nor do I know how > bad such suboptimal behavior might be. (If they really are exclusive, > then I don't see how to use these at all.) > > When we discussed this problem previously, we talked about having > specific names associated with categories of off-heap references that > might be handled differently by different collectors. Some specific > examples that came up in that discussion were JNI global (and weak) > handles, and interned strings. Even if we really expect all of our > concurrent collectors to eventually process all of these concurrently, > such features might be added on different schedules for different > collectors. > > Without such a naming scheme, e.g. with only a generic > IS_CONCURRENT_ROOT, different collectors may pay the cost for being > conservative for different categories. That might be acceptable if > being conservative is cheap. But then I would expect the possibly > concurrent case to be pretty much the default, to be used nearly > everywhere, since it is unreasonable to expect non-GC experts to stay > up to date on which roots are never ever scanned concurrently by any > collector. > > > From ekaterina.pavlova at oracle.com Thu Nov 16 23:49:12 2017 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Thu, 16 Nov 2017 15:49:12 -0800 Subject: RFR(XS) 8190975: Tests which run with "--limit-modules java.base" could fail when Graal is used as JIT Message-ID: <9f8786d3-5512-bf41-03c2-a5e9df9ab467@oracle.com> Hi all, The following change fixes tests which run with "--limit-modules java.base" and as result could fail in case they are run in Graal mode. The fix adds "jdk.internal.vm.compiler" module so Graal classes can be loaded during Graal initialization. JBS: https://bugs.openjdk.java.net/browse/JDK-8190975 webrev: http://cr.openjdk.java.net/~epavlova//8190975/webrev.00/index.html testing: Tested by running the tests in Graal as JIT compiler mode with -Xcomp flag. Thanks, -katya p.s. Igor Ignatyev volunteered to sponsor this change. From coleen.phillimore at oracle.com Thu Nov 16 23:59:25 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 16 Nov 2017 18:59:25 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: References: <5A048993.2000002@oracle.com> Message-ID: <350d3449-f425-773e-cf8c-b9874ec373e5@oracle.com> Hi Erik, I believe that the access API belongs in the "oops" directory, as that is where the code uses them primarily.? Other than the location of the access* files, I've read through much of the code and don't have anything specific to add that would improve this change.? It's a bit big, ie. the Access class is large but separating out the implementations into access.inline.hpp doesn't seem like that useful of an improvement.? The template heavy code starts to look like boilerplate after a while. The Access::verify_decorators() could be made out-of-line in access.inline.hpp file to make the class more readable but it's not a strong request. The IN_CONCURRENT_ROOT decorator looks like something that can't be used or is the default from the runtime perspective, but can be removed or sorted out later. I'd found a typo on first reading but now I don't know where it was. Nice work! Coleen On 11/14/17 7:37 PM, coleen.phillimore at oracle.com wrote: > > Hi,? Meta-comment: I think the access API should be in oops rather > than the runtime directory.?? This API is for accessing objects in the > heap from other objects in the heap or in runtime code.?? So that > seems like it belongs in the oops directory to me (even though > metadata is there for historical reasons).?? The memory directory > would be my second choice, and runtime third. > > I've been reading through much of the code with help and explanation > of what these templates do from Kim.? They are pretty tricky but I can > see why they are there and what they do.?? I'm going to suggest some > comments in places when I've gotten through more of this. > > Thanks, > Coleen > > On 11/9/17 12:00 PM, Erik ?sterlund wrote: >> Hi, >> >> In an effort to remove explicit calls to GC barriers (and other >> orthogonal forms of barriers, like encoding/decoding oops for >> compressed oops and fencing for memory ordering), I have built an API >> that I call "Access". Its purpose is to perform accesses with >> declarative semantics, to handle multiple orthogonal concerns that >> affect how an access is performed, including memory ordering, >> compressed oops, GC barriers for marking, reference strength, etc, >> and as a result making GCs more modular, and as a result allow new >> concurrently compacting GC schemes utilizing load barriers to live in >> harmony in hotspot without everyone going crazy manually inserting >> barriers if UseBlahGC is enabled. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8189871 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ >> >> So there are three views of this I suppose: >> >> 1) The frontend: how this is actually used in shared code >> 2) The backends: how anyone writing a GC sticks their required >> barriers in there >> 3) The internals: how accesses find their way from the frontend to >> the corresponding backend >> >> == Frontend == >> >> Let's start with the frontend. I hope I made this fairly simple! You >> can find it in runtime/access.hpp >> Each access annotates its declarative semantics with a set of >> "decorators", which is the name of the attributes/properties >> affecting how an access is performed. >> There is an Access API that makes the declarative >> semantics possible. >> >> For example, if I want to perform a load acquire of an oop in the >> heap that has "weak" strength, I would do something like: >> oop result = Access> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >> >> The Access API would then send the access through some GC backend, >> that overrides the whole access and tells it to perform a "raw" load >> acquire, and then possibly keep it alive if necessary (G1 SATB >> enqueue barriers). >> >> To make life easier, there are some helpers for the most common >> access patterns that merely add some default decorator for the >> involved type of access. For example, there is a RawAccess for >> performing AS_RAW accesses (that bypasses runtime checks and GC >> barriers), HeapAccess sets the IN_HEAP decorator and RootAccess sets >> the IN_ROOT decorator for accessing root oops. So for the previous >> call, I could simply do: >> >> oop result = HeapAccess> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >> >> The access.hpp file introduces each decorator (belonging to some >> category) with an explanation what it is for. It also introduces all >> operations you can make with access (loads, stores, cmpxchg, xchg, >> arraycopy and clone). >> >> This changeset mostly introduces the Access API but is not complete >> in annotating the code more than where it gets very awkward if I don't. >> >> == Backend == >> >> For a GC maintainer, the BarrierSet::AccessBarrier is the top level >> backend that provides basic accesses that may be overridden. By >> default, it just performs raw accesses without any GC barriers, that >> handle things like compressed oops and memory ordering only. The >> ModRef barrier set introduces the notion of pre/post write barriers, >> that can be overridden for each GC. The CardTableModRef barrier set >> overrides the post write barrier to mark cards, and G1 overrides it >> to mark cards slightly differently and do some SATB enqueueing. G1 >> also overrides loads to see if we need to perform SATB enqueue on >> weak references. >> >> The raw accesses go to the RawAccessBarrier (living in >> accessBackend.hpp) that performs the actual accesses. It connects to >> Atomic and OrderAccess for accesses that require that. >> >> == Internals == >> >> Internally, the accesses go through a number of stages in >> access.inline.hpp as documented at the top. >> >> 1) set default decorators and get rid of CV qualifiers etc. Sanity >> checking also happens here: we check that the decorators make sense >> for the access being performed, and that the passed in types are not >> bogus. >> 2) reduce types so if we have a different type of the address and >> value, then either it is not allowed or it implies we use compressed >> oops and remember that we know something about whether compressed >> oops are used or not, before erasing address type >> 3) pre-runtime dispatch: figure out if all runtime checks can be >> bypassed into a raw access >> 4) runtime dispatch: send the access through a function pointer that >> upon the first invocation resolves the intended GC AccessBarrier >> accessor on the BarrierSet that handles this access, as well as >> figures out whether we are using compressed oops or not while we are >> at it, and then calls it through the post-runtime dispatch >> 5) post-runtime dispatch: fix some erased types that were not known >> at compile time such as whether the address is a narrowOop* or oop* >> depending on whether compressed oops was selected at runtime or not, >> and call the resolved BarrierSet::AccessBarrier accessor >> (load/store/etc) with all the call-site build-time and run-time >> resolved decorators and type information that describes the access. >> >> Testing: mach5 tier1-5 >> >> Thanks, >> /Erik > From kim.barrett at oracle.com Fri Nov 17 01:28:20 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 16 Nov 2017 20:28:20 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <92136b21-3d1f-8b18-2bc0-9f83e4ef096e@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <92136b21-3d1f-8b18-2bc0-9f83e4ef096e@oracle.com> Message-ID: > On Nov 16, 2017, at 6:48 PM, coleen.phillimore at oracle.com wrote: >>>> We were also trying to figure out how the runtime would know whether to use IN_CONCURRENT_ROOT vs IN_ROOT decorator, since it probably varies for GCs. And requires runtime code to know whether the root is scanned concurrently or not, which we don't know. >>>> >>> The Access API needs to know whether this is scanned concurrently or not (because we *have* to perform different barriers then). So whatever data structure the access is performed on, needs to make sure this is known. >> The person writing the access call cannot be expected to accurately >> know whether or not the associated location will be scanned >> concurrently. Even ignoring some of those people not being GC >> experts, there is the problem that the answer might not be knowable >> until runtime, because it may (will) depend on which GC is selected, >> and possibly other considerations as well. > > So, yeah, this is pretty confusing. The RootAccess() assumes that using it will have a barrier because it's *possibly* scanned concurrently by the GC. The roots that are scanned at a safepoint, like the thread stacks, can't one assume that they do not need an access decoration? I can't imagine that you are going to add the Access API to the interpreter code for the bytecodes that push objects to the stack for example. RootAccess uses the IN_ROOT decorator, which seems to be the one to use for locations which are *always* scanned at a safepoint. > So I have this in OopHandle::resolve() which is eventually going to be scanned concurrently by some GCs but probably not others: > > oop OopHandle::resolve() const { > return _obj == NULL ? NULL : RootAccess<>(_obj); > } > > And a WeakHandle from the vm perspective, will have access like: > > oop WeakHandle::resolve() const { > oop obj = RootAccess(_obj); > // does this: ensure_obj_alive(obj); > return obj; > } > > Nowhere do I know or care that these are accessed concurrently, or rather I assume it could be accessed concurrently so not taking any chances. I don't think we want a different decorator. Assuming IN_CONCURRENT_ROOT is conservative, and works for both ?scanned at a safepoint? and ?scanned concurrently?, then I think those resolve functions should be using Access(_obj). From david.holmes at oracle.com Fri Nov 17 02:20:42 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Nov 2017 12:20:42 +1000 Subject: RFR(XS) 8190975: Tests which run with "--limit-modules java.base" could fail when Graal is used as JIT In-Reply-To: <9f8786d3-5512-bf41-03c2-a5e9df9ab467@oracle.com> References: <9f8786d3-5512-bf41-03c2-a5e9df9ab467@oracle.com> Message-ID: <167f6185-35cc-b671-bfab-ca038f086406@oracle.com> Hi Katya, This seems reasonable. Thanks, David On 17/11/2017 9:49 AM, Ekaterina Pavlova wrote: > Hi all, > > The following change fixes tests which run with "--limit-modules > java.base" and as result could fail > in case they are run in Graal mode. The fix adds > "jdk.internal.vm.compiler" module so Graal classes > can be loaded during Graal initialization. > > > ?? JBS:? https://bugs.openjdk.java.net/browse/JDK-8190975 > webrev:? http://cr.openjdk.java.net/~epavlova//8190975/webrev.00/index.html > > testing: Tested by running the tests in Graal as JIT compiler mode with > -Xcomp flag. > > Thanks, > -katya > > p.s. > ?Igor Ignatyev volunteered to sponsor this change. From Alan.Bateman at oracle.com Fri Nov 17 07:54:54 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Nov 2017 07:54:54 +0000 Subject: RFR(XS) 8190975: Tests which run with "--limit-modules java.base" could fail when Graal is used as JIT In-Reply-To: <9f8786d3-5512-bf41-03c2-a5e9df9ab467@oracle.com> References: <9f8786d3-5512-bf41-03c2-a5e9df9ab467@oracle.com> Message-ID: <3a9a5ddf-2d6d-12b2-ea57-c642f4f0ebde@oracle.com> On 16/11/2017 23:49, Ekaterina Pavlova wrote: > Hi all, > > The following change fixes tests which run with "--limit-modules > java.base" and as result could fail > in case they are run in Graal mode. The fix adds > "jdk.internal.vm.compiler" module so Graal classes > can be loaded during Graal initialization. > > > ?? JBS:? https://bugs.openjdk.java.net/browse/JDK-8190975 > webrev: > http://cr.openjdk.java.net/~epavlova//8190975/webrev.00/index.html This looks okay although you don't need to list java.base as all modules require java.base. -Alan From thomas.stuefe at gmail.com Fri Nov 17 08:51:29 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 17 Nov 2017 09:51:29 +0100 Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist In-Reply-To: <1c305b2e-ae87-4161-b094-c5407e9f389e@default> References: <811da80f-e107-4d0c-903b-c109b592176e@default> <6e7c7f30-599d-4558-8c84-0360f0535cf4@default> <9e7f3290-8dd3-4ca0-a445-fd50ff389642@default> <1c305b2e-ae87-4161-b094-c5407e9f389e@default> Message-ID: Hi Muthusamy, >From the look of it updated webrev looks fine, but I do not have the time to build and check on jdk8u. I also would prefer that the gtests you omitted should be part of the change (I think before there were gtests, these kind of tests were implemented as file-local static test functions and called I think via whitebox.cpp ? But I wait what others say. Someone from Oracle should confirm this patch. Note that Mikael left Oracle, I took him off the reply list because mail bounce. Kind Regards, Thomas On Thu, Nov 16, 2017 at 10:08 AM, Muthusamy Chinnathambi < muthusamy.chinnathambi at oracle.com> wrote: > Hi Thomas, > > > > Thanks for the review. > > > > > But are there gtests already in jdk8u? I thought gtests came with jdk9? > > > http://openjdk.java.net/jeps/281 > > > If not, how does http://cr.openjdk.java.net/~ > mchinnathamb/8170395/webrev.00/test/native/memory/test_ > spaceManager.cpp.html run or even compile? > > Yes, you are right. "test_spaceManager.cpp" should not have been included > here. > > Please find the updated webrev at http://cr.openjdk.java.net/~ > mchinnathamb/8170395/webrev.01/ . > > > > Regards, > > Muthusamy C > > *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com] > *Sent:* Wednesday, November 15, 2017 6:30 PM > *To:* Muthusamy Chinnathambi > *Cc:* HotSpot Open Source Developers ; > Mikael Gerdin ; Per Liden ; > Stefan Karlsson ; Stephen Fitch < > stephen.fitch at oracle.com> > *Subject:* Re: [8u] RFR for backport of JDK-8170395: Metaspace > initialization queries the wrong chunk freelist > > > > Hi Muthusamy, > > Looks okay. But are there gtests already in jdk8u? I thought gtests came > with jdk9? > > http://openjdk.java.net/jeps/281 > > If not, how does http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev. > 00/test/native/memory/test_spaceManager.cpp.html run or even compile? > > Thanks, Thomas > > > > On Wed, Nov 15, 2017 at 11:19 AM, Muthusamy Chinnathambi < > muthusamy.chinnathambi at oracle.com> wrote: > > Hi, > > Could someone please review this backport. > > Regards, > Muthusamy C > > -----Original Message----- > From: Muthusamy Chinnathambi > > Sent: Friday, November 10, 2017 3:27 PM > To: HotSpot Open Source Developers > Cc: Mikael Gerdin > Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace > initialization queries the wrong chunk freelist > > Hi, > > Can someone please review this. > > Thanks! > Muthusamy C > > -----Original Message----- > From: Muthusamy Chinnathambi > Sent: Wednesday, November 8, 2017 11:24 AM > To: Thomas St?fe > Cc: Mikael Gerdin ; HotSpot Open Source > Developers > Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace > initialization queries the wrong chunk freelist > > Hi Thomas, > > > > > the webrev link seems to be dead. > > Sorry for the trouble. > > Please find the corrected link below > > http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ > > > > Somehow the line following the link got appended to the previous one > leading to a dead link. > > > > Regards, > > Muthusamy C > > > > From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] > Sent: Tuesday, November 7, 2017 8:12 PM > To: Muthusamy Chinnathambi > Cc: HotSpot Open Source Developers ; Mikael > Gerdin > Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace > initialization queries the wrong chunk freelist > > > > Hi Muthusamy, > > > > the webrev link seems to be dead. > > > > ..Thomas > > > > On Tue, Nov 7, 2017 at 10:05 AM, Muthusamy Chinnathambi muthusamy.chinnathambi at oracle.com"muthusamy.chinnathambi at oracle.com> > wrote: > > Hi, > > Please review the backport of bug: "JDK-8170395: Metaspace initialization > queries the wrong chunk freelist" to jdk8u-dev > > Please note that this is not a clean backport due to new entries in > debug.cpp and copyright changes. > > > Webrev: HYPERLINK "http://cr.openjdk.java.net/~ > mchinnathamb/8170395/webrev.00/jdk9"http://cr.openjdk. > java.net/~mchinnathamb/8170395/webrev.00/ > jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8170395 > Original patch pushed to jdk9: http://hg.openjdk.java.net/ > jdk9/jdk9/hotspot/rev/2e971a72675a > > Test: Had run jtreg and jprt hotspot testsets. > > Regards, > Muthusamy C > > > > > From muthusamy.chinnathambi at oracle.com Fri Nov 17 08:59:07 2017 From: muthusamy.chinnathambi at oracle.com (Muthusamy Chinnathambi) Date: Fri, 17 Nov 2017 00:59:07 -0800 (PST) Subject: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist In-Reply-To: References: <811da80f-e107-4d0c-903b-c109b592176e@default> <6e7c7f30-599d-4558-8c84-0360f0535cf4@default> <9e7f3290-8dd3-4ca0-a445-fd50ff389642@default> <1c305b2e-ae87-4161-b094-c5407e9f389e@default> Message-ID: <94651bf0-3eaa-406a-89b3-361c8408ce19@default> Hi Thomas, ? Thanks for the review. ? > . I also would prefer that the gtests you omitted should be part of the change (I think before there were gtests, these kind of tests were implemented as file-local static test functions and called I think via whitebox.cpp ? But I wait what others say. Yes, the test is part of https://bugs.openjdk.java.net/browse/JDK-8169931 . I would be backporting this as well, just that I didn?t want to pollute the current BP. ? Regards, Muthusamy C ? From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] Sent: Friday, November 17, 2017 2:21 PM To: Muthusamy Chinnathambi Cc: HotSpot Open Source Developers ; Per Liden ; Stefan Karlsson ; Stephen Fitch Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist ? Hi Muthusamy, ? >From the look of it updated webrev looks fine, but I do not have the time to build and check on jdk8u. I also would prefer that the gtests you omitted should be part of the change (I think before there were gtests, these kind of tests were implemented as file-local static test functions and called I think via whitebox.cpp ? But I wait what others say. ? Someone from Oracle should confirm this patch. Note that Mikael left Oracle, I took him off the reply list because mail bounce. ? Kind Regards, Thomas ? ? ? On Thu, Nov 16, 2017 at 10:08 AM, Muthusamy Chinnathambi wrote: Hi Thomas, ? Thanks for the review. ? > But are there gtests already in jdk8u? I thought gtests came with jdk9? > http://openjdk.java.net/jeps/281 > If not, how does http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html run or even compile? Yes, you are right. "test_spaceManager.cpp" should not have been included here. Please find the updated webrev at http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.01/? . ? Regards, Muthusamy C From: Thomas St?fe [mailto:HYPERLINK "mailto:thomas.stuefe at gmail.com"thomas.stuefe at gmail.com] Sent: Wednesday, November 15, 2017 6:30 PM To: Muthusamy Chinnathambi Cc: HotSpot Open Source Developers ; Mikael Gerdin ; Per Liden ; Stefan Karlsson ; Stephen Fitch Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist ? Hi Muthusamy, Looks okay. But are there gtests already in jdk8u? I thought gtests came with jdk9? http://openjdk.java.net/jeps/281 If not, how does http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/test/native/memory/test_spaceManager.cpp.html run or even compile? Thanks, Thomas ? On Wed, Nov 15, 2017 at 11:19 AM, Muthusamy Chinnathambi wrote: Hi, Could someone please review this backport. Regards, Muthusamy C -----Original Message----- From: Muthusamy Chinnathambi Sent: Friday, November 10, 2017 3:27 PM To: HotSpot Open Source Developers Cc: Mikael Gerdin Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist Hi, Can someone please review this. Thanks! Muthusamy C -----Original Message----- From: Muthusamy Chinnathambi Sent: Wednesday, November 8, 2017 11:24 AM To: Thomas St?fe Cc: Mikael Gerdin ; HotSpot Open Source Developers Subject: RE: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist Hi Thomas, ? > ?the webrev link seems to be dead. Sorry for the trouble. Please find the corrected link below http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ ? Somehow the line following the link got appended to the previous one leading to a dead link. ? Regards, Muthusamy C ? From: Thomas St?fe [mailto:HYPERLINK "mailto:thomas.stuefe at gmail.com"thomas.stuefe at gmail.com] Sent: Tuesday, November 7, 2017 8:12 PM To: Muthusamy Chinnathambi Cc: HotSpot Open Source Developers ; Mikael Gerdin Subject: Re: [8u] RFR for backport of JDK-8170395: Metaspace initialization queries the wrong chunk freelist ? Hi Muthusamy, ? the webrev link seems to be dead. ? ..Thomas ? On Tue, Nov 7, 2017 at 10:05 AM, Muthusamy Chinnathambi wrote: Hi, Please review the backport of bug: "JDK-8170395: Metaspace initialization queries the wrong chunk freelist" to jdk8u-dev Please note that this is not a clean backport due to new entries in debug.cpp and copyright changes. Webrev: HYPERLINK "http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9"HYPERLINK "http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/jdk9"http://cr.openjdk.java.net/~mchinnathamb/8170395/webrev.00/ jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8170395 Original patch pushed to jdk9: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2e971a72675a Test:? Had run jtreg and jprt hotspot testsets. Regards, Muthusamy C ? ? ? From david.holmes at oracle.com Fri Nov 17 09:24:22 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Nov 2017 19:24:22 +1000 Subject: RFR(XS) 8190975: Tests which run with "--limit-modules java.base" could fail when Graal is used as JIT In-Reply-To: <3a9a5ddf-2d6d-12b2-ea57-c642f4f0ebde@oracle.com> References: <9f8786d3-5512-bf41-03c2-a5e9df9ab467@oracle.com> <3a9a5ddf-2d6d-12b2-ea57-c642f4f0ebde@oracle.com> Message-ID: On 17/11/2017 5:54 PM, Alan Bateman wrote: > On 16/11/2017 23:49, Ekaterina Pavlova wrote: >> Hi all, >> >> The following change fixes tests which run with "--limit-modules >> java.base" and as result could fail >> in case they are run in Graal mode. The fix adds >> "jdk.internal.vm.compiler" module so Graal classes >> can be loaded during Graal initialization. >> >> >> ?? JBS:? https://bugs.openjdk.java.net/browse/JDK-8190975 >> webrev: >> http://cr.openjdk.java.net/~epavlova//8190975/webrev.00/index.html > This looks okay although you don't need to list java.base as all modules > require java.base. Isn't the point to limit the observable modules to only java.base (and now the compiler module) ? David > -Alan From Alan.Bateman at oracle.com Fri Nov 17 09:28:31 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Nov 2017 09:28:31 +0000 Subject: RFR(XS) 8190975: Tests which run with "--limit-modules java.base" could fail when Graal is used as JIT In-Reply-To: References: <9f8786d3-5512-bf41-03c2-a5e9df9ab467@oracle.com> <3a9a5ddf-2d6d-12b2-ea57-c642f4f0ebde@oracle.com> Message-ID: On 17/11/2017 09:24, David Holmes wrote: > On 17/11/2017 5:54 PM, Alan Bateman wrote: >> On 16/11/2017 23:49, Ekaterina Pavlova wrote: >>> Hi all, >>> >>> The following change fixes tests which run with "--limit-modules >>> java.base" and as result could fail >>> in case they are run in Graal mode. The fix adds >>> "jdk.internal.vm.compiler" module so Graal classes >>> can be loaded during Graal initialization. >>> >>> >>> ?? JBS:? https://bugs.openjdk.java.net/browse/JDK-8190975 >>> webrev: >>> http://cr.openjdk.java.net/~epavlova//8190975/webrev.00/index.html >> This looks okay although you don't need to list java.base as all >> modules require java.base. > > Isn't the point to limit the observable modules to only java.base (and > now the compiler module) ? `--limit-modules` will limit the set of observable modules to the transitive closure of the modules that you specify to the option. If you run `java --limit-modules jdk.internal.vm.compiler --list-modules` then you'll see what I mean. -Alan From david.holmes at oracle.com Fri Nov 17 10:37:17 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Nov 2017 20:37:17 +1000 Subject: RFR(XS) 8190975: Tests which run with "--limit-modules java.base" could fail when Graal is used as JIT In-Reply-To: References: <9f8786d3-5512-bf41-03c2-a5e9df9ab467@oracle.com> <3a9a5ddf-2d6d-12b2-ea57-c642f4f0ebde@oracle.com> Message-ID: On 17/11/2017 7:28 PM, Alan Bateman wrote: > On 17/11/2017 09:24, David Holmes wrote: >> On 17/11/2017 5:54 PM, Alan Bateman wrote: >>> On 16/11/2017 23:49, Ekaterina Pavlova wrote: >>>> Hi all, >>>> >>>> The following change fixes tests which run with "--limit-modules >>>> java.base" and as result could fail >>>> in case they are run in Graal mode. The fix adds >>>> "jdk.internal.vm.compiler" module so Graal classes >>>> can be loaded during Graal initialization. >>>> >>>> >>>> ?? JBS:? https://bugs.openjdk.java.net/browse/JDK-8190975 >>>> webrev: >>>> http://cr.openjdk.java.net/~epavlova//8190975/webrev.00/index.html >>> This looks okay although you don't need to list java.base as all >>> modules require java.base. >> >> Isn't the point to limit the observable modules to only java.base (and >> now the compiler module) ? > `--limit-modules` will limit the set of observable modules to the > transitive closure of the modules that you specify to the option. If you > run `java --limit-modules jdk.internal.vm.compiler --list-modules` then > you'll see what I mean. Ah I see what you mean - java.base is redundant now. David > -Alan > From erik.osterlund at oracle.com Fri Nov 17 14:09:01 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 17 Nov 2017 15:09:01 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> Message-ID: <5A0EED7D.6070207@oracle.com> Hi Kim, Thank you for the review. On 2017-11-16 20:43, Kim Barrett wrote: >> On Nov 15, 2017, at 11:55 AM, Erik ?sterlund wrote: >>> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/src/hotspot/share/runtime/access.hpp.html >>> >>> 240 template >>> 241 struct OopOrNarrowOopInternal: AllStatic { >>> 242 typedef oop type; >>> 243 }; >>> 244 >>> 245 template <> >>> 246 struct OopOrNarrowOopInternal: AllStatic { >>> 247 typedef narrowOop type; >>> 248 }; >>> 249 >>> >>> Kim and I agree that we should not have the default template definition for oop and have two specializations instead. Mostly I agree because this is confusing. >>> >>> 240 template >>> 241 struct OopOrNarrowOopInternal; >>> >>> 240 template <> >>> 241 struct OopOrNarrowOopInternal: AllStatic { >>> 242 typedef oop type; >>> 243 }; >>> 244 >>> 245 template <> >>> 246 struct OopOrNarrowOopInternal: AllStatic { >>> 247 typedef narrowOop type; >>> 248 }; >>> 249 >>> >> This choice is actually deliberate. The reason is that we pass in things that is-an oop but is not exactly oop, like for example arrayOop or oopDesc* and the whole subclass tree if oop. An earlier incarnation of the Access API used a new IsDerived metafunction to determine whether a type is-an oop. >> However, in order to keep the solution simpler and introduce less type dependencies, I instead use this OopOrNarrowOop thing to pass oop-like things through it and narrow it down to oop or narrowOop. If a narrowOop is passed in, then it becomes narrowOop, if you pass in oopDesc*, arrayOop, oop, instanceOop, or whatever, then it results in an oop, and tries to implicitly convert whatever was passed in to oop. That will act as if the overload was "oop" in the way that you can pass in anything that is implicitly convertible to exactly oop or narrowOop, and once you make it past that layer, it will be treated only as oop or narrowOop. >> >> Sorry for any resulting confusion. > Thanks for the explanation. That wasn?t at all obvious. It might be useful to add a comment that the default case handles all variants of oop and treats them all as oop. I have added a comment for that. >>> We were also trying to figure out how the runtime would know whether to use IN_CONCURRENT_ROOT vs IN_ROOT decorator, since it probably varies for GCs. And requires runtime code to know whether the root is scanned concurrently or not, which we don't know. >>> >> The Access API needs to know whether this is scanned concurrently or not (because we *have* to perform different barriers then). So whatever data structure the access is performed on, needs to make sure this is known. > The person writing the access call cannot be expected to accurately > know whether or not the associated location will be scanned > concurrently. Even ignoring some of those people not being GC > experts, there is the problem that the answer might not be knowable > until runtime, because it may (will) depend on which GC is selected, > and possibly other considerations as well. I see your point. > Does IN_CONCURRENT_ROOT really mean the location *might* be > concurrently processed, and using that tag is a conservative choice > that won't actually be wrong, but may be suboptimal? (E.g. it should > really be called IS_POSSIBLY_CONCURRENT_ROOT?) Or are the choices > between these really exclusive? I'm guessing the former, but I'm not > certain of that, and the descriptions are no help. Nor do I know how > bad such suboptimal behavior might be. (If they really are exclusive, > then I don't see how to use these at all.) It is indeed the case that they *might* be concurrently processed concurrently. > When we discussed this problem previously, we talked about having > specific names associated with categories of off-heap references that > might be handled differently by different collectors. Some specific > examples that came up in that discussion were JNI global (and weak) > handles, and interned strings. Even if we really expect all of our > concurrent collectors to eventually process all of these concurrently, > such features might be added on different schedules for different > collectors. > > Without such a naming scheme, e.g. with only a generic > IS_CONCURRENT_ROOT, different collectors may pay the cost for being > conservative for different categories. That might be acceptable if > being conservative is cheap. But then I would expect the possibly > concurrent case to be pretty much the default, to be used nearly > everywhere, since it is unreasonable to expect non-GC experts to stay > up to date on which roots are never ever scanned concurrently by any > collector. Okay so I really want the ability to say my roots are definitely scanned in a pause, e.g. when storing oops in thread-local value type values that are considered semantically as part of the stack, and will definitely for all thinkable weird forseeable GC combinations be scanned in a pause. At the moment it is really a special case with potentially concurrently scanned roots rather than the norm. So if that is okay, I would like to defer a decision to make concurrent root the default type of root. At least now that we are annotating the access, if any GC developer is adding concurrent processing of roots, it is very easy to find which where potential trouble lies. Thanks, /Erik From erik.osterlund at oracle.com Fri Nov 17 14:39:11 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 17 Nov 2017 15:39:11 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <350d3449-f425-773e-cf8c-b9874ec373e5@oracle.com> References: <5A048993.2000002@oracle.com> <350d3449-f425-773e-cf8c-b9874ec373e5@oracle.com> Message-ID: <5A0EF48F.6030909@oracle.com> Hi Coleen, On 2017-11-17 00:59, coleen.phillimore at oracle.com wrote: > > Hi Erik, > > I believe that the access API belongs in the "oops" directory, as that > is where the code uses them primarily. Other than the location of the > access* files, I've read through much of the code and don't have > anything specific to add that would improve this change. It's a bit > big, ie. the Access class is large but separating out the > implementations into access.inline.hpp doesn't seem like that useful > of an improvement. The template heavy code starts to look like > boilerplate after a while. I moved the Access API to the oops directory as you wished. > The Access::verify_decorators() could be made out-of-line > in access.inline.hpp file to make the class more readable but it's not > a strong request. Fixed. > The IN_CONCURRENT_ROOT decorator looks like something that can't be > used or is the default from the runtime perspective, but can be > removed or sorted out later. I would like to defer the default discussion until later if that is okay. We definitely need the ability to have non-concurrent roots, they definitely are the norm and not the exception today, but eventually we might want to change that. But I don't know if we are quite there yet. > I'd found a typo on first reading but now I don't know where it was. If you find it again, I will happily remove it. > Nice work! Thanks! And thank you for the review. The latest full webrev can be found here: http://cr.openjdk.java.net/~eosterlund/8189871/webrev.02/ The latest incremental webrev can be found here: http://cr.openjdk.java.net/~eosterlund/8189871/webrev.01_02/ Thanks, /Erik > Coleen > > On 11/14/17 7:37 PM, coleen.phillimore at oracle.com wrote: >> >> Hi, Meta-comment: I think the access API should be in oops rather >> than the runtime directory. This API is for accessing objects in >> the heap from other objects in the heap or in runtime code. So that >> seems like it belongs in the oops directory to me (even though >> metadata is there for historical reasons). The memory directory >> would be my second choice, and runtime third. >> >> I've been reading through much of the code with help and explanation >> of what these templates do from Kim. They are pretty tricky but I >> can see why they are there and what they do. I'm going to suggest >> some comments in places when I've gotten through more of this. >> >> Thanks, >> Coleen >> >> On 11/9/17 12:00 PM, Erik ?sterlund wrote: >>> Hi, >>> >>> In an effort to remove explicit calls to GC barriers (and other >>> orthogonal forms of barriers, like encoding/decoding oops for >>> compressed oops and fencing for memory ordering), I have built an >>> API that I call "Access". Its purpose is to perform accesses with >>> declarative semantics, to handle multiple orthogonal concerns that >>> affect how an access is performed, including memory ordering, >>> compressed oops, GC barriers for marking, reference strength, etc, >>> and as a result making GCs more modular, and as a result allow new >>> concurrently compacting GC schemes utilizing load barriers to live >>> in harmony in hotspot without everyone going crazy manually >>> inserting barriers if UseBlahGC is enabled. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8189871 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ >>> >>> So there are three views of this I suppose: >>> >>> 1) The frontend: how this is actually used in shared code >>> 2) The backends: how anyone writing a GC sticks their required >>> barriers in there >>> 3) The internals: how accesses find their way from the frontend to >>> the corresponding backend >>> >>> == Frontend == >>> >>> Let's start with the frontend. I hope I made this fairly simple! You >>> can find it in runtime/access.hpp >>> Each access annotates its declarative semantics with a set of >>> "decorators", which is the name of the attributes/properties >>> affecting how an access is performed. >>> There is an Access API that makes the declarative >>> semantics possible. >>> >>> For example, if I want to perform a load acquire of an oop in the >>> heap that has "weak" strength, I would do something like: >>> oop result = Access>> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >>> >>> The Access API would then send the access through some GC backend, >>> that overrides the whole access and tells it to perform a "raw" load >>> acquire, and then possibly keep it alive if necessary (G1 SATB >>> enqueue barriers). >>> >>> To make life easier, there are some helpers for the most common >>> access patterns that merely add some default decorator for the >>> involved type of access. For example, there is a RawAccess for >>> performing AS_RAW accesses (that bypasses runtime checks and GC >>> barriers), HeapAccess sets the IN_HEAP decorator and RootAccess sets >>> the IN_ROOT decorator for accessing root oops. So for the previous >>> call, I could simply do: >>> >>> oop result = HeapAccess>> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >>> >>> The access.hpp file introduces each decorator (belonging to some >>> category) with an explanation what it is for. It also introduces all >>> operations you can make with access (loads, stores, cmpxchg, xchg, >>> arraycopy and clone). >>> >>> This changeset mostly introduces the Access API but is not complete >>> in annotating the code more than where it gets very awkward if I don't. >>> >>> == Backend == >>> >>> For a GC maintainer, the BarrierSet::AccessBarrier is the top level >>> backend that provides basic accesses that may be overridden. By >>> default, it just performs raw accesses without any GC barriers, that >>> handle things like compressed oops and memory ordering only. The >>> ModRef barrier set introduces the notion of pre/post write barriers, >>> that can be overridden for each GC. The CardTableModRef barrier set >>> overrides the post write barrier to mark cards, and G1 overrides it >>> to mark cards slightly differently and do some SATB enqueueing. G1 >>> also overrides loads to see if we need to perform SATB enqueue on >>> weak references. >>> >>> The raw accesses go to the RawAccessBarrier (living in >>> accessBackend.hpp) that performs the actual accesses. It connects to >>> Atomic and OrderAccess for accesses that require that. >>> >>> == Internals == >>> >>> Internally, the accesses go through a number of stages in >>> access.inline.hpp as documented at the top. >>> >>> 1) set default decorators and get rid of CV qualifiers etc. Sanity >>> checking also happens here: we check that the decorators make sense >>> for the access being performed, and that the passed in types are not >>> bogus. >>> 2) reduce types so if we have a different type of the address and >>> value, then either it is not allowed or it implies we use compressed >>> oops and remember that we know something about whether compressed >>> oops are used or not, before erasing address type >>> 3) pre-runtime dispatch: figure out if all runtime checks can be >>> bypassed into a raw access >>> 4) runtime dispatch: send the access through a function pointer that >>> upon the first invocation resolves the intended GC AccessBarrier >>> accessor on the BarrierSet that handles this access, as well as >>> figures out whether we are using compressed oops or not while we are >>> at it, and then calls it through the post-runtime dispatch >>> 5) post-runtime dispatch: fix some erased types that were not known >>> at compile time such as whether the address is a narrowOop* or oop* >>> depending on whether compressed oops was selected at runtime or not, >>> and call the resolved BarrierSet::AccessBarrier accessor >>> (load/store/etc) with all the call-site build-time and run-time >>> resolved decorators and type information that describes the access. >>> >>> Testing: mach5 tier1-5 >>> >>> Thanks, >>> /Erik >> > From coleen.phillimore at oracle.com Fri Nov 17 15:55:47 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Nov 2017 10:55:47 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <92136b21-3d1f-8b18-2bc0-9f83e4ef096e@oracle.com> Message-ID: <68259132-24dd-da5b-d9de-cc9e0408fb3d@oracle.com> On 11/16/17 8:28 PM, Kim Barrett wrote: >> On Nov 16, 2017, at 6:48 PM, coleen.phillimore at oracle.com wrote: >>>>> We were also trying to figure out how the runtime would know whether to use IN_CONCURRENT_ROOT vs IN_ROOT decorator, since it probably varies for GCs. And requires runtime code to know whether the root is scanned concurrently or not, which we don't know. >>>>> >>>> The Access API needs to know whether this is scanned concurrently or not (because we *have* to perform different barriers then). So whatever data structure the access is performed on, needs to make sure this is known. >>> The person writing the access call cannot be expected to accurately >>> know whether or not the associated location will be scanned >>> concurrently. Even ignoring some of those people not being GC >>> experts, there is the problem that the answer might not be knowable >>> until runtime, because it may (will) depend on which GC is selected, >>> and possibly other considerations as well. >> So, yeah, this is pretty confusing. The RootAccess() assumes that using it will have a barrier because it's *possibly* scanned concurrently by the GC. The roots that are scanned at a safepoint, like the thread stacks, can't one assume that they do not need an access decoration? I can't imagine that you are going to add the Access API to the interpreter code for the bytecodes that push objects to the stack for example. > RootAccess uses the IN_ROOT decorator, which seems to be the one to use for locations which are *always* scanned at a safepoint. > >> So I have this in OopHandle::resolve() which is eventually going to be scanned concurrently by some GCs but probably not others: >> >> oop OopHandle::resolve() const { >> return _obj == NULL ? NULL : RootAccess<>(_obj); >> } >> >> And a WeakHandle from the vm perspective, will have access like: >> >> oop WeakHandle::resolve() const { >> oop obj = RootAccess(_obj); >> // does this: ensure_obj_alive(obj); >> return obj; >> } >> >> Nowhere do I know or care that these are accessed concurrently, or rather I assume it could be accessed concurrently so not taking any chances. I don't think we want a different decorator. > Assuming IN_CONCURRENT_ROOT is conservative, and works for both ?scanned at a safepoint? and ?scanned concurrently?, then I think those resolve functions should be using Access(_obj). Hm, ok.?? I wish it could use the default, but I can see avoiding any sort of barriers for off heap objects that are scanned during root scanning. thanks, Coleen From coleen.phillimore at oracle.com Fri Nov 17 15:58:43 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Nov 2017 10:58:43 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A0EF48F.6030909@oracle.com> References: <5A048993.2000002@oracle.com> <350d3449-f425-773e-cf8c-b9874ec373e5@oracle.com> <5A0EF48F.6030909@oracle.com> Message-ID: <75b9a6e1-d6b0-2393-ae78-670e2a595b34@oracle.com> On 11/17/17 9:39 AM, Erik ?sterlund wrote: > Hi Coleen, > > On 2017-11-17 00:59, coleen.phillimore at oracle.com wrote: >> >> Hi Erik, >> >> I believe that the access API belongs in the "oops" directory, as >> that is where the code uses them primarily.? Other than the location >> of the access* files, I've read through much of the code and don't >> have anything specific to add that would improve this change.? It's a >> bit big, ie. the Access class is large but separating out the >> implementations into access.inline.hpp doesn't seem like that useful >> of an improvement.? The template heavy code starts to look like >> boilerplate after a while. > > I moved the Access API to the oops directory as you wished. Thanks! > >> The Access::verify_decorators() could be made out-of-line >> in access.inline.hpp file to make the class more readable but it's >> not a strong request. > > Fixed. Thanks, that helps a bit with readability. > >> The IN_CONCURRENT_ROOT decorator looks like something that can't be >> used or is the default from the runtime perspective, but can be >> removed or sorted out later. > > I would like to defer the default discussion until later if that is > okay. We definitely need the ability to have non-concurrent roots, > they definitely are the norm and not the exception today, but > eventually we might want to change that. But I don't know if we are > quite there yet. > I agree with you.? Let's see how these are used and adjust accordingly. >> I'd found a typo on first reading but now I don't know where it was. > > If you find it again, I will happily remove it. > >> Nice work! > > Thanks! And thank you for the review. > > The latest full webrev can be found here: > http://cr.openjdk.java.net/~eosterlund/8189871/webrev.02/ > > The latest incremental webrev can be found here: > http://cr.openjdk.java.net/~eosterlund/8189871/webrev.01_02/ Looks good!! Coleen > > Thanks, > /Erik > >> Coleen >> >> On 11/14/17 7:37 PM, coleen.phillimore at oracle.com wrote: >>> >>> Hi,? Meta-comment: I think the access API should be in oops rather >>> than the runtime directory.?? This API is for accessing objects in >>> the heap from other objects in the heap or in runtime code.?? So >>> that seems like it belongs in the oops directory to me (even though >>> metadata is there for historical reasons).?? The memory directory >>> would be my second choice, and runtime third. >>> >>> I've been reading through much of the code with help and explanation >>> of what these templates do from Kim.? They are pretty tricky but I >>> can see why they are there and what they do.?? I'm going to suggest >>> some comments in places when I've gotten through more of this. >>> >>> Thanks, >>> Coleen >>> >>> On 11/9/17 12:00 PM, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> In an effort to remove explicit calls to GC barriers (and other >>>> orthogonal forms of barriers, like encoding/decoding oops for >>>> compressed oops and fencing for memory ordering), I have built an >>>> API that I call "Access". Its purpose is to perform accesses with >>>> declarative semantics, to handle multiple orthogonal concerns that >>>> affect how an access is performed, including memory ordering, >>>> compressed oops, GC barriers for marking, reference strength, etc, >>>> and as a result making GCs more modular, and as a result allow new >>>> concurrently compacting GC schemes utilizing load barriers to live >>>> in harmony in hotspot without everyone going crazy manually >>>> inserting barriers if UseBlahGC is enabled. >>>> >>>> CR: >>>> https://bugs.openjdk.java.net/browse/JDK-8189871 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ >>>> >>>> So there are three views of this I suppose: >>>> >>>> 1) The frontend: how this is actually used in shared code >>>> 2) The backends: how anyone writing a GC sticks their required >>>> barriers in there >>>> 3) The internals: how accesses find their way from the frontend to >>>> the corresponding backend >>>> >>>> == Frontend == >>>> >>>> Let's start with the frontend. I hope I made this fairly simple! >>>> You can find it in runtime/access.hpp >>>> Each access annotates its declarative semantics with a set of >>>> "decorators", which is the name of the attributes/properties >>>> affecting how an access is performed. >>>> There is an Access API that makes the declarative >>>> semantics possible. >>>> >>>> For example, if I want to perform a load acquire of an oop in the >>>> heap that has "weak" strength, I would do something like: >>>> oop result = Access>>> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >>>> >>>> The Access API would then send the access through some GC backend, >>>> that overrides the whole access and tells it to perform a "raw" >>>> load acquire, and then possibly keep it alive if necessary (G1 SATB >>>> enqueue barriers). >>>> >>>> To make life easier, there are some helpers for the most common >>>> access patterns that merely add some default decorator for the >>>> involved type of access. For example, there is a RawAccess for >>>> performing AS_RAW accesses (that bypasses runtime checks and GC >>>> barriers), HeapAccess sets the IN_HEAP decorator and RootAccess >>>> sets the IN_ROOT decorator for accessing root oops. So for the >>>> previous call, I could simply do: >>>> >>>> oop result = HeapAccess>>> ON_WEAK_OOP_REF>::oop_load_at(obj, offset); >>>> >>>> The access.hpp file introduces each decorator (belonging to some >>>> category) with an explanation what it is for. It also introduces >>>> all operations you can make with access (loads, stores, cmpxchg, >>>> xchg, arraycopy and clone). >>>> >>>> This changeset mostly introduces the Access API but is not complete >>>> in annotating the code more than where it gets very awkward if I >>>> don't. >>>> >>>> == Backend == >>>> >>>> For a GC maintainer, the BarrierSet::AccessBarrier is the top level >>>> backend that provides basic accesses that may be overridden. By >>>> default, it just performs raw accesses without any GC barriers, >>>> that handle things like compressed oops and memory ordering only. >>>> The ModRef barrier set introduces the notion of pre/post write >>>> barriers, that can be overridden for each GC. The CardTableModRef >>>> barrier set overrides the post write barrier to mark cards, and G1 >>>> overrides it to mark cards slightly differently and do some SATB >>>> enqueueing. G1 also overrides loads to see if we need to perform >>>> SATB enqueue on weak references. >>>> >>>> The raw accesses go to the RawAccessBarrier (living in >>>> accessBackend.hpp) that performs the actual accesses. It connects >>>> to Atomic and OrderAccess for accesses that require that. >>>> >>>> == Internals == >>>> >>>> Internally, the accesses go through a number of stages in >>>> access.inline.hpp as documented at the top. >>>> >>>> 1) set default decorators and get rid of CV qualifiers etc. Sanity >>>> checking also happens here: we check that the decorators make sense >>>> for the access being performed, and that the passed in types are >>>> not bogus. >>>> 2) reduce types so if we have a different type of the address and >>>> value, then either it is not allowed or it implies we use >>>> compressed oops and remember that we know something about whether >>>> compressed oops are used or not, before erasing address type >>>> 3) pre-runtime dispatch: figure out if all runtime checks can be >>>> bypassed into a raw access >>>> 4) runtime dispatch: send the access through a function pointer >>>> that upon the first invocation resolves the intended GC >>>> AccessBarrier accessor on the BarrierSet that handles this access, >>>> as well as figures out whether we are using compressed oops or not >>>> while we are at it, and then calls it through the post-runtime >>>> dispatch >>>> 5) post-runtime dispatch: fix some erased types that were not known >>>> at compile time such as whether the address is a narrowOop* or oop* >>>> depending on whether compressed oops was selected at runtime or >>>> not, and call the resolved BarrierSet::AccessBarrier accessor >>>> (load/store/etc) with all the call-site build-time and run-time >>>> resolved decorators and type information that describes the access. >>>> >>>> Testing: mach5 tier1-5 >>>> >>>> Thanks, >>>> /Erik >>> >> > From coleen.phillimore at oracle.com Fri Nov 17 16:30:17 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Nov 2017 11:30:17 -0500 Subject: CFV: New hotspot Group Member: Per Liden Message-ID: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> I hereby nominate Per Liden (OpenJDK user name: pliden) to Membership in the hotspot Group. Per has been working on the Hotspot JVM for over 5 years at Oracle and has contributed 64 changes to the OpenJDK repository, including multiple G1 garbage collector fixes, string deduplication, and logging.?? Per is the initial author of ZGC and is the lead of the OpenJDK ZGC project sponsored by the hotspot group. Votes are due by Friday, December 1, 2017. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen [1]http://openjdk.java.net/census#hotspot [2]http://openjdk.java.net/groups/#member-vote From volker.simonis at gmail.com Fri Nov 17 16:40:02 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Nov 2017 17:40:02 +0100 Subject: CFV: New hotspot Group Member: Per Liden In-Reply-To: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> References: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> Message-ID: Vote: yes On Fri, Nov 17, 2017 at 5:30 PM, wrote: > I hereby nominate Per Liden (OpenJDK user name: pliden) to Membership in the > hotspot Group. > > Per has been working on the Hotspot JVM for over 5 years at Oracle and has > contributed 64 changes to the OpenJDK repository, including multiple G1 > garbage collector fixes, string deduplication, and logging. Per is the > initial author of ZGC and is the lead of the OpenJDK ZGC project sponsored > by the hotspot group. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From thomas.schatzl at oracle.com Fri Nov 17 16:42:30 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 17 Nov 2017 17:42:30 +0100 Subject: CFV: New hotspot Group Member: Per Liden In-Reply-To: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> References: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> Message-ID: <1510936950.2689.4.camel@oracle.com> Vote: yes On Fri, 2017-11-17 at 11:30 -0500, coleen.phillimore at oracle.com wrote: > I hereby nominate Per Liden (OpenJDK user name: pliden) to Membership > in? > the hotspot Group. > > Per has been working on the Hotspot JVM for over 5 years at Oracle > and? > has contributed 64 changes to the OpenJDK repository, including > multiple? > G1 garbage collector fixes, string deduplication, and logging.?? Per > is? > the initial author of ZGC and is the lead of the OpenJDK ZGC project? > sponsored by the hotspot group. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote > on? > this nomination. Votes must be cast in the open by replying to this? > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From daniel.daugherty at oracle.com Fri Nov 17 16:49:54 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 17 Nov 2017 11:49:54 -0500 Subject: CFV: New hotspot Group Member: Per Liden In-Reply-To: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> References: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> Message-ID: Vote: yes Dan On 11/17/17 11:30 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Per Liden (OpenJDK user name: pliden) to Membership > in the hotspot Group. > > Per has been working on the Hotspot JVM for over 5 years at Oracle and > has contributed 64 changes to the OpenJDK repository, including > multiple G1 garbage collector fixes, string deduplication, and > logging.?? Per is the initial author of ZGC and is the lead of the > OpenJDK ZGC project sponsored by the hotspot group. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote > From erik.osterlund at oracle.com Fri Nov 17 18:03:57 2017 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 17 Nov 2017 19:03:57 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <75b9a6e1-d6b0-2393-ae78-670e2a595b34@oracle.com> References: <5A048993.2000002@oracle.com> <350d3449-f425-773e-cf8c-b9874ec373e5@oracle.com> <5A0EF48F.6030909@oracle.com> <75b9a6e1-d6b0-2393-ae78-670e2a595b34@oracle.com> Message-ID: <989E758A-8B69-45B8-BB7B-A0849F7C453D@oracle.com> Hi Coleen, Thanks for the review. /Erik > On 17 Nov 2017, at 16:58, coleen.phillimore at oracle.com wrote: > > > >> On 11/17/17 9:39 AM, Erik ?sterlund wrote: >> Hi Coleen, >> >>> On 2017-11-17 00:59, coleen.phillimore at oracle.com wrote: >>> >>> Hi Erik, >>> >>> I believe that the access API belongs in the "oops" directory, as that is where the code uses them primarily. Other than the location of the access* files, I've read through much of the code and don't have anything specific to add that would improve this change. It's a bit big, ie. the Access class is large but separating out the implementations into access.inline.hpp doesn't seem like that useful of an improvement. The template heavy code starts to look like boilerplate after a while. >> >> I moved the Access API to the oops directory as you wished. > > Thanks! >> >>> The Access::verify_decorators() could be made out-of-line in access.inline.hpp file to make the class more readable but it's not a strong request. >> >> Fixed. > > Thanks, that helps a bit with readability. >> >>> The IN_CONCURRENT_ROOT decorator looks like something that can't be used or is the default from the runtime perspective, but can be removed or sorted out later. >> >> I would like to defer the default discussion until later if that is okay. We definitely need the ability to have non-concurrent roots, they definitely are the norm and not the exception today, but eventually we might want to change that. But I don't know if we are quite there yet. >> > > I agree with you. Let's see how these are used and adjust accordingly. > >>> I'd found a typo on first reading but now I don't know where it was. >> >> If you find it again, I will happily remove it. >> >>> Nice work! >> >> Thanks! And thank you for the review. >> >> The latest full webrev can be found here: >> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.02/ >> >> The latest incremental webrev can be found here: >> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.01_02/ > > Looks good!! > > Coleen > >> >> Thanks, >> /Erik >> >>> Coleen >>> >>>> On 11/14/17 7:37 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> Hi, Meta-comment: I think the access API should be in oops rather than the runtime directory. This API is for accessing objects in the heap from other objects in the heap or in runtime code. So that seems like it belongs in the oops directory to me (even though metadata is there for historical reasons). The memory directory would be my second choice, and runtime third. >>>> >>>> I've been reading through much of the code with help and explanation of what these templates do from Kim. They are pretty tricky but I can see why they are there and what they do. I'm going to suggest some comments in places when I've gotten through more of this. >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> On 11/9/17 12:00 PM, Erik ?sterlund wrote: >>>>> Hi, >>>>> >>>>> In an effort to remove explicit calls to GC barriers (and other orthogonal forms of barriers, like encoding/decoding oops for compressed oops and fencing for memory ordering), I have built an API that I call "Access". Its purpose is to perform accesses with declarative semantics, to handle multiple orthogonal concerns that affect how an access is performed, including memory ordering, compressed oops, GC barriers for marking, reference strength, etc, and as a result making GCs more modular, and as a result allow new concurrently compacting GC schemes utilizing load barriers to live in harmony in hotspot without everyone going crazy manually inserting barriers if UseBlahGC is enabled. >>>>> >>>>> CR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8189871 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~eosterlund/8189871/webrev.00/ >>>>> >>>>> So there are three views of this I suppose: >>>>> >>>>> 1) The frontend: how this is actually used in shared code >>>>> 2) The backends: how anyone writing a GC sticks their required barriers in there >>>>> 3) The internals: how accesses find their way from the frontend to the corresponding backend >>>>> >>>>> == Frontend == >>>>> >>>>> Let's start with the frontend. I hope I made this fairly simple! You can find it in runtime/access.hpp >>>>> Each access annotates its declarative semantics with a set of "decorators", which is the name of the attributes/properties affecting how an access is performed. >>>>> There is an Access API that makes the declarative semantics possible. >>>>> >>>>> For example, if I want to perform a load acquire of an oop in the heap that has "weak" strength, I would do something like: >>>>> oop result = Access::oop_load_at(obj, offset); >>>>> >>>>> The Access API would then send the access through some GC backend, that overrides the whole access and tells it to perform a "raw" load acquire, and then possibly keep it alive if necessary (G1 SATB enqueue barriers). >>>>> >>>>> To make life easier, there are some helpers for the most common access patterns that merely add some default decorator for the involved type of access. For example, there is a RawAccess for performing AS_RAW accesses (that bypasses runtime checks and GC barriers), HeapAccess sets the IN_HEAP decorator and RootAccess sets the IN_ROOT decorator for accessing root oops. So for the previous call, I could simply do: >>>>> >>>>> oop result = HeapAccess::oop_load_at(obj, offset); >>>>> >>>>> The access.hpp file introduces each decorator (belonging to some category) with an explanation what it is for. It also introduces all operations you can make with access (loads, stores, cmpxchg, xchg, arraycopy and clone). >>>>> >>>>> This changeset mostly introduces the Access API but is not complete in annotating the code more than where it gets very awkward if I don't. >>>>> >>>>> == Backend == >>>>> >>>>> For a GC maintainer, the BarrierSet::AccessBarrier is the top level backend that provides basic accesses that may be overridden. By default, it just performs raw accesses without any GC barriers, that handle things like compressed oops and memory ordering only. The ModRef barrier set introduces the notion of pre/post write barriers, that can be overridden for each GC. The CardTableModRef barrier set overrides the post write barrier to mark cards, and G1 overrides it to mark cards slightly differently and do some SATB enqueueing. G1 also overrides loads to see if we need to perform SATB enqueue on weak references. >>>>> >>>>> The raw accesses go to the RawAccessBarrier (living in accessBackend.hpp) that performs the actual accesses. It connects to Atomic and OrderAccess for accesses that require that. >>>>> >>>>> == Internals == >>>>> >>>>> Internally, the accesses go through a number of stages in access.inline.hpp as documented at the top. >>>>> >>>>> 1) set default decorators and get rid of CV qualifiers etc. Sanity checking also happens here: we check that the decorators make sense for the access being performed, and that the passed in types are not bogus. >>>>> 2) reduce types so if we have a different type of the address and value, then either it is not allowed or it implies we use compressed oops and remember that we know something about whether compressed oops are used or not, before erasing address type >>>>> 3) pre-runtime dispatch: figure out if all runtime checks can be bypassed into a raw access >>>>> 4) runtime dispatch: send the access through a function pointer that upon the first invocation resolves the intended GC AccessBarrier accessor on the BarrierSet that handles this access, as well as figures out whether we are using compressed oops or not while we are at it, and then calls it through the post-runtime dispatch >>>>> 5) post-runtime dispatch: fix some erased types that were not known at compile time such as whether the address is a narrowOop* or oop* depending on whether compressed oops was selected at runtime or not, and call the resolved BarrierSet::AccessBarrier accessor (load/store/etc) with all the call-site build-time and run-time resolved decorators and type information that describes the access. >>>>> >>>>> Testing: mach5 tier1-5 >>>>> >>>>> Thanks, >>>>> /Erik >>>> >>> >> > From jesper.wilhelmsson at oracle.com Fri Nov 17 18:48:38 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Fri, 17 Nov 2017 19:48:38 +0100 Subject: CFV: New hotspot Group Member: Per Liden In-Reply-To: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> References: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> Message-ID: <28F32935-B18B-43C9-B607-7E6E24562573@oracle.com> Vote: Yes /Jesper > On 17 Nov 2017, at 17:30, coleen.phillimore at oracle.com wrote: > > I hereby nominate Per Liden (OpenJDK user name: pliden) to Membership in the hotspot Group. > > Per has been working on the Hotspot JVM for over 5 years at Oracle and has contributed 64 changes to the OpenJDK repository, including multiple G1 garbage collector fixes, string deduplication, and logging. Per is the initial author of ZGC and is the lead of the OpenJDK ZGC project sponsored by the hotspot group. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Fri Nov 17 18:56:41 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Nov 2017 13:56:41 -0500 Subject: CFV: New hotspot Group Member: Per Liden In-Reply-To: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> References: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> Message-ID: <10caf505-0a08-e495-c6be-710e7b521a2e@oracle.com> Vote: yes On 11/17/17 11:30 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Per Liden (OpenJDK user name: pliden) to Membership > in the hotspot Group. > > Per has been working on the Hotspot JVM for over 5 years at Oracle and > has contributed 64 changes to the OpenJDK repository, including > multiple G1 garbage collector fixes, string deduplication, and > logging.?? Per is the initial author of ZGC and is the lead of the > OpenJDK ZGC project sponsored by the hotspot group. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Fri Nov 17 19:26:12 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Nov 2017 14:26:12 -0500 Subject: CFV: New hotspot Group Member: Kim Barrett Message-ID: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> I hereby nominate Kim Barrett (OpenJDK user name: kbarrett) to Membership in the hotspot Group. Kim has been working on the Hotspot JVM for 4 years.? He has contributed 110 changesets in the areas of the G1 garbage collector, reference processing and the atomic functions.? He is expert in C++ and has guided many improvements to the portability and correctness of the hotspot source code as well. Votes are due by Friday, December 1, 2017. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen [1]http://openjdk.java.net/census#hotspot [2]http://openjdk.java.net/groups/#member-vote From coleen.phillimore at oracle.com Fri Nov 17 19:28:45 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Nov 2017 14:28:45 -0500 Subject: CFV: New hotspot Group Member: Kim Barrett In-Reply-To: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> References: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> Message-ID: <908ebd03-0805-5b1c-f911-7ca9ae5ad38c@oracle.com> Vote: yes On 11/17/17 2:26 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Kim Barrett (OpenJDK user name: kbarrett) to > Membership in the hotspot Group. > > Kim has been working on the Hotspot JVM for 4 years.? He has > contributed 110 changesets in the areas of the G1 garbage collector, > reference processing and the atomic functions.? He is expert in C++ > and has guided many improvements to the portability and correctness of > the hotspot source code as well. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From karen.kinnear at oracle.com Fri Nov 17 19:29:28 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 17 Nov 2017 14:29:28 -0500 Subject: CFV: New hotspot Group Member: Kim Barrett In-Reply-To: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> References: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> Message-ID: <4DA9BC00-31E6-4FF9-BB97-FD66712C4B08@oracle.com> vote: yes thanks, Karen > On Nov 17, 2017, at 2:26 PM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Kim Barrett (OpenJDK user name: kbarrett) to Membership in the hotspot Group. > > Kim has been working on the Hotspot JVM for 4 years. He has contributed 110 changesets in the areas of the G1 garbage collector, reference processing and the atomic functions. He is expert in C++ and has guided many improvements to the portability and correctness of the hotspot source code as well. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From tobias.hartmann at oracle.com Fri Nov 17 19:30:00 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Nov 2017 14:30:00 -0500 Subject: CFV: New hotspot Group Member: Per Liden In-Reply-To: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> References: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> Message-ID: <53626d39-b59c-e845-7bd1-066d904578a6@oracle.com> Vote: yes On 17.11.2017 11:30, coleen.phillimore at oracle.com wrote: > I hereby nominate Per Liden (OpenJDK user name: pliden) to Membership in the hotspot Group. > > Per has been working on the Hotspot JVM for over 5 years at Oracle and has contributed 64 changes to the OpenJDK > repository, including multiple G1 garbage collector fixes, string deduplication, and logging.?? Per is the initial > author of ZGC and is the lead of the OpenJDK ZGC project sponsored by the hotspot group. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From tobias.hartmann at oracle.com Fri Nov 17 19:30:28 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Nov 2017 14:30:28 -0500 Subject: CFV: New hotspot Group Member: Kim Barrett In-Reply-To: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> References: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> Message-ID: Vote: yes On 17.11.2017 14:26, coleen.phillimore at oracle.com wrote: > I hereby nominate Kim Barrett (OpenJDK user name: kbarrett) to Membership in the hotspot Group. > > Kim has been working on the Hotspot JVM for 4 years.? He has contributed 110 changesets in the areas of the G1 garbage > collector, reference processing and the atomic functions.? He is expert in C++ and has guided many improvements to the > portability and correctness of the hotspot source code as well. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by > replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From daniel.daugherty at oracle.com Fri Nov 17 19:32:06 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 17 Nov 2017 14:32:06 -0500 Subject: CFV: New hotspot Group Member: Kim Barrett In-Reply-To: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> References: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> Message-ID: <68fcc25c-89ce-7d33-5774-f45aa13fb3d8@oracle.com> Vote: yes Dan On 11/17/17 2:26 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Kim Barrett (OpenJDK user name: kbarrett) to > Membership in the hotspot Group. > > Kim has been working on the Hotspot JVM for 4 years.? He has > contributed 110 changesets in the areas of the G1 garbage collector, > reference processing and the atomic functions.? He is expert in C++ > and has guided many improvements to the portability and correctness of > the hotspot source code as well. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote > From thomas.schatzl at oracle.com Fri Nov 17 19:38:24 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 17 Nov 2017 20:38:24 +0100 Subject: CFV: New hotspot Group Member: Kim Barrett In-Reply-To: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> References: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> Message-ID: <1510947504.2686.1.camel@oracle.com> Vote: yes On Fri, 2017-11-17 at 14:26 -0500, coleen.phillimore at oracle.com wrote: > I hereby nominate Kim Barrett (OpenJDK user name: kbarrett) to? > Membership in the hotspot Group. > > Kim has been working on the Hotspot JVM for 4 years.? He has > contributed? > 110 changesets in the areas of the G1 garbage collector, reference? > processing and the atomic functions.? He is expert in C++ and has > guided? > many improvements to the portability and correctness of the hotspot? > source code as well. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote > on? > this nomination. Votes must be cast in the open by replying to this? > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From mark.reinhold at oracle.com Fri Nov 17 21:27:29 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 17 Nov 2017 13:27:29 -0800 (PST) Subject: JEP 316: Heap Allocation on Alternative Memory Devices Message-ID: <20171117212729.2FD90FE33A@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/316 - Mark From glaubitz at physik.fu-berlin.de Sat Nov 18 00:36:31 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 18 Nov 2017 01:36:31 +0100 Subject: RFR: 8187227: __m68k_cmpxchg() is not being used correctly Message-ID: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> Hi! On m68k, linux-zero has platform-specific implementations for compare_and_swap(), add_and_fetch() and lock_test_and_set(). These functions are all using __m68k_cmpxchg() which is basically a wrapper around the m68k assembly instruction CAS. Currently, all three functions make incorrect assumptions about how CAS and its wrapper actually work and consequently use __m68k_cmpxchg() incorrectly. The source code comment for __m68_cmpxchg() states: * Atomically store newval in *ptr if *ptr is equal to oldval for user space. * Returns newval on success and oldval if no exchange happened. * This implementation is processor specific and works on * 68020 68030 68040 and 68060. However, looking at the documentation for the CAS instruction on m68k [1] and the implementation of __m68k_cmpxchg(), this is actually not how the function works. It does not return the update value on a successful exchange but rather the contents the compare operand, i.e. oldval. If no exchange happened, it will actually return the contents of the memory location. newval is never returned and consequently testing for "newval" in compare_and_swap(), add_and_fetch() and lock_test_and_set() is a bug. I have preapred a patch that fixes this issue by making correct use of __m68k_cmpxchg() in compare_and_swap(), add_and_fetch() and lock_test_and_set(). This patch has been tested to work on Debian m68k. Additional notes: In a previous of RFR of this bug - which I cannot find anymore - David Holmes was questioning whether the use of the loops within the atomic helper functions was correct. After thinking about the problem again, the answer is very simple: The CAS operation, while guaranteed to perform the swap atomically, is actually not guaranteed to succeed on first attempt trying to swap a memory operand with a direct operand. Hence, we have to keep trying to perform the compare-and-swap operation until it succeeds. That's what the loops are foor. Updated webrev can be found in [2]. Thanks, Adrian > [1] http://68k.hax.com/CAS > [2] http://cr.openjdk.java.net/~glaubitz/8187227/webrev.02/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Sat Nov 18 02:38:03 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 18 Nov 2017 12:38:03 +1000 Subject: RFR: 8187227: __m68k_cmpxchg() is not being used correctly In-Reply-To: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> Message-ID: Previous RFR: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-September/028266.html David On 18/11/2017 10:36 AM, John Paul Adrian Glaubitz wrote: > Hi! > > On m68k, linux-zero has platform-specific implementations for compare_and_swap(), > add_and_fetch() and lock_test_and_set(). These functions are all using __m68k_cmpxchg() > which is basically a wrapper around the m68k assembly instruction CAS. > > Currently, all three functions make incorrect assumptions about how CAS and its > wrapper actually work and consequently use __m68k_cmpxchg() incorrectly. The source > code comment for __m68_cmpxchg() states: > > * Atomically store newval in *ptr if *ptr is equal to oldval for user space. > * Returns newval on success and oldval if no exchange happened. > * This implementation is processor specific and works on > * 68020 68030 68040 and 68060. > > However, looking at the documentation for the CAS instruction on m68k [1] and the > implementation of __m68k_cmpxchg(), this is actually not how the function works. > It does not return the update value on a successful exchange but rather the contents > the compare operand, i.e. oldval. If no exchange happened, it will actually return > the contents of the memory location. newval is never returned and consequently > testing for "newval" in compare_and_swap(), add_and_fetch() and lock_test_and_set() > is a bug. > > I have preapred a patch that fixes this issue by making correct use of __m68k_cmpxchg() > in compare_and_swap(), add_and_fetch() and lock_test_and_set(). This patch has been > tested to work on Debian m68k. > > Additional notes: > > In a previous of RFR of this bug - which I cannot find anymore - David Holmes was > questioning whether the use of the loops within the atomic helper functions was > correct. After thinking about the problem again, the answer is very simple: The > CAS operation, while guaranteed to perform the swap atomically, is actually not > guaranteed to succeed on first attempt trying to swap a memory operand with a > direct operand. Hence, we have to keep trying to perform the compare-and-swap > operation until it succeeds. That's what the loops are foor. > > Updated webrev can be found in [2]. > > Thanks, > Adrian > >> [1] http://68k.hax.com/CAS >> [2] http://cr.openjdk.java.net/~glaubitz/8187227/webrev.02/ > From david.holmes at oracle.com Sat Nov 18 02:47:21 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 18 Nov 2017 12:47:21 +1000 Subject: RFR: 8187227: __m68k_cmpxchg() is not being used correctly In-Reply-To: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> Message-ID: <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> Hi Adrian, On 18/11/2017 10:36 AM, John Paul Adrian Glaubitz wrote: > Hi! > > On m68k, linux-zero has platform-specific implementations for compare_and_swap(), > add_and_fetch() and lock_test_and_set(). These functions are all using __m68k_cmpxchg() > which is basically a wrapper around the m68k assembly instruction CAS. Without seeing how that wrapper actually works, it is hard to know whether what you are saying and your fix is correct. The description of the CAS at [1] doesn't help without knowing how it actually gets used. David > Currently, all three functions make incorrect assumptions about how CAS and its > wrapper actually work and consequently use __m68k_cmpxchg() incorrectly. The source > code comment for __m68_cmpxchg() states: > > * Atomically store newval in *ptr if *ptr is equal to oldval for user space. > * Returns newval on success and oldval if no exchange happened. > * This implementation is processor specific and works on > * 68020 68030 68040 and 68060. > > However, looking at the documentation for the CAS instruction on m68k [1] and the > implementation of __m68k_cmpxchg(), this is actually not how the function works. > It does not return the update value on a successful exchange but rather the contents > the compare operand, i.e. oldval. If no exchange happened, it will actually return > the contents of the memory location. newval is never returned and consequently > testing for "newval" in compare_and_swap(), add_and_fetch() and lock_test_and_set() > is a bug. > > I have preapred a patch that fixes this issue by making correct use of __m68k_cmpxchg() > in compare_and_swap(), add_and_fetch() and lock_test_and_set(). This patch has been > tested to work on Debian m68k. > > Additional notes: > > In a previous of RFR of this bug - which I cannot find anymore - David Holmes was > questioning whether the use of the loops within the atomic helper functions was > correct. After thinking about the problem again, the answer is very simple: The > CAS operation, while guaranteed to perform the swap atomically, is actually not > guaranteed to succeed on first attempt trying to swap a memory operand with a > direct operand. Hence, we have to keep trying to perform the compare-and-swap > operation until it succeeds. That's what the loops are foor. > > Updated webrev can be found in [2]. > > Thanks, > Adrian > >> [1] http://68k.hax.com/CAS >> [2] http://cr.openjdk.java.net/~glaubitz/8187227/webrev.02/ > From aph at redhat.com Sat Nov 18 11:46:27 2017 From: aph at redhat.com (Andrew Haley) Date: Sat, 18 Nov 2017 11:46:27 +0000 Subject: RFR: 8187227: __m68k_cmpxchg() is not being used correctly In-Reply-To: <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> Message-ID: <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> Hi, On 18/11/17 02:47, David Holmes wrote: > On 18/11/2017 10:36 AM, John Paul Adrian Glaubitz wrote: >> Hi! >> >> On m68k, linux-zero has platform-specific implementations for compare_and_swap(), >> add_and_fetch() and lock_test_and_set(). These functions are all using __m68k_cmpxchg() >> which is basically a wrapper around the m68k assembly instruction CAS. > > Without seeing how that wrapper actually works, it is hard to know > whether what you are saying and your fix is correct. The description of > the CAS at [1] doesn't help without knowing how it actually gets used. I can't see the point of the loops. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Sat Nov 18 12:15:24 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 18 Nov 2017 13:15:24 +0100 Subject: RFR: 8187227: __m68k_cmpxchg() is not being used correctly In-Reply-To: <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> Message-ID: <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> On 11/18/2017 12:46 PM, Andrew Haley wrote: >> Without seeing how that wrapper actually works, it is hard to know >> whether what you are saying and your fix is correct. The description of >> the CAS at [1] doesn't help without knowing how it actually gets used. > > I can't see the point of the loops. The loops are necessary because it's not guaranteed that the CAS instruction will succeed at first attempt. You basically have to keep trying until it succeeds. At least to my current knowledge. The loops are already in the code, FWIW. I am just modifying the code because the current code makes incorrect assumptions on how __m68k_cmpxchg() actually works. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Sun Nov 19 12:25:02 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 19 Nov 2017 22:25:02 +1000 Subject: RFR: 8187227: __m68k_cmpxchg() is not being used correctly In-Reply-To: <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> Message-ID: <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> On 18/11/2017 10:15 PM, John Paul Adrian Glaubitz wrote: > On 11/18/2017 12:46 PM, Andrew Haley wrote: >>> Without seeing how that wrapper actually works, it is hard to know >>> whether what you are saying and your fix is correct. The description of >>> the CAS at [1] doesn't help without knowing how it actually gets used. >> >> I can't see the point of the loops. > > The loops are necessary because it's not guaranteed that the CAS instruction > will succeed at first attempt. You basically have to keep trying until it > succeeds. At least to my current knowledge. But a CAS can fail. Only if it can fail spuriously (ie for a reason other than *dest!=expected) should a loop be needed. > The loops are already in the code, FWIW. I am just modifying the code because > the current code makes incorrect assumptions on how __m68k_cmpxchg() actually > works. True the loops do exist. But I for one can't make much sense out this code at present, so impossible to validate your changes. If the code is as broken as you suggest why don't you see massive failures during testing? David > Adrian > From david.holmes at oracle.com Sun Nov 19 12:26:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 19 Nov 2017 22:26:53 +1000 Subject: CFV: New hotspot Group Member: Kim Barrett In-Reply-To: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> References: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> Message-ID: <9afa5ed9-31fe-9bbe-8d1d-d130735fcd53@oracle.com> Vote: yes. David On 18/11/2017 5:26 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Kim Barrett (OpenJDK user name: kbarrett) to > Membership in the hotspot Group. From david.holmes at oracle.com Sun Nov 19 12:27:28 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 19 Nov 2017 22:27:28 +1000 Subject: CFV: New hotspot Group Member: Per Liden In-Reply-To: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> References: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> Message-ID: <7bc42944-196e-88cf-5376-e0ad6144816f@oracle.com> Vote: yes David On 18/11/2017 2:30 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Per Liden (OpenJDK user name: pliden) to Membership in > the hotspot Group. From erik.helin at oracle.com Mon Nov 20 07:36:22 2017 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 20 Nov 2017 08:36:22 +0100 Subject: CFV: New hotspot Group Member: Kim Barrett In-Reply-To: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> References: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> Message-ID: Vote: yes Thanks, Erik On 11/17/2017 08:26 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Kim Barrett (OpenJDK user name: kbarrett) to > Membership in the hotspot Group. > > Kim has been working on the Hotspot JVM for 4 years.? He has contributed > 110 changesets in the areas of the G1 garbage collector, reference > processing and the atomic functions.? He is expert in C++ and has guided > many improvements to the portability and correctness of the hotspot > source code as well. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From erik.helin at oracle.com Mon Nov 20 07:36:43 2017 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 20 Nov 2017 08:36:43 +0100 Subject: CFV: New hotspot Group Member: Per Liden In-Reply-To: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> References: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> Message-ID: <27d3763a-bb6d-4bf8-1191-5c75f60a1da4@oracle.com> Vote: yes Thanks, Erik On 11/17/2017 05:30 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate Per Liden (OpenJDK user name: pliden) to Membership in > the hotspot Group. > > Per has been working on the Hotspot JVM for over 5 years at Oracle and > has contributed 64 changes to the OpenJDK repository, including multiple > G1 garbage collector fixes, string deduplication, and logging.?? Per is > the initial author of ZGC and is the lead of the OpenJDK ZGC project > sponsored by the hotspot group. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From volker.simonis at gmail.com Mon Nov 20 07:45:04 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Sun, 19 Nov 2017 23:45:04 -0800 Subject: CFV: New hotspot Group Member: Kim Barrett In-Reply-To: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> References: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> Message-ID: Vote: yes On Fri, Nov 17, 2017 at 11:26 AM, wrote: > I hereby nominate Kim Barrett (OpenJDK user name: kbarrett) to Membership in > the hotspot Group. > > Kim has been working on the Hotspot JVM for 4 years. He has contributed 110 > changesets in the areas of the G1 garbage collector, reference processing > and the atomic functions. He is expert in C++ and has guided many > improvements to the portability and correctness of the hotspot source code > as well. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From markus.gronlund at oracle.com Mon Nov 20 09:40:22 2017 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 20 Nov 2017 01:40:22 -0800 (PST) Subject: CFV: New hotspot Group Member: Kim Barrett In-Reply-To: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> References: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> Message-ID: Vote: yes Thanks Markus -----Original Message----- From: Coleen Phillimore Sent: den 17 november 2017 20:26 To: hotspot-dev developers Subject: CFV: New hotspot Group Member: Kim Barrett I hereby nominate Kim Barrett (OpenJDK user name: kbarrett) to Membership in the hotspot Group. Kim has been working on the Hotspot JVM for 4 years.? He has contributed 110 changesets in the areas of the G1 garbage collector, reference processing and the atomic functions.? He is expert in C++ and has guided many improvements to the portability and correctness of the hotspot source code as well. Votes are due by Friday, December 1, 2017. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen [1]http://openjdk.java.net/census#hotspot [2]http://openjdk.java.net/groups/#member-vote From markus.gronlund at oracle.com Mon Nov 20 09:41:03 2017 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 20 Nov 2017 01:41:03 -0800 (PST) Subject: CFV: New hotspot Group Member: Per Liden In-Reply-To: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> References: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> Message-ID: <2c08ecff-ef09-4544-b5d4-98d1c46a8b72@default> Vote: yes Thanks Markus -----Original Message----- From: Coleen Phillimore Sent: den 17 november 2017 17:30 To: hotspot-dev developers Subject: CFV: New hotspot Group Member: Per Liden I hereby nominate Per Liden (OpenJDK user name: pliden) to Membership in the hotspot Group. Per has been working on the Hotspot JVM for over 5 years at Oracle and has contributed 64 changes to the OpenJDK repository, including multiple G1 garbage collector fixes, string deduplication, and logging.?? Per is the initial author of ZGC and is the lead of the OpenJDK ZGC project sponsored by the hotspot group. Votes are due by Friday, December 1, 2017. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Coleen [1]http://openjdk.java.net/census#hotspot [2]http://openjdk.java.net/groups/#member-vote From aph at redhat.com Mon Nov 20 11:13:31 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 Nov 2017 11:13:31 +0000 Subject: RFR: 8187227: __m68k_cmpxchg() is not being used correctly In-Reply-To: <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> Message-ID: <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> On 19/11/17 12:25, David Holmes wrote: > On 18/11/2017 10:15 PM, John Paul Adrian Glaubitz wrote: >> On 11/18/2017 12:46 PM, Andrew Haley wrote: >>>> Without seeing how that wrapper actually works, it is hard to know >>>> whether what you are saying and your fix is correct. The description of >>>> the CAS at [1] doesn't help without knowing how it actually gets used. >>> >>> I can't see the point of the loops. >> >> The loops are necessary because it's not guaranteed that the CAS instruction >> will succeed at first attempt. You basically have to keep trying until it >> succeeds. At least to my current knowledge. > > But a CAS can fail. Only if it can fail spuriously (ie for a reason > other than *dest!=expected) should a loop be needed. > >> The loops are already in the code, FWIW. I am just modifying the code because >> the current code makes incorrect assumptions on how __m68k_cmpxchg() actually >> works. > > True the loops do exist. But I for one can't make much sense out this > code at present, so impossible to validate your changes. If the code is > as broken as you suggest why don't you see massive failures during testing? For avoidance of doubt, this is what GCC does: int m68k_sync_compare_and_swap(int newval, volatile int *ptr, int oldval) { return __sync_val_compare_and_swap (ptr, oldval, newval); } m68k_sync_compare_and_swap: move.l 4(%sp),%d1 move.l 8(%sp),%a0 move.l 12(%sp),%d0 cas.l %d0,%d1,(%a0) seq %d1 rts You could do many things worse than simply using __sync_val_compare_and_swap for Zero on 68k. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Nov 20 16:26:50 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 Nov 2017 16:26:50 +0000 Subject: JAOTC in JDK 10: kicking the tyres Message-ID: <3f6e3051-a485-3b55-8cac-d74f5970c3ee@redhat.com> $ ./build/linux-x86_64-normal-server-release/images/jdk/bin/jaotc ./build/linux-x86_64-normal-server-release/images/jdk/jmods/java.base.jmod Exception in thread "main" java.lang.NoClassDefFoundError: java/util/AbstractList (wrong name: classes/java/util/AbstractList) at java.base/java.lang.ClassLoader.defineClass1(Native Method) at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1008) at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoad ... This is with jdk/jdk, checked out about an hour ago. This should work, shouldn't it? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dean.long at oracle.com Mon Nov 20 18:34:50 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 20 Nov 2017 10:34:50 -0800 Subject: JAOTC in JDK 10: kicking the tyres In-Reply-To: <3f6e3051-a485-3b55-8cac-d74f5970c3ee@redhat.com> References: <3f6e3051-a485-3b55-8cac-d74f5970c3ee@redhat.com> Message-ID: <015bf12f-7ff3-498f-7688-27cfd4be7e8d@oracle.com> I think you want --module java.base here.? I guess jaotc doesn't support .jmod files. dl On 11/20/17 8:26 AM, Andrew Haley wrote: > $ ./build/linux-x86_64-normal-server-release/images/jdk/bin/jaotc ./build/linux-x86_64-normal-server-release/images/jdk/jmods/java.base.jmod > Exception in thread "main" java.lang.NoClassDefFoundError: java/util/AbstractList (wrong name: classes/java/util/AbstractList) > at java.base/java.lang.ClassLoader.defineClass1(Native Method) > at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1008) > at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoad ... > > This is with jdk/jdk, checked out about an hour ago. This should > work, shouldn't it? > From aph at redhat.com Mon Nov 20 18:43:23 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 Nov 2017 18:43:23 +0000 Subject: JAOTC in JDK 10: kicking the tyres In-Reply-To: <015bf12f-7ff3-498f-7688-27cfd4be7e8d@oracle.com> References: <3f6e3051-a485-3b55-8cac-d74f5970c3ee@redhat.com> <015bf12f-7ff3-498f-7688-27cfd4be7e8d@oracle.com> Message-ID: <40a0383b-c7d1-9848-1704-78ca5fd70e58@redhat.com> On 20/11/17 18:34, dean.long at oracle.com wrote: > I think you want --module java.base here.? I guess jaotc doesn't support > .jmod files. Aha! Yes, that seems to be much better, thanks. It still doesn't work, but oh well: Error: Failed compilation: sun.net.www.protocol.jrt.Handler.openConnection(Ljava/net/URL;)Ljava/net/URLConnection;: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.ExceptionInInitializerError at parsing java.base/sun.net.www.protocol.jrt.Handler.openConnection(Handler.java:42) If this isn't expected to fail I'll report it as a bug. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dean.long at oracle.com Mon Nov 20 19:06:10 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 20 Nov 2017 11:06:10 -0800 Subject: JAOTC in JDK 10: kicking the tyres In-Reply-To: <40a0383b-c7d1-9848-1704-78ca5fd70e58@redhat.com> References: <3f6e3051-a485-3b55-8cac-d74f5970c3ee@redhat.com> <015bf12f-7ff3-498f-7688-27cfd4be7e8d@oracle.com> <40a0383b-c7d1-9848-1704-78ca5fd70e58@redhat.com> Message-ID: <4d91af81-28e2-e5b7-3039-a62e7470a979@oracle.com> On 11/20/17 10:43 AM, Andrew Haley wrote: > On 20/11/17 18:34, dean.long at oracle.com wrote: >> I think you want --module java.base here.? I guess jaotc doesn't support >> .jmod files. > Aha! Yes, that seems to be much better, thanks. > > It still doesn't work, but oh well: > > Error: Failed compilation: sun.net.www.protocol.jrt.Handler.openConnection(Ljava/net/URL;)Ljava/net/URLConnection;: org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: java.lang.ExceptionInInitializerError > at parsing java.base/sun.net.www.protocol.jrt.Handler.openConnection(Handler.java:42) > > If this isn't expected to fail I'll report it as a bug. > There are problem methods listed in test/hotspot/jtreg/compiler/aot/scripts/java.base-list.txt and also on http://openjdk.java.net/jeps/295.? So please try with --compile-commands java.base-list.txt first and if it still fails then please file a bug. dl From kim.barrett at oracle.com Mon Nov 20 19:37:29 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 20 Nov 2017 14:37:29 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A0EED7D.6070207@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> Message-ID: <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> > On Nov 17, 2017, at 9:09 AM, Erik ?sterlund wrote: >> When we discussed this problem previously, we talked about having >> specific names associated with categories of off-heap references that >> might be handled differently by different collectors. Some specific >> examples that came up in that discussion were JNI global (and weak) >> handles, and interned strings. Even if we really expect all of our >> concurrent collectors to eventually process all of these concurrently, >> such features might be added on different schedules for different >> collectors. >> >> Without such a naming scheme, e.g. with only a generic >> IS_CONCURRENT_ROOT, different collectors may pay the cost for being >> conservative for different categories. That might be acceptable if >> being conservative is cheap. But then I would expect the possibly >> concurrent case to be pretty much the default, to be used nearly >> everywhere, since it is unreasonable to expect non-GC experts to stay >> up to date on which roots are never ever scanned concurrently by any >> collector. > > Okay so I really want the ability to say my roots are definitely scanned in a pause, e.g. when storing oops in thread-local value type values that are considered semantically as part of the stack, and will definitely for all thinkable weird forseeable GC combinations be scanned in a pause. > > At the moment it is really a special case with potentially concurrently scanned roots rather than the norm. So if that is okay, I would like to defer a decision to make concurrent root the default type of root. At least now that we are annotating the access, if any GC developer is adding concurrent processing of roots, it is very easy to find which where potential trouble lies. To me, that suggests there should be an IN_STACK_ROOT decorator. And I have reason to think the "will definitely for all thinkable weird forseeable GC combinations be scanned in a pause" set is empty. I guess I'm okay with deferring some of the design in this specific area for the moment. (I was going to say "defer until needed", but with Shenandoah and ZGC that might be essentially now, and even G1 could probably benefit pretty quickly.) I was going to suggest removing IN_CONCURRENT_ROOT, since I really doubt any sort of generic label like that is the right approach, and it's very nearly unused. But it appears there are no uses as actual access annotations yet, and the places where it is used appear to be parts of the implementation that would need to be adapted for any redesign, so maybe it's worth keeping as a placeholder. While looking at uses of IN_CONCURRENT_ROOT, I found a few more things to comment on. In Access::verify_heap_oop_decorators, I think (IN_ROOT ^ IN_CONCURRENT_ROOT) should be using | rather than ^. In Access::verify_(primitive|oop|heap_oop)_decorators, I don't understand the expected_mo_decorators template parameter. If it is the set of allowed memory order decorators, it is being effectively ignored by the inclusion of MO_DECORATOR_MASK in the function-specific decorators set. In Access::verify_decorators, all the category checks allow a zero value in the category being checked. I wouldn't expect a zero value to be permitted; for all categories there's an explicit default, which ought to be present. Is this verification done before defaulting? If so, then is there a later check that there's no bug in defaulting that would introduce an inconsistency? From paul.sandoz at oracle.com Mon Nov 20 19:56:42 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 20 Nov 2017 11:56:42 -0800 Subject: Moving dynamic constants to 11 Re: [10] RFR 8186046 Minimal ConstantDynamic support In-Reply-To: References: Message-ID: <15A29A84-1420-4E69-A715-A68B2DF436AA@oracle.com> Hi, The schedule of dynamic constants has been adjusted, the JEP is currently proposed to target for 11. There is risk to integrating a change such as constant dynamic this late in the 10 release schedule. Instead it's better, and more aligned with the new release process, to integrate early on into the main repository so it has time to bake. I don?t anticipate there will be significant changes to the existing reviews in progress (code, CSRs, VM specification), so we can keep the momentum, integrate, then iterate. Thanks, Paul. > On 26 Oct 2017, at 10:03, Paul Sandoz wrote: > > Hi, > > Please review the following patch for minimal dynamic constant support: > > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/ > > https://bugs.openjdk.java.net/browse/JDK-8186046 > https://bugs.openjdk.java.net/browse/JDK-8186209 > > This patch is based on the JDK 10 unified HotSpot repository. Testing so far looks good. > > By minimal i mean just the support in the runtime for a dynamic constant pool entry to be referenced by a LDC instruction or a bootstrap method argument. Much of the work leverages the foundations built by invoke dynamic but is arguably simpler since resolution is less complex. > > A small set of bootstrap methods will be proposed as a follow on issue for 10 (these are currently being refined in the amber repository). > > Bootstrap method invocation has not changed (and the rules are the same for dynamic constants and indy). It is planned to enhance this in a further major release to support lazy resolution of bootstrap method arguments. > > The CSR for the VM specification is here: > > https://bugs.openjdk.java.net/browse/JDK-8189199 > > the j.l.invoke package documentation was also updated but please consider the VM specification as the definitive "source of truth" (we may clean up this area further later on so it becomes more informative, and that may also apply to duplicative text on MethodHandles/VarHandles). > > Any AoT-related work will be deferred to a future release. > > ? > > This patch only supports x64 platforms. There is a small set of changes specific to x64 (specifically to support null and primitives constants, as prior to this patch null was used as a sentinel for resolution and certain primitives types would never have been encountered, such as say byte). > > We will need to follow up with the SPARC platform and it is hoped/anticipated that OpenJDK members responsible for other platforms (namely ARM and PPC) will separately provide patches. > > ? > > Many of tests rely on an experimental byte code API that supports the generation of byte code with dynamic constants. > > One test uses class file bytes produced from a modified version of asmtools. The modifications have now been pushed but a new version of asmtools need to be rolled into jtreg before the test can operate directly on asmtools information rather than embedding class file bytes directly in the test. > > ? > > Paul. From mark.reinhold at oracle.com Mon Nov 20 20:14:04 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 20 Nov 2017 12:14:04 -0800 Subject: Moving dynamic constants to 11 Re: [10] RFR 8186046 Minimal ConstantDynamic support In-Reply-To: <15A29A84-1420-4E69-A715-A68B2DF436AA@oracle.com> References: <15A29A84-1420-4E69-A715-A68B2DF436AA@oracle.com> Message-ID: <20171120121404.172170633@eggemoggin.niobe.net> 2017/11/20 11:56:42 -0800, paul.sandoz at oracle.com: > The schedule of dynamic constants has been adjusted, the JEP is > currently proposed to target for 11. > > There is risk to integrating a change such as constant dynamic this > late in the 10 release schedule. Instead it's better, and more aligned > with the new release process, to integrate early on into the main > repository so it has time to bake. Thanks for the update. It's too bad that JEP 309 won't make JDK 10, but this sounds like the right decision. - Mark From kim.barrett at oracle.com Tue Nov 21 07:07:03 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Nov 2017 02:07:03 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> Message-ID: <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> Noticed another issue while looking for something else. Before these changes, Unsafe_CompareAndExchangeObject does not specially handle Reference referents. Attempting to do so is new behavior introduced by Access. I don't think that change should be made. I think anyone who uses an Unsafe compare and swap to modify the referent of a reference deserves all the pain and suffering we can inflict upon them. With Unsafe, just because the current implementation doesn't outright prevent something doesn't make it a valid thing to do. There are many ways to (mis)use Unsafe that create havoc by breaking invariants and such. Consider the damange that could be done by using Unsafe to modify the discovered field of a reference, for example. I haven't looked for other similar "quiet changes". I'm also finding what look to me like some inconsistencies between the documentation for Unsafe and the implementation, but except for things like the above they are pre-existing. From kim.barrett at oracle.com Tue Nov 21 07:16:08 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Nov 2017 02:16:08 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> Message-ID: > On Nov 21, 2017, at 2:07 AM, Kim Barrett wrote: > > Noticed another issue while looking for something else. And another one. The modified unsafe.cpp doesn't use field_offset_(to|from)_byte_offset in places where Access is being used. Those functions and their use is intentional documentation and abstraction, despite their implementations presently being nops. Where Access is being used, the offset is now just quietly assumed to be in bytes, ignoring that abstraction. I think the use of those functions ought to be retained. From kim.barrett at oracle.com Tue Nov 21 07:18:12 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Nov 2017 02:18:12 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> Message-ID: > On Nov 21, 2017, at 2:16 AM, Kim Barrett wrote: > >> On Nov 21, 2017, at 2:07 AM, Kim Barrett wrote: >> >> Noticed another issue while looking for something else. > > And another one. Oh, and I?ve now noticed that this change has already been pushed. I guess these late comments should be turned into bug reports. From magnus.ihse.bursie at oracle.com Tue Nov 21 08:46:03 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Nov 2017 09:46:03 +0100 Subject: RFR: JDK-8190418 Stop generating jvmtiEnvStub and jvmtiEnvRecommended In-Reply-To: <475eb71c-d770-e0a3-a82e-943fadecb293@oracle.com> References: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> <475eb71c-d770-e0a3-a82e-943fadecb293@oracle.com> Message-ID: <56fea37f-eb99-9a82-e3fb-7df7b861a8ef@oracle.com> On 2017-11-14 22:55, David Holmes wrote: > Hi Magnus, > > On 14/11/2017 11:06 PM, Magnus Ihse Bursie wrote: >> During hotspot gensrc, we create two files, jvmtiEnvStub and >> jvmtiEnvRecommended, which later on are explicitly excluded from the >> build. We should just stop generating them. > > cc'd Dan: Need someone who knows to chime in with what these files are > and why they exist. The stub is like a dummy implementation that may > have been useful for testing against. No idea what the "recommended" > file may represent. ?? > >> I have built hotspot with and without this patch, and used the build >> comparison script (compare.sh) to verify that it has not changed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190418 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8190418-stop-generating-unneeded-jvmti-files/webrev.01 > > > Change itself seems fine. Not sure if jvmtiEnv.xsl is now a dead file > that can be removed (if so we'll file a hotspot bug for that). It seems likely that it is. There's no reference to it. I leave it to you do delete it then. /Magnus > > Thanks, > David > >> >> /Magnus >> From glaubitz at physik.fu-berlin.de Tue Nov 21 10:34:53 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 11:34:53 +0100 Subject: RFR: 8187227: __m68k_cmpxchg() is not being used correctly In-Reply-To: <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> Message-ID: Hi Andrew! On 11/20/2017 12:13 PM, Andrew Haley wrote: > For avoidance of doubt, this is what GCC does: > > > int m68k_sync_compare_and_swap(int newval, > volatile int *ptr, > int oldval) { > return __sync_val_compare_and_swap (ptr, oldval, newval); > } > > m68k_sync_compare_and_swap: > move.l 4(%sp),%d1 > move.l 8(%sp),%a0 > move.l 12(%sp),%d0 > cas.l %d0,%d1,(%a0) > seq %d1 > rts > > You could do many things worse than simply using __sync_val_compare_and_swap > for Zero on 68k. This sounds like a good idea. I'll look into using that. Might make the code also more readable. Although I would be a bit worried that this introduces too many layers of indirection, wouldn't it? Thanks for the valuable input! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Tue Nov 21 10:37:14 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Nov 2017 10:37:14 +0000 Subject: RFR: 8187227: __m68k_cmpxchg() is not being used correctly In-Reply-To: References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> Message-ID: <64330224-086a-8257-2303-f375a8aaf637@redhat.com> On 21/11/17 10:34, John Paul Adrian Glaubitz wrote: > Hi Andrew! > > On 11/20/2017 12:13 PM, Andrew Haley wrote: >> For avoidance of doubt, this is what GCC does: >> >> >> int m68k_sync_compare_and_swap(int newval, >> volatile int *ptr, >> int oldval) { >> return __sync_val_compare_and_swap (ptr, oldval, newval); >> } >> >> m68k_sync_compare_and_swap: >> move.l 4(%sp),%d1 >> move.l 8(%sp),%a0 >> move.l 12(%sp),%d0 >> cas.l %d0,%d1,(%a0) >> seq %d1 >> rts >> >> You could do many things worse than simply using __sync_val_compare_and_swap >> for Zero on 68k. > > This sounds like a good idea. I'll look into using that. Might make the > code also more readable. Although I would be a bit worried that this > introduces too many layers of indirection, wouldn't it? It's a a compiler builtin, so it should be (at least) as good as inline assembly. It's GCC-specific, but that shouldn't matter. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Tue Nov 21 10:41:53 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 11:41:53 +0100 Subject: RFR: 8187227: __m68k_cmpxchg() is not being used correctly In-Reply-To: <64330224-086a-8257-2303-f375a8aaf637@redhat.com> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> Message-ID: On 11/21/2017 11:37 AM, Andrew Haley wrote: >> This sounds like a good idea. I'll look into using that. Might make the >> code also more readable. Although I would be a bit worried that this >> introduces too many layers of indirection, wouldn't it? > > It's a a compiler builtin, so it should be (at least) as good as inline > assembly. It's GCC-specific, but that shouldn't matter. Ok, that's what I guessed but I wasn't sure about. Thanks for confirming it. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From magnus.ihse.bursie at oracle.com Tue Nov 21 11:42:30 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Nov 2017 12:42:30 +0100 Subject: RFR: JDK-8191202 Remove duplicated jmm.h Message-ID: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> As part of the effort to remove duplicated files between Hotspot and JDK, the turn has now come to jmm.h. Bug: https://bugs.openjdk.java.net/browse/JDK-8191202 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191202-remove-duplicated-jmm-h/webrev.01 /Magnus From david.holmes at oracle.com Tue Nov 21 11:49:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Nov 2017 21:49:20 +1000 Subject: RFR: JDK-8191202 Remove duplicated jmm.h In-Reply-To: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> References: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> Message-ID: <2cd090e5-2272-e3f8-3a9e-da487b3f1550@oracle.com> Hi Magnus, Seems to me that jmm is an interface exported by the VM, so the hotspot version of the header is the one that should survive IMO. David On 21/11/2017 9:42 PM, Magnus Ihse Bursie wrote: > As part of the effort to remove duplicated files between Hotspot and > JDK, the turn has now come to jmm.h. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191202 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191202-remove-duplicated-jmm-h/webrev.01 > > > /Magnus From glaubitz at physik.fu-berlin.de Tue Nov 21 12:02:59 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 13:02:59 +0100 Subject: RFR: 8187227: __m68k_cmpxchg() is not being used correctly In-Reply-To: References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> Message-ID: <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> On 11/21/2017 11:41 AM, John Paul Adrian Glaubitz wrote: > On 11/21/2017 11:37 AM, Andrew Haley wrote: >>> This sounds like a good idea. I'll look into using that. Might make the >>> code also more readable. Although I would be a bit worried that this >>> introduces too many layers of indirection, wouldn't it? >> >> It's a a compiler builtin, so it should be (at least) as good as inline >> assembly. It's GCC-specific, but that shouldn't matter. > > Ok, that's what I guessed but I wasn't sure about. Thanks for confirming > it. I have just talked to Andreas Schwab, a colleague of mine at SUSE, who has been working on the Linux m68k stuff for a long time. According to him, the compiler built-ins didn't exist back then for m68k which is why the platform-specific functions exist in OpenJDK. They do now, however. I'll just remove them for m68k and test if that works as expected. If yes, we should change this changeset to do that instead of fixing the platform-specific functions. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Nov 21 13:37:45 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 14:37:45 +0100 Subject: RFR: 8187227: Zero should use compiler built-ins for atomics on linux-m68k In-Reply-To: <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> Message-ID: <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> On 11/21/2017 01:02 PM, John Paul Adrian Glaubitz wrote: > I have just talked to Andreas Schwab, a colleague of mine at SUSE, who > has been working on the Linux m68k stuff for a long time. According to > him, the compiler built-ins didn't exist back then for m68k which is why > the platform-specific functions exist in OpenJDK. They do now, however. > > I'll just remove them for m68k and test if that works as expected. If > yes, we should change this changeset to do that instead of fixing the > platform-specific functions. I have updated the webrev now accordingly and pushed it to [1]. The build and run-test is currently pending (still building), but since libjvm.so already compiled successfully, I am 99% confident the change is correct as is. Thanks, Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8187227/webrev.03/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Nov 21 13:52:18 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 14:52:18 +0100 Subject: Zero broken again, probably due to JDK-8189871 Message-ID: Hi! While working on JDK-8187227 I noticed that Zero got broken again: === Output from failing command(s) repeated here === /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_abstractCompiler.o:\n" * For target hotspot_variant-zero_libjvm_objs_abstractCompiler.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_abstractCompiler.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/barrierSet.hpp:31:0, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/collectorPolicy.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/genCollectedHeap.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/gcLocker.hpp:29, from /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/interfaceSupport.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/prims/methodHandles.hpp:32, from /home/glaubitz/openjdk/hs/src/hotspot/share/ci/ciMethod.hpp:33, from /home/glaubitz/openjdk/hs/src/hotspot/share/code/debugInfoRec.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/ci/ciEnv.hpp:31, from /home/glaubitz/openjdk/hs/src/hotspot/share/ci/ciUtilities.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/ci/ciNullObject.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/ci/ciConstant.hpp:29, if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_abstractCompiler.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_abstractInterpreter.o:\n" * For target hotspot_variant-zero_libjvm_objs_abstractInterpreter.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_abstractInterpreter.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/barrierSet.hpp:31:0, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/collectorPolicy.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/genCollectedHeap.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/oops/oop.inline.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/memory/metaspaceShared.hpp:32, from /home/glaubitz/openjdk/hs/src/hotspot/share/interpreter/abstractInterpreter.cpp:36: /home/glaubitz/openjdk/hs/src/hotspot/share/oops/accessBackend.hpp:85:85: error: expected ?{? before ?>? token struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; ^ if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_abstractInterpreter.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_accessBackend.o:\n" * For target hotspot_variant-zero_libjvm_objs_accessBackend.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_accessBackend.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/oops/accessBackend.inline.hpp:29:0, from /home/glaubitz/openjdk/hs/src/hotspot/share/oops/accessBackend.cpp:26: /home/glaubitz/openjdk/hs/src/hotspot/share/oops/accessBackend.hpp:85:85: error: expected ?{? before ?>? token struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; ^ if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_accessBackend.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_accessBarrierSupport.o:\n" * For target hotspot_variant-zero_libjvm_objs_accessBarrierSupport.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_accessBarrierSupport.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/barrierSet.hpp:31:0, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/collectorPolicy.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/genCollectedHeap.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/oops/oop.inline.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/classfile/javaClasses.inline.hpp:29, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/accessBarrierSupport.cpp:26: /home/glaubitz/openjdk/hs/src/hotspot/share/oops/accessBackend.hpp:85:85: error: expected ?{? before ?>? token struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; ^ if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_accessBarrierSupport.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_accessFlags.o:\n" * For target hotspot_variant-zero_libjvm_objs_accessFlags.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_accessFlags.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/barrierSet.hpp:31:0, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/collectorPolicy.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/genCollectedHeap.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/oops/oop.inline.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/utilities/accessFlags.cpp:26: /home/glaubitz/openjdk/hs/src/hotspot/share/oops/accessBackend.hpp:85:85: error: expected ?{? before ?>? token struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; ^ if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_accessFlags.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_adaptiveSizePolicy.o:\n" * For target hotspot_variant-zero_libjvm_objs_adaptiveSizePolicy.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_adaptiveSizePolicy.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/barrierSet.hpp:31:0, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/collectorPolicy.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/adaptiveSizePolicy.cpp:27: /home/glaubitz/openjdk/hs/src/hotspot/share/oops/accessBackend.hpp:85:85: error: expected ?{? before ?>? token struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; ^ if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_adaptiveSizePolicy.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_adjoiningGenerations.o:\n" * For target hotspot_variant-zero_libjvm_objs_adjoiningGenerations.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_adjoiningGenerations.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/barrierSet.hpp:31:0, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/modRefBarrierSet.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/cardTableModRefBS.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/space.hpp:29, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/spaceDecorator.hpp:29, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/parallel/asPSYoungGen.hpp:34, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/parallel/adjoiningGenerations.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/parallel/adjoiningGenerations.cpp:26: /home/glaubitz/openjdk/hs/src/hotspot/share/oops/accessBackend.hpp:85:85: error: expected ?{? before ?>? token struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; ^ if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_adjoiningGenerations.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_advancedThresholdPolicy.o:\n" * For target hotspot_variant-zero_libjvm_objs_advancedThresholdPolicy.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_advancedThresholdPolicy.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/barrierSet.hpp:31:0, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/collectorPolicy.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/genCollectedHeap.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/gcLocker.hpp:29, from /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/interfaceSupport.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/prims/methodHandles.hpp:32, from /home/glaubitz/openjdk/hs/src/hotspot/share/ci/ciMethod.hpp:33, from /home/glaubitz/openjdk/hs/src/hotspot/share/code/debugInfoRec.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/ci/ciEnv.hpp:31, from /home/glaubitz/openjdk/hs/src/hotspot/share/ci/ciUtilities.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/ci/ciNullObject.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/ci/ciConstant.hpp:29, if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_advancedThresholdPolicy.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_ageTable.o:\n" * For target hotspot_variant-zero_libjvm_objs_ageTable.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_ageTable.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/barrierSet.hpp:31:0, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/collectorPolicy.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/genCollectedHeap.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/oops/oop.inline.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/ageTable.inline.hpp:29, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/ageTable.cpp:27: /home/glaubitz/openjdk/hs/src/hotspot/share/oops/accessBackend.hpp:85:85: error: expected ?{? before ?>? token struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; ^ if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_ageTable.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_allocation.o:\n" * For target hotspot_variant-zero_libjvm_objs_allocation.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_allocation.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/barrierSet.hpp:31:0, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/collectorPolicy.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/genCollectedHeap.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/memory/allocation.cpp:26: /home/glaubitz/openjdk/hs/src/hotspot/share/oops/accessBackend.hpp:85:85: error: expected ?{? before ?>? token struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; ^ if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_allocation.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_arena.o:\n" * For target hotspot_variant-zero_libjvm_objs_arena.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_arena.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/barrierSet.hpp:31:0, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/collectorPolicy.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/gc/shared/genCollectedHeap.hpp:30, from /home/glaubitz/openjdk/hs/src/hotspot/share/memory/arena.cpp:26: /home/glaubitz/openjdk/hs/src/hotspot/share/oops/accessBackend.hpp:85:85: error: expected ?{? before ?>? token struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; ^ if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_arena.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "\n* All command lines available in /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs.\n" * All command lines available in /home/glaubitz/openjdk/hs/build/linux-sparcv9-normal-zero-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === I assume this regression came with JDK-8189871, but I haven't looked yet. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From magnus.ihse.bursie at oracle.com Tue Nov 21 13:55:57 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Nov 2017 14:55:57 +0100 Subject: RFR: JDK-8191202 Remove duplicated jmm.h In-Reply-To: <2cd090e5-2272-e3f8-3a9e-da487b3f1550@oracle.com> References: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> <2cd090e5-2272-e3f8-3a9e-da487b3f1550@oracle.com> Message-ID: <25e3f830-394d-a549-6889-abf36021e93b@oracle.com> On 2017-11-21 12:49, David Holmes wrote: > Hi Magnus, > > Seems to me that jmm is an interface exported by the VM, so the > hotspot version of the header is the one that should survive IMO. We had a similar discussion about the other header files, were we kept the JDK version, for the time being. A bug, JDK-8190484 was opened to discuss the final location of the one remaining copy. This has in fact already prepared for the removal of the duplicated jmm.h, since it's titled "Revisit the source location of jvm.h and jmm.h". I'd prefer to treat this one similar to the other duplicated header files, and keep the JDK version for the time being. And then leaving it to whoever solves JDK-8190484 to figure out a proper location. Are you okay with that? /Magnus > David > > On 21/11/2017 9:42 PM, Magnus Ihse Bursie wrote: >> As part of the effort to remove duplicated files between Hotspot and >> JDK, the turn has now come to jmm.h. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191202 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8191202-remove-duplicated-jmm-h/webrev.01 >> >> >> /Magnus From glaubitz at physik.fu-berlin.de Tue Nov 21 13:56:38 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 14:56:38 +0100 Subject: Zero broken again, probably due to JDK-8189871 In-Reply-To: References: Message-ID: <209442a1-b8e7-b9e4-4ae4-6378f61df245@physik.fu-berlin.de> On 11/21/2017 02:52 PM, John Paul Adrian Glaubitz wrote: > I assume this regression came with JDK-8189871, but I haven't looked yet. Line 85, in accessBackend.hpp doesn't look right: #ifdef SUPPORTS_NATIVE_CX8 struct PossiblyLockedAccess: public IntegralConstant {}; #else struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; // line 85 #endif emacs' syntax highlighting is also confused. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Nov 21 14:01:07 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 15:01:07 +0100 Subject: Zero broken again, probably due to JDK-8189871 In-Reply-To: <209442a1-b8e7-b9e4-4ae4-6378f61df245@physik.fu-berlin.de> References: <209442a1-b8e7-b9e4-4ae4-6378f61df245@physik.fu-berlin.de> Message-ID: <58f32ed0-c474-2fc9-27f0-a2075dd8e334@physik.fu-berlin.de> On 11/21/2017 02:56 PM, John Paul Adrian Glaubitz wrote: > #ifdef SUPPORTS_NATIVE_CX8 > struct PossiblyLockedAccess: public IntegralConstant {}; > #else > struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; // line 85 > #endif This fixes it: glaubitz at z6:..upstream/hs> hg diff diff -r 1f77dcf5577e src/hotspot/share/oops/accessBackend.hpp --- a/src/hotspot/share/oops/accessBackend.hpp Tue Nov 21 13:48:28 2017 +0100 +++ b/src/hotspot/share/oops/accessBackend.hpp Tue Nov 21 15:00:24 2017 +0100 @@ -82,7 +82,7 @@ #ifdef SUPPORTS_NATIVE_CX8 struct PossiblyLockedAccess: public IntegralConstant {}; #else - struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; + struct PossiblyLockedAccess: public IntegralConstant 4)> {}; #endif template glaubitz at z6:..upstream/hs> But then I still have: === Output from failing command(s) repeated here === /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_os_linux_zero.o:\n" * For target hotspot_variant-zero_libjvm_objs_os_linux_zero.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_os_linux_zero.o.log || true) | /usr/bin/head -n 12 /home/glaubitz/upstream/hs/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp: In function ?void current_stack_region(u_char**, size_t*)?: /home/glaubitz/upstream/hs/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:375:18: error: ?is_initial_thread? is not a member of ?os::Linux? if (os::Linux::is_initial_thread()) { ^~~~~~~~~~~~~~~~~ if test `/usr/bin/wc -l < /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_os_linux_zero.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "\n* All command lines available in /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs.\n" * All command lines available in /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Nov 21 14:04:02 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 15:04:02 +0100 Subject: Zero broken again, probably due to JDK-8189871 In-Reply-To: <58f32ed0-c474-2fc9-27f0-a2075dd8e334@physik.fu-berlin.de> References: <209442a1-b8e7-b9e4-4ae4-6378f61df245@physik.fu-berlin.de> <58f32ed0-c474-2fc9-27f0-a2075dd8e334@physik.fu-berlin.de> Message-ID: <9b82da8b-b7b7-933b-063f-9f252135df4d@physik.fu-berlin.de> On 11/21/2017 03:01 PM, John Paul Adrian Glaubitz wrote: > === Output from failing command(s) repeated here === > /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_os_linux_zero.o:\n" > * For target hotspot_variant-zero_libjvm_objs_os_linux_zero.o: > (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_os_linux_zero.o.log || true) | /usr/bin/head -n 12 > /home/glaubitz/upstream/hs/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp: In function ?void current_stack_region(u_char**, size_t*)?: > /home/glaubitz/upstream/hs/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:375:18: error: ?is_initial_thread? is not a member of ?os::Linux? > if (os::Linux::is_initial_thread()) { > ^~~~~~~~~~~~~~~~~ > if test `/usr/bin/wc -l < /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_os_linux_zero.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi > /usr/bin/printf "\n* All command lines available in /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs.\n" > > * All command lines available in /home/glaubitz/upstream/hs/build/linux-x86_64-normal-zero-release/make-support/failure-logs. > /usr/bin/printf "=== End of repeated output ===\n" > === End of repeated output === Which got broken by JDK-8189170. -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Nov 21 14:12:49 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 15:12:49 +0100 Subject: Zero broken again, probably due to JDK-8189871 In-Reply-To: <9b82da8b-b7b7-933b-063f-9f252135df4d@physik.fu-berlin.de> References: <209442a1-b8e7-b9e4-4ae4-6378f61df245@physik.fu-berlin.de> <58f32ed0-c474-2fc9-27f0-a2075dd8e334@physik.fu-berlin.de> <9b82da8b-b7b7-933b-063f-9f252135df4d@physik.fu-berlin.de> Message-ID: <5579228f-8517-ccfe-2844-e3b4838ae319@physik.fu-berlin.de> > Which got broken by JDK-8189170. Complete fix is: glaubitz at z6:..upstream/hs> hg diff diff -r 1f77dcf5577e src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp --- a/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp Tue Nov 21 13:48:28 2017 +0100 +++ b/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp Tue Nov 21 15:12:03 2017 +0100 @@ -372,7 +372,7 @@ // The initial thread has a growable stack, and the size reported // by pthread_attr_getstack is the maximum size it could possibly // be given what currently mapped. This can be huge, so we cap it. - if (os::Linux::is_initial_thread()) { + if (os::is_primordial_thread()) { stack_bytes = stack_top - stack_bottom; if (stack_bytes > JavaThread::stack_size_at_create()) diff -r 1f77dcf5577e src/hotspot/share/oops/accessBackend.hpp --- a/src/hotspot/share/oops/accessBackend.hpp Tue Nov 21 13:48:28 2017 +0100 +++ b/src/hotspot/share/oops/accessBackend.hpp Tue Nov 21 15:12:03 2017 +0100 @@ -82,7 +82,7 @@ #ifdef SUPPORTS_NATIVE_CX8 struct PossiblyLockedAccess: public IntegralConstant {}; #else - struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; + struct PossiblyLockedAccess: public IntegralConstant 4)> {}; #endif template glaubitz at z6:..upstream/hs> I have filed JDK-8191663 and will push a webrev shortly. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From rkennke at redhat.com Tue Nov 21 14:15:27 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Nov 2017 15:15:27 +0100 Subject: Zero broken again, probably due to JDK-8189871 In-Reply-To: <5579228f-8517-ccfe-2844-e3b4838ae319@physik.fu-berlin.de> References: <209442a1-b8e7-b9e4-4ae4-6378f61df245@physik.fu-berlin.de> <58f32ed0-c474-2fc9-27f0-a2075dd8e334@physik.fu-berlin.de> <9b82da8b-b7b7-933b-063f-9f252135df4d@physik.fu-berlin.de> <5579228f-8517-ccfe-2844-e3b4838ae319@physik.fu-berlin.de> Message-ID: <3ad0e6b8-0199-5628-9ed9-417123ff0b37@redhat.com> Am 21.11.2017 um 15:12 schrieb John Paul Adrian Glaubitz: >> Which got broken by JDK-8189170. > > Complete fix is: > > glaubitz at z6:..upstream/hs> hg diff > diff -r 1f77dcf5577e src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp > --- a/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp Tue Nov 21 13:48:28 2017 +0100 > +++ b/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp Tue Nov 21 15:12:03 2017 +0100 > @@ -372,7 +372,7 @@ > // The initial thread has a growable stack, and the size reported > // by pthread_attr_getstack is the maximum size it could possibly > // be given what currently mapped. This can be huge, so we cap it. > - if (os::Linux::is_initial_thread()) { > + if (os::is_primordial_thread()) { > stack_bytes = stack_top - stack_bottom; > > if (stack_bytes > JavaThread::stack_size_at_create()) > diff -r 1f77dcf5577e src/hotspot/share/oops/accessBackend.hpp > --- a/src/hotspot/share/oops/accessBackend.hpp Tue Nov 21 13:48:28 2017 +0100 > +++ b/src/hotspot/share/oops/accessBackend.hpp Tue Nov 21 15:12:03 2017 +0100 > @@ -82,7 +82,7 @@ > #ifdef SUPPORTS_NATIVE_CX8 > struct PossiblyLockedAccess: public IntegralConstant {}; > #else > - struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; > + struct PossiblyLockedAccess: public IntegralConstant 4)> {}; > #endif > > template > glaubitz at z6:..upstream/hs> > > I have filed JDK-8191663 and will push a webrev shortly. > You are fast! :-) Thanks! Roman From glaubitz at physik.fu-berlin.de Tue Nov 21 14:23:46 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 15:23:46 +0100 Subject: Webrev and multiple changesets Message-ID: <49fe306a-d0f6-0c89-6743-afdbaa473e67@physik.fu-berlin.de> Hello! Can someone give a hint on how to use webrev when making multiple, independent changes? Since I'm still rather a beginner when it comes to Mercurial, I have no idea how to use branches. I have now fixed JDK-8187227 and created a webrev for it in [1]. Now, I also want to fix JDK-8191663, commit the changes and run webrev, it will create a changeset which includes the changes for 8187227 as well which is not what I want. I tried checking out a second a branch but the commit for JDK-8187227 is still in the history. Can someone tell me what the proper process in this context is? For now, I'm just going to strip the changeset for JDK-8187227 since it's already in [1]. Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8187227/webrev.03/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From rkennke at redhat.com Tue Nov 21 14:26:53 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Nov 2017 15:26:53 +0100 Subject: Webrev and multiple changesets In-Reply-To: <49fe306a-d0f6-0c89-6743-afdbaa473e67@physik.fu-berlin.de> References: <49fe306a-d0f6-0c89-6743-afdbaa473e67@physik.fu-berlin.de> Message-ID: Am 21.11.2017 um 15:23 schrieb John Paul Adrian Glaubitz: > Hello! > > Can someone give a hint on how to use webrev when making multiple, > independent changes? Since I'm still rather a beginner when it comes > to Mercurial, I have no idea how to use branches. > > I have now fixed JDK-8187227 and created a webrev for it in [1]. > > Now, I also want to fix JDK-8191663, commit the changes and run webrev, > it will create a changeset which includes the changes for 8187227 as > well which is not what I want. > > I tried checking out a second a branch but the commit for JDK-8187227 > is still in the history. > > Can someone tell me what the proper process in this context is? > > For now, I'm just going to strip the changeset for JDK-8187227 since > it's already in [1]. > > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8187227/webrev.03/ > I am usually stacking patches with MQ and then use webrev -r to specify a base revision. Roman From glaubitz at physik.fu-berlin.de Tue Nov 21 14:26:56 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 15:26:56 +0100 Subject: RFR: 8191663: Zero variant broken after 8189170 and 8189871 Message-ID: Hello! Please review this change which fixes the Zero build which got broken after the changes introduced by 8189170 and 8189871. Webrev in [1]. Thanks, Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8191663/webrev.00/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Nov 21 14:28:43 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 15:28:43 +0100 Subject: Webrev and multiple changesets In-Reply-To: References: <49fe306a-d0f6-0c89-6743-afdbaa473e67@physik.fu-berlin.de> Message-ID: On 11/21/2017 03:26 PM, Roman Kennke wrote: > I am usually stacking patches with MQ and then use webrev -r to specify a base revision. The problem is: When I use the -r option, it doesn't generate a "hotspot.changeset" but a "hotspot.patch" and I have been told on this list that such a patch cannot be imported directly by Mercurial unlike the changesets. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From shade at redhat.com Tue Nov 21 14:30:30 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 21 Nov 2017 15:30:30 +0100 Subject: Webrev and multiple changesets In-Reply-To: <49fe306a-d0f6-0c89-6743-afdbaa473e67@physik.fu-berlin.de> References: <49fe306a-d0f6-0c89-6743-afdbaa473e67@physik.fu-berlin.de> Message-ID: <874bac47-b083-da11-1227-caf431558395@redhat.com> On 11/21/2017 03:23 PM, John Paul Adrian Glaubitz wrote: > Hello! > > Can someone give a hint on how to use webrev when making multiple, > independent changes? Since I'm still rather a beginner when it comes > to Mercurial, I have no idea how to use branches. Use mq. Then webrev would generate the difference against repository with all your mq patches applied. When you are happy, qfinish converts them to individual changesets, and you can push. > I have now fixed JDK-8187227 and created a webrev for it in [1]. > > Now, I also want to fix JDK-8191663, commit the changes and run webrev, > it will create a changeset which includes the changes for 8187227 as > well which is not what I want. > > I tried checking out a second a branch but the commit for JDK-8187227 > is still in the history. > > Can someone tell me what the proper process in this context is? I'd say: $ hq qnew 8187227-fix # $ hg qrefresh -m "Fix for 8187227" $ hg qnew 8191663-fix # $ hg qrefresh -m "Fix for 8191663" $ ksh ./webrev.ksh # webrev is generated for both 8187227 and 8191663. # use ./webrev.ksh -r to change the base for comparisons # unhappy with patch? roll back/forth with qpop/qpush, # ...make changes, qrefresh $ hg qpush -a # run tests $ hg qfinish -a # both patches are converted to individual changesets in repo $ hg push Thanks, -Aleksey From rkennke at redhat.com Tue Nov 21 14:32:03 2017 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Nov 2017 15:32:03 +0100 Subject: Webrev and multiple changesets In-Reply-To: References: <49fe306a-d0f6-0c89-6743-afdbaa473e67@physik.fu-berlin.de> Message-ID: <2686c334-7366-3da5-bc3a-c8a2c1890c0c@redhat.com> Am 21.11.2017 um 15:28 schrieb John Paul Adrian Glaubitz: > On 11/21/2017 03:26 PM, Roman Kennke wrote: >> I am usually stacking patches with MQ and then use webrev -r to specify a base revision. > > The problem is: When I use the -r option, it doesn't generate a "hotspot.changeset" > but a "hotspot.patch" and I have been told on this list that such a patch cannot > be imported directly by Mercurial unlike the changesets. > > Adrian > Never was aware of that, but right. OTOH; nobody ever complained when I did it :-) Roman From glaubitz at physik.fu-berlin.de Tue Nov 21 14:35:00 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 15:35:00 +0100 Subject: Webrev and multiple changesets In-Reply-To: <874bac47-b083-da11-1227-caf431558395@redhat.com> References: <49fe306a-d0f6-0c89-6743-afdbaa473e67@physik.fu-berlin.de> <874bac47-b083-da11-1227-caf431558395@redhat.com> Message-ID: <591961b9-8954-b8fa-331d-68d9b2ef83b2@physik.fu-berlin.de> Hi Aleksey! On 11/21/2017 03:30 PM, Aleksey Shipilev wrote: > Use mq. Then webrev would generate the difference against repository with all your mq patches > applied. When you are happy, qfinish converts them to individual changesets, and you can push. > >> I have now fixed JDK-8187227 and created a webrev for it in [1]. >> >> Now, I also want to fix JDK-8191663, commit the changes and run webrev, >> it will create a changeset which includes the changes for 8187227 as >> well which is not what I want. >> >> I tried checking out a second a branch but the commit for JDK-8187227 >> is still in the history. >> >> Can someone tell me what the proper process in this context is? > > I'd say: > (snip) Thanks for the suggestions. I will try this procedure for the next fixes. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From thomas.stuefe at gmail.com Tue Nov 21 14:45:33 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 Nov 2017 15:45:33 +0100 Subject: RFR: 8191663: Zero variant broken after 8189170 and 8189871 In-Reply-To: References: Message-ID: Hi Adrian, looks good. Thanks for fixing zero again. Kind Regards, Thomas On Tue, Nov 21, 2017 at 3:26 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Hello! > > Please review this change which fixes the Zero build which got broken after > the changes introduced by 8189170 and 8189871. Webrev in [1]. > > Thanks, > > Adrian > > > [1] http://cr.openjdk.java.net/~glaubitz/8191663/webrev.00/ > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From erik.osterlund at oracle.com Tue Nov 21 15:10:25 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 21 Nov 2017 16:10:25 +0100 Subject: RFR: 8191663: Zero variant broken after 8189170 and 8189871 In-Reply-To: References: Message-ID: <5A1441E1.1070102@oracle.com> Hi Adrian, Looks good. Thanks for fixing this. Thanks, /Erik On 2017-11-21 15:26, John Paul Adrian Glaubitz wrote: > Hello! > > Please review this change which fixes the Zero build which got broken after > the changes introduced by 8189170 and 8189871. Webrev in [1]. > > Thanks, > > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8191663/webrev.00/ From coleen.phillimore at oracle.com Tue Nov 21 15:51:25 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 Nov 2017 10:51:25 -0500 Subject: RFR: JDK-8191202 Remove duplicated jmm.h In-Reply-To: <25e3f830-394d-a549-6889-abf36021e93b@oracle.com> References: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> <2cd090e5-2272-e3f8-3a9e-da487b3f1550@oracle.com> <25e3f830-394d-a549-6889-abf36021e93b@oracle.com> Message-ID: <962d3f6f-30cb-00da-15ef-d8a989650031@oracle.com> I think this looks good. I'd rather these be in the same place for now until a better destination is agreed upon. thank you for removing this file. Coleen On 11/21/17 8:55 AM, Magnus Ihse Bursie wrote: > On 2017-11-21 12:49, David Holmes wrote: >> Hi Magnus, >> >> Seems to me that jmm is an interface exported by the VM, so the >> hotspot version of the header is the one that should survive IMO. > > We had a similar discussion about the other header files, were we kept > the JDK version, for the time being. A bug, JDK-8190484 was opened to > discuss the final location of the one remaining copy. This has in fact > already prepared for the removal of the duplicated jmm.h, since it's > titled "Revisit the source location of jvm.h and jmm.h". > > I'd prefer to treat this one similar to the other duplicated header > files, and keep the JDK version for the time being. And then leaving > it to whoever solves JDK-8190484 to figure out a proper location. Are > you okay with that? > > /Magnus > >> David >> >> On 21/11/2017 9:42 PM, Magnus Ihse Bursie wrote: >>> As part of the effort to remove duplicated files between Hotspot and >>> JDK, the turn has now come to jmm.h. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191202 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8191202-remove-duplicated-jmm-h/webrev.01 >>> >>> >>> /Magnus > From erik.osterlund at oracle.com Tue Nov 21 16:14:31 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 21 Nov 2017 17:14:31 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> Message-ID: <5A1450E7.4060805@oracle.com> Hi Kim, My apologies - I already pushed my changes and did not realize you had more feedback. On 2017-11-20 20:37, Kim Barrett wrote: >> On Nov 17, 2017, at 9:09 AM, Erik ?sterlund wrote: >>> When we discussed this problem previously, we talked about having >>> specific names associated with categories of off-heap references that >>> might be handled differently by different collectors. Some specific >>> examples that came up in that discussion were JNI global (and weak) >>> handles, and interned strings. Even if we really expect all of our >>> concurrent collectors to eventually process all of these concurrently, >>> such features might be added on different schedules for different >>> collectors. >>> >>> Without such a naming scheme, e.g. with only a generic >>> IS_CONCURRENT_ROOT, different collectors may pay the cost for being >>> conservative for different categories. That might be acceptable if >>> being conservative is cheap. But then I would expect the possibly >>> concurrent case to be pretty much the default, to be used nearly >>> everywhere, since it is unreasonable to expect non-GC experts to stay >>> up to date on which roots are never ever scanned concurrently by any >>> collector. >> Okay so I really want the ability to say my roots are definitely scanned in a pause, e.g. when storing oops in thread-local value type values that are considered semantically as part of the stack, and will definitely for all thinkable weird forseeable GC combinations be scanned in a pause. >> >> At the moment it is really a special case with potentially concurrently scanned roots rather than the norm. So if that is okay, I would like to defer a decision to make concurrent root the default type of root. At least now that we are annotating the access, if any GC developer is adding concurrent processing of roots, it is very easy to find which where potential trouble lies. > To me, that suggests there should be an IN_STACK_ROOT decorator. > > And I have reason to think the "will definitely for all thinkable > weird forseeable GC combinations be scanned in a pause" set is empty. > > I guess I'm okay with deferring some of the design in this specific > area for the moment. (I was going to say "defer until needed", but > with Shenandoah and ZGC that might be essentially now, and even G1 > could probably benefit pretty quickly.) > > I was going to suggest removing IN_CONCURRENT_ROOT, since I really > doubt any sort of generic label like that is the right approach, and > it's very nearly unused. But it appears there are no uses as actual > access annotations yet, and the places where it is used appear to be > parts of the implementation that would need to be adapted for any > redesign, so maybe it's worth keeping as a placeholder. Yes I think time will tell best what to do here. > While looking at uses of IN_CONCURRENT_ROOT, I found a few more things > to comment on. > > In Access::verify_heap_oop_decorators, I think (IN_ROOT ^ > IN_CONCURRENT_ROOT) should be using | rather than ^. IN_ROOT ^ IN_CONCURRENT_ROOT is equal to IN_ROOT | IN_CONCURRENT_ROOT But yes, perhaps that would have looked nicer. > In Access::verify_(primitive|oop|heap_oop)_decorators, I don't > understand the expected_mo_decorators template parameter. If it is the > set of allowed memory order decorators, it is being effectively > ignored by the inclusion of MO_DECORATOR_MASK in the function-specific > decorators set. > > In Access::verify_decorators, all the category checks allow a zero > value in the category being checked. I wouldn't expect a zero value to > be permitted; for all categories there's an explicit default, which > ought to be present. Is this verification done before defaulting? If > so, then is there a later check that there's no bug in defaulting that > would introduce an inconsistency? The verify_decorators stuff checks the decorators passed in by the users only. For each type of access there is first a check that decorators outside of a certain mask are not used (nonsense decorators for a given access type). When we know there are no nonsense decorators, we check for each set of decorators that either precisely one or no decorator conbination has been selected. For the sets that did not have a decorator value, defaults are applied. For example, memory ordering is by default unordered for loads/stores, seq_cst for xchg and cmpxchg, and reference strength is by default AS_NORMAL. So to answer the question: it is fine for decorator sets passed in by users to not explicitly set default decorator values, which indeed will be set later on. Thanks, /Erik From erik.osterlund at oracle.com Tue Nov 21 16:20:45 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 21 Nov 2017 17:20:45 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> Message-ID: <5A14525D.4030006@oracle.com> Hi Kim, I am merely more precisely annotating that unsafe accesses on oops have explicitly unknown oop ref strength. However, the GC backends do not do more about it than they did before. I.e. only G1 loads check the actual reference strength and act accordingly (as before), and other exotic accesses are treated the same in the backends (as before) since their pre-write barriers are enough anyway. The behaviour is the same before and after. Thanks, /Erik On 2017-11-21 08:07, Kim Barrett wrote: > Noticed another issue while looking for something else. > > Before these changes, Unsafe_CompareAndExchangeObject does not > specially handle Reference referents. Attempting to do so is new > behavior introduced by Access. I don't think that change should be > made. I think anyone who uses an Unsafe compare and swap to modify the > referent of a reference deserves all the pain and suffering we can > inflict upon them. With Unsafe, just because the current > implementation doesn't outright prevent something doesn't make it a > valid thing to do. There are many ways to (mis)use Unsafe that create > havoc by breaking invariants and such. Consider the damange that could > be done by using Unsafe to modify the discovered field of a reference, > for example. > > I haven't looked for other similar "quiet changes". > > I'm also finding what look to me like some inconsistencies between the > documentation for Unsafe and the implementation, but except for things > like the above they are pre-existing. > From karen.kinnear at oracle.com Tue Nov 21 16:24:10 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Tue, 21 Nov 2017 11:24:10 -0500 Subject: CFV: New hotspot Group Member: Per Liden In-Reply-To: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> References: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> Message-ID: <5BE1A0AD-882E-4FBE-B103-F6A82D3B53E6@oracle.com> Vote: yes thanks, Karen > On Nov 17, 2017, at 11:30 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate Per Liden (OpenJDK user name: pliden) to Membership in the hotspot Group. > > Per has been working on the Hotspot JVM for over 5 years at Oracle and has contributed 64 changes to the OpenJDK repository, including multiple G1 garbage collector fixes, string deduplication, and logging. Per is the initial author of ZGC and is the lead of the OpenJDK ZGC project sponsored by the hotspot group. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From erik.osterlund at oracle.com Tue Nov 21 16:33:05 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 21 Nov 2017 17:33:05 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> Message-ID: <5A145541.5070601@oracle.com> Hi Kim, On 2017-11-21 08:16, Kim Barrett wrote: >> On Nov 21, 2017, at 2:07 AM, Kim Barrett wrote: >> >> Noticed another issue while looking for something else. > And another one. > > The modified unsafe.cpp doesn't use field_offset_(to|from)_byte_offset > in places where Access is being used. Those functions and their use > is intentional documentation and abstraction, despite their > implementations presently being nops. Where Access is being used, the > offset is now just quietly assumed to be in bytes, ignoring that > abstraction. I think the use of those functions ought to be retained. I will file an RFE to re-introduce this no-op abstraction. Thanks, /Erik From vladimir.kozlov at oracle.com Tue Nov 21 17:06:50 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Nov 2017 09:06:50 -0800 Subject: CFV: New hotspot Group Member: Per Liden In-Reply-To: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> References: <7a681aaf-1937-3eb6-0eb6-47ce7db79ed3@oracle.com> Message-ID: Vote: yes On 11/17/17 8:30 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Per Liden (OpenJDK user name: pliden) to Membership in > the hotspot Group. > > Per has been working on the Hotspot JVM for over 5 years at Oracle and > has contributed 64 changes to the OpenJDK repository, including multiple > G1 garbage collector fixes, string deduplication, and logging.?? Per is > the initial author of ZGC and is the lead of the OpenJDK ZGC project > sponsored by the hotspot group. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From serguei.spitsyn at oracle.com Tue Nov 21 17:50:32 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 Nov 2017 09:50:32 -0800 Subject: CFV: New hotspot Group Member: Kim Barrett In-Reply-To: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> References: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> Message-ID: Vote: yes From glaubitz at physik.fu-berlin.de Tue Nov 21 17:52:37 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 18:52:37 +0100 Subject: RFR: 8187227: Zero should use compiler built-ins for atomics on linux-m68k In-Reply-To: <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> Message-ID: <937fa509-2e5f-0e20-fa9d-458556550f04@physik.fu-berlin.de> On 11/21/2017 02:37 PM, John Paul Adrian Glaubitz wrote: > The build and run-test is currently pending (still building), but since > libjvm.so already compiled successfully, I am 99% confident the change > is correct as is. Yes, I can confirm that the change in [1] works. Thanks, Adrian >> [1] http://cr.openjdk.java.net/~glaubitz/8187227/webrev.03/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From erik.joelsson at oracle.com Tue Nov 21 17:52:56 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 Nov 2017 09:52:56 -0800 Subject: RFR: JDK-8191202 Remove duplicated jmm.h In-Reply-To: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> References: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> Message-ID: The change looks good. I'm fine with leaving the decision for later with the open bug, but I do think the file should be in the library that exports the API. /Erik On 2017-11-21 03:42, Magnus Ihse Bursie wrote: > As part of the effort to remove duplicated files between Hotspot and > JDK, the turn has now come to jmm.h. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191202 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191202-remove-duplicated-jmm-h/webrev.01 > > /Magnus From kim.barrett at oracle.com Tue Nov 21 18:29:18 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Nov 2017 13:29:18 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A145541.5070601@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> <5A145541.5070601@oracle.com> Message-ID: <514A2FCD-B25E-4EE6-99FF-8EE29F89A664@oracle.com> > On Nov 21, 2017, at 11:33 AM, Erik ?sterlund wrote: > > Hi Kim, > > On 2017-11-21 08:16, Kim Barrett wrote: >>> On Nov 21, 2017, at 2:07 AM, Kim Barrett wrote: >>> >>> Noticed another issue while looking for something else. >> And another one. >> >> The modified unsafe.cpp doesn't use field_offset_(to|from)_byte_offset >> in places where Access is being used. Those functions and their use >> is intentional documentation and abstraction, despite their >> implementations presently being nops. Where Access is being used, the >> offset is now just quietly assumed to be in bytes, ignoring that >> abstraction. I think the use of those functions ought to be retained. > > I will file an RFE to re-introduce this no-op abstraction. Thanks. From vladimir.kozlov at oracle.com Tue Nov 21 18:47:34 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Nov 2017 10:47:34 -0800 Subject: JAOTC in JDK 10: kicking the tyres In-Reply-To: <4d91af81-28e2-e5b7-3039-a62e7470a979@oracle.com> References: <3f6e3051-a485-3b55-8cac-d74f5970c3ee@redhat.com> <015bf12f-7ff3-498f-7688-27cfd4be7e8d@oracle.com> <40a0383b-c7d1-9848-1704-78ca5fd70e58@redhat.com> <4d91af81-28e2-e5b7-3039-a62e7470a979@oracle.com> Message-ID: Unfortunately some methods have to be excluded from AOT compilation with --compile-commands. One case, like this, class initialization dependencies. AOT is loading classes in different order than when they are loaded during normal execution. Other case - missing classes which usually are not present and not used and loaded only in special case (running on particular platform, for example). I saw it during jruby compilation. In both cases we have to exclude such methods from compilation. Note, missing classes (when they are present) exceptions during compilation is different case. As described in http://openjdk.java.net/jeps/295 you may need to use '-J -cp ...' to specify path for existing classes which AOT does not load by default. Regards, Vladimir On 11/20/17 11:06 AM, dean.long at oracle.com wrote: > On 11/20/17 10:43 AM, Andrew Haley wrote: > >> On 20/11/17 18:34, dean.long at oracle.com wrote: >>> I think you want --module java.base here.? I guess jaotc doesn't support >>> .jmod files. >> Aha!? Yes, that seems to be much better, thanks. >> >> It still doesn't work, but oh well: >> >> Error: Failed compilation: >> sun.net.www.protocol.jrt.Handler.openConnection(Ljava/net/URL;)Ljava/net/URLConnection;: >> org.graalvm.compiler.java.BytecodeParser$BytecodeParserError: >> java.lang.ExceptionInInitializerError >> ????at parsing >> java.base/sun.net.www.protocol.jrt.Handler.openConnection(Handler.java:42) >> >> >> If this isn't expected to fail I'll report it as a bug. >> > There are problem methods listed in > test/hotspot/jtreg/compiler/aot/scripts/java.base-list.txt and also on > http://openjdk.java.net/jeps/295.? So please try with --compile-commands > java.base-list.txt first and if it still fails then please file a bug. > > dl From kim.barrett at oracle.com Tue Nov 21 18:48:36 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Nov 2017 13:48:36 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A14525D.4030006@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> <5A14525D.4030006@oracle.com> Message-ID: > On Nov 21, 2017, at 11:20 AM, Erik ?sterlund wrote: > > Hi Kim, > > I am merely more precisely annotating that unsafe accesses on oops have explicitly unknown oop ref strength. However, the GC backends do not do more about it than they did before. I.e. only G1 loads check the actual reference strength and act accordingly (as before), and other exotic accesses are treated the same in the backends (as before) since their pre-write barriers are enough anyway. The behaviour is the same before and after. For the operations in question, there were no checks for reference strength before, not even for G1. So the behavior is not the same before and after the Access changes. Unsafe_CompareAndExchangeObject on a referent was effectively UB. I don't think adding the special handling for referents makes it any less UB; it's still an abuse of Unsafe to break invariants. In which case, any potential additional work that might be done to handle that specific case is not just pointless, but actively harmful. > Thanks, > /Erik > > On 2017-11-21 08:07, Kim Barrett wrote: >> Noticed another issue while looking for something else. >> >> Before these changes, Unsafe_CompareAndExchangeObject does not >> specially handle Reference referents. Attempting to do so is new >> behavior introduced by Access. I don't think that change should be >> made. I think anyone who uses an Unsafe compare and swap to modify the >> referent of a reference deserves all the pain and suffering we can >> inflict upon them. With Unsafe, just because the current >> implementation doesn't outright prevent something doesn't make it a >> valid thing to do. There are many ways to (mis)use Unsafe that create >> havoc by breaking invariants and such. Consider the damange that could >> be done by using Unsafe to modify the discovered field of a reference, >> for example. >> >> I haven't looked for other similar "quiet changes". >> >> I'm also finding what look to me like some inconsistencies between the >> documentation for Unsafe and the implementation, but except for things >> like the above they are pre-existing. From vladimir.kozlov at oracle.com Tue Nov 21 18:55:20 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Nov 2017 10:55:20 -0800 Subject: CFV: New hotspot Group Member: Kim Barrett In-Reply-To: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> References: <761b3e36-8f2e-c97a-97de-0c10df923fc4@oracle.com> Message-ID: <65007fa8-0b0b-c947-6baf-22638436d05d@oracle.com> Vote: yes On 11/17/17 11:26 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate Kim Barrett (OpenJDK user name: kbarrett) to > Membership in the hotspot Group. > > Kim has been working on the Hotspot JVM for 4 years.? He has contributed > 110 changesets in the areas of the G1 garbage collector, reference > processing and the atomic functions.? He is expert in C++ and has guided > many improvements to the portability and correctness of the hotspot > source code as well. > > Votes are due by Friday, December 1, 2017. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Coleen > > [1]http://openjdk.java.net/census#hotspot > [2]http://openjdk.java.net/groups/#member-vote From erik.osterlund at oracle.com Tue Nov 21 19:50:58 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 21 Nov 2017 20:50:58 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> <5A14525D.4030006@oracle.com> Message-ID: <1b967127-668e-f57d-2992-7680bb924396@oracle.com> Hi Kim, On 2017-11-21 19:48, Kim Barrett wrote: >> On Nov 21, 2017, at 11:20 AM, Erik ?sterlund wrote: >> >> Hi Kim, >> >> I am merely more precisely annotating that unsafe accesses on oops have explicitly unknown oop ref strength. However, the GC backends do not do more about it than they did before. I.e. only G1 loads check the actual reference strength and act accordingly (as before), and other exotic accesses are treated the same in the backends (as before) since their pre-write barriers are enough anyway. The behaviour is the same before and after. > For the operations in question, there were no checks for reference > strength before, not even for G1. So the behavior is not the same > before and after the Access changes. > > Unsafe_CompareAndExchangeObject on a referent was effectively UB. I > don't think adding the special handling for referents makes it any > less UB; it's still an abuse of Unsafe to break invariants. In which > case, any potential additional work that might be done to handle that > specific case is not just pointless, but actively harmful. For the operations in question, there were no checks for reference strength before or after. The unsafe.cpp file annotates that this is an unknown oop ref, the backends don't check for it or care. Seems very much the same to me. Am I missing something? Thanks, /Erik >> Thanks, >> /Erik >> >> On 2017-11-21 08:07, Kim Barrett wrote: >>> Noticed another issue while looking for something else. >>> >>> Before these changes, Unsafe_CompareAndExchangeObject does not >>> specially handle Reference referents. Attempting to do so is new >>> behavior introduced by Access. I don't think that change should be >>> made. I think anyone who uses an Unsafe compare and swap to modify the >>> referent of a reference deserves all the pain and suffering we can >>> inflict upon them. With Unsafe, just because the current >>> implementation doesn't outright prevent something doesn't make it a >>> valid thing to do. There are many ways to (mis)use Unsafe that create >>> havoc by breaking invariants and such. Consider the damange that could >>> be done by using Unsafe to modify the discovered field of a reference, >>> for example. >>> >>> I haven't looked for other similar "quiet changes". >>> >>> I'm also finding what look to me like some inconsistencies between the >>> documentation for Unsafe and the implementation, but except for things >>> like the above they are pre-existing. > From kim.barrett at oracle.com Tue Nov 21 21:28:33 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Nov 2017 16:28:33 -0500 Subject: RFR: 8187227: Zero should use compiler built-ins for atomics on linux-m68k In-Reply-To: <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> Message-ID: <4DD2EF85-52F6-4A4F-9F98-E8F1854E1E63@oracle.com> > On Nov 21, 2017, at 8:37 AM, John Paul Adrian Glaubitz wrote: > > On 11/21/2017 01:02 PM, John Paul Adrian Glaubitz wrote: >> I have just talked to Andreas Schwab, a colleague of mine at SUSE, who >> has been working on the Linux m68k stuff for a long time. According to >> him, the compiler built-ins didn't exist back then for m68k which is why >> the platform-specific functions exist in OpenJDK. They do now, however. >> >> I'll just remove them for m68k and test if that works as expected. If >> yes, we should change this changeset to do that instead of fixing the >> platform-specific functions. > > I have updated the webrev now accordingly and pushed it to [1]. > > The build and run-test is currently pending (still building), but since > libjvm.so already compiled successfully, I am 99% confident the change > is correct as is. > > Thanks, > Adrian > >> [1] http://cr.openjdk.java.net/~glaubitz/8187227/webrev.03/ > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 Looks good. From david.holmes at oracle.com Tue Nov 21 21:33:24 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Nov 2017 07:33:24 +1000 Subject: RFR: JDK-8191202 Remove duplicated jmm.h In-Reply-To: References: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> Message-ID: <0a52249c-762d-49f1-1811-75b0f1ac740d@oracle.com> On 22/11/2017 3:52 AM, Erik Joelsson wrote: > The change looks good. I'm fine with leaving the decision for later with > the open bug, but I do think the file should be in the library that > exports the API. Exactly! Deferring this placement decision seems pointless to me as the right location is plainly evident for these internal interfaces. It's just double shuffling and wasting time and effort. :( David > /Erik > > > On 2017-11-21 03:42, Magnus Ihse Bursie wrote: >> As part of the effort to remove duplicated files between Hotspot and >> JDK, the turn has now come to jmm.h. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191202 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8191202-remove-duplicated-jmm-h/webrev.01 >> >> >> /Magnus > From david.holmes at oracle.com Tue Nov 21 22:10:33 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Nov 2017 08:10:33 +1000 Subject: Zero broken again, probably due to JDK-8189871 In-Reply-To: <5579228f-8517-ccfe-2844-e3b4838ae319@physik.fu-berlin.de> References: <209442a1-b8e7-b9e4-4ae4-6378f61df245@physik.fu-berlin.de> <58f32ed0-c474-2fc9-27f0-a2075dd8e334@physik.fu-berlin.de> <9b82da8b-b7b7-933b-063f-9f252135df4d@physik.fu-berlin.de> <5579228f-8517-ccfe-2844-e3b4838ae319@physik.fu-berlin.de> Message-ID: <018e7427-d63d-f7b1-0f57-0a5ed7170e58@oracle.com> Adrian, On 22/11/2017 12:12 AM, John Paul Adrian Glaubitz wrote: >> Which got broken by JDK-8189170. Sincerest apologies for that. I should have grepped for os::Linux::is_initial_thread usage. David > Complete fix is: > > glaubitz at z6:..upstream/hs> hg diff > diff -r 1f77dcf5577e src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp > --- a/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp Tue Nov 21 13:48:28 2017 +0100 > +++ b/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp Tue Nov 21 15:12:03 2017 +0100 > @@ -372,7 +372,7 @@ > // The initial thread has a growable stack, and the size reported > // by pthread_attr_getstack is the maximum size it could possibly > // be given what currently mapped. This can be huge, so we cap it. > - if (os::Linux::is_initial_thread()) { > + if (os::is_primordial_thread()) { > stack_bytes = stack_top - stack_bottom; > > if (stack_bytes > JavaThread::stack_size_at_create()) > diff -r 1f77dcf5577e src/hotspot/share/oops/accessBackend.hpp > --- a/src/hotspot/share/oops/accessBackend.hpp Tue Nov 21 13:48:28 2017 +0100 > +++ b/src/hotspot/share/oops/accessBackend.hpp Tue Nov 21 15:12:03 2017 +0100 > @@ -82,7 +82,7 @@ > #ifdef SUPPORTS_NATIVE_CX8 > struct PossiblyLockedAccess: public IntegralConstant {}; > #else > - struct PossiblyLockedAccess: public IntegralConstant 4)>::value> {}; > + struct PossiblyLockedAccess: public IntegralConstant 4)> {}; > #endif > > template > glaubitz at z6:..upstream/hs> > > I have filed JDK-8191663 and will push a webrev shortly. > > Adrian > From alexander.harlap at oracle.com Tue Nov 21 22:18:43 2017 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Tue, 21 Nov 2017 17:18:43 -0500 Subject: Request for review JDK-8185591 guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified Message-ID: <706fbd26-7038-98de-d04e-d4158a94a00d@oracle.com> Please review change for JDK-8185591 - guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified Change is located at http://cr.openjdk.java.net/~aharlap/8185591/webrev.01/ Problem was in mishandling zero count in code generated by gen_write_ref_array_post_barrier(). Code is machine specific. Suggested fix for arm, sparc and x86_64. No changes are? required for x86_32 - case zero count already is handled properly ( same as for s390 and ppc). Aarch64 code have same problem as arm, sparc and x86_64, but I did not include this platform in suggested changeset. I attached possiible change for aarch64 stubGenerator_aarch64.cpp.diff Testing was done with JPRT. Thank you, Alex -------------- next part -------------- diff -r b512c5781ca1 src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp --- a/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Tue Oct 10 16:29:04 2017 +0200 +++ b/src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Tue Nov 21 13:19:17 2017 -0500 @@ -701,13 +701,17 @@ CardTableModRefBS* ct = (CardTableModRefBS*)bs; assert(sizeof(*ct->byte_map_base) == sizeof(jbyte), "adjust this code"); - Label L_loop; + Label L_loop, L_done; __ lsr(start, start, CardTableModRefBS::card_shift); __ lsr(end, end, CardTableModRefBS::card_shift); __ sub(end, end, start); // number of bytes to copy const Register count = end; // 'end' register contains bytes count now + + __ cmp(count, 0); + __ br(Assembler::LT, L_done) // count < 0 - nothing to do + __ load_byte_map_base(scratch); __ add(start, start, scratch); if (UseConcMarkSweepGC) { @@ -717,6 +721,7 @@ __ strb(zr, Address(start, count)); __ subs(count, count, 1); __ br(Assembler::GE, L_loop); + __ BIND(L_done); } break; default: From glaubitz at physik.fu-berlin.de Tue Nov 21 22:21:00 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 21 Nov 2017 23:21:00 +0100 Subject: Zero broken again, probably due to JDK-8189871 In-Reply-To: <018e7427-d63d-f7b1-0f57-0a5ed7170e58@oracle.com> References: <209442a1-b8e7-b9e4-4ae4-6378f61df245@physik.fu-berlin.de> <58f32ed0-c474-2fc9-27f0-a2075dd8e334@physik.fu-berlin.de> <9b82da8b-b7b7-933b-063f-9f252135df4d@physik.fu-berlin.de> <5579228f-8517-ccfe-2844-e3b4838ae319@physik.fu-berlin.de> <018e7427-d63d-f7b1-0f57-0a5ed7170e58@oracle.com> Message-ID: <16882626-750b-4273-da76-05295b1cda47@physik.fu-berlin.de> On 11/21/2017 11:10 PM, David Holmes wrote: > Adrian, > > On 22/11/2017 12:12 AM, John Paul Adrian Glaubitz wrote: >>> Which got broken by JDK-8189170. > > Sincerest apologies for that. I should have grepped for os::Linux::is_initial_thread usage. No worries. Given the size of the two changes, I'm not surprised that such things happen. As long as we can get them fixed in time, I don't see any problems ;-). I'm actually thinking of setting up a Jenkins job for daily test builds of both the server and the zero variant to spot these issues the moment they are introduced. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From coleen.phillimore at oracle.com Tue Nov 21 22:54:12 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 Nov 2017 17:54:12 -0500 Subject: RFR: 8191663: Zero variant broken after 8189170 and 8189871 In-Reply-To: <5A1441E1.1070102@oracle.com> References: <5A1441E1.1070102@oracle.com> Message-ID: <18906b95-dd4c-f7b1-b9da-f5620b61ea4a@oracle.com> Hi, this looks good.? I'll sponsor it for you. Coleen On 11/21/17 10:10 AM, Erik ?sterlund wrote: > Hi Adrian, > > Looks good. Thanks for fixing this. > > Thanks, > /Erik > > On 2017-11-21 15:26, John Paul Adrian Glaubitz wrote: >> Hello! >> >> Please review this change which fixes the Zero build which got broken >> after >> the changes introduced by 8189170 and 8189871. Webrev in [1]. >> >> Thanks, >> >> Adrian >> >>> [1] http://cr.openjdk.java.net/~glaubitz/8191663/webrev.00/ > From kim.barrett at oracle.com Tue Nov 21 23:24:36 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 21 Nov 2017 18:24:36 -0500 Subject: Request for review JDK-8185591 guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified In-Reply-To: <706fbd26-7038-98de-d04e-d4158a94a00d@oracle.com> References: <706fbd26-7038-98de-d04e-d4158a94a00d@oracle.com> Message-ID: > On Nov 21, 2017, at 5:18 PM, Alexander Harlap wrote: > > Please review change for JDK-8185591 - guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified > > Change is located at http://cr.openjdk.java.net/~aharlap/8185591/webrev.01/ > > Problem was in mishandling zero count in code generated by gen_write_ref_array_post_barrier(). > > Code is machine specific. Suggested fix for arm, sparc and x86_64. > > No changes are required for x86_32 - case zero count already is handled properly ( same as for s390 and ppc). > > Aarch64 code have same problem as arm, sparc and x86_64, but I did not include this platform in suggested changeset. > > I attached possiible change for aarch64 stubGenerator_aarch64.cpp.diff > > Testing was done with JPRT. > > Thank you, > > Alex Thanks for tracking this down. ------------------------------------------------------------------------------ src/hotspot/cpu/x86/stubGenerator_x86_64.cpp 1270 __ testl(count, count); 1271 __ jcc(Assembler::zero, L_done); // zero count - nothing to do Instead of that, might it be better to instead add something like this? 1277 __ subptr(end, start); // end --> cards count + 1278 __ jcc(Assembler::less, L_done); // negative inclusive count - nothing to do Similar question for all of the affected platforms. I don't currently have a strong preference either way, but wonder if there's a good reason to choose one over the other. ------------------------------------------------------------------------------ From dean.long at oracle.com Wed Nov 22 00:28:04 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 21 Nov 2017 16:28:04 -0800 Subject: Request for review JDK-8185591 guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified In-Reply-To: <706fbd26-7038-98de-d04e-d4158a94a00d@oracle.com> References: <706fbd26-7038-98de-d04e-d4158a94a00d@oracle.com> Message-ID: <1dd5d3ab-6c30-36c8-620d-514ad2eebad3@oracle.com> For arm you can use cbz_32. dl On 11/21/17 2:18 PM, Alexander Harlap wrote: > Please review change for JDK-8185591 > - > guarantee(_byte_map[_guard_index] == last_card) failed: card table > guard has been modified > > Change is located at > http://cr.openjdk.java.net/~aharlap/8185591/webrev.01/ > > Problem was in mishandling zero count in code generated by > gen_write_ref_array_post_barrier(). > > Code is machine specific. Suggested fix for arm, sparc and x86_64. > > No changes are? required for x86_32 - case zero count already is > handled properly ( same as for s390 and ppc). > > Aarch64 code have same problem as arm, sparc and x86_64, but I did not > include this platform in suggested changeset. > > I attached possiible change for aarch64 stubGenerator_aarch64.cpp.diff > > Testing was done with JPRT. > > Thank you, > > Alex > From thomas.schatzl at oracle.com Wed Nov 22 08:28:33 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 22 Nov 2017 09:28:33 +0100 Subject: Request for review JDK-8185591 guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified In-Reply-To: References: <706fbd26-7038-98de-d04e-d4158a94a00d@oracle.com> Message-ID: <1511339313.3392.12.camel@oracle.com> On Tue, 2017-11-21 at 18:24 -0500, Kim Barrett wrote: > > On Nov 21, 2017, at 5:18 PM, Alexander Harlap > cle.com> wrote: > > > > Please review change for JDK-8185591 > /browse/JDK-8185591> - guarantee(_byte_map[_guard_index] == > > last_card) failed: card table guard has been modified > > > > Change is located at http://cr.openjdk.java.net/~aharlap/8185591/we > > brev.01/ > > > > Problem was in mishandling zero count in code generated by > > gen_write_ref_array_post_barrier(). > > > > Code is machine specific. Suggested fix for arm, sparc and x86_64. > > > > No changes are required for x86_32 - case zero count already is > > handled properly ( same as for s390 and ppc). > > > > Aarch64 code have same problem as arm, sparc and x86_64, but I did > > not include this platform in suggested changeset. > > > > I attached possiible change for aarch64 > > stubGenerator_aarch64.cpp.diff > > > > Testing was done with JPRT. > > > > Thank you, > > > > Alex > > Thanks for tracking this down. Thanks! Looks good to me. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp > 1270 __ testl(count, count); > 1271 __ jcc(Assembler::zero, L_done); // zero count - > nothing to do > > Instead of that, might it be better to instead add something like > this? > > 1277 __ subptr(end, start); // end --> cards count > + 1278 __ jcc(Assembler::less, L_done); // negative > inclusive count - nothing to do > > Similar question for all of the affected platforms. > > I don't currently have a strong preference either way, but wonder if > there's a good reason to choose one over the other. Basically the test instruction, particularly in combination with jcc, has some fast paths in processors. While in current ones that difference is pretty small after looking at the optimization manual (current Intel manuals only indicate that the test instruction (macro-) fuses with all flags afterwards; the sub does not [0]). On earlier processors (probably includes AMD ones) only test fuses with the jcc. I.e. some nano-optimization. Thanks, Thomas [0] https://www.intel.com/content/dam/www/public/us/en/documents/manual s/64-ia-32-architectures-optimization-manual.pdf , 3-13 From thomas.schatzl at oracle.com Wed Nov 22 08:38:35 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 22 Nov 2017 09:38:35 +0100 Subject: Request for review JDK-8185591 guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified In-Reply-To: <1511339313.3392.12.camel@oracle.com> References: <706fbd26-7038-98de-d04e-d4158a94a00d@oracle.com> <1511339313.3392.12.camel@oracle.com> Message-ID: <1511339915.3392.16.camel@oracle.com> Hi again, On Wed, 2017-11-22 at 09:28 +0100, Thomas Schatzl wrote: > On Tue, 2017-11-21 at 18:24 -0500, Kim Barrett wrote: > > > On Nov 21, 2017, at 5:18 PM, Alexander Harlap > > > wrote: > > > > > > Please review change for JDK-8185591 > > > - > > > guarantee(_byte_map[_guard_index] == > > > last_card) failed: card table guard has been modified > > > [...] > > Instead of that, might it be better to instead add something like > > this? > > > > 1277 __ subptr(end, start); // end --> cards count > > + 1278 __ jcc(Assembler::less, L_done); // negative > > inclusive count - nothing to do > > > > Similar question for all of the affected platforms. Also, ARM32 has its own instruction. > > > > I don't currently have a strong preference either way, but wonder > > if there's a good reason to choose one over the other. > > Basically the test instruction, particularly in combination with jcc, > has some fast paths in processors. While in current ones that > difference is pretty small after looking at the optimization manual > (current Intel manuals only indicate that the test instruction > (macro-) > fuses with all flags afterwards; the sub does not [0]). On earlier > processors (probably includes AMD ones) only test fuses with the jcc. > > I.e. some nano-optimization. Also, I think in this case testl has a denser encoding than subptr, because subptr probably ends up using 64 bit registers (+1 prefix byte), while testl is explicitly 32 bit. Thanks, Thomas From sean.mullan at oracle.com Wed Nov 22 14:37:07 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 22 Nov 2017 09:37:07 -0500 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields Message-ID: Please review this change to remove the pre-JDK 1.2 SecurityManager methods that have been deprecated since JDK 1.2 and marked for removal in JDK 9. These methods are fragile, error-prone and have been obsolete since the SecurityManager was revamped in JDK 1.2. The methods to be removed are: getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader. In addition, the deprecated and error-prone checkMemberAccess method (which was deprecated in JDK 8 and marked for removal in JDK 9) has been changed to throw SecurityException if the caller has not been granted AllPermission. This makes the method less likely it will be used incorrectly while still allowing some more time before it is removed. http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/ Thanks, Sean From Alan.Bateman at oracle.com Wed Nov 22 14:59:28 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Nov 2017 14:59:28 +0000 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields In-Reply-To: References: Message-ID: <0bd1f8ea-0d96-ce98-a587-818742f191d1@oracle.com> On 22/11/2017 14:37, Sean Mullan wrote: > Please review this change to remove the pre-JDK 1.2 SecurityManager > methods that have been deprecated since JDK 1.2 and marked for removal > in JDK 9. These methods are fragile, error-prone and have been > obsolete since the SecurityManager was revamped in JDK 1.2. The > methods to be removed are: getInCheck, classDepth, classLoaderDepth, > currentClassLoader, currentLoadedClass, inClass, and inClassLoader. > > In addition, the deprecated and error-prone checkMemberAccess method > (which was deprecated in JDK 8 and marked for removal in JDK 9) has > been changed to throw SecurityException if the caller has not been > granted AllPermission. This makes the method less likely it will be > used incorrectly while still allowing some more time before it is > removed. > > http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/ This mostly looks good. Does the stack walker created in AppletSecurity need to be done in a privileged block? If this is just the mouldy appletviewer tool then ignore my comment. A minor comment is that the is legacy and we've been using {@code ...} for recent changes. We changed some of these methods to use {@code ...} when we degraded them in JDK 9. Also NoAWT probably isn't the right place to test checkMemberAccess. If the test is renamed and the description changed then it would be okay. -Alan From sean.mullan at oracle.com Wed Nov 22 15:49:16 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 22 Nov 2017 10:49:16 -0500 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields In-Reply-To: <0bd1f8ea-0d96-ce98-a587-818742f191d1@oracle.com> References: <0bd1f8ea-0d96-ce98-a587-818742f191d1@oracle.com> Message-ID: On 11/22/17 9:59 AM, Alan Bateman wrote: >> http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/ > This mostly looks good. > > Does the stack walker created in AppletSecurity need to be done in a > privileged block? If this is just the mouldy appletviewer tool then > ignore my comment. Hmm. Where do you see it being called inside doPrivileged? > A minor comment is that the is legacy and we've been using {@code > ...} for recent changes. We changed some of these methods to use {@code > ...} when we degraded them in JDK 9. I guess you are referring to the checkMemberAccess method. Sure I can change it to use {@code}. > Also NoAWT probably isn't the right > place to test checkMemberAccess. If the test is renamed and the > description changed then it would be okay. Sure, the test already had everything I need so it was easier to leverage it rather than just duplicating. I had changed the description already. I will just rename it to something more generic, like DepMethodsRequireAllPerm. --Sean From Alan.Bateman at oracle.com Wed Nov 22 15:59:25 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 22 Nov 2017 15:59:25 +0000 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields In-Reply-To: References: <0bd1f8ea-0d96-ce98-a587-818742f191d1@oracle.com> Message-ID: On 22/11/2017 15:49, Sean Mullan wrote: > > Hmm. Where do you see it being called inside doPrivileged? StackWalker.getInstance does a permission check when you want class refs. > : > > Sure, the test already had everything I need so it was easier to > leverage it rather than just duplicating. I had changed the > description already. I will just rename it to something more generic, > like DepMethodsRequireAllPerm. > I think I added the NoAWT test for the checkXXX methods that used to check AWTPermission, hence the name. Renaming it would be good. -Alan From kim.barrett at oracle.com Wed Nov 22 16:31:30 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 22 Nov 2017 11:31:30 -0500 Subject: Request for review JDK-8185591 guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified In-Reply-To: <1511339313.3392.12.camel@oracle.com> References: <706fbd26-7038-98de-d04e-d4158a94a00d@oracle.com> <1511339313.3392.12.camel@oracle.com> Message-ID: <44E27962-F612-4DFF-800F-7CEB39D1A5C4@oracle.com> > On Nov 22, 2017, at 3:28 AM, Thomas Schatzl wrote: > > https://www.intel.com/content/dam/www/public/us/en/documents/manual > s/64-ia-32-architectures-optimization-manual.pdf , 3-13 Thanks for the cite. Change looks good. From volker.simonis at gmail.com Wed Nov 22 17:15:55 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 22 Nov 2017 18:15:55 +0100 Subject: RFR(XS): 8187280: Remove unused methods from StubQueue In-Reply-To: References: <63AB2BF3-F230-4A5E-963F-B9958FDA6F58@oracle.com> Message-ID: Hi, this somehow got lost and you boss is now urging me to finish it before Ramp Down Phase 1 :) I've rebased it upon the current version of jdk/hs: http://cr.openjdk.java.net/~simonis/webrevs/2017/8187280.v2/ Besides the usual directory shuffling because of the repo consolidation, the change is still the same. Can somebody please sponsor this? Thank you and best regards, Volker On Wed, Sep 6, 2017 at 10:06 PM, Vladimir Kozlov wrote: > Good > > Thanks > Vladimir > >> On Sep 6, 2017, at 10:31 AM, Volker Simonis wrote: >> >> On Wed, Sep 6, 2017 at 6:14 PM, Vladimir Kozlov >> wrote: >>> What about stub_code_begin and stub_code_end? >>> >> >> You're right! Removed them as well: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2017/8187280.v1/ >> >> Thanks, >> Volker >> >>> Thanks >>> Vladimir >>> >>> Sent from my iPhone >>> >>>> On Sep 6, 2017, at 7:02 AM, Volker Simonis wrote: >>>> >>>> Hi, >>>> >>>> can I please get a review and a sponsor for the following trivial change: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8187280/ >>>> https://bugs.openjdk.java.net/browse/JDK-8187280 >>>> >>>> >>>> While working on "8166317: InterpreterCodeSize should be computed" I >>>> found that several methods on StubQueue are not used any more in the >>>> current code base. As StubQueue's code is "more subtle than it looks" >>>> (see stubs.cpp) I think it helps to at least remove the unused parts >>>> :) >>>> >>>> Tested by doing a product/slowdebug build and running the hotspot >>>> regression tests. >>>> >>>> Thank you and best regards, >>>> Volker >>> > From kim.barrett at oracle.com Wed Nov 22 18:44:56 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 22 Nov 2017 13:44:56 -0500 Subject: RFR(XS): 8187280: Remove unused methods from StubQueue In-Reply-To: References: <63AB2BF3-F230-4A5E-963F-B9958FDA6F58@oracle.com> Message-ID: > On Nov 22, 2017, at 12:15 PM, Volker Simonis wrote: > > Hi, > > this somehow got lost and you boss is now urging me to finish it > before Ramp Down Phase 1 :) > > I've rebased it upon the current version of jdk/hs: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/8187280.v2/ > > Besides the usual directory shuffling because of the repo > consolidation, the change is still the same. > > Can somebody please sponsor this? No sign of these in closed code either. Looks good, and looks trivial. I can sponsor. From alexander.harlap at oracle.com Wed Nov 22 20:08:17 2017 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Wed, 22 Nov 2017 15:08:17 -0500 Subject: Request for review JDK-8185591 guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified In-Reply-To: <44E27962-F612-4DFF-800F-7CEB39D1A5C4@oracle.com> References: <706fbd26-7038-98de-d04e-d4158a94a00d@oracle.com> <1511339313.3392.12.camel@oracle.com> <44E27962-F612-4DFF-800F-7CEB39D1A5C4@oracle.com> Message-ID: <37fda1dc-44c9-e9a9-b391-07349b310cef@oracle.com> Thank you very much for looking into this issue. I follow Dean's advice to use cbz_32 for arm. New version of changes located at http://cr.openjdk.java.net/~aharlap/8185591/webrev.02/ Alex On 11/22/2017 11:31 AM, Kim Barrett wrote: >> On Nov 22, 2017, at 3:28 AM, Thomas Schatzl wrote: >> >> https://www.intel.com/content/dam/www/public/us/en/documents/manual >> s/64-ia-32-architectures-optimization-manual.pdf , 3-13 > Thanks for the cite. > > Change looks good. > From dean.long at oracle.com Wed Nov 22 22:45:11 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 22 Nov 2017 14:45:11 -0800 Subject: Request for review JDK-8185591 guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified In-Reply-To: <37fda1dc-44c9-e9a9-b391-07349b310cef@oracle.com> References: <706fbd26-7038-98de-d04e-d4158a94a00d@oracle.com> <1511339313.3392.12.camel@oracle.com> <44E27962-F612-4DFF-800F-7CEB39D1A5C4@oracle.com> <37fda1dc-44c9-e9a9-b391-07349b310cef@oracle.com> Message-ID: <4da2bc2d-546a-e569-6d50-46a51aafbc81@oracle.com> Looks good. dl On 11/22/17 12:08 PM, Alexander Harlap wrote: > Thank you very much for looking into this issue. > > I follow Dean's advice to use cbz_32 for arm. > > New version of changes located at > http://cr.openjdk.java.net/~aharlap/8185591/webrev.02/ > > Alex > > > > On 11/22/2017 11:31 AM, Kim Barrett wrote: >>> On Nov 22, 2017, at 3:28 AM, Thomas Schatzl >>> wrote: >>> >>> https://www.intel.com/content/dam/www/public/us/en/documents/manual >>> s/64-ia-32-architectures-optimization-manual.pdf , 3-13 >> Thanks for the cite. >> >> Change looks good. >> > From kim.barrett at oracle.com Wed Nov 22 22:50:34 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 22 Nov 2017 17:50:34 -0500 Subject: Request for review JDK-8185591 guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified In-Reply-To: <37fda1dc-44c9-e9a9-b391-07349b310cef@oracle.com> References: <706fbd26-7038-98de-d04e-d4158a94a00d@oracle.com> <1511339313.3392.12.camel@oracle.com> <44E27962-F612-4DFF-800F-7CEB39D1A5C4@oracle.com> <37fda1dc-44c9-e9a9-b391-07349b310cef@oracle.com> Message-ID: <5F6DB205-A249-443A-8F32-F97CCA6CB292@oracle.com> > On Nov 22, 2017, at 3:08 PM, Alexander Harlap wrote: > > Thank you very much for looking into this issue. > > I follow Dean's advice to use cbz_32 for arm. > > New version of changes located at http://cr.openjdk.java.net/~aharlap/8185591/webrev.02/ Still looks good. > > Alex > > > > On 11/22/2017 11:31 AM, Kim Barrett wrote: >>> On Nov 22, 2017, at 3:28 AM, Thomas Schatzl wrote: >>> >>> https://www.intel.com/content/dam/www/public/us/en/documents/manual >>> s/64-ia-32-architectures-optimization-manual.pdf , 3-13 >> Thanks for the cite. >> >> Change looks good. From volker.simonis at gmail.com Thu Nov 23 07:43:39 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Nov 2017 08:43:39 +0100 Subject: RFR(XS): 8187280: Remove unused methods from StubQueue In-Reply-To: References: <63AB2BF3-F230-4A5E-963F-B9958FDA6F58@oracle.com> Message-ID: Thanks, Kim! On Wed, Nov 22, 2017 at 7:44 PM, Kim Barrett wrote: >> On Nov 22, 2017, at 12:15 PM, Volker Simonis wrote: >> >> Hi, >> >> this somehow got lost and you boss is now urging me to finish it >> before Ramp Down Phase 1 :) >> >> I've rebased it upon the current version of jdk/hs: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2017/8187280.v2/ >> >> Besides the usual directory shuffling because of the repo >> consolidation, the change is still the same. >> >> Can somebody please sponsor this? > > No sign of these in closed code either. > > Looks good, and looks trivial. I can sponsor. > From glaubitz at physik.fu-berlin.de Thu Nov 23 10:21:55 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 23 Nov 2017 11:21:55 +0100 Subject: RFR: 8187227: Zero should use compiler built-ins for atomics on linux-m68k In-Reply-To: <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> Message-ID: Hi! On 11/21/2017 02:37 PM, John Paul Adrian Glaubitz wrote: > I have updated the webrev now accordingly and pushed it to [1]. > > The build and run-test is currently pending (still building), but since > libjvm.so already compiled successfully, I am 99% confident the change > is correct as is. Sorry for poking again, but could someone review the change? Thanks! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Thu Nov 23 11:16:17 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Nov 2017 11:16:17 +0000 Subject: RFR: 8187227: Zero should use compiler built-ins for atomics on linux-m68k In-Reply-To: References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> Message-ID: On 23/11/17 10:21, John Paul Adrian Glaubitz wrote: > Hi! > > On 11/21/2017 02:37 PM, John Paul Adrian Glaubitz wrote: >> I have updated the webrev now accordingly and pushed it to [1]. >> >> The build and run-test is currently pending (still building), but since >> libjvm.so already compiled successfully, I am 99% confident the change >> is correct as is. > > Sorry for poking again, but could someone review the change? Yes, that looks fine. I assume you're picking up the compiler builtin for 68k. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Nov 23 11:30:09 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Nov 2017 11:30:09 +0000 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes Message-ID: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> It was quite tricky to get this one right. Sime notes: I deleted LIR_Assembler::poll_for_safepoint because it's dead code. I set ThreadLocalHandshakes to true. This follows x86-64 and is probably the right thing to do, but it does have the disadvantage that it considerably extends the time to safepoint for interpreted code because we only poll at branches. I think this is probably a bad idea, but again it's the same as x86-64. OTOH, checking the safepoint bit at every bytecode would seriously bloat the interpreter. Oh dear. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Thu Nov 23 11:56:11 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Nov 2017 12:56:11 +0100 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? Message-ID: Hi Zhengyu and Andrew, Have you had any new ideas on how to deal with https://bugs.openjdk.java.net/browse/JDK-8187338? I also see this in my tests and I think this will be an issue with our customers. My thoughts are 1) as a first workaround to provide a threshold switch to change the small-chunk-limit - the number of bytes a class loader has to allocate from metaspace and classpace to qualify for medium sized chunks. With such a switch, one could at least tune a system which shows a pathological allocation pattern. E.g., using Zhengyu's new NMT per-classloader trace, if I see that the majority of all class loaders stop allocating after 500K, I'd set the threshold to 500K. 2) Future better solutions could involve some kind of self-regulating mechanism: Somehow automatically identifying which are "tiny" class loaders - loaders which have with a certain probability stopped allocoating while still gnawing at their first or second medium chunk. And then, using that number, dynamically adjusting the small-chunk-limit for future class loaders. (1) could be quite easily implemented. What do you think? Kind Regards, Thomas From glaubitz at physik.fu-berlin.de Thu Nov 23 12:12:47 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 23 Nov 2017 13:12:47 +0100 Subject: RFR: 8187227: Zero should use compiler built-ins for atomics on linux-m68k In-Reply-To: References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> Message-ID: <98b49b41-66c7-f384-f2a5-a5abc2cbd35e@physik.fu-berlin.de> On 11/23/2017 12:16 PM, Andrew Haley wrote: >> Sorry for poking again, but could someone review the change? > > Yes, that looks fine. I assume you're picking up the compiler builtin > for 68k. Yes, this is correct! I have also verified for the changes to work, so the m68k-specific code is definitely no longer needed in atomic_linux_zero.hpp anymore. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From claes.redestad at oracle.com Thu Nov 23 12:59:57 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 23 Nov 2017 13:59:57 +0100 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: References: Message-ID: Hi, while non-intrusive and easily attainable improvements to reduce class loader metadata is surely welcome, I think the high-level idea is to remove the overhead entirely? Isolated Methods, see draft JEP: https://bugs.openjdk.java.net/browse/JDK-8158765 Thanks! /Claes On 2017-11-23 12:56, Thomas St?fe wrote: > Hi Zhengyu and Andrew, > > Have you had any new ideas on how to deal with > https://bugs.openjdk.java.net/browse/JDK-8187338? > > I also see this in my tests and I think this will be an issue with our > customers. > > My thoughts are > > 1) as a first workaround to provide a threshold switch to change the > small-chunk-limit - the number of bytes a class loader has to allocate from > metaspace and classpace to qualify for medium sized chunks. With such a > switch, one could at least tune a system which shows a pathological > allocation pattern. E.g., using Zhengyu's new NMT per-classloader trace, if > I see that the majority of all class loaders stop allocating after 500K, > I'd set the threshold to 500K. > > 2) Future better solutions could involve some kind of self-regulating > mechanism: Somehow automatically identifying which are "tiny" class loaders > - loaders which have with a certain probability stopped allocoating while > still gnawing at their first or second medium chunk. And then, using that > number, dynamically adjusting the small-chunk-limit for future class > loaders. > > (1) could be quite easily implemented. What do you think? > > Kind Regards, Thomas From aph at redhat.com Thu Nov 23 13:05:41 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Nov 2017 13:05:41 +0000 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: References: Message-ID: <7d40153b-93b7-1c2e-77ed-fd250a6aabcf@redhat.com> On 23/11/17 12:59, Claes Redestad wrote: > while non-intrusive and easily attainable improvements to reduce class > loader metadata is surely welcome, I think the high-level idea is to > remove the overhead entirely? Isolated Methods, see draft JEP: > https://bugs.openjdk.java.net/browse/JDK-8158765 Mmm, but it's still very much worth reducing the overhead of class metadata, -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.x.ivanov at oracle.com Thu Nov 23 13:12:37 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 23 Nov 2017 16:12:37 +0300 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: References: Message-ID: <090e4c69-f24e-55b0-aeea-b0ade4bb616c@oracle.com> On 11/23/17 3:59 PM, Claes Redestad wrote: > Hi, > > while non-intrusive and easily attainable improvements to reduce class > loader metadata is surely welcome, I think the high-level idea is to > remove the overhead entirely? Isolated Methods, see draft JEP: > https://bugs.openjdk.java.net/browse/JDK-8158765 Just a note: though Isolated Methods cover most of the current use cases of VM anonymous classes, they aren't a complete replacement. For example, lambdas can't switch to isolated methods: there should be a class implementing functional interface to instantiate from. There are other VMAC replacement strategies (e.g., caching those classes on per-function interface & captured values base), but right now it affects performance. Best regards, Vladimir Ivanov > On 2017-11-23 12:56, Thomas St?fe wrote: >> Hi Zhengyu and Andrew, >> >> Have you had any new ideas on how to deal with >> https://bugs.openjdk.java.net/browse/JDK-8187338? >> >> I also see this in my tests and I think this will be an issue with our >> customers. >> >> My thoughts are >> >> 1) as a first workaround to provide a threshold switch to change the >> small-chunk-limit - the number of bytes a class loader has to allocate >> from >> metaspace and classpace to qualify for medium sized chunks. With such a >> switch, one could at least tune a system which shows a pathological >> allocation pattern. E.g., using Zhengyu's new NMT per-classloader >> trace, if >> I see that the majority of all class loaders stop allocating after 500K, >> I'd set the threshold to 500K. >> >> 2) Future better solutions could involve some kind of self-regulating >> mechanism: Somehow automatically identifying which are "tiny" class >> loaders >> - loaders which have with a certain probability stopped allocoating while >> still gnawing at their first or second medium chunk. And then, using that >> number, dynamically adjusting the small-chunk-limit for future class >> loaders. >> >> (1) could be quite easily implemented. What do you think? >> >> Kind Regards, Thomas > From robbin.ehn at oracle.com Thu Nov 23 13:38:45 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 23 Nov 2017 14:38:45 +0100 Subject: RFR: 8187227: Zero should use compiler built-ins for atomics on linux-m68k In-Reply-To: References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> Message-ID: Hi, a bit out of scope, mostly for Andrew. Not sure how old compiler you want to be use but __sync_XXX is 'legacy' since 4.7. So shouldn't we change to __atomic_XXX ? Manual vaguely says: "They should not be used for new code which should use the ?__atomic? builtins instead." /Robbin On 2017-11-23 12:16, Andrew Haley wrote: > On 23/11/17 10:21, John Paul Adrian Glaubitz wrote: >> Hi! >> >> On 11/21/2017 02:37 PM, John Paul Adrian Glaubitz wrote: >>> I have updated the webrev now accordingly and pushed it to [1]. >>> >>> The build and run-test is currently pending (still building), but since >>> libjvm.so already compiled successfully, I am 99% confident the change >>> is correct as is. >> >> Sorry for poking again, but could someone review the change? > > Yes, that looks fine. I assume you're picking up the compiler builtin > for 68k. > From glaubitz at physik.fu-berlin.de Thu Nov 23 14:01:18 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 23 Nov 2017 15:01:18 +0100 Subject: RFR: 8187227: Zero should use compiler built-ins for atomics on linux-m68k In-Reply-To: References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> Message-ID: <3c88004c-fb69-91b1-7ecf-c666793adcea@physik.fu-berlin.de> Hi Robbin! On 11/23/2017 02:38 PM, Robbin Ehn wrote: > Hi, a bit out of scope, mostly for Andrew. > > Not sure how old compiler you want to be use but __sync_XXX is 'legacy' since 4.7. > So shouldn't we change to __atomic_XXX ? Thanks for the heads-up! Do you have a link to the manual where this is mentioned? I just want to make sure the new functions are available on all targets supported by Zero and gcc. Also, since this particular changeset only removes the m68k-specific code, I don't think we should incorporate your suggested change in this changeset, but I guess it should be good to go after the ARM- and m68k-specific functions have been removed. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Thu Nov 23 14:12:08 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Nov 2017 14:12:08 +0000 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> Message-ID: <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> On 23/11/17 11:30, Andrew Haley wrote: > It was quite tricky to get this one right. > > Some notes: > > I deleted LIR_Assembler::poll_for_safepoint because it's dead code. > > I set ThreadLocalHandshakes to true. This follows x86-64 and is > probably the right thing to do, but it does have the disadvantage that > it considerably extends the time to safepoint for interpreted code > because we only poll at branches. I think this is probably a bad > idea, but again it's the same as x86-64. OTOH, checking the safepoint > bit at every bytecode would seriously bloat the interpreter. Oh dear. > http://cr.openjdk.java.net/~aph/8189596-1/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Nov 23 14:15:33 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Nov 2017 14:15:33 +0000 Subject: RFR: 8187227: Zero should use compiler built-ins for atomics on linux-m68k In-Reply-To: <3c88004c-fb69-91b1-7ecf-c666793adcea@physik.fu-berlin.de> References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> <3c88004c-fb69-91b1-7ecf-c666793adcea@physik.fu-berlin.de> Message-ID: On 23/11/17 14:01, John Paul Adrian Glaubitz wrote: > Hi Robbin! > > On 11/23/2017 02:38 PM, Robbin Ehn wrote: >> Hi, a bit out of scope, mostly for Andrew. >> >> Not sure how old compiler you want to be use but __sync_XXX is 'legacy' since 4.7. >> So shouldn't we change to __atomic_XXX ? No. There's no need, and the __atomic builtins aren't quite as convenient to use. There's certainly no reason to change at this point. > Also, since this particular changeset only removes the m68k-specific code, > I don't think we should incorporate your suggested change in this changeset, > but I guess it should be good to go after the ARM- and m68k-specific functions > have been removed. Take care: it's not absolutely guaranteed that the GCC builtins are correct for HotSpot. Don't change anything that isn't broken. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Thu Nov 23 14:19:24 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 23 Nov 2017 15:19:24 +0100 Subject: RFR: 8187227: Zero should use compiler built-ins for atomics on linux-m68k In-Reply-To: References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> <3c88004c-fb69-91b1-7ecf-c666793adcea@physik.fu-berlin.de> Message-ID: On 11/23/2017 03:15 PM, Andrew Haley wrote: > Take care: it's not absolutely guaranteed that the GCC builtins are > correct for HotSpot. Don't change anything that isn't broken. I have tested them, both for m68k and ARMv4T, and both work fine. Also, looking at what gcc does for ARM: > https://github.com/gcc-mirror/gcc/blob/1cb6c2eb3b8361d850be8e8270c597270a1a7967/libgcc/config/arm/linux-atomic.c#L27 and what OpenJDK does for ARM: > http://hg.openjdk.java.net/jdk/hs/file/ab188c22d4b6/src/hotspot/os_cpu/linux_zero/atomic_linux_zero.hpp#l101 it seems both code is identical as both call the kernel helper for cmpxchg from the VDSO. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Thu Nov 23 14:22:34 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Nov 2017 14:22:34 +0000 Subject: RFR: 8187227: Zero should use compiler built-ins for atomics on linux-m68k In-Reply-To: References: <1a8fd964-9ed6-3805-c266-f4011fb21469@physik.fu-berlin.de> <95455e8c-b9dd-0c76-bc70-5df8a80a0997@oracle.com> <881d872c-591b-2e24-f567-f497e5c40a11@redhat.com> <837e0d3d-d8d8-0850-cbee-df318c54fa60@physik.fu-berlin.de> <498f6deb-6292-6c16-ed7f-6ce482681abe@oracle.com> <617978bb-fe2c-2dff-e71f-1ec3248b40bd@redhat.com> <64330224-086a-8257-2303-f375a8aaf637@redhat.com> <05e1922e-62b0-bd72-2434-21f5536ef5c6@physik.fu-berlin.de> <4a1b1b5b-d267-ceeb-8a5e-06be7230441e@physik.fu-berlin.de> <3c88004c-fb69-91b1-7ecf-c666793adcea@physik.fu-berlin.de> Message-ID: On 23/11/17 14:19, John Paul Adrian Glaubitz wrote: > Also, looking at what gcc does for ARM: > >> https://github.com/gcc-mirror/gcc/blob/1cb6c2eb3b8361d850be8e8270c597270a1a7967/libgcc/config/arm/linux-atomic.c#L27 > and what OpenJDK does for ARM: > >> http://hg.openjdk.java.net/jdk/hs/file/ab188c22d4b6/src/hotspot/os_cpu/linux_zero/atomic_linux_zero.hpp#l101 > it seems both code is identical as both call the kernel helper > for cmpxchg from the VDSO. Yeah. I wrote that one, I think. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Thu Nov 23 14:40:49 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Nov 2017 15:40:49 +0100 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: <7d40153b-93b7-1c2e-77ed-fd250a6aabcf@redhat.com> References: <7d40153b-93b7-1c2e-77ed-fd250a6aabcf@redhat.com> Message-ID: On Thu, Nov 23, 2017 at 2:05 PM, Andrew Haley wrote: > On 23/11/17 12:59, Claes Redestad wrote: > > while non-intrusive and easily attainable improvements to reduce class > > loader metadata is surely welcome, I think the high-level idea is to > > remove the overhead entirely Isolated Methods, see draft JEP: > > https://bugs.openjdk.java.net/browse/JDK-8158765 > > Mmm, but it's still very much worth reducing the overhead of > class metadata, > > I agree. E.g. in Osgi context, we see many small class loaders. Metaspace currently does not play well with many small class loaders. Wwe are also interested in metaspace improvements which can be downported to older releases without too much hassle. I am currently working on a prototype for this thing: https://bugs.openjdk. java.net/browse/JDK-8166690. Basically, a patch to make free metaspace chunks split and merge on demand to improve chance of them being reused. This helps in situations where we have many tiny short lived class loaders flooding the free list with small chunks upon dying. Those chunks currently are locked in into their size and cannot be reused in any other form. This especially hurts in class metaspace, because there we never release the one VirtualSpaceNode we have. JDK-8187338 is a different waste scenario. But both scenarios are worth fixing, ihmo. Thanks, Thomas -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From forax at univ-mlv.fr Thu Nov 23 16:08:37 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 23 Nov 2017 16:08:37 +0000 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: <090e4c69-f24e-55b0-aeea-b0ade4bb616c@oracle.com> References: <090e4c69-f24e-55b0-aeea-b0ade4bb616c@oracle.com> Message-ID: <42D9CF7C-B4D6-40EA-9F5A-B01452549F08@univ-mlv.fr> On November 23, 2017 2:12:37 PM GMT+01:00, Vladimir Ivanov wrote: > > >On 11/23/17 3:59 PM, Claes Redestad wrote: >> Hi, >> >> while non-intrusive and easily attainable improvements to reduce >class >> loader metadata is surely welcome, I think the high-level idea is to >> remove the overhead entirely? Isolated Methods, see draft JEP: >> https://bugs.openjdk.java.net/browse/JDK-8158765 > >Just a note: though Isolated Methods cover most of the current use >cases >of VM anonymous classes, they aren't a complete replacement. > >For example, lambdas can't switch to isolated methods: there should be >a >class implementing functional interface to instantiate from. There are >other VMAC replacement strategies (e.g., caching those classes on >per-function interface & captured values base), but right now it >affects >performance. is it still affect perf ? I think a guy from elastic search mention that they use method handles in their proxy class with no perf issue. We may also be able to create parameterized class with a method handle hole as part of Valhalla. > >Best regards, >Vladimir Ivanov regards, R?mi > >> On 2017-11-23 12:56, Thomas St?fe wrote: >>> Hi Zhengyu and Andrew, >>> >>> Have you had any new ideas on how to deal with >>> https://bugs.openjdk.java.net/browse/JDK-8187338? >>> >>> I also see this in my tests and I think this will be an issue with >our >>> customers. >>> >>> My thoughts are >>> >>> 1) as a first workaround to provide a threshold switch to change the >>> small-chunk-limit - the number of bytes a class loader has to >allocate >>> from >>> metaspace and classpace to qualify for medium sized chunks. With >such a >>> switch, one could at least tune a system which shows a pathological >>> allocation pattern. E.g., using Zhengyu's new NMT per-classloader >>> trace, if >>> I see that the majority of all class loaders stop allocating after >500K, >>> I'd set the threshold to 500K. >>> >>> 2) Future better solutions could involve some kind of >self-regulating >>> mechanism: Somehow automatically identifying which are "tiny" class >>> loaders >>> - loaders which have with a certain probability stopped allocoating >while >>> still gnawing at their first or second medium chunk. And then, using >that >>> number, dynamically adjusting the small-chunk-limit for future class >>> loaders. >>> >>> (1) could be quite easily implemented. What do you think? >>> >>> Kind Regards, Thomas >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From adinn at redhat.com Thu Nov 23 16:15:07 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 23 Nov 2017 16:15:07 +0000 Subject: [aarch64-port-dev ] RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> Message-ID: <8121f844-a156-ef1e-fa5f-a30774f1776b@redhat.com> On 23/11/17 14:12, Andrew Haley wrote: > On 23/11/17 11:30, Andrew Haley wrote: >> It was quite tricky to get this one right. >> >> Some notes: >> >> I deleted LIR_Assembler::poll_for_safepoint because it's dead code. >> >> I set ThreadLocalHandshakes to true. This follows x86-64 and is >> probably the right thing to do, but it does have the disadvantage that >> it considerably extends the time to safepoint for interpreted code >> because we only poll at branches. I think this is probably a bad >> idea, but again it's the same as x86-64. OTOH, checking the safepoint >> bit at every bytecode would seriously bloat the interpreter. Oh dear. >> > > http://cr.openjdk.java.net/~aph/8189596-1/ I have reviewed this by eyeball and it all looks good. I still need to build and run to be 100% sure. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Thu Nov 23 16:50:00 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 23 Nov 2017 16:50:00 +0000 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: References: Message-ID: On 23/11/17 11:56, Thomas St?fe wrote: > Hi Zhengyu and Andrew, > > Have you had any new ideas on how to deal > with?https://bugs.openjdk.java.net/browse/JDK-8187338? Zhengyu developed a prototype patch against jdk8u which extends the time an anonymous loader is willing to hand out SpecializedChunks after the initial one is exhausted (it will use up to 4 1K chunks before scaling up to a 4K chunk). In his tests this brought the average waste down from ~60%$ to ~30%. This will be a help for lambdas but in the long term I guess the real solution needs to be a solution like the one in M Cimadamore's JEP (JDK-8158765). I have already reviewed this patch privately and found it to be ok. I'll leave Zhengyu to reply as to whether he thinks it is ready to push to jdk10 and/or down to jdk8. > My thoughts are > . . . > (1) could be quite easily implemented. What do you think? Well, I guess option (1) might be useful for apps which have a lot of normal (non-anon) classloaders that define only small numbers of classes. However, the really bad waste %ges we saw with anon loaders were because they had just one class and so always had one partial chunk. That left a high potential for waste to be in the ~50% range (well, actually, it was two partial chunks with CompressedClassPointers -- one for the class object and one for the related non-class objects). If you have enough classes to start biting into a 2nd chunk (i.e just 2-3) then your waste is going to be in the 0-50% range. 3 Chunks puts it in the 0-34% range. So, 'small' loaders is not quite such an issue as 1-shot 'anon' loaders. That said, I think (1) could still be helpful for some (unusual?) apps. I don't think it is too difficult to implement or as you say to come up with a workable default -- the hardest bit will probably be getting the new product flag accepted. Zhengyu may have something to say here as well? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Thu Nov 23 16:58:07 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Nov 2017 16:58:07 +0000 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: References: Message-ID: On 23/11/17 16:50, Andrew Dinn wrote: > I have already reviewed this patch privately and found it to be ok. I'll > leave Zhengyu to reply as to whether he thinks it is ready to push to > jdk10 and/or down to jdk8. Whatever happens, it needs to be made public in some form. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Thu Nov 23 17:15:35 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 23 Nov 2017 17:15:35 +0000 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: References: Message-ID: <9ebd2a88-1c9c-d004-8889-5501ec1b5b5d@redhat.com> On 23/11/17 16:58, Andrew Haley wrote: > On 23/11/17 16:50, Andrew Dinn wrote: >> I have already reviewed this patch privately and found it to be ok. I'll >> leave Zhengyu to reply as to whether he thinks it is ready to push to >> jdk10 and/or down to jdk8. > > Whatever happens, it needs to be made public in some form. Sure. I think the delay is simply a marshalling issue because Zhengyu has a few changes lined up. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vladimir.x.ivanov at oracle.com Thu Nov 23 17:24:33 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 23 Nov 2017 20:24:33 +0300 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: <42D9CF7C-B4D6-40EA-9F5A-B01452549F08@univ-mlv.fr> References: <090e4c69-f24e-55b0-aeea-b0ade4bb616c@oracle.com> <42D9CF7C-B4D6-40EA-9F5A-B01452549F08@univ-mlv.fr> Message-ID: <0b6389f4-5c78-6357-2997-b61c79a7a0be@oracle.com> >> For example, lambdas can't switch to isolated methods: there should be >> a >> class implementing functional interface to instantiate from. There are >> other VMAC replacement strategies (e.g., caching those classes on >> per-function interface & captured values base), but right now it >> affects >> performance. > > is it still affect perf ? I think a guy from elastic search mention that they use method handles in their proxy class with no perf issue. I don't remember what exactly elastic search did, but yes, it does (due to type profiling pollution). Current scheme produces a class-per-lambda and profile info allows to disambiguate lambda body. In case lambda body is represented as a method handle and stored is a field (class-per-shape), type profile becomes useless. (There's another problem - constant folding loads from final fields - but it's quite easy to fix inside jdk by marking corresponding classes as trusted.) > We may also be able to create parameterized class with a method handle hole as part of Valhalla. Interesting. A class parameterized by a method handle instance? JVM support for reified dependent types? :-) Best regards, Vladimir Ivanov >>> On 2017-11-23 12:56, Thomas St?fe wrote: >>>> Hi Zhengyu and Andrew, >>>> >>>> Have you had any new ideas on how to deal with >>>> https://bugs.openjdk.java.net/browse/JDK-8187338? >>>> >>>> I also see this in my tests and I think this will be an issue with >> our >>>> customers. >>>> >>>> My thoughts are >>>> >>>> 1) as a first workaround to provide a threshold switch to change the >>>> small-chunk-limit - the number of bytes a class loader has to >> allocate >>>> from >>>> metaspace and classpace to qualify for medium sized chunks. With >> such a >>>> switch, one could at least tune a system which shows a pathological >>>> allocation pattern. E.g., using Zhengyu's new NMT per-classloader >>>> trace, if >>>> I see that the majority of all class loaders stop allocating after >> 500K, >>>> I'd set the threshold to 500K. >>>> >>>> 2) Future better solutions could involve some kind of >> self-regulating >>>> mechanism: Somehow automatically identifying which are "tiny" class >>>> loaders >>>> - loaders which have with a certain probability stopped allocoating >> while >>>> still gnawing at their first or second medium chunk. And then, using >> that >>>> number, dynamically adjusting the small-chunk-limit for future class >>>> loaders. >>>> >>>> (1) could be quite easily implemented. What do you think? >>>> >>>> Kind Regards, Thomas >>> > From kim.barrett at oracle.com Thu Nov 23 20:23:19 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Nov 2017 15:23:19 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <1b967127-668e-f57d-2992-7680bb924396@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> <5A14525D.4030006@oracle.com> <1b967127-668e-f57d-2992-7680bb924396@oracle.com> Message-ID: > On Nov 21, 2017, at 2:50 PM, Erik ?sterlund wrote: > > Hi Kim, > > > On 2017-11-21 19:48, Kim Barrett wrote: >>> On Nov 21, 2017, at 11:20 AM, Erik ?sterlund wrote: >>> >>> Hi Kim, >>> >>> I am merely more precisely annotating that unsafe accesses on oops have explicitly unknown oop ref strength. However, the GC backends do not do more about it than they did before. I.e. only G1 loads check the actual reference strength and act accordingly (as before), and other exotic accesses are treated the same in the backends (as before) since their pre-write barriers are enough anyway. The behaviour is the same before and after. >> For the operations in question, there were no checks for reference >> strength before, not even for G1. So the behavior is not the same >> before and after the Access changes. >> >> Unsafe_CompareAndExchangeObject on a referent was effectively UB. I >> don't think adding the special handling for referents makes it any >> less UB; it's still an abuse of Unsafe to break invariants. In which >> case, any potential additional work that might be done to handle that >> specific case is not just pointless, but actively harmful. > > For the operations in question, there were no checks for reference strength before or after. The unsafe.cpp file annotates that this is an unknown oop ref, the backends don't check for it or care. Seems very much the same to me. Am I missing something? Apparently not. I was sure I saw a call to resolve_possibly_unknown_oop_ref_strength in the relevant code path. That seems to have been a mirage. Sorry for the noise. However, while re-exploring that code path, I did notice something that bothered me. ModRefBarrierSet::AccessBarrier<...>::oop_atomic_cmpxchg_in_heap bs->template write_ref_field_pre(addr); oop result = Raw::oop_atomic_cmpxchg(...); if (result == compare_value) { bs->template write_ref_field_post(...); } return result; does an extra load for G1, to apply the pre-barrier. The old code applied the pre-barrier to the result obtained from the raw cmpxchg. From thomas.stuefe at gmail.com Thu Nov 23 20:43:15 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Nov 2017 21:43:15 +0100 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: References: Message-ID: On Thu, Nov 23, 2017 at 5:50 PM, Andrew Dinn wrote: > On 23/11/17 11:56, Thomas St?fe wrote: > > Hi Zhengyu and Andrew, > > > > Have you had any new ideas on how to deal > > with https://bugs.openjdk.java.net/browse/JDK-8187338? > > Zhengyu developed a prototype patch against jdk8u which extends the time > an anonymous loader is willing to hand out SpecializedChunks after the > initial one is exhausted (it will use up to 4 1K chunks before scaling > up to a 4K chunk). In his tests this brought the average waste down from > ~60%$ to ~30%. This will be a help for lambdas but in the long term I > guess the real solution needs to be a solution like the one in M > Cimadamore's JEP (JDK-8158765). > > I have already reviewed this patch privately and found it to be ok. I'll > leave Zhengyu to reply as to whether he thinks it is ready to push to > jdk10 and/or down to jdk8. > > > My thoughts are > > . . . > > (1) could be quite easily implemented. What do you think? > Well, I guess option (1) might be useful for apps which have a lot of > normal (non-anon) classloaders that define only small numbers of > classes. However, the really bad waste %ges we saw with anon loaders > were because they had just one class and so always had one partial > chunk. That left a high potential for waste to be in the ~50% range > (well, actually, it was two partial chunks with CompressedClassPointers > -- one for the class object and one for the related non-class objects). > If you have enough classes to start biting into a 2nd chunk (i.e just > 2-3) then your waste is going to be in the 0-50% range. 3 Chunks puts it > in the 0-34% range. So, 'small' loaders is not quite such an issue as > 1-shot 'anon' loaders. > > That said, I think (1) could still be helpful for some (unusual?) apps. > I don't think it is too difficult to implement or as you say to come up > with a workable default -- the hardest bit will probably be getting the > new product flag accepted. Zhengyu may have something to say here as well? > > regards, > > > Sounds reasonable. Trying to understand: you estimate that the "half-eaten-medium-chunk" problem is only really a bad problem for anonymous class loaders, because they only ever load one class, yes? Which is known beforehand, and we do not have to guess at their future loading behaviour, which is 0? Well, this sounds both simpler and more to the point than my proposal (2). How did Zhengyu arrive at the 4K limit? Why not just always use SpecializedChunks for anon class loaders? ..Thomas > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > > From erik.osterlund at oracle.com Fri Nov 24 09:17:13 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 24 Nov 2017 10:17:13 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> <5A14525D.4030006@oracle.com> <1b967127-668e-f57d-2992-7680bb924396@oracle.com> Message-ID: <5A17E399.5080201@oracle.com> Hi Kim, On 2017-11-23 21:23, Kim Barrett wrote: >> On Nov 21, 2017, at 2:50 PM, Erik ?sterlund wrote: >> >> Hi Kim, >> >> >> On 2017-11-21 19:48, Kim Barrett wrote: >>>> On Nov 21, 2017, at 11:20 AM, Erik ?sterlund wrote: >>>> >>>> Hi Kim, >>>> >>>> I am merely more precisely annotating that unsafe accesses on oops have explicitly unknown oop ref strength. However, the GC backends do not do more about it than they did before. I.e. only G1 loads check the actual reference strength and act accordingly (as before), and other exotic accesses are treated the same in the backends (as before) since their pre-write barriers are enough anyway. The behaviour is the same before and after. >>> For the operations in question, there were no checks for reference >>> strength before, not even for G1. So the behavior is not the same >>> before and after the Access changes. >>> >>> Unsafe_CompareAndExchangeObject on a referent was effectively UB. I >>> don't think adding the special handling for referents makes it any >>> less UB; it's still an abuse of Unsafe to break invariants. In which >>> case, any potential additional work that might be done to handle that >>> specific case is not just pointless, but actively harmful. >> For the operations in question, there were no checks for reference strength before or after. The unsafe.cpp file annotates that this is an unknown oop ref, the backends don't check for it or care. Seems very much the same to me. Am I missing something? > Apparently not. I was sure I saw a call to > resolve_possibly_unknown_oop_ref_strength in the relevant code path. > That seems to have been a mirage. Sorry for the noise. No problem. I am glad we agree on this point. > However, while re-exploring that code path, I did notice something > that bothered me. > > ModRefBarrierSet::AccessBarrier<...>::oop_atomic_cmpxchg_in_heap > bs->template write_ref_field_pre(addr); > oop result = Raw::oop_atomic_cmpxchg(...); > if (result == compare_value) { > bs->template write_ref_field_post(...); > } > return result; > > does an extra load for G1, to apply the pre-barrier. The old code > applied the pre-barrier to the result obtained from the raw cmpxchg. In my Access API, I want the notion of pre and post write barriers introduced on ModRef level to be respected as just that - pre and post write barriers. Previous code assumed that pre-write barrier really has nothing to do with whether it comes before or after the write - instead it was assumed that a pre-write barrier is equivalent to the SATB barrier, to the extent that in some places the pre-write barrier is used as an implementation for Reference.get for G1 (a weak load!), because it happens to be a SATB barrier and has nothing to do with happening before a write. So to on the ModRef level assume that pre-write barriers can be performed *after* the write, because we know it is an SATB barrier, is an abstraction crime. That is why I apply it before the write instead like we do for stores - because it is a pre-write barrier (and if it wasn't expensive in the context of a store, I see no point in optimizing it in the context of an atomic CAS). If a specific GC wants to apply it after as a micro optimization, then they should override the ModRef implementation for their CAS to do that. To apply the pre-write barrier *after* the write for CAS specifically, is an optimization to get rid of a relaxed load from a conservatively fenced atomic operation, in a cold runtime path. That seemed like not a good idea to micro optimize and violate abstractions for to me. If we really want to optimize that code path, I see more point in applying the xor shift filter to not perform the expensive StoreLoad fence and card fiddling for writes within the same old region in the runtime path of the post-write barrier, as we do in compiled code. I hope you agree that performing the pre-write barrier as a post-write barrier for the rather chilly runtime CAS is a bad idea and not an optimization that is worth it. Thanks, /Erik From adinn at redhat.com Fri Nov 24 09:18:06 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 24 Nov 2017 09:18:06 +0000 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: References: Message-ID: <0ebd16bb-1330-600b-1dc8-f4a53db8638b@redhat.com> On 23/11/17 20:43, Thomas St?fe wrote: > Sounds reasonable. Trying to understand: you estimate that the > "half-eaten-medium-chunk"? > problem is only really a bad problem for anonymous class loaders, > because they only ever load > one class, yes? Which is known beforehand, and we do not have to guess > at their future > loading behaviour, which is 0? > > Well, this sounds both simpler and more to the point than my proposal (2). Not quite. We know that the "half-eaten-medium-chunk" problem is really a bad problem for anonymous class loaders and Zhengyu's patch improves that case. We don't know it is that is the only problem case. Other loaders may only load a small number of classes -- perhaps 1, maybe 2 -- and also end up wasting a lot of space. If an app hits that case a lot then your proposal would allow the user to configure round it. > How did Zhengyu arrive at the 4K limit? Why not just always use > SpecializedChunks for > ?anon class loaders? The limit was found by experiment -- measuring chunk usage/wastage as various different lambdas were loaded. Handing out up to 4 SpecializedChunks looked like it would cover most cases. Why not just stick with SpecializedChunks? Well, some lambdas are 'bigger' than others. Also, anon loaders have been used for other cases in the past and might be so used in the future. So, it is possible that anon loaders might be used in situations where more than 4K (4 * 1K) is needed. Zhengyu's patch moves up to using a 4K chunk in two cases i) an allocation size is too big for a 1K chunk ii) more than 4 1K chunks have been used. Case i is necessary. Case ii seems like a hedge against what might really be needed. Both are probably going to be uncommon for now at least. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Fri Nov 24 09:29:51 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 24 Nov 2017 09:29:51 +0000 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: <0ebd16bb-1330-600b-1dc8-f4a53db8638b@redhat.com> References: <0ebd16bb-1330-600b-1dc8-f4a53db8638b@redhat.com> Message-ID: One small additional comment: On 24/11/17 09:18, Andrew Dinn wrote: > On 23/11/17 20:43, Thomas St?fe wrote: >> ... >> Well, this sounds both simpler and more to the point than my proposal (2). > > Not quite. We know that the "half-eaten-medium-chunk" problem is really > a bad problem for anonymous class loaders and Zhengyu's patch improves > that case. We don't know it is that is the only problem case. Other > loaders may only load a small number of classes -- perhaps 1, maybe 2 -- > and also end up wasting a lot of space. If an app hits that case a lot > then your proposal would allow the user to configure round it. n.b. I'm not sure we need to worry much about any such apps as this scenario is, arguably, very unlikely? I know, for example, that JBoss Modules uses many classloaders but they rarely load just one or two classes. Once you get to 3 or 4 classes I think the current behaviour will be unlikely to increase waste because larger chunks means less fragmentation. Are OSGi loaders likely to load just one or two classes for a significant number of loaders? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From erik.osterlund at oracle.com Fri Nov 24 10:36:59 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 24 Nov 2017 11:36:59 +0100 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> Message-ID: <5A17F64B.3000101@oracle.com> Hi Andrew, I am glad to see you also support the move to use Thread-local handshakes. Thank you for that. I think your approach looks good. However, there is a certain race that I believe you are currently vulnerable to that could cause trouble for you. So I thought I'd point it out. Specifically, when transitioning from native back to Java, there is a peculiar race condition on your platform unless more synchronization is applied. I would recommend loading the thread-local poll value when waking up from native with ldar instead to avoid subsequent checks for is_at_safepoint() on the thread waking up from native to provide the wrong result, which could cause MutexLockerEx that is conditionally taken only if we are not in a safepoint to hit the wrong path and not be taken as it still thinks you are in a safepoint. The race is due to an interaction between the wake-up path of the native wrapper and the safepoint unsynchronizing path. When SafepointSynchronize::end() starts, all JavaThreads except the ones in native and in blocked are blocked. Specifically there exists a race with the native wrapper trying to wake up from native while the SafepointSynchronizer is waking up from a safepoint. The SafepointSynchronize::end() will conceptually perform the following important steps: VM.1) SafepointSynchronize::_state = _not_synchronized VM.2) For each thread: disarm local poll Your native wrapper wakeup path filters slow paths on the local poll (without acquire() or loadload()), but no longer the global _state value. So a JavaThread waking up from native could do: JT.1) load local poll (with plain ldr), check if it is armed (it is not, because it observes the store from VM.1) JT.2) release_store the thread state to Java with stlr JT.3) enter arbitrary Java code JT.4) make leaf call to the runtime from Java without thread transition JT.5) Check if in a safepoint by loading SafepointSynchronize::_state At JT.5, it is not guaranteed that the load observes the updated _not_synchronized value written in VM.1 (because the load in JT.1 and JT.5 may reorder). In this scenario the check to see whether you are in a safepoint might if very unlucky return true spuriously. From then on, bad things can happen. By placing loading the local poll value with ldar *only* in the native wrapper wakeup function, you avoid these issues. Another approach you may elect to use is to only in the native wrapper load both the thread-local poll value and the SafepointSynchronize::_state, when filtering slow paths to avoid this unfortunate race. I have a bunch of other ideas as well exploiting dependent loads, but thought maybe I should start the conversation and see what you think before running off too much. Again, very happy to see this move to use thread-local handshakes. Thanks for doing this. Thanks, /Erik On 2017-11-23 15:12, Andrew Haley wrote: > On 23/11/17 11:30, Andrew Haley wrote: >> It was quite tricky to get this one right. >> >> Some notes: >> >> I deleted LIR_Assembler::poll_for_safepoint because it's dead code. >> >> I set ThreadLocalHandshakes to true. This follows x86-64 and is >> probably the right thing to do, but it does have the disadvantage that >> it considerably extends the time to safepoint for interpreted code >> because we only poll at branches. I think this is probably a bad >> idea, but again it's the same as x86-64. OTOH, checking the safepoint >> bit at every bytecode would seriously bloat the interpreter. Oh dear. >> > http://cr.openjdk.java.net/~aph/8189596-1/ > From glaubitz at physik.fu-berlin.de Fri Nov 24 11:32:09 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 24 Nov 2017 12:32:09 +0100 Subject: RFR: 8186461: Zero's atomic_copy64() should use SPE instructions on linux-powerpcspe Message-ID: <13ec6e9f-d944-59b8-be06-207268bb5c25@physik.fu-berlin.de> Hello! Zero's atomic_copy64() uses inline-assembly on PPC32 to implement an atomic load and store using FPU instructions. While this works fine on most 32-bit PowerPC systems, there are some PPC systems, most notably PowerPC e500 [1] which don't come with an FPU but rather a special processing unit called "SPE" (not to be confused with the SPEs of the IBM Cell architecture). Thus, the current implementation of atomic_copy64() will not build on PowerPC e500 systems. This issue was already discussed in 2010 but the proposed change was never merged [2]. While I think the 2010 approach was clever, I have decided to prefer the more explicit solution and not rely on the compiler generating the code we want, hence the use of evldd and evstdd. For reference of these instructions, see [3], page 184 and [4]. The changeset for review can be found in [5]. Thanks, Adrian > [1] https://en.wikipedia.org/wiki/PowerPC_e500 > [2] http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-June/001870.html > [3] https://www.nxp.com/docs/en/reference-manual/E500CORERM.pdf > [4] https://shipilev.net/blog/2014/all-accesses-are-atomic/ > [5] http://cr.openjdk.java.net/~glaubitz/8186461/webrev.01/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From adinn at redhat.com Fri Nov 24 12:07:01 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 24 Nov 2017 12:07:01 +0000 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <5A17F64B.3000101@oracle.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> Message-ID: <0ebb3f3e-a6f7-38ac-03a6-12cde24234a1@redhat.com> On 24/11/17 10:36, Erik ?sterlund wrote: > By placing loading the local poll value with ldar *only* in the native > wrapper wakeup function, you avoid these issues. > Another approach you may elect to use is to only in the native wrapper > load both the thread-local poll value and the > SafepointSynchronize::_state, when filtering slow paths to avoid this > unfortunate race. I can see why an ldar (actually ldarw) is needed when safepoint_poll is called from the nativewrapper. Can you explain why ldar is not needed for *all* calls to safepoint_poll? > I have a bunch of other ideas as well exploiting dependent loads, but > thought maybe I should start the conversation and see what you think > before running off too much regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From stefan.karlsson at oracle.com Fri Nov 24 13:02:18 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 24 Nov 2017 14:02:18 +0100 Subject: RFR: 8191858: Add missing includes in memoryManager.hpp Message-ID: <11d07932-85e8-fc41-4db9-c54f0b518322@oracle.com> Hi all, Please review this trivial patch to add some missing includes to memoryManager.hpp. http://cr.openjdk.java.net/~stefank/8191858/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8191858 This was found when I was restructuring other parts of the code base. Thanks, StefanK From stefan.karlsson at oracle.com Fri Nov 24 13:21:23 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 24 Nov 2017 14:21:23 +0100 Subject: RFR: 8191860: Add perfData.inline.hpp Message-ID: Hi all, Please review this patch to create a perfData.inline.hpp file and move inline functions in perfData.hpp that depend on functions in other .inline.hpp files. http://cr.openjdk.java.net/~stefank/8191860/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8191860 Note 1: I consider growableArray.hpp to be an .inline.hpp in disguise, since it includes allocation.inline.hpp. Note 2: Some .hpp files that used to include perfData.hpp now explicitly includes allocation.inline.hpp. We should deal with that, but in another RFE. thanks, StefanK From erik.osterlund at oracle.com Fri Nov 24 13:36:22 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 24 Nov 2017 14:36:22 +0100 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <0ebb3f3e-a6f7-38ac-03a6-12cde24234a1@redhat.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> <0ebb3f3e-a6f7-38ac-03a6-12cde24234a1@redhat.com> Message-ID: <5A182056.9000009@oracle.com> Hi Andrew, On 2017-11-24 13:07, Andrew Dinn wrote: > On 24/11/17 10:36, Erik ?sterlund wrote: >> By placing loading the local poll value with ldar *only* in the native >> wrapper wakeup function, you avoid these issues. >> Another approach you may elect to use is to only in the native wrapper >> load both the thread-local poll value and the >> SafepointSynchronize::_state, when filtering slow paths to avoid this >> unfortunate race. > I can see why an ldar (actually ldarw) is needed when safepoint_poll is > called from the nativewrapper. Can you explain why ldar is not needed > for *all* calls to safepoint_poll? That is a long story. :) But since you asked, here we go... First we need to recognize that the following previous polls (with different contexts): 1) Poll in JIT-compiled code (poll against the global page) 2) Poll in the VM for thread transitions 3) Poll in the interpreter (safepoint table) 4) Poll in the native wrapper ...have been replaced with polls reading the thread-local state. But they have different races they are concerned with. Previously, the global _state, the safepoint table, and polling page, have all been manipulated in different places in SafepointSynchronize::begin/end, causing interesting interactions now that it is replaced with one poll. When we synchronize a safepoint, we have a fast-path poll on the local poll, but if it is indeed armed, we *have* to use acquire before loading the global state to check if we need to block or not. If the local poll is disarmed on the other hand, then there is no harm with races with synchronization of a safepoint. The lack of acquire can cause a stale load of the global state. But the possible stale values when racing with the synchronization is that you observe _not_synchronized instead of _synchronizing, which is already racy and fine. So the race with synchronization comes with the constraint that if the local poll is armed, we have to acquire before reading the global state. When we unsynchronize the safepoint, on the other hand, we are in a much more dangerous situation. Unsynchronization races with transitions from dormant states (blocked and native) to active states (Java and VM). During the dormant to active transitions, reading a stale value of the _state from SafepointSynchronize::end() is a disaster, because now a stale load may observe _synchronized instead of !_synchronized values. This must be prevented (to not get false positives on the query is_at_safepoint()) by either a) making the load of the local poll use acquire unconditionally (making sure subsequent loads of the _state are not stale), or check both the local poll and global _state to make sure you simply do not wake up when the stale state is observed to be _synchronized. So looking back at the scenarios we have replaced in order: 1) The JIT-compiled code races with SafepointSynchronize::begin(), not end(), and hence only has the requirement that acquire() is conditionally used before reading an armed poll value and checking if the global _state is _synchronizing. 2) In the VM, the conservative standpoint is taken - the load uses load_acquire unconditionally. Because it might be used for waking up from dormant or transitioning between active states. 3) The interpreter scenario is similar to the JIT-compiled code in that it races with SafepointSynchronize::begin(), and not end(). So similar reasoning applies. 4) The poll in the native wrapper wakes up from a dormant state, and hence races with SafepointSynchronize::end(). Therefore it comes with the additional requirement of either using a load_acquire, or polling both the local and global state to make sure stale loads do not cause us to observe we are still in a safepoint when we are not. The check for blocking in the VM currently uses acquire unconditionally, but if you find that too expensive, it really only needs to conditionally use acquire if the local poll is armed before reading the global state, and unconditionally when waking up from a dormant state (racing with SafepointSynchronize::end()). Those are the true restrictions. I hope this sheds some light on the important races you need to be aware of. Thanks, /Erik >> I have a bunch of other ideas as well exploiting dependent loads, but >> thought maybe I should start the conversation and see what you think >> before running off too much > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From erik.helin at oracle.com Fri Nov 24 13:46:44 2017 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 24 Nov 2017 14:46:44 +0100 Subject: RFR: 8191860: Add perfData.inline.hpp In-Reply-To: References: Message-ID: <78834ffb-3da8-6c15-3e71-ab36107ead96@oracle.com> On 11/24/2017 02:21 PM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to create a perfData.inline.hpp file and move > inline functions in perfData.hpp that depend on functions in other > .inline.hpp files. > > http://cr.openjdk.java.net/~stefank/8191860/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8191860 Looks good, Reviewed. Thanks for cleaning this up. Thanks, Erik > Note 1: I consider growableArray.hpp to be an .inline.hpp in disguise, > since it includes allocation.inline.hpp. > > Note 2: Some .hpp files that used to include perfData.hpp now explicitly > includes allocation.inline.hpp. We should deal with that, but in another > RFE. > > thanks, > StefanK From erik.helin at oracle.com Fri Nov 24 13:47:03 2017 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 24 Nov 2017 14:47:03 +0100 Subject: RFR: 8191858: Add missing includes in memoryManager.hpp In-Reply-To: <11d07932-85e8-fc41-4db9-c54f0b518322@oracle.com> References: <11d07932-85e8-fc41-4db9-c54f0b518322@oracle.com> Message-ID: <21c10914-36a0-6faf-7bd6-fa64864f7290@oracle.com> On 11/24/2017 02:02 PM, Stefan Karlsson wrote: > Hi all, > > Please review this trivial patch to add some missing includes to > memoryManager.hpp. > > http://cr.openjdk.java.net/~stefank/8191858/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8191858 Looks good, Reviewed. Thanks! Erik > This was found when I was restructuring other parts of the code base. > > Thanks, > StefanK From thomas.schatzl at oracle.com Fri Nov 24 14:00:01 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 24 Nov 2017 15:00:01 +0100 Subject: RFR: 8191858: Add missing includes in memoryManager.hpp In-Reply-To: <11d07932-85e8-fc41-4db9-c54f0b518322@oracle.com> References: <11d07932-85e8-fc41-4db9-c54f0b518322@oracle.com> Message-ID: <1511532001.2425.12.camel@oracle.com> Hi, On Fri, 2017-11-24 at 14:02 +0100, Stefan Karlsson wrote: > Hi all, > > Please review this trivial patch to add some missing includes to > memoryManager.hpp. > > http://cr.openjdk.java.net/~stefank/8191858/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8191858 > > This was found when I was restructuring other parts of the code base. looks good. Thomas From per.liden at oracle.com Fri Nov 24 14:06:26 2017 From: per.liden at oracle.com (Per Liden) Date: Fri, 24 Nov 2017 15:06:26 +0100 Subject: RFR: 8191860: Add perfData.inline.hpp In-Reply-To: References: Message-ID: <48fbddfc-b9c7-4915-2a77-233b078351b9@oracle.com> Looks good! /Per On 2017-11-24 14:21, Stefan Karlsson wrote: > Hi all, > > Please review this patch to create a perfData.inline.hpp file and move > inline functions in perfData.hpp that depend on functions in other > .inline.hpp files. > > http://cr.openjdk.java.net/~stefank/8191860/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8191860 > > Note 1: I consider growableArray.hpp to be an .inline.hpp in disguise, > since it includes allocation.inline.hpp. > > Note 2: Some .hpp files that used to include perfData.hpp now explicitly > includes allocation.inline.hpp. We should deal with that, but in another > RFE. > > thanks, > StefanK From per.liden at oracle.com Fri Nov 24 14:06:50 2017 From: per.liden at oracle.com (Per Liden) Date: Fri, 24 Nov 2017 15:06:50 +0100 Subject: RFR: 8191858: Add missing includes in memoryManager.hpp In-Reply-To: <11d07932-85e8-fc41-4db9-c54f0b518322@oracle.com> References: <11d07932-85e8-fc41-4db9-c54f0b518322@oracle.com> Message-ID: Looks good! /Per On 2017-11-24 14:02, Stefan Karlsson wrote: > Hi all, > > Please review this trivial patch to add some missing includes to > memoryManager.hpp. > > http://cr.openjdk.java.net/~stefank/8191858/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8191858 > > This was found when I was restructuring other parts of the code base. > > Thanks, > StefanK From adinn at redhat.com Fri Nov 24 14:32:33 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 24 Nov 2017 14:32:33 +0000 Subject: [aarch64-port-dev ] RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <8121f844-a156-ef1e-fa5f-a30774f1776b@redhat.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <8121f844-a156-ef1e-fa5f-a30774f1776b@redhat.com> Message-ID: <0eedce01-56a4-d800-fb30-f262d6a56d03@redhat.com> On 23/11/17 16:15, Andrew Dinn wrote: >> http://cr.openjdk.java.net/~aph/8189596-1/ > I have reviewed this by eyeball and it all looks good. I still need to > build and run to be 100% sure. Well, it builds and runs stuff ok (e.g. netbeans) despite Erik's race (I'll address that separately in reply to Erik). One minor peccadillo I did notice: in src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp +void MacroAssembler::safepoint_poll(Label& slow_path) { + if (SafepointMechanism::uses_thread_local_poll()) { + ldr(rscratch1, Address(rthread, Thread::polling_page_offset())); + tbnz(rscratch1, exact_log2(SafepointMechanism::poll_bit()), slow_path); + } else { + ExternalAddress state(SafepointSynchronize::address_of_state()); + unsigned long offset; + adrp(rscratch1, ExternalAddress(SafepointSynchronize::address_of_state()), offset); + ldrw(rscratch1, Address(rscratch1, offset)); + assert(SafepointSynchronize::_not_synchronized == 0, "rewrite this code"); + cbnz(rscratch1, slow_path); + } +} In the else branch you declare ExternalAddress state then don't use it in the adrp call. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Fri Nov 24 14:39:07 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 24 Nov 2017 14:39:07 +0000 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <5A182056.9000009@oracle.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> <0ebb3f3e-a6f7-38ac-03a6-12cde24234a1@redhat.com> <5A182056.9000009@oracle.com> Message-ID: <34ea268c-3d05-b1f2-1b74-7d862db36f87@redhat.com> On 24/11/17 13:36, Erik ?sterlund wrote: > On 2017-11-24 13:07, Andrew Dinn wrote: >> On 24/11/17 10:36, Erik ?sterlund wrote: >>> By placing loading the local poll value with ldar *only* in the native >>> wrapper wakeup function, you avoid these issues. >>> Another approach you may elect to use is to only in the native wrapper >>> load both the thread-local poll value and the >>> SafepointSynchronize::_state, when filtering slow paths to avoid this >>> unfortunate race. >> I can see why an ldar (actually ldarw) is needed when safepoint_poll is >> called from the nativewrapper. Can you explain why ldar is not needed >> for *all* calls to safepoint_poll? > > That is a long story. :) But since you asked, here we go... > . . . > I hope this sheds some light on the important races you need to be aware > of. Well, that's a good story and maybe needs to be included somewhere in the code even if only in precis. The asymmetry between start and end makes clear why you want an ldar in the native wrapper. The one detail I am still not sure of is how this design ensures that the benign races in JIT/interpreter ever come to an end. What guarantees that JITted code or the interpreter actually performs an acquiring load and thereby notices a change to the armed poll value? That might take a very long time (if it happens at all?). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From erik.osterlund at oracle.com Fri Nov 24 15:10:51 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 24 Nov 2017 16:10:51 +0100 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <34ea268c-3d05-b1f2-1b74-7d862db36f87@redhat.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> <0ebb3f3e-a6f7-38ac-03a6-12cde24234a1@redhat.com> <5A182056.9000009@oracle.com> <34ea268c-3d05-b1f2-1b74-7d862db36f87@redhat.com> Message-ID: <5A18367B.9070601@oracle.com> Hi Andrew, On 2017-11-24 15:39, Andrew Dinn wrote: > On 24/11/17 13:36, Erik ?sterlund wrote: >> On 2017-11-24 13:07, Andrew Dinn wrote: >>> On 24/11/17 10:36, Erik ?sterlund wrote: >>>> By placing loading the local poll value with ldar *only* in the native >>>> wrapper wakeup function, you avoid these issues. >>>> Another approach you may elect to use is to only in the native wrapper >>>> load both the thread-local poll value and the >>>> SafepointSynchronize::_state, when filtering slow paths to avoid this >>>> unfortunate race. >>> I can see why an ldar (actually ldarw) is needed when safepoint_poll is >>> called from the nativewrapper. Can you explain why ldar is not needed >>> for *all* calls to safepoint_poll? >> That is a long story. :) But since you asked, here we go... >> . . . >> I hope this sheds some light on the important races you need to be aware >> of. > Well, that's a good story and maybe needs to be included somewhere in > the code even if only in precis. The asymmetry between start and end > makes clear why you want an ldar in the native wrapper. Thank you. And yes, you are right - this should probably be documented. > The one detail I am still not sure of is how this design ensures that > the benign races in JIT/interpreter ever come to an end. What guarantees > that JITted code or the interpreter actually performs an acquiring load > and thereby notices a change to the armed poll value? That might take a > very long time (if it happens at all?). The JMM defines opaque stores as stores that among other properties guarantee progress: the store will eventually become observable to other threads. The stores that arm the thread-local polls use a release_store(), which is strictly stronger than opaque on each platform (and hence have the guarantee that they will "eventually" become observable to opaque loads). Therefore, the fast-path in JIT-compiled code and interpreter code are guaranteed to "eventually" observe those stores with opaque loads (and ldr is an opaque load). When they do, they will jump into the VM (directly or through a trampoline), and perform the acquiring load on the thread-local poll, used before loading the global state. As for how long time it takes for the stores to become eventually observable by remote loads, I imagine it should be no worse than the delay of the TLB shootdown event. And just for completeness for this discussion: the arming of the local polls is followed by a fence() which performs a dmb ish in your GCC intrinsics. Thanks, /Erik > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Fri Nov 24 15:30:58 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Nov 2017 15:30:58 +0000 Subject: [aarch64-port-dev ] RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <0ebb3f3e-a6f7-38ac-03a6-12cde24234a1@redhat.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> <0ebb3f3e-a6f7-38ac-03a6-12cde24234a1@redhat.com> Message-ID: <240506f3-2e69-4e1e-4cdc-ac9579db3f06@redhat.com> On 24/11/17 12:07, Andrew Dinn wrote: > I can see why an ldar (actually ldarw) is needed when safepoint_poll is > called from the nativewrapper. Can you explain why ldar is not needed > for *all* calls to safepoint_poll? Because there's no ordering to worry about: the worst that will happen is that a safepoint will be acted on after, say, a memory location is updated. But because in general we don't care about that ordering, it doesn't matter. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Nov 24 15:34:23 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Nov 2017 15:34:23 +0000 Subject: [aarch64-port-dev ] RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <0eedce01-56a4-d800-fb30-f262d6a56d03@redhat.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <8121f844-a156-ef1e-fa5f-a30774f1776b@redhat.com> <0eedce01-56a4-d800-fb30-f262d6a56d03@redhat.com> Message-ID: <4e4688bf-32d7-2d80-79ed-8a0e75d4cf6a@redhat.com> On 24/11/17 14:32, Andrew Dinn wrote: > In the else branch you declare ExternalAddress state then don't use it > in the adrp call. Oh yes. Oops, will fix. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Fri Nov 24 15:55:30 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 24 Nov 2017 15:55:30 +0000 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <5A18367B.9070601@oracle.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> <0ebb3f3e-a6f7-38ac-03a6-12cde24234a1@redhat.com> <5A182056.9000009@oracle.com> <34ea268c-3d05-b1f2-1b74-7d862db36f87@redhat.com> <5A18367B.9070601@oracle.com> Message-ID: <0439c1ac-69db-7498-d843-85d807c8d021@redhat.com> On 24/11/17 15:10, Erik ?sterlund wrote: > On 2017-11-24 15:39, Andrew Dinn wrote: >> The one detail I am still not sure of is how this design ensures that >> the benign races in JIT/interpreter ever come to an end. What guarantees >> that JITted code or the interpreter actually performs an acquiring load >> and thereby notices a change to the armed poll value? That might take a >> very long time (if it happens at all?). > > The JMM defines opaque stores as stores that among other properties > guarantee progress: the store will eventually become observable to other > threads. The stores that arm the thread-local polls use a > release_store(), which is strictly stronger than opaque on each platform > (and hence have the guarantee that they will "eventually" become > observable to opaque loads). Therefore, the fast-path in JIT-compiled > code and interpreter code are guaranteed to "eventually" observe those > stores with opaque loads (and ldr is an opaque load). When they do, they > will jump into the VM (directly or through a trampoline), and perform > the acquiring load on the thread-local poll, used before loading the > global state. > > As for how long time it takes for the stores to become eventually > observable by remote loads, I imagine it should be no worse than the > delay of the TLB shootdown event. And just for completeness for this > discussion: the arming of the local polls is followed by a fence() which > performs a dmb ish in your GCC intrinsics. Well, that's really what I was thinking about with the original question. I understand that writes will become visible "eventually". I'm just concerned to know what sort of upper bound is implied by that word (theoretical might be interesting but I'm more interested in practical). This is the mechanism intended to halt individual threads or all threads. If there is any possibility of some extended delay -- especially in the latter case -- then that would merit quantifying. I assume "no worse than the delay of the TLB shootdown event" means "TLB shootdown relies on the same sort of benign race"? If so that doesn't help quantify anything except to say that prior experience has not shown any significant delay (so far as we know). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From erik.osterlund at oracle.com Fri Nov 24 16:19:10 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 24 Nov 2017 17:19:10 +0100 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <0439c1ac-69db-7498-d843-85d807c8d021@redhat.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> <0ebb3f3e-a6f7-38ac-03a6-12cde24234a1@redhat.com> <5A182056.9000009@oracle.com> <34ea268c-3d05-b1f2-1b74-7d862db36f87@redhat.com> <5A18367B.9070601@oracle.com> <0439c1ac-69db-7498-d843-85d807c8d021@redhat.com> Message-ID: <5A18467E.2040300@oracle.com> Hi Andrew, On 2017-11-24 16:55, Andrew Dinn wrote: > On 24/11/17 15:10, Erik ?sterlund wrote: >> On 2017-11-24 15:39, Andrew Dinn wrote: >>> The one detail I am still not sure of is how this design ensures that >>> the benign races in JIT/interpreter ever come to an end. What guarantees >>> that JITted code or the interpreter actually performs an acquiring load >>> and thereby notices a change to the armed poll value? That might take a >>> very long time (if it happens at all?). >> The JMM defines opaque stores as stores that among other properties >> guarantee progress: the store will eventually become observable to other >> threads. The stores that arm the thread-local polls use a >> release_store(), which is strictly stronger than opaque on each platform >> (and hence have the guarantee that they will "eventually" become >> observable to opaque loads). Therefore, the fast-path in JIT-compiled >> code and interpreter code are guaranteed to "eventually" observe those >> stores with opaque loads (and ldr is an opaque load). When they do, they >> will jump into the VM (directly or through a trampoline), and perform >> the acquiring load on the thread-local poll, used before loading the >> global state. >> >> As for how long time it takes for the stores to become eventually >> observable by remote loads, I imagine it should be no worse than the >> delay of the TLB shootdown event. And just for completeness for this >> discussion: the arming of the local polls is followed by a fence() which >> performs a dmb ish in your GCC intrinsics. > Well, that's really what I was thinking about with the original > question. I understand that writes will become visible "eventually". I'm > just concerned to know what sort of upper bound is implied by that word > (theoretical might be interesting but I'm more interested in practical). > This is the mechanism intended to halt individual threads or all > threads. If there is any possibility of some extended delay -- > especially in the latter case -- then that would merit quantifying. > > I assume "no worse than the delay of the TLB shootdown event" means "TLB > shootdown relies on the same sort of benign race"? If so that doesn't > help quantify anything except to say that prior experience has not shown > any significant delay (so far as we know). Naturally the actual delay of a single store to make it through a store buffer and then the cache coherency protocol to eventually show up in a load on another CPU depends on a bunch of stuff that is bound to look different on every machine. And I can't say I know what typical delays look like on typical AArch64 machines. But I would be *very* surprised if it would get anywhere close to millisecond levels, which is typically when it starts being noticeable on the radar at all to a safepointing operation (compared to the time of doing the crazy things we do in safepoints). A gut feeling is that it should be comparable to the time for performing a dmb sy (which by contract makes preceding stores globally observable in the whole system). Based on what Andrew had observed, it seems like the delays were dominated by the sparse polling of the interpreter, suggesting to me that it does not seem like a large issue to propagate the state change in practice. Thanks, /Erik > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From erik.osterlund at oracle.com Fri Nov 24 16:22:01 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 24 Nov 2017 17:22:01 +0100 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. Message-ID: <5A184729.4090107@oracle.com> Hi, When creating a ciInstanceKlass handle, G1 might need a SATB barrier to keep "peeked" weak klass pointers alive during marking. This should now be done with the Access API instead of manual calls to the G1 SATB barrier. Bug: https://bugs.openjdk.java.net/browse/JDK-8191567 Webrev: http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ Thanks, /Erik From rkennke at redhat.com Fri Nov 24 16:25:16 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 24 Nov 2017 17:25:16 +0100 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. In-Reply-To: <5A184729.4090107@oracle.com> References: <5A184729.4090107@oracle.com> Message-ID: <41b26c4a-2b21-4248-eb9e-9cc5557f429b@redhat.com> Am 24.11.2017 um 17:22 schrieb Erik ?sterlund: > Hi, > > When creating a ciInstanceKlass handle, G1 might need a SATB barrier to > keep "peeked" weak klass pointers alive during marking. > This should now be done with the Access API instead of manual calls to > the G1 SATB barrier. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8191567 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ > > Thanks, > /Erik Looks good. There are many more places where G1SATBCardTableModRefBS::enqueue() is callled from shared code that would require the same treatment. Are you planning to take them one by one? Otherwise, maybe squeeze them all into this patch too because it's related and similar? Roman From erik.osterlund at oracle.com Fri Nov 24 16:31:20 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 24 Nov 2017 17:31:20 +0100 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. In-Reply-To: <41b26c4a-2b21-4248-eb9e-9cc5557f429b@redhat.com> References: <5A184729.4090107@oracle.com> <41b26c4a-2b21-4248-eb9e-9cc5557f429b@redhat.com> Message-ID: <5A184958.4030707@oracle.com> Hi Roman, On 2017-11-24 17:25, Roman Kennke wrote: > Am 24.11.2017 um 17:22 schrieb Erik ?sterlund: >> Hi, >> >> When creating a ciInstanceKlass handle, G1 might need a SATB barrier >> to keep "peeked" weak klass pointers alive during marking. >> This should now be done with the Access API instead of manual calls >> to the G1 SATB barrier. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8191567 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ >> >> Thanks, >> /Erik > > Looks good. Thanks for the review. > There are many more places where G1SATBCardTableModRefBS::enqueue() is > callled from shared code that would require the same treatment. Are > you planning to take them one by one? Otherwise, maybe squeeze them > all into this patch too because it's related and similar? I think I would prefer to have a few small well contained RFEs compared to one very large one, unless people prefer the large change approach. Thanks, /Erik > Roman > From aph at redhat.com Fri Nov 24 16:32:24 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Nov 2017 16:32:24 +0000 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <5A18467E.2040300@oracle.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> <0ebb3f3e-a6f7-38ac-03a6-12cde24234a1@redhat.com> <5A182056.9000009@oracle.com> <34ea268c-3d05-b1f2-1b74-7d862db36f87@redhat.com> <5A18367B.9070601@oracle.com> <0439c1ac-69db-7498-d843-85d807c8d021@redhat.com> <5A18467E.2040300@oracle.com> Message-ID: <9993b109-09fc-7af6-57c9-9d532306588d@redhat.com> On 24/11/17 16:19, Erik ?sterlund wrote: > But I would be *very* surprised if it would get anywhere close to > millisecond levels, which is typically when it starts being > noticeable on the radar at all to a safepointing operation (compared > to the time of doing the crazy things we do in safepoints). It's very unlikely but not impossible. > A gut feeling is that it should be comparable to the time for > performing a dmb sy (which by contract makes preceding stores > globally observable in the whole system). It's not really comparable. It can be microseconds before a store from one core is picked up by another; I have measured times as long as that. On the other hand, a full barrier can be a purely local operation: all it has to do is flush the store buffer to the local cache and mark the entries in the invalidate queue. That takes a matter of nanoseconds and the core can proceed, but of course, it does slow down subsequent load and store operations. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Fri Nov 24 16:35:41 2017 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 24 Nov 2017 17:35:41 +0100 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. In-Reply-To: <5A184958.4030707@oracle.com> References: <5A184729.4090107@oracle.com> <41b26c4a-2b21-4248-eb9e-9cc5557f429b@redhat.com> <5A184958.4030707@oracle.com> Message-ID: <13994c56-8ffa-1da7-86ac-3f10e7e044a0@redhat.com> > Hi Roman, > > On 2017-11-24 17:25, Roman Kennke wrote: >> Am 24.11.2017 um 17:22 schrieb Erik ?sterlund: >>> Hi, >>> >>> When creating a ciInstanceKlass handle, G1 might need a SATB barrier >>> to keep "peeked" weak klass pointers alive during marking. >>> This should now be done with the Access API instead of manual calls >>> to the G1 SATB barrier. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8191567 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ >>> >>> Thanks, >>> /Erik >> >> Looks good. > > Thanks for the review. > >> There are many more places where G1SATBCardTableModRefBS::enqueue() is >> callled from shared code that would require the same treatment. Are >> you planning to take them one by one? Otherwise, maybe squeeze them >> all into this patch too because it's related and similar? > > I think I would prefer to have a few small well contained RFEs compared > to one very large one, unless people prefer the large change approach. I am ok with whatever works best for you :-) Roman From thomas.schatzl at oracle.com Fri Nov 24 17:01:03 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 24 Nov 2017 18:01:03 +0100 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. In-Reply-To: <5A184729.4090107@oracle.com> References: <5A184729.4090107@oracle.com> Message-ID: <1511542863.2917.0.camel@oracle.com> Hi, On Fri, 2017-11-24 at 17:22 +0100, Erik ?sterlund wrote: > Hi, > > When creating a ciInstanceKlass handle, G1 might need a SATB barrier > to keep "peeked" weak klass pointers alive during marking. > This should now be done with the Access API instead of manual calls > to the G1 SATB barrier. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8191567 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ looks good. Thanks for providing such nice usage examples for the new Access klass separately from the huge Access change :) Thanks, Thomas From erik.osterlund at oracle.com Fri Nov 24 17:08:42 2017 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 24 Nov 2017 18:08:42 +0100 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. In-Reply-To: <1511542863.2917.0.camel@oracle.com> References: <5A184729.4090107@oracle.com> <1511542863.2917.0.camel@oracle.com> Message-ID: <6360E882-1CAB-40FA-BF1B-A879C2E2BB2B@oracle.com> Hi Thomas, > On 24 Nov 2017, at 18:01, Thomas Schatzl wrote: > > Hi, > >> On Fri, 2017-11-24 at 17:22 +0100, Erik ?sterlund wrote: >> Hi, >> >> When creating a ciInstanceKlass handle, G1 might need a SATB barrier >> to keep "peeked" weak klass pointers alive during marking. >> This should now be done with the Access API instead of manual calls >> to the G1 SATB barrier. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8191567 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ > > looks good. Thanks for the review! > Thanks for providing such nice usage examples for the new Access klass > separately from the huge Access change :) > No problem! :) Thanks, /Erik > Thanks, > Thomas > From thomas.stuefe at gmail.com Fri Nov 24 17:21:31 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 24 Nov 2017 18:21:31 +0100 Subject: zero debug still broken after 8189871 Message-ID: Hi all, seems that "8191663: Zero variant broken after 8189170 and 8189871" was alone not sufficient to fix zero debug. When building zero (fast|slow)debug, I get this error: --- In file included from /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/gc/shared/specialized_oop_closures.hpp:28:0, from /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/objArrayOop.cpp:26: /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp: In instantiation of ?void AccessInternal::verify_types() [with long unsigned int decorators = 2048ul; T = volatile oop]?: /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:905:32: required from ?T AccessInternal::load(P*) [with long unsigned int decorators = 2048ul; P = volatile oop; T = volatile oop]? /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:450:50: required from ?static P Access::load(P*) [with P = volatile oop; long unsigned int decorators = 2048ul]? /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.inline.hpp:247:34: required from ?static typename EnableIf::value, T>::type RawAccessBarrier::atomic_cmpxchg_maybe_locked(T, void*, T) [with long unsigned int ds = 1030ul; T = oop; long unsigned int decorators = 1030ul; typename EnableIf::value, T>::type = oop]? /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.hpp:325:51: required from ?static T RawAccessBarrier::atomic_cmpxchg(T, void*, T) [with T = oop; long unsigned int decorators = 1030ul]? /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:619:37: required from ?static typename EnableIf::value, T>::type AccessInternal::PreRuntimeDispatch::atomic_cmpxchg(T, void*, T) [with long unsigned int decorators = 289798ul; T = oop; typename EnableIf::value, T>::type = oop]? /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:637:71: required from ?static typename EnableIf<(! HasDecorator::value), T>::type AccessInternal::PreRuntimeDispatch::atomic_cmpxchg(T, void*, T) [with long unsigned int decorators = 287750ul; T = oop; typename EnableIf<(! HasDecorator::value), T>::type = oop]? /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:821:67: required from ?oop AccessInternal::atomic_cmpxchg_reduce_types(oop, HeapWord*, oop) [with long unsigned int decorators = 287748ul]? /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:942:60: required from ?T AccessInternal::atomic_cmpxchg(T, P*, T) [with long unsigned int decorators = 262148ul; P = volatile HeapWord; T = oop]? /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:492:78: required from ?static T Access::oop_atomic_cmpxchg(T, P*, T) [with P = volatile HeapWord; T = oop; long unsigned int decorators = 262144ul]? /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/objArrayOop.cpp:40:78: required from here /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:29: error: incomplete type ?STATIC_ASSERT_FAILURE? used in nested name specifier typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \ ^ /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:47:33: note: in definition of macro ?PASTE_TOKENS_AUX2? #define PASTE_TOKENS_AUX2(x, y) x ## y ^ /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:45:28: note: in expansion of macro ?PASTE_TOKENS_AUX? #define PASTE_TOKENS(x, y) PASTE_TOKENS_AUX(x, y) ^ /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:16: note: in expansion of macro ?PASTE_TOKENS? typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \ ^ /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:873:5: note: in expansion of macro ?STATIC_ASSERT? STATIC_ASSERT((HasDecorator::value || // oops have already been validated ^ -- with CONFIGURE_COMMAND_LINE:=--with-boot-jdk=/shared/projects/openjdk/jdks/openjdk9 --with-debug-level=fastdebug --with-jvm-variants=zero --with-native-debug-symbols=internal --disable-precompiled-headers --with-build-jdk=../output-release/images/jdk on Ubuntu 16.4. x64 The error also happens in slow and fastdebug, with precompiled headers enabled or not. Release is fine (in a fashion, I need disable-warnings-as-errors to get it built, but I guess that is another bug). Thanks, ThomasIt seems triggered by "8189871: Refactor GC barriers to use declarative semantics", but I stared at this error message for half an hour now with not much progress... I do not really understand why the STATIC_ASSERT is failing here. Does anyone have an idea? Thanks, Thomas From thomas.stuefe at gmail.com Fri Nov 24 17:23:42 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 24 Nov 2017 18:23:42 +0100 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: References: <0ebd16bb-1330-600b-1dc8-f4a53db8638b@redhat.com> Message-ID: On Fri, Nov 24, 2017 at 10:29 AM, Andrew Dinn wrote: > One small additional comment: > > On 24/11/17 09:18, Andrew Dinn wrote: > > On 23/11/17 20:43, Thomas St?fe wrote: > >> ... > >> Well, this sounds both simpler and more to the point than my proposal > (2). > > > > Not quite. We know that the "half-eaten-medium-chunk" problem is really > > a bad problem for anonymous class loaders and Zhengyu's patch improves > > that case. We don't know it is that is the only problem case. Other > > loaders may only load a small number of classes -- perhaps 1, maybe 2 -- > > and also end up wasting a lot of space. If an app hits that case a lot > > then your proposal would allow the user to configure round it. > n.b. I'm not sure we need to worry much about any such apps as this > scenario is, arguably, very unlikely? I know, for example, that JBoss > Modules uses many classloaders but they rarely load just one or two > classes. Once you get to 3 or 4 classes I think the current behaviour > will be unlikely to increase waste because larger chunks means less > fragmentation. Are OSGi loaders likely to load just one or two classes > for a significant number of loaders? > > I do not think so. I think you are right, this is less pressing once we get Zhengyus patch. I will add the switch when there is some time, I still think it may be good to have. Kind Regards, Thomas > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From glaubitz at physik.fu-berlin.de Fri Nov 24 17:26:02 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 24 Nov 2017 18:26:02 +0100 Subject: zero debug still broken after 8189871 In-Reply-To: References: Message-ID: <0348A36C-37EA-437B-ADAA-C5A46EF395B3@physik.fu-berlin.de> That?s odd. I just built Zero successfully a few hours ago after ?hg pull && hg update ?clean?. If there had been an issue, I would have run into it. Will try to test in an hour, currently on mobile. Adrian > On Nov 24, 2017, at 6:21 PM, Thomas St?fe wrote: > > Hi all, > > seems that "8191663: Zero variant broken after 8189170 and 8189871" was alone not sufficient to fix zero debug. > > When building zero (fast|slow)debug, I get this error: > > --- > In file included from /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/gc/shared/specialized_oop_closures.hpp:28:0, > from /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/objArrayOop.cpp:26: > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp: In instantiation of ?void AccessInternal::verify_types() [with long unsigned int decorators = 2048ul; T = volatile oop]?: > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:905:32: required from ?T AccessInternal::load(P*) [with long unsigned int decorators = 2048ul; P = volatile oop; T = volatile oop]? > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:450:50: required from ?static P Access::load(P*) [with P = volatile oop; long unsigned int decorators = 2048ul]? > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.inline.hpp:247:34: required from ?static typename EnableIf::value, T>::type RawAccessBarrier::atomic_cmpxchg_maybe_locked(T, void*, T) [with long unsigned int ds = 1030ul; T = oop; long unsigned int decorators = 1030ul; typename EnableIf::value, T>::type = oop]? > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.hpp:325:51: required from ?static T RawAccessBarrier::atomic_cmpxchg(T, void*, T) [with T = oop; long unsigned int decorators = 1030ul]? > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:619:37: required from ?static typename EnableIf::value, T>::type AccessInternal::PreRuntimeDispatch::atomic_cmpxchg(T, void*, T) [with long unsigned int decorators = 289798ul; T = oop; typename EnableIf::value, T>::type = oop]? > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:637:71: required from ?static typename EnableIf<(! HasDecorator::value), T>::type AccessInternal::PreRuntimeDispatch::atomic_cmpxchg(T, void*, T) [with long unsigned int decorators = 287750ul; T = oop; typename EnableIf<(! HasDecorator::value), T>::type = oop]? > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:821:67: required from ?oop AccessInternal::atomic_cmpxchg_reduce_types(oop, HeapWord*, oop) [with long unsigned int decorators = 287748ul]? > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:942:60: required from ?T AccessInternal::atomic_cmpxchg(T, P*, T) [with long unsigned int decorators = 262148ul; P = volatile HeapWord; T = oop]? > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:492:78: required from ?static T Access::oop_atomic_cmpxchg(T, P*, T) [with P = volatile HeapWord; T = oop; long unsigned int decorators = 262144ul]? > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/objArrayOop.cpp:40:78: required from here > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:29: error: incomplete type ?STATIC_ASSERT_FAILURE? used in nested name specifier > typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \ > ^ > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:47:33: note: in definition of macro ?PASTE_TOKENS_AUX2? > #define PASTE_TOKENS_AUX2(x, y) x ## y > ^ > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:45:28: note: in expansion of macro ?PASTE_TOKENS_AUX? > #define PASTE_TOKENS(x, y) PASTE_TOKENS_AUX(x, y) > ^ > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:16: note: in expansion of macro ?PASTE_TOKENS? > typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \ > ^ > /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:873:5: note: in expansion of macro ?STATIC_ASSERT? > STATIC_ASSERT((HasDecorator::value || // oops have already been validated > ^ > -- > > with > > CONFIGURE_COMMAND_LINE:=--with-boot-jdk=/shared/projects/openjdk/jdks/openjdk9 --with-debug-level=fastdebug --with-jvm-variants=zero --with-native-debug-symbols=internal --disable-precompiled-headers --with-build-jdk=../output-release/images/jdk > > on Ubuntu 16.4. x64 > > The error also happens in slow and fastdebug, with precompiled headers enabled or not. Release is fine (in a fashion, I need disable-warnings-as-errors to get it built, but I guess that is another bug). > > Thanks, ThomasIt seems triggered by "8189871: Refactor GC barriers to use declarative semantics", but I stared at this error message for half an hour now with not much progress... I do not really understand why the STATIC_ASSERT is failing here. Does anyone have an idea? > > > Thanks, Thomas > From gromero at linux.vnet.ibm.com Fri Nov 24 17:29:03 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 24 Nov 2017 15:29:03 -0200 Subject: RFR(XXS): 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated bootstrap.url Message-ID: <5A1856DF.7010405@linux.vnet.ibm.com> Hi, Please, could the following simple change be reviewed? It just updates the bootstrap.url variable so IdealGraphVisualizer build can find the correct dependencies to succeed. Accordingly to [1] server deadlock.netbeans.org is not up anymore. Bug: https://bugs.openjdk.java.net/browse/JDK-8191868 Webrev: http://cr.openjdk.java.net/~gromero/8191868/v1/ Since this util was before consolidation under hotspot tree this ML was my best guest for reviewing such a kind of change. If it's wrong, please let me know so I can resend it. Thank you and best regards, Gustavo [1] https://netbeans.org/bugzilla/show_bug.cgi?id=238447 From aph at redhat.com Fri Nov 24 17:33:32 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Nov 2017 17:33:32 +0000 Subject: RFR: 8186461: Zero's atomic_copy64() should use SPE instructions on linux-powerpcspe In-Reply-To: <13ec6e9f-d944-59b8-be06-207268bb5c25@physik.fu-berlin.de> References: <13ec6e9f-d944-59b8-be06-207268bb5c25@physik.fu-berlin.de> Message-ID: <61129821-5a76-3d2c-0d06-25917716e841@redhat.com> On 24/11/17 11:32, John Paul Adrian Glaubitz wrote: > Thus, the current implementation of atomic_copy64() will not build > on PowerPC e500 systems. This issue was already discussed in 2010 > but the proposed change was never merged [2]. While I think the > 2010 approach was clever, I have decided to prefer the more explicit > solution and not rely on the compiler generating the code we want, > hence the use of evldd and evstdd. I agree. > For reference of these instructions, > see [3], page 184 and [4]. > > The changeset for review can be found in [5]. That's fine, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Nov 24 17:39:48 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Nov 2017 17:39:48 +0000 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <5A17F64B.3000101@oracle.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> Message-ID: On 24/11/17 10:36, Erik ?sterlund wrote: > By placing loading the local poll value with ldar *only* in the native > wrapper wakeup function, you avoid these issues. OK, thanks. http://cr.openjdk.java.net/~aph/8189596-2 -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Fri Nov 24 17:42:16 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 24 Nov 2017 18:42:16 +0100 Subject: zero debug still broken after 8189871 In-Reply-To: <0348A36C-37EA-437B-ADAA-C5A46EF395B3@physik.fu-berlin.de> References: <0348A36C-37EA-437B-ADAA-C5A46EF395B3@physik.fu-berlin.de> Message-ID: Just built successfully on Debian unstable with: CONF=linux-x86_64-normal-zero-release MAKE_VERBOSE=y QUIETLY= LOG=debug make clean CONF=linux-x86_64-normal-zero-release ; sh ./configure --with-jvm-variants=zero --with-boot-jdk=/usr/lib/jvm/java-9-openjdk-amd64/ --disable-precompiled-headers --disable-warnings-as-errors && make JOBS=32 MAKE_VERBOSE=y QUIETLY= LOG=debug CONF=linux-x86_64-normal-zero-release Did a ?hg pull && hg update ?clean? prior that. Luckily, I have an SSH client on my iPhone ;). Adrian > On Nov 24, 2017, at 6:26 PM, John Paul Adrian Glaubitz wrote: > > That?s odd. I just built Zero successfully a few hours ago after ?hg pull && hg update ?clean?. > > If there had been an issue, I would have run into it. > > Will try to test in an hour, currently on mobile. > > Adrian > >> On Nov 24, 2017, at 6:21 PM, Thomas St?fe wrote: >> >> Hi all, >> >> seems that "8191663: Zero variant broken after 8189170 and 8189871" was alone not sufficient to fix zero debug. >> >> When building zero (fast|slow)debug, I get this error: >> >> --- >> In file included from /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/gc/shared/specialized_oop_closures.hpp:28:0, >> from /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/objArrayOop.cpp:26: >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp: In instantiation of ?void AccessInternal::verify_types() [with long unsigned int decorators = 2048ul; T = volatile oop]?: >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:905:32: required from ?T AccessInternal::load(P*) [with long unsigned int decorators = 2048ul; P = volatile oop; T = volatile oop]? >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:450:50: required from ?static P Access::load(P*) [with P = volatile oop; long unsigned int decorators = 2048ul]? >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.inline.hpp:247:34: required from ?static typename EnableIf::value, T>::type RawAccessBarrier::atomic_cmpxchg_maybe_locked(T, void*, T) [with long unsigned int ds = 1030ul; T = oop; long unsigned int decorators = 1030ul; typename EnableIf::value, T>::type = oop]? >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.hpp:325:51: required from ?static T RawAccessBarrier::atomic_cmpxchg(T, void*, T) [with T = oop; long unsigned int decorators = 1030ul]? >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:619:37: required from ?static typename EnableIf::value, T>::type AccessInternal::PreRuntimeDispatch::atomic_cmpxchg(T, void*, T) [with long unsigned int decorators = 289798ul; T = oop; typename EnableIf::value, T>::type = oop]? >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:637:71: required from ?static typename EnableIf<(! HasDecorator::value), T>::type AccessInternal::PreRuntimeDispatch::atomic_cmpxchg(T, void*, T) [with long unsigned int decorators = 287750ul; T = oop; typename EnableIf<(! HasDecorator::value), T>::type = oop]? >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:821:67: required from ?oop AccessInternal::atomic_cmpxchg_reduce_types(oop, HeapWord*, oop) [with long unsigned int decorators = 287748ul]? >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:942:60: required from ?T AccessInternal::atomic_cmpxchg(T, P*, T) [with long unsigned int decorators = 262148ul; P = volatile HeapWord; T = oop]? >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:492:78: required from ?static T Access::oop_atomic_cmpxchg(T, P*, T) [with P = volatile HeapWord; T = oop; long unsigned int decorators = 262144ul]? >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/objArrayOop.cpp:40:78: required from here >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:29: error: incomplete type ?STATIC_ASSERT_FAILURE? used in nested name specifier >> typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \ >> ^ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:47:33: note: in definition of macro ?PASTE_TOKENS_AUX2? >> #define PASTE_TOKENS_AUX2(x, y) x ## y >> ^ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:45:28: note: in expansion of macro ?PASTE_TOKENS_AUX? >> #define PASTE_TOKENS(x, y) PASTE_TOKENS_AUX(x, y) >> ^ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:16: note: in expansion of macro ?PASTE_TOKENS? >> typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \ >> ^ >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:873:5: note: in expansion of macro ?STATIC_ASSERT? >> STATIC_ASSERT((HasDecorator::value || // oops have already been validated >> ^ >> -- >> >> with >> >> CONFIGURE_COMMAND_LINE:=--with-boot-jdk=/shared/projects/openjdk/jdks/openjdk9 --with-debug-level=fastdebug --with-jvm-variants=zero --with-native-debug-symbols=internal --disable-precompiled-headers --with-build-jdk=../output-release/images/jdk >> >> on Ubuntu 16.4. x64 >> >> The error also happens in slow and fastdebug, with precompiled headers enabled or not. Release is fine (in a fashion, I need disable-warnings-as-errors to get it built, but I guess that is another bug). >> >> Thanks, ThomasIt seems triggered by "8189871: Refactor GC barriers to use declarative semantics", but I stared at this error message for half an hour now with not much progress... I do not really understand why the STATIC_ASSERT is failing here. Does anyone have an idea? >> >> >> Thanks, Thomas >> From thomas.stuefe at gmail.com Fri Nov 24 17:59:05 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 24 Nov 2017 18:59:05 +0100 Subject: zero debug still broken after 8189871 In-Reply-To: References: <0348A36C-37EA-437B-ADAA-C5A46EF395B3@physik.fu-berlin.de> Message-ID: On Fri, Nov 24, 2017 at 6:42 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Just built successfully on Debian unstable with: > > CONF=linux-x86_64-normal-zero-release MAKE_VERBOSE=y QUIETLY= LOG=debug > make clean CONF=linux-x86_64-normal-zero-release ; sh ./configure > --with-jvm-variants=zero --with-boot-jdk=/usr/lib/jvm/java-9-openjdk-amd64/ > --disable-precompiled-headers --disable-warnings-as-errors && make JOBS=32 > MAKE_VERBOSE=y QUIETLY= LOG=debug CONF=linux-x86_64-normal-zero-release > > debug is broken. Release works. You must build with --with-debug-level=fastdebug or slowdebug to get the error. > Did a ?hg pull && hg update ?clean? prior that. > > Luckily, I have an SSH client on my iPhone ;). > > :) ..Thomas > Adrian > > > > On Nov 24, 2017, at 6:26 PM, John Paul Adrian Glaubitz < > glaubitz at physik.fu-berlin.de> wrote: > > > > That?s odd. I just built Zero successfully a few hours ago after ?hg > pull && hg update ?clean?. > > > > If there had been an issue, I would have run into it. > > > > Will try to test in an hour, currently on mobile. > > > > Adrian > > > >> On Nov 24, 2017, at 6:21 PM, Thomas St?fe > wrote: > >> > >> Hi all, > >> > >> seems that "8191663: Zero variant broken after 8189170 and 8189871" was > alone not sufficient to fix zero debug. > >> > >> When building zero (fast|slow)debug, I get this error: > >> > >> --- > >> In file included from /shared/projects/openjdk/jdk- > hs/source/src/hotspot/share/gc/shared/specialized_oop_closures.hpp:28:0, > >> from /shared/projects/openjdk/jdk- > hs/source/src/hotspot/share/oops/objArrayOop.cpp:26: > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp: > In instantiation of ?void AccessInternal::verify_types() [with long > unsigned int decorators = 2048ul; T = volatile oop]?: > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:905:32: > required from ?T AccessInternal::load(P*) [with long unsigned int > decorators = 2048ul; P = volatile oop; T = volatile oop]? > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:450:50: > required from ?static P Access::load(P*) [with P = volatile > oop; long unsigned int decorators = 2048ul]? > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/ > oops/accessBackend.inline.hpp:247:34: required from ?static typename > EnableIf::value, T>::type > RawAccessBarrier::atomic_cmpxchg_maybe_locked(T, void*, T) > [with long unsigned int ds = 1030ul; T = oop; long unsigned int decorators > = 1030ul; typename EnableIf::value, > T>::type = oop]? > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.hpp:325:51: > required from ?static T RawAccessBarrier::atomic_cmpxchg(T, > void*, T) [with T = oop; long unsigned int decorators = 1030ul]? > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:619:37: > required from ?static typename EnableIf 2048ul>::value, T>::type AccessInternal::PreRuntimeDispatch::atomic_cmpxchg(T, > void*, T) [with long unsigned int decorators = 289798ul; T = oop; typename > EnableIf::value, T>::type = oop]? > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:637:71: > required from ?static typename EnableIf<(! HasDecorator 2048ul>::value), T>::type AccessInternal::PreRuntimeDispatch::atomic_cmpxchg(T, > void*, T) [with long unsigned int decorators = 287750ul; T = oop; typename > EnableIf<(! HasDecorator::value), T>::type = oop]? > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:821:67: > required from ?oop AccessInternal::atomic_cmpxchg_reduce_types(oop, > HeapWord*, oop) [with long unsigned int decorators = 287748ul]? > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:942:60: > required from ?T AccessInternal::atomic_cmpxchg(T, P*, T) [with long > unsigned int decorators = 262148ul; P = volatile HeapWord; T = oop]? > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:492:78: > required from ?static T Access::oop_atomic_cmpxchg(T, P*, T) > [with P = volatile HeapWord; T = oop; long unsigned int decorators = > 262144ul]? > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/objArrayOop.cpp:40:78: > required from here > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:29: > error: incomplete type ?STATIC_ASSERT_FAILURE? used in nested name > specifier > >> typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \ > >> ^ > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:47:33: > note: in definition of macro ?PASTE_TOKENS_AUX2? > >> #define PASTE_TOKENS_AUX2(x, y) x ## y > >> ^ > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:45:28: > note: in expansion of macro ?PASTE_TOKENS_AUX? > >> #define PASTE_TOKENS(x, y) PASTE_TOKENS_AUX(x, y) > >> ^ > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:16: > note: in expansion of macro ?PASTE_TOKENS? > >> typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \ > >> ^ > >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:873:5: > note: in expansion of macro ?STATIC_ASSERT? > >> STATIC_ASSERT((HasDecorator INTERNAL_VALUE_IS_OOP>::value || // oops have already been validated > >> ^ > >> -- > >> > >> with > >> > >> CONFIGURE_COMMAND_LINE:=--with-boot-jdk=/shared/projects/openjdk/jdks/openjdk9 > --with-debug-level=fastdebug --with-jvm-variants=zero > --with-native-debug-symbols=internal --disable-precompiled-headers > --with-build-jdk=../output-release/images/jdk > >> > >> on Ubuntu 16.4. x64 > >> > >> The error also happens in slow and fastdebug, with precompiled headers > enabled or not. Release is fine (in a fashion, I need > disable-warnings-as-errors to get it built, but I guess that is another > bug). > >> > >> Thanks, ThomasIt seems triggered by "8189871: Refactor GC barriers to > use declarative semantics", but I stared at this error message for half an > hour now with not much progress... I do not really understand why the > STATIC_ASSERT is failing here. Does anyone have an idea? > >> > >> > >> Thanks, Thomas > >> > > From glaubitz at physik.fu-berlin.de Fri Nov 24 18:45:06 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 24 Nov 2017 19:45:06 +0100 Subject: zero debug still broken after 8189871 In-Reply-To: References: <0348A36C-37EA-437B-ADAA-C5A46EF395B3@physik.fu-berlin.de> Message-ID: <3AA22FAE-D7A3-467B-983F-411467FD872B@physik.fu-berlin.de> Ok, I?ll have at this on Sunday evening. Enjoying my weekend now. Have a nice weekend. Adrian > On Nov 24, 2017, at 6:59 PM, Thomas St?fe wrote: > > > >> On Fri, Nov 24, 2017 at 6:42 PM, John Paul Adrian Glaubitz wrote: >> Just built successfully on Debian unstable with: >> >> CONF=linux-x86_64-normal-zero-release MAKE_VERBOSE=y QUIETLY= LOG=debug make clean CONF=linux-x86_64-normal-zero-release ; sh ./configure --with-jvm-variants=zero --with-boot-jdk=/usr/lib/jvm/java-9-openjdk-amd64/ --disable-precompiled-headers --disable-warnings-as-errors && make JOBS=32 MAKE_VERBOSE=y QUIETLY= LOG=debug CONF=linux-x86_64-normal-zero-release >> > > debug is broken. Release works. You must build with --with-debug-level=fastdebug or slowdebug to get the error. > > >> Did a ?hg pull && hg update ?clean? prior that. >> >> Luckily, I have an SSH client on my iPhone ;). >> > > :) > > ..Thomas > >> Adrian >> >> >> > On Nov 24, 2017, at 6:26 PM, John Paul Adrian Glaubitz wrote: >> > >> > That?s odd. I just built Zero successfully a few hours ago after ?hg pull && hg update ?clean?. >> > >> > If there had been an issue, I would have run into it. >> > >> > Will try to test in an hour, currently on mobile. >> > >> > Adrian >> > >> >> On Nov 24, 2017, at 6:21 PM, Thomas St?fe wrote: >> >> >> >> Hi all, >> >> >> >> seems that "8191663: Zero variant broken after 8189170 and 8189871" was alone not sufficient to fix zero debug. >> >> >> >> When building zero (fast|slow)debug, I get this error: >> >> >> >> --- >> >> In file included from /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/gc/shared/specialized_oop_closures.hpp:28:0, >> >> from /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/objArrayOop.cpp:26: >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp: In instantiation of ?void AccessInternal::verify_types() [with long unsigned int decorators = 2048ul; T = volatile oop]?: >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:905:32: required from ?T AccessInternal::load(P*) [with long unsigned int decorators = 2048ul; P = volatile oop; T = volatile oop]? >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:450:50: required from ?static P Access::load(P*) [with P = volatile oop; long unsigned int decorators = 2048ul]? >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.inline.hpp:247:34: required from ?static typename EnableIf::value, T>::type RawAccessBarrier::atomic_cmpxchg_maybe_locked(T, void*, T) [with long unsigned int ds = 1030ul; T = oop; long unsigned int decorators = 1030ul; typename EnableIf::value, T>::type = oop]? >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.hpp:325:51: required from ?static T RawAccessBarrier::atomic_cmpxchg(T, void*, T) [with T = oop; long unsigned int decorators = 1030ul]? >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:619:37: required from ?static typename EnableIf::value, T>::type AccessInternal::PreRuntimeDispatch::atomic_cmpxchg(T, void*, T) [with long unsigned int decorators = 289798ul; T = oop; typename EnableIf::value, T>::type = oop]? >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:637:71: required from ?static typename EnableIf<(! HasDecorator::value), T>::type AccessInternal::PreRuntimeDispatch::atomic_cmpxchg(T, void*, T) [with long unsigned int decorators = 287750ul; T = oop; typename EnableIf<(! HasDecorator::value), T>::type = oop]? >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:821:67: required from ?oop AccessInternal::atomic_cmpxchg_reduce_types(oop, HeapWord*, oop) [with long unsigned int decorators = 287748ul]? >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:942:60: required from ?T AccessInternal::atomic_cmpxchg(T, P*, T) [with long unsigned int decorators = 262148ul; P = volatile HeapWord; T = oop]? >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:492:78: required from ?static T Access::oop_atomic_cmpxchg(T, P*, T) [with P = volatile HeapWord; T = oop; long unsigned int decorators = 262144ul]? >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/objArrayOop.cpp:40:78: required from here >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:29: error: incomplete type ?STATIC_ASSERT_FAILURE? used in nested name specifier >> >> typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \ >> >> ^ >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:47:33: note: in definition of macro ?PASTE_TOKENS_AUX2? >> >> #define PASTE_TOKENS_AUX2(x, y) x ## y >> >> ^ >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:45:28: note: in expansion of macro ?PASTE_TOKENS_AUX? >> >> #define PASTE_TOKENS(x, y) PASTE_TOKENS_AUX(x, y) >> >> ^ >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:16: note: in expansion of macro ?PASTE_TOKENS? >> >> typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \ >> >> ^ >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:873:5: note: in expansion of macro ?STATIC_ASSERT? >> >> STATIC_ASSERT((HasDecorator::value || // oops have already been validated >> >> ^ >> >> -- >> >> >> >> with >> >> >> >> CONFIGURE_COMMAND_LINE:=--with-boot-jdk=/shared/projects/openjdk/jdks/openjdk9 --with-debug-level=fastdebug --with-jvm-variants=zero --with-native-debug-symbols=internal --disable-precompiled-headers --with-build-jdk=../output-release/images/jdk >> >> >> >> on Ubuntu 16.4. x64 >> >> >> >> The error also happens in slow and fastdebug, with precompiled headers enabled or not. Release is fine (in a fashion, I need disable-warnings-as-errors to get it built, but I guess that is another bug). >> >> >> >> Thanks, ThomasIt seems triggered by "8189871: Refactor GC barriers to use declarative semantics", but I stared at this error message for half an hour now with not much progress... I do not really understand why the STATIC_ASSERT is failing here. Does anyone have an idea? >> >> >> >> >> >> Thanks, Thomas >> >> >> > From thomas.stuefe at gmail.com Fri Nov 24 18:49:52 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 24 Nov 2017 18:49:52 +0000 Subject: zero debug still broken after 8189871 In-Reply-To: <3AA22FAE-D7A3-467B-983F-411467FD872B@physik.fu-berlin.de> References: <0348A36C-37EA-437B-ADAA-C5A46EF395B3@physik.fu-berlin.de> <3AA22FAE-D7A3-467B-983F-411467FD872B@physik.fu-berlin.de> Message-ID: Thanks, you too! ..Thomas On Fri 24. Nov 2017 at 19:45, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Ok, I?ll have at this on Sunday evening. Enjoying my weekend now. > > Have a nice weekend. > > Adrian > > On Nov 24, 2017, at 6:59 PM, Thomas St?fe wrote: > > > > On Fri, Nov 24, 2017 at 6:42 PM, John Paul Adrian Glaubitz < > glaubitz at physik.fu-berlin.de> wrote: > >> Just built successfully on Debian unstable with: >> >> CONF=linux-x86_64-normal-zero-release MAKE_VERBOSE=y QUIETLY= LOG=debug >> make clean CONF=linux-x86_64-normal-zero-release ; sh ./configure >> --with-jvm-variants=zero --with-boot-jdk=/usr/lib/jvm/java-9-openjdk-amd64/ >> --disable-precompiled-headers --disable-warnings-as-errors && make JOBS=32 >> MAKE_VERBOSE=y QUIETLY= LOG=debug CONF=linux-x86_64-normal-zero-release >> >> > debug is broken. Release works. You must build with > --with-debug-level=fastdebug or slowdebug to get the error. > > > >> Did a ?hg pull && hg update ?clean? prior that. >> >> Luckily, I have an SSH client on my iPhone ;). >> >> > :) > > ..Thomas > > >> Adrian >> >> >> > On Nov 24, 2017, at 6:26 PM, John Paul Adrian Glaubitz < >> glaubitz at physik.fu-berlin.de> wrote: >> > >> > That?s odd. I just built Zero successfully a few hours ago after ?hg >> pull && hg update ?clean?. >> > >> > If there had been an issue, I would have run into it. >> > >> > Will try to test in an hour, currently on mobile. >> > >> > Adrian >> > >> >> On Nov 24, 2017, at 6:21 PM, Thomas St?fe >> wrote: >> >> >> >> Hi all, >> >> >> >> seems that "8191663: Zero variant broken after 8189170 and 8189871" >> was alone not sufficient to fix zero debug. >> >> >> >> When building zero (fast|slow)debug, I get this error: >> >> >> >> --- >> >> In file included from >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/gc/shared/specialized_oop_closures.hpp:28:0, >> >> from >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/objArrayOop.cpp:26: >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp: >> In instantiation of ?void AccessInternal::verify_types() [with long >> unsigned int decorators = 2048ul; T = volatile oop]?: >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:905:32: >> required from ?T AccessInternal::load(P*) [with long unsigned int >> decorators = 2048ul; P = volatile oop; T = volatile oop]? >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:450:50: >> required from ?static P Access::load(P*) [with P = volatile >> oop; long unsigned int decorators = 2048ul]? >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.inline.hpp:247:34: >> required from ?static typename >> EnableIf::value, T>::type >> RawAccessBarrier::atomic_cmpxchg_maybe_locked(T, void*, T) >> [with long unsigned int ds = 1030ul; T = oop; long unsigned int decorators >> = 1030ul; typename EnableIf::value, >> T>::type = oop]? >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/accessBackend.hpp:325:51: >> required from ?static T RawAccessBarrier::atomic_cmpxchg(T, >> void*, T) [with T = oop; long unsigned int decorators = 1030ul]? >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:619:37: >> required from ?static typename EnableIf> 2048ul>::value, T>::type >> AccessInternal::PreRuntimeDispatch::atomic_cmpxchg(T, void*, T) [with long >> unsigned int decorators = 289798ul; T = oop; typename >> EnableIf::value, T>::type = oop]? >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:637:71: >> required from ?static typename EnableIf<(! HasDecorator> 2048ul>::value), T>::type >> AccessInternal::PreRuntimeDispatch::atomic_cmpxchg(T, void*, T) [with long >> unsigned int decorators = 287750ul; T = oop; typename EnableIf<(! >> HasDecorator::value), T>::type = oop]? >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:821:67: >> required from ?oop AccessInternal::atomic_cmpxchg_reduce_types(oop, >> HeapWord*, oop) [with long unsigned int decorators = 287748ul]? >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:942:60: >> required from ?T AccessInternal::atomic_cmpxchg(T, P*, T) [with long >> unsigned int decorators = 262148ul; P = volatile HeapWord; T = oop]? >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.hpp:492:78: >> required from ?static T Access::oop_atomic_cmpxchg(T, P*, T) >> [with P = volatile HeapWord; T = oop; long unsigned int decorators = >> 262144ul]? >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/objArrayOop.cpp:40:78: >> required from here >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:29: >> error: incomplete type ?STATIC_ASSERT_FAILURE? used in nested name >> specifier >> >> typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \ >> >> ^ >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:47:33: >> note: in definition of macro ?PASTE_TOKENS_AUX2? >> >> #define PASTE_TOKENS_AUX2(x, y) x ## y >> >> ^ >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/macros.hpp:45:28: >> note: in expansion of macro ?PASTE_TOKENS_AUX? >> >> #define PASTE_TOKENS(x, y) PASTE_TOKENS_AUX(x, y) >> >> ^ >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/utilities/debug.hpp:184:16: >> note: in expansion of macro ?PASTE_TOKENS? >> >> typedef char PASTE_TOKENS(STATIC_ASSERT_DUMMY_TYPE_, __LINE__)[ \ >> >> ^ >> >> >> /shared/projects/openjdk/jdk-hs/source/src/hotspot/share/oops/access.inline.hpp:873:5: >> note: in expansion of macro ?STATIC_ASSERT? >> >> STATIC_ASSERT((HasDecorator> INTERNAL_VALUE_IS_OOP>::value || // oops have already been validated >> >> ^ >> >> -- >> >> >> >> with >> >> >> >> >> CONFIGURE_COMMAND_LINE:=--with-boot-jdk=/shared/projects/openjdk/jdks/openjdk9 >> --with-debug-level=fastdebug --with-jvm-variants=zero >> --with-native-debug-symbols=internal --disable-precompiled-headers >> --with-build-jdk=../output-release/images/jdk >> >> >> >> on Ubuntu 16.4. x64 >> >> >> >> The error also happens in slow and fastdebug, with precompiled headers >> enabled or not. Release is fine (in a fashion, I need >> disable-warnings-as-errors to get it built, but I guess that is another >> bug). >> >> >> >> Thanks, ThomasIt seems triggered by "8189871: Refactor GC barriers to >> use declarative semantics", but I stared at this error message for half an >> hour now with not much progress... I do not really understand why the >> STATIC_ASSERT is failing here. Does anyone have an idea? >> >> >> >> >> >> Thanks, Thomas >> >> >> >> > From erik.osterlund at oracle.com Fri Nov 24 20:09:09 2017 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 24 Nov 2017 21:09:09 +0100 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> Message-ID: <4C835D94-ED3A-4C25-8286-305C2AE621AB@oracle.com> Hi Andrew, > On 24 Nov 2017, at 18:39, Andrew Haley wrote: > >> On 24/11/17 10:36, Erik ?sterlund wrote: >> By placing loading the local poll value with ldar *only* in the native >> wrapper wakeup function, you avoid these issues. > > OK, thanks. You are welcome. :) > http://cr.openjdk.java.net/~aph/8189596-2 Looks a lot better now. Thanks for doing this. /Erik > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Sat Nov 25 05:35:21 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 25 Nov 2017 00:35:21 -0500 Subject: RFR: 8191870: Remove badJNIHandle Message-ID: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> Please review this change to eliminate badJNIHandle and the special debug-only handling of it when resolving JNI handles. For the intended purpose of catching bad JNI handle usage while sometimes normalizing some to NULL, we mostly don't need such a special value. We can instead use NULL directly, and get largely the same effect. By filling blocks with NULL, rather than badJNIHandle, we avoid the difficulties related to the Access protocol (see the CR). A NULL value is sufficient for local and non-weak global handles. A JNI handle is never allocated to refer to a NULL value; instead, a NULL handle is used. resolve and friends already treat the case of a NULL pointee specially (asserting, except in the external guard case, where it is allowed to pass through). Only weak global handles lose the protection afforded by badJNIHandle. (This is because, unlike local and global handles, a weak global handle can refer to a NULL value, because it may have been cleared by the GC.) That protection was already fairly minimal for such handles, even when using badJNIHandle. That protection only applied for entries in a newly allocated block that have never yet been allocated. Blocks in the global lists are currently never released, so the setting to a "bad" value for released handles never occurs for weak global handles. So the most interesting use-case for badJNIHandle (identifying uses of stale handles) doesn't even apply. There is one other use of badJNIHandle: throw_unsatisfied_link_error. This function isn't currently called, only used as a marker. The discussion in bug 4524377, where that function was added, suggested using badAddress, so we're replacing badJNIHandle with badAddress. CR: https://bugs.openjdk.java.net/browse/JDK-8191870 Webrev: http://cr.openjdk.java.net/~kbarrett/8191870/open.00/ Testing: Mach5 hs-tier1-3 tonga: nsk.jvmti, nsk.stress, vm.runtime (for various JNI tests) From erik.osterlund at oracle.com Sat Nov 25 08:44:11 2017 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Sat, 25 Nov 2017 09:44:11 +0100 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> Message-ID: <2CDA5D17-FC87-49CF-BABF-6BFA7F45733E@oracle.com> Hi Kim, This change is absolutely fantastic. No more nightmares about zapped JNI handle values. Thank you for doing this. Looks magnificent. Thanks, /Erik > On 25 Nov 2017, at 06:35, Kim Barrett wrote: > > Please review this change to eliminate badJNIHandle and the special > debug-only handling of it when resolving JNI handles. > > For the intended purpose of catching bad JNI handle usage while > sometimes normalizing some to NULL, we mostly don't need such a > special value. We can instead use NULL directly, and get largely the > same effect. > > By filling blocks with NULL, rather than badJNIHandle, we avoid the > difficulties related to the Access protocol (see the CR). > > A NULL value is sufficient for local and non-weak global handles. A > JNI handle is never allocated to refer to a NULL value; instead, a > NULL handle is used. resolve and friends already treat the case of a > NULL pointee specially (asserting, except in the external guard case, > where it is allowed to pass through). > > Only weak global handles lose the protection afforded by badJNIHandle. > (This is because, unlike local and global handles, a weak global > handle can refer to a NULL value, because it may have been cleared by > the GC.) That protection was already fairly minimal for such handles, > even when using badJNIHandle. That protection only applied for > entries in a newly allocated block that have never yet been allocated. > Blocks in the global lists are currently never released, so the > setting to a "bad" value for released handles never occurs for weak > global handles. So the most interesting use-case for badJNIHandle > (identifying uses of stale handles) doesn't even apply. > > There is one other use of badJNIHandle: throw_unsatisfied_link_error. > This function isn't currently called, only used as a marker. The > discussion in bug 4524377, where that function was added, suggested > using badAddress, so we're replacing badJNIHandle with badAddress. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8191870 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8191870/open.00/ > > Testing: > Mach5 hs-tier1-3 > tonga: nsk.jvmti, nsk.stress, vm.runtime (for various JNI tests) > > From daniel.daugherty at oracle.com Sat Nov 25 14:20:47 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 25 Nov 2017 09:20:47 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> Message-ID: <342af90e-aaa2-dd1b-d7a0-db515fed493a@oracle.com> On 11/25/17 12:35 AM, Kim Barrett wrote: > Please review this change to eliminate badJNIHandle and the special > debug-only handling of it when resolving JNI handles. > > For the intended purpose of catching bad JNI handle usage while > sometimes normalizing some to NULL, we mostly don't need such a > special value. We can instead use NULL directly, and get largely the > same effect. > > By filling blocks with NULL, rather than badJNIHandle, we avoid the > difficulties related to the Access protocol (see the CR). > > A NULL value is sufficient for local and non-weak global handles. A > JNI handle is never allocated to refer to a NULL value; instead, a > NULL handle is used. resolve and friends already treat the case of a > NULL pointee specially (asserting, except in the external guard case, > where it is allowed to pass through). > > Only weak global handles lose the protection afforded by badJNIHandle. > (This is because, unlike local and global handles, a weak global > handle can refer to a NULL value, because it may have been cleared by > the GC.) That protection was already fairly minimal for such handles, > even when using badJNIHandle. That protection only applied for > entries in a newly allocated block that have never yet been allocated. > Blocks in the global lists are currently never released, so the > setting to a "bad" value for released handles never occurs for weak > global handles. So the most interesting use-case for badJNIHandle > (identifying uses of stale handles) doesn't even apply. > > There is one other use of badJNIHandle: throw_unsatisfied_link_error. > This function isn't currently called, only used as a marker. The > discussion in bug 4524377, where that function was added, suggested > using badAddress, so we're replacing badJNIHandle with badAddress. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8191870 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8191870/open.00/ src/hotspot/share/runtime/globals.hpp ??? No comments. src/hotspot/share/runtime/jniHandles.cpp ??? No comments. src/hotspot/share/runtime/jniHandles.hpp ??? No comments. src/hotspot/share/runtime/sharedRuntime.cpp ??? No comments. src/hotspot/share/utilities/globalDefinitions.hpp ??? No comments. Thumbs up! Thanks for leaving JNIHandles::resolve_external_guard() so that JVM/TI can still do its (limited) bad parameter checks. Dan > > Testing: > Mach5 hs-tier1-3 > tonga: nsk.jvmti, nsk.stress, vm.runtime (for various JNI tests) > > From stefan.karlsson at oracle.com Mon Nov 27 08:51:15 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 27 Nov 2017 09:51:15 +0100 Subject: RFR: 8191860: Add perfData.inline.hpp In-Reply-To: <78834ffb-3da8-6c15-3e71-ab36107ead96@oracle.com> References: <78834ffb-3da8-6c15-3e71-ab36107ead96@oracle.com> Message-ID: <4fbf72bf-7ead-ea26-74d5-b85ba9a0bc42@oracle.com> Thanks, Erik! StefanK On 2017-11-24 14:46, Erik Helin wrote: > On 11/24/2017 02:21 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to create a perfData.inline.hpp file and move >> inline functions in perfData.hpp that depend on functions in other >> .inline.hpp files. >> >> http://cr.openjdk.java.net/~stefank/8191860/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8191860 > > Looks good, Reviewed. Thanks for cleaning this up. > > Thanks, > Erik > >> Note 1: I consider growableArray.hpp to be an .inline.hpp in disguise, >> since it includes allocation.inline.hpp. >> >> Note 2: Some .hpp files that used to include perfData.hpp now >> explicitly includes allocation.inline.hpp. We should deal with that, >> but in another RFE. >> >> thanks, >> StefanK From stefan.karlsson at oracle.com Mon Nov 27 08:51:28 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 27 Nov 2017 09:51:28 +0100 Subject: RFR: 8191860: Add perfData.inline.hpp In-Reply-To: <48fbddfc-b9c7-4915-2a77-233b078351b9@oracle.com> References: <48fbddfc-b9c7-4915-2a77-233b078351b9@oracle.com> Message-ID: <1192ac09-8192-8749-7782-b3a784aedc37@oracle.com> Thanks, Per! StefanK On 2017-11-24 15:06, Per Liden wrote: > Looks good! > > /Per > > On 2017-11-24 14:21, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to create a perfData.inline.hpp file and move >> inline functions in perfData.hpp that depend on functions in other >> .inline.hpp files. >> >> http://cr.openjdk.java.net/~stefank/8191860/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8191860 >> >> Note 1: I consider growableArray.hpp to be an .inline.hpp in disguise, >> since it includes allocation.inline.hpp. >> >> Note 2: Some .hpp files that used to include perfData.hpp now explicitly >> includes allocation.inline.hpp. We should deal with that, but in another >> RFE. >> >> thanks, >> StefanK From stefan.karlsson at oracle.com Mon Nov 27 08:51:39 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 27 Nov 2017 09:51:39 +0100 Subject: RFR: 8191858: Add missing includes in memoryManager.hpp In-Reply-To: <21c10914-36a0-6faf-7bd6-fa64864f7290@oracle.com> References: <11d07932-85e8-fc41-4db9-c54f0b518322@oracle.com> <21c10914-36a0-6faf-7bd6-fa64864f7290@oracle.com> Message-ID: <067c7f5d-53b8-3052-79d9-6ae6ce12a72d@oracle.com> Thanks, Erik! StefanK On 2017-11-24 14:47, Erik Helin wrote: > On 11/24/2017 02:02 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this trivial patch to add some missing includes to >> memoryManager.hpp. >> >> http://cr.openjdk.java.net/~stefank/8191858/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8191858 > > Looks good, Reviewed. > > Thanks! > Erik > >> This was found when I was restructuring other parts of the code base. >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Mon Nov 27 08:54:33 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 27 Nov 2017 09:54:33 +0100 Subject: RFR: 8191858: Add missing includes in memoryManager.hpp In-Reply-To: <1511532001.2425.12.camel@oracle.com> References: <11d07932-85e8-fc41-4db9-c54f0b518322@oracle.com> <1511532001.2425.12.camel@oracle.com> Message-ID: <5bc0a733-f7e7-283a-da41-d6cd6caf1dcd@oracle.com> Thanks, Thomas! StefanK On 2017-11-24 15:00, Thomas Schatzl wrote: > Hi, > > On Fri, 2017-11-24 at 14:02 +0100, Stefan Karlsson wrote: >> Hi all, >> >> Please review this trivial patch to add some missing includes to >> memoryManager.hpp. >> >> http://cr.openjdk.java.net/~stefank/8191858/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8191858 >> >> This was found when I was restructuring other parts of the code base. > > looks good. > > Thomas > From stefan.karlsson at oracle.com Mon Nov 27 08:54:55 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 27 Nov 2017 09:54:55 +0100 Subject: RFR: 8191858: Add missing includes in memoryManager.hpp In-Reply-To: References: <11d07932-85e8-fc41-4db9-c54f0b518322@oracle.com> Message-ID: <2a1d0b9f-794d-6bb9-f9cd-b54fdbe5b554@oracle.com> Thanks, Per! StefanK On 2017-11-24 15:06, Per Liden wrote: > Looks good! > > /Per > > On 2017-11-24 14:02, Stefan Karlsson wrote: >> Hi all, >> >> Please review this trivial patch to add some missing includes to >> memoryManager.hpp. >> >> http://cr.openjdk.java.net/~stefank/8191858/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8191858 >> >> This was found when I was restructuring other parts of the code base. >> >> Thanks, >> StefanK From adinn at redhat.com Mon Nov 27 09:24:26 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 27 Nov 2017 09:24:26 +0000 Subject: [aarch64-port-dev ] RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> Message-ID: <085883c1-4cd6-9adc-16b5-e6fe86b0a98d@redhat.com> On 24/11/17 17:39, Andrew Haley wrote: > On 24/11/17 10:36, Erik ?sterlund wrote: >> By placing loading the local poll value with ldar *only* in the native >> wrapper wakeup function, you avoid these issues. > > OK, thanks. > > http://cr.openjdk.java.net/~aph/8189596-2 Yes, looks good. Nice catch on the two dmb instructions :-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From tobias.hartmann at oracle.com Mon Nov 27 10:29:47 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Nov 2017 11:29:47 +0100 Subject: RFR(XXS): 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated bootstrap.url In-Reply-To: <5A1856DF.7010405@linux.vnet.ibm.com> References: <5A1856DF.7010405@linux.vnet.ibm.com> Message-ID: <678efe47-b2d5-aa0e-124e-a1e2b00729a3@oracle.com> Hi Gustavo, this looks good to me. Thanks for fixing! Best regards, Tobias On 24.11.2017 18:29, Gustavo Romero wrote: > Hi, > > Please, could the following simple change be reviewed? > > It just updates the bootstrap.url variable so IdealGraphVisualizer build can > find the correct dependencies to succeed. Accordingly to [1] server > deadlock.netbeans.org is not up anymore. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191868 > Webrev: http://cr.openjdk.java.net/~gromero/8191868/v1/ > > Since this util was before consolidation under hotspot tree this ML was my best > guest for reviewing such a kind of change. If it's wrong, please let me know so > I can resend it. > > Thank you and best regards, > Gustavo > > [1] https://netbeans.org/bugzilla/show_bug.cgi?id=238447 > From gromero at linux.vnet.ibm.com Mon Nov 27 13:10:37 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 27 Nov 2017 11:10:37 -0200 Subject: RFR(XXS): 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated bootstrap.url In-Reply-To: <678efe47-b2d5-aa0e-124e-a1e2b00729a3@oracle.com> References: <5A1856DF.7010405@linux.vnet.ibm.com> <678efe47-b2d5-aa0e-124e-a1e2b00729a3@oracle.com> Message-ID: <5A1C0ECD.7040509@linux.vnet.ibm.com> Hi Tobias, On 27-11-2017 08:29, Tobias Hartmann wrote: > this looks good to me. Thanks for fixing! Thanks for reviewing the change. Could you sponsor it? Regards, Gustavo > > Best regards, > Tobias > > On 24.11.2017 18:29, Gustavo Romero wrote: >> Hi, >> >> Please, could the following simple change be reviewed? >> >> It just updates the bootstrap.url variable so IdealGraphVisualizer build can >> find the correct dependencies to succeed. Accordingly to [1] server >> deadlock.netbeans.org is not up anymore. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191868 >> Webrev: http://cr.openjdk.java.net/~gromero/8191868/v1/ >> >> Since this util was before consolidation under hotspot tree this ML was my best >> guest for reviewing such a kind of change. If it's wrong, please let me know so >> I can resend it. >> >> Thank you and best regards, >> Gustavo >> >> [1] https://netbeans.org/bugzilla/show_bug.cgi?id=238447 >> > From zgu at redhat.com Mon Nov 27 13:57:40 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Nov 2017 08:57:40 -0500 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: References: <0ebd16bb-1330-600b-1dc8-f4a53db8638b@redhat.com> Message-ID: <735e0f9b-d634-daf0-b0a4-f2f213e93a6d@redhat.com> Hi, Sorry, I was out for Thanksgiving holiday. The prototype was done under JDK-8190729 (https://bugs.openjdk.java.net/browse/JDK-8190729). The patch uses up to 4 SpecializeChunks for anonymous metadata space, then switches to SmallChunks. It covers well with my testcases, where about 98.5% metadata space size is under 4K. For occasional big anonymous metadata spaces, it starts to allocation SmallChunks after 4K. The reason that it is on hold, is that, it appears to have missed jdk10 train (see comments in bug). Under this circumstance, I would love to test more applications to see size distributions still in neighborhood of the assumption, or should make it another VM parameter (?). Thomas, have you seen the similar size distribution pattern, or otherwise? Thanks, -Zhengyu On 11/24/2017 12:23 PM, Thomas St?fe wrote: > On Fri, Nov 24, 2017 at 10:29 AM, Andrew Dinn wrote: > >> One small additional comment: >> >> On 24/11/17 09:18, Andrew Dinn wrote: >>> On 23/11/17 20:43, Thomas St?fe wrote: >>>> ... >>>> Well, this sounds both simpler and more to the point than my proposal >> (2). >>> >>> Not quite. We know that the "half-eaten-medium-chunk" problem is really >>> a bad problem for anonymous class loaders and Zhengyu's patch improves >>> that case. We don't know it is that is the only problem case. Other >>> loaders may only load a small number of classes -- perhaps 1, maybe 2 -- >>> and also end up wasting a lot of space. If an app hits that case a lot >>> then your proposal would allow the user to configure round it. >> n.b. I'm not sure we need to worry much about any such apps as this >> scenario is, arguably, very unlikely? I know, for example, that JBoss >> Modules uses many classloaders but they rarely load just one or two >> classes. Once you get to 3 or 4 classes I think the current behaviour >> will be unlikely to increase waste because larger chunks means less >> fragmentation. Are OSGi loaders likely to load just one or two classes >> for a significant number of loaders? >> >> > I do not think so. I think you are right, this is less pressing once we get > Zhengyus patch. > I will add the switch when there is some time, I still think it may be good > to have. > > Kind Regards, Thomas > > >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >> From tobias.hartmann at oracle.com Mon Nov 27 14:04:46 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Nov 2017 15:04:46 +0100 Subject: RFR(XXS): 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated bootstrap.url In-Reply-To: <5A1C0ECD.7040509@linux.vnet.ibm.com> References: <5A1856DF.7010405@linux.vnet.ibm.com> <678efe47-b2d5-aa0e-124e-a1e2b00729a3@oracle.com> <5A1C0ECD.7040509@linux.vnet.ibm.com> Message-ID: <6724862e-77a5-72e2-f351-6aa6a3599310@oracle.com> Hi Gustavo, On 27.11.2017 14:10, Gustavo Romero wrote: > Could you sponsor it? Sure, I've pushed it: http://hg.openjdk.java.net/jdk/hs/rev/f140bebf0348 Best regards, Tobias From gromero at linux.vnet.ibm.com Mon Nov 27 14:47:35 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 27 Nov 2017 12:47:35 -0200 Subject: RFR(XXS): 8191868: IdealGraphVisualizer: "ant build/run" fails due to outdated bootstrap.url In-Reply-To: <6724862e-77a5-72e2-f351-6aa6a3599310@oracle.com> References: <5A1856DF.7010405@linux.vnet.ibm.com> <678efe47-b2d5-aa0e-124e-a1e2b00729a3@oracle.com> <5A1C0ECD.7040509@linux.vnet.ibm.com> <6724862e-77a5-72e2-f351-6aa6a3599310@oracle.com> Message-ID: <5A1C2587.6020702@linux.vnet.ibm.com> Hi Tobias, On 27-11-2017 12:04, Tobias Hartmann wrote: > Sure, I've pushed it: > http://hg.openjdk.java.net/jdk/hs/rev/f140bebf0348 Thanks a lot. Regards, Gustavo From coleen.phillimore at oracle.com Mon Nov 27 14:53:51 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Nov 2017 09:53:51 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> Message-ID: Hi, This looks good. http://cr.openjdk.java.net/~kbarrett/8191870/open.00/src/hotspot/share/runtime/globals.hpp.udiff.html Is there a point to this command line option?? It's a develop option- can we just remove it? Thanks, Coleen On 11/25/17 12:35 AM, Kim Barrett wrote: > Please review this change to eliminate badJNIHandle and the special > debug-only handling of it when resolving JNI handles. > > For the intended purpose of catching bad JNI handle usage while > sometimes normalizing some to NULL, we mostly don't need such a > special value. We can instead use NULL directly, and get largely the > same effect. > > By filling blocks with NULL, rather than badJNIHandle, we avoid the > difficulties related to the Access protocol (see the CR). > > A NULL value is sufficient for local and non-weak global handles. A > JNI handle is never allocated to refer to a NULL value; instead, a > NULL handle is used. resolve and friends already treat the case of a > NULL pointee specially (asserting, except in the external guard case, > where it is allowed to pass through). > > Only weak global handles lose the protection afforded by badJNIHandle. > (This is because, unlike local and global handles, a weak global > handle can refer to a NULL value, because it may have been cleared by > the GC.) That protection was already fairly minimal for such handles, > even when using badJNIHandle. That protection only applied for > entries in a newly allocated block that have never yet been allocated. > Blocks in the global lists are currently never released, so the > setting to a "bad" value for released handles never occurs for weak > global handles. So the most interesting use-case for badJNIHandle > (identifying uses of stale handles) doesn't even apply. > > There is one other use of badJNIHandle: throw_unsatisfied_link_error. > This function isn't currently called, only used as a marker. The > discussion in bug 4524377, where that function was added, suggested > using badAddress, so we're replacing badJNIHandle with badAddress. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8191870 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8191870/open.00/ > > Testing: > Mach5 hs-tier1-3 > tonga: nsk.jvmti, nsk.stress, vm.runtime (for various JNI tests) > > From daniel.daugherty at oracle.com Mon Nov 27 15:02:10 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 27 Nov 2017 10:02:10 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> Message-ID: Because it is a 'trueInDebug' option, we only do the ZAP'ing in non-product builds... so we don't take the time to ZAP in product bits. As for the ZAP'ing, it helps us diagnose stale JNI handle usage... Dan On 11/27/17 9:53 AM, coleen.phillimore at oracle.com wrote: > > Hi, This looks good. > > http://cr.openjdk.java.net/~kbarrett/8191870/open.00/src/hotspot/share/runtime/globals.hpp.udiff.html > > > Is there a point to this command line option?? It's a develop option- > can we just remove it? > > Thanks, > Coleen > > On 11/25/17 12:35 AM, Kim Barrett wrote: >> Please review this change to eliminate badJNIHandle and the special >> debug-only handling of it when resolving JNI handles. >> >> For the intended purpose of catching bad JNI handle usage while >> sometimes normalizing some to NULL, we mostly don't need such a >> special value. We can instead use NULL directly, and get largely the >> same effect. >> >> By filling blocks with NULL, rather than badJNIHandle, we avoid the >> difficulties related to the Access protocol (see the CR). >> >> A NULL value is sufficient for local and non-weak global handles.? A >> JNI handle is never allocated to refer to a NULL value; instead, a >> NULL handle is used.? resolve and friends already treat the case of a >> NULL pointee specially (asserting, except in the external guard case, >> where it is allowed to pass through). >> >> Only weak global handles lose the protection afforded by badJNIHandle. >> (This is because, unlike local and global handles, a weak global >> handle can refer to a NULL value, because it may have been cleared by >> the GC.)? That protection was already fairly minimal for such handles, >> even when using badJNIHandle.? That protection only applied for >> entries in a newly allocated block that have never yet been allocated. >> Blocks in the global lists are currently never released, so the >> setting to a "bad" value for released handles never occurs for weak >> global handles.? So the most interesting use-case for badJNIHandle >> (identifying uses of stale handles) doesn't even apply. >> >> There is one other use of badJNIHandle: throw_unsatisfied_link_error. >> This function isn't currently called, only used as a marker. The >> discussion in bug 4524377, where that function was added, suggested >> using badAddress, so we're replacing badJNIHandle with badAddress. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8191870 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8191870/open.00/ >> >> Testing: >> Mach5 hs-tier1-3 >> tonga: nsk.jvmti, nsk.stress, vm.runtime (for various JNI tests) >> >> > From coleen.phillimore at oracle.com Mon Nov 27 15:19:20 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Nov 2017 10:19:20 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> Message-ID: My question was why there's a command line option, which seems like nobody on earth should use it.? Yes, we don't need to zap for product, only for debug. Coleen On 11/27/17 10:02 AM, Daniel D. Daugherty wrote: > Because it is a 'trueInDebug' option, we only do the ZAP'ing in > non-product > builds... so we don't take the time to ZAP in product bits. As for the > ZAP'ing, > it helps us diagnose stale JNI handle usage... > > Dan > > > On 11/27/17 9:53 AM, coleen.phillimore at oracle.com wrote: >> >> Hi, This looks good. >> >> http://cr.openjdk.java.net/~kbarrett/8191870/open.00/src/hotspot/share/runtime/globals.hpp.udiff.html >> >> >> Is there a point to this command line option?? It's a develop option- >> can we just remove it? >> >> Thanks, >> Coleen >> >> On 11/25/17 12:35 AM, Kim Barrett wrote: >>> Please review this change to eliminate badJNIHandle and the special >>> debug-only handling of it when resolving JNI handles. >>> >>> For the intended purpose of catching bad JNI handle usage while >>> sometimes normalizing some to NULL, we mostly don't need such a >>> special value. We can instead use NULL directly, and get largely the >>> same effect. >>> >>> By filling blocks with NULL, rather than badJNIHandle, we avoid the >>> difficulties related to the Access protocol (see the CR). >>> >>> A NULL value is sufficient for local and non-weak global handles.? A >>> JNI handle is never allocated to refer to a NULL value; instead, a >>> NULL handle is used.? resolve and friends already treat the case of a >>> NULL pointee specially (asserting, except in the external guard case, >>> where it is allowed to pass through). >>> >>> Only weak global handles lose the protection afforded by badJNIHandle. >>> (This is because, unlike local and global handles, a weak global >>> handle can refer to a NULL value, because it may have been cleared by >>> the GC.)? That protection was already fairly minimal for such handles, >>> even when using badJNIHandle.? That protection only applied for >>> entries in a newly allocated block that have never yet been allocated. >>> Blocks in the global lists are currently never released, so the >>> setting to a "bad" value for released handles never occurs for weak >>> global handles.? So the most interesting use-case for badJNIHandle >>> (identifying uses of stale handles) doesn't even apply. >>> >>> There is one other use of badJNIHandle: throw_unsatisfied_link_error. >>> This function isn't currently called, only used as a marker. The >>> discussion in bug 4524377, where that function was added, suggested >>> using badAddress, so we're replacing badJNIHandle with badAddress. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8191870 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8191870/open.00/ >>> >>> Testing: >>> Mach5 hs-tier1-3 >>> tonga: nsk.jvmti, nsk.stress, vm.runtime (for various JNI tests) >>> >>> >> > From karen.kinnear at oracle.com Mon Nov 27 15:24:17 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 27 Nov 2017 10:24:17 -0500 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: <735e0f9b-d634-daf0-b0a4-f2f213e93a6d@redhat.com> References: <0ebd16bb-1330-600b-1dc8-f4a53db8638b@redhat.com> <735e0f9b-d634-daf0-b0a4-f2f213e93a6d@redhat.com> Message-ID: <4ABD0585-AF54-4503-9F68-2A18639B8C26@oracle.com> First, many thanks for all the work in this area - it is a very important one. Zhengyu?s fix seems like a good first step here. Coleen asked David Holmes and I how this relates to the future of nestmates. The nestmate relationship here is a the plan in jdk 11 to evolve away from Unsafe.DefineAnonymousClass. In jdk 10 Alan added Lookup.defineClass(byte[]) which operates in Package Mode to allow you to create a findable class in the same package/class loader/protection domain as the caller in the Lookup object. The intention is to extend Lookup.defineClass() in two dimensions. The first is to allow dynamic creation of nestmates of the Lookup?s caller, based on the authority granted by having a Lookup with lookup mode private. This nest mate would not only be in the same package/class loader/protection domain, it would be granted nest mate access to private members declared in the nest of the Lookup?s caller. The second dimension we want to expand is the evolution of Unsafe.DefineAnonymousClass by added a boolean that can allow creating non-findable, temporary classes - which can therefore be unloaded independently of any other references to a given class loader. When customers adopt this, we will see an increase in the need to unload individual classes for existing class loaders. In terms of the isolated methods question - I do not know exactly what John Rose?s vision is here. I do know that in discussions with Michael Haupt, in feedback from the JVMLS 2016 at which he introduced it, that there is interest in information regarding isolated methods (sorry, I really think independent method might be a better name) such as - constant pool constants for the byte codes - debug information such as line number tables - ability to invoke bootstrap methods, so attributes of some form ? My understanding is that the lifecycle of these methods would be temporary, controlled by the lifecycle of the MethodHandle representing them. My point here is - that these methods will require some set of temporary metadata, much of which is similar to the metadata we currently need to execute a method, so we will need a place to store it. At this point it is not clear to me that this would obviate the need for a good way to store/free temporary metadata. thanks, Karen > On Nov 27, 2017, at 8:57 AM, Zhengyu Gu wrote: > > Hi, > > Sorry, I was out for Thanksgiving holiday. > > The prototype was done under JDK-8190729 (https://bugs.openjdk.java.net/browse/JDK-8190729). > > The patch uses up to 4 SpecializeChunks for anonymous metadata space, then switches to SmallChunks. It covers well with my testcases, where about 98.5% metadata space size is under 4K. For occasional big anonymous metadata spaces, it starts to allocation SmallChunks after 4K. > > The reason that it is on hold, is that, it appears to have missed jdk10 train (see comments in bug). Under this circumstance, I would love to test more applications to see size distributions still in neighborhood of the assumption, or should make it another VM parameter (?). > > Thomas, have you seen the similar size distribution pattern, or otherwise? > > > Thanks, > > -Zhengyu > > > > On 11/24/2017 12:23 PM, Thomas St?fe wrote: >> On Fri, Nov 24, 2017 at 10:29 AM, Andrew Dinn wrote: >>> One small additional comment: >>> >>> On 24/11/17 09:18, Andrew Dinn wrote: >>>> On 23/11/17 20:43, Thomas St?fe wrote: >>>>> ... >>>>> Well, this sounds both simpler and more to the point than my proposal >>> (2). >>>> >>>> Not quite. We know that the "half-eaten-medium-chunk" problem is really >>>> a bad problem for anonymous class loaders and Zhengyu's patch improves >>>> that case. We don't know it is that is the only problem case. Other >>>> loaders may only load a small number of classes -- perhaps 1, maybe 2 -- >>>> and also end up wasting a lot of space. If an app hits that case a lot >>>> then your proposal would allow the user to configure round it. >>> n.b. I'm not sure we need to worry much about any such apps as this >>> scenario is, arguably, very unlikely? I know, for example, that JBoss >>> Modules uses many classloaders but they rarely load just one or two >>> classes. Once you get to 3 or 4 classes I think the current behaviour >>> will be unlikely to increase waste because larger chunks means less >>> fragmentation. Are OSGi loaders likely to load just one or two classes >>> for a significant number of loaders? >>> >>> >> I do not think so. I think you are right, this is less pressing once we get >> Zhengyus patch. >> I will add the switch when there is some time, I still think it may be good >> to have. >> Kind Regards, Thomas >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> Senior Principal Software Engineer >>> Red Hat UK Ltd >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >>> From dmitry.samersoff at bell-sw.com Mon Nov 27 15:30:42 2017 From: dmitry.samersoff at bell-sw.com (Dmitry Samersov) Date: Mon, 27 Nov 2017 18:30:42 +0300 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> Message-ID: Andrew, > http://cr.openjdk.java.net/~aph/8189596-2 1. interp_masm_aarch64.cpp 456 if (needs_thread_local_poll) { It might be better to put the code related to needs_thread_local_poll into the single block for better readability. Approx : if (needs_thread_local_poll) { NOT_PRODUCT(block_comment("Thread-local Safepoint poll")); ldr(rscratch2, Address(rthread, Thread::polling_page_offset())); tbz(rscratch2, exact_log2(SafepointMechanism::poll_bit()), notsafepoint); lea(rscratch2, ExternalAddress((address)safepoint_table)); ldr(rscratch2, Address(rscratch2, rscratch1, Address::uxtw(3))); br(rscratch2); } bind(notsafepoint); 2. macroAssembler_aarch64.cpp 321 safepoint_poll(slow_path); It might be better to put global poll code to a separate function, to avoid double checking of SafepointMechanism::uses_thread_local_poll() 3. templateInterpreterGenerator_aarch64.cpp : 1382 1382 __ safepoint_poll_acquire(L); Do we really need acquire here? -Dmitry On 24.11.2017 20:39, Andrew Haley wrote: > On 24/11/17 10:36, Erik ?sterlund wrote: >> By placing loading the local poll value with ldar *only* in the native >> wrapper wakeup function, you avoid these issues. > > OK, thanks. > > http://cr.openjdk.java.net/~aph/8189596-2 > From erik.osterlund at oracle.com Mon Nov 27 15:33:58 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 27 Nov 2017 16:33:58 +0100 Subject: RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API Message-ID: <5A1C3066.7050502@oracle.com> Hi, The ResolvedMethodTable has weak oop references in it. Currently it uses explicit SATB enqueueing for G1 to make the weak semantics work. This should be refactored to use the Access API instead. The previous raw loads should be ON_PHANTOM_OOP | AS_NO_KEEPALIVE and the loads followed by explicit G1 SATB enqueueing should be ON_PHANTOM_OOP. Webrev: http://cr.openjdk.java.net/~eosterlund/8191904/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8191904 Thanks, /Erik From aph at redhat.com Mon Nov 27 15:47:11 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Nov 2017 15:47:11 +0000 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> Message-ID: <47862e40-9f57-a0d6-a20c-6fd5ac5c1177@redhat.com> On 27/11/17 15:30, Dmitry Samersov wrote: > Andrew, > >> http://cr.openjdk.java.net/~aph/8189596-2 > > 1. interp_masm_aarch64.cpp > > 456 if (needs_thread_local_poll) { > > It might be better to put the code related to needs_thread_local_poll > into the single block for better readability. > > Approx : > > if (needs_thread_local_poll) { > NOT_PRODUCT(block_comment("Thread-local Safepoint poll")); > ldr(rscratch2, Address(rthread, Thread::polling_page_offset())); > tbz(rscratch2, exact_log2(SafepointMechanism::poll_bit()), notsafepoint); > > lea(rscratch2, ExternalAddress((address)safepoint_table)); > ldr(rscratch2, Address(rscratch2, rscratch1, Address::uxtw(3))); > br(rscratch2); > > } > > bind(notsafepoint); I didn't want to do that because I wanted to put the uncommon case out of line. In any case, I don't think it warrants a respin. > 2. macroAssembler_aarch64.cpp > > 321 safepoint_poll(slow_path); > > It might be better to put global poll code to a separate function, to > avoid double checking of SafepointMechanism::uses_thread_local_poll(); We don't need to do it for efficiency because GCC already knows how to do that. I can't think of any other reason we'd want to change it. > 3. templateInterpreterGenerator_aarch64.cpp : 1382 > > 1382 __ safepoint_poll_acquire(L); > > Do we really need acquire here? I believe so,, for the reason discussed upthread. We need to do it whenever transitioning from native to Java state. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Mon Nov 27 15:55:19 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 27 Nov 2017 16:55:19 +0100 Subject: RFR(S): 8191863: [s390] Fix CDS: some bytecode rewriting doesn't depend on RewriteControl Message-ID: Hi, can I please have a review for the following small, s390-only change which fixes CDS on s390: http://cr.openjdk.java.net/~simonis/webrevs/2017/8191863/ https://bugs.openjdk.java.net/browse/JDK-8191863 The problem was that mistakenly rewrote zputfield into fast_zputfield although the active RewriteControl instance indicated that we shouldn't rewrite bytecodes. With this change, all the CDS and upcoming AppCDS jtreg pass on Linux/s390. Thank you and best regards, Volker From volker.simonis at gmail.com Mon Nov 27 15:55:27 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 27 Nov 2017 16:55:27 +0100 Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces Message-ID: Hi, can I please have a review for the following small, ppc64-only change which fixes CDS on Power: http://cr.openjdk.java.net/~simonis/webrevs/2017/8191770/ https://bugs.openjdk.java.net/browse/JDK-8191770 Don't rewrite invokefinal into fast_invokevfinal if running with DumpSharedSpaces or UseSharedSpaces. The Template-Interpreter of the ppc-Port was initially derived from the SPARC version which didn't had full CDS support at that time, that's why the guard against DumpSharedSpaces was missing at the place where invokefinal is rewritten. With this change, all the CDS and upcoming AppCDS jtreg pass on Linux/ppc64, Linux/ppc64le and AIX. Thank you and best regards, Volker From martin.doerr at sap.com Mon Nov 27 16:05:04 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 27 Nov 2017 16:05:04 +0000 Subject: RFR(S): 8191863: [s390] Fix CDS: some bytecode rewriting doesn't depend on RewriteControl In-Reply-To: References: Message-ID: <23e5c33654654ed184d1fbc80b54c652@sap.com> Hi Volker, looks good. Thanks for fixing. Best regards, Martin -----Original Message----- From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Montag, 27. November 2017 16:55 To: HotSpot Open Source Developers Cc: s390x-port-dev at openjdk.java.net Subject: RFR(S): 8191863: [s390] Fix CDS: some bytecode rewriting doesn't depend on RewriteControl Hi, can I please have a review for the following small, s390-only change which fixes CDS on s390: http://cr.openjdk.java.net/~simonis/webrevs/2017/8191863/ https://bugs.openjdk.java.net/browse/JDK-8191863 The problem was that mistakenly rewrote zputfield into fast_zputfield although the active RewriteControl instance indicated that we shouldn't rewrite bytecodes. With this change, all the CDS and upcoming AppCDS jtreg pass on Linux/s390. Thank you and best regards, Volker From martin.doerr at sap.com Mon Nov 27 16:05:17 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 27 Nov 2017 16:05:17 +0000 Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces In-Reply-To: References: Message-ID: <76c7e1c810bd4d7eadb243a163f1bb7a@sap.com> Hi Volker, looks good. Thanks for fixing. Best regards, Martin -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis Sent: Montag, 27. November 2017 16:55 To: HotSpot Open Source Developers Cc: ppc-aix-port-dev at openjdk.java.net Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces Hi, can I please have a review for the following small, ppc64-only change which fixes CDS on Power: http://cr.openjdk.java.net/~simonis/webrevs/2017/8191770/ https://bugs.openjdk.java.net/browse/JDK-8191770 Don't rewrite invokefinal into fast_invokevfinal if running with DumpSharedSpaces or UseSharedSpaces. The Template-Interpreter of the ppc-Port was initially derived from the SPARC version which didn't had full CDS support at that time, that's why the guard against DumpSharedSpaces was missing at the place where invokefinal is rewritten. With this change, all the CDS and upcoming AppCDS jtreg pass on Linux/ppc64, Linux/ppc64le and AIX. Thank you and best regards, Volker From zgu at redhat.com Mon Nov 27 17:09:18 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Nov 2017 12:09:18 -0500 Subject: RFR(XXS) 8190729: Adjustment to anonymous metadata space chunk allocation algorithm Message-ID: <96f500fa-7628-bbc0-637f-c819480f7d46@redhat.com> Hi, To follow up recent discussion of anonymous metadata space memory usage, I would like submit this simple fix for review. By continuing allocating anonymous metadata space from SpecializeChunk pool, up to 4 chunks, it reduces the waste from 60+% to about 30%. Bug: https://bugs.openjdk.java.net/browse/JDK-8190729 Webrev: http://cr.openjdk.java.net/~zgu/8190729/webrev.00/ Test: hotspot_tier1_runtime on Linux x64 (fastdebug and release) Thanks, -Zhengyu From volker.simonis at gmail.com Mon Nov 27 17:16:51 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 27 Nov 2017 18:16:51 +0100 Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces In-Reply-To: <76c7e1c810bd4d7eadb243a163f1bb7a@sap.com> References: <76c7e1c810bd4d7eadb243a163f1bb7a@sap.com> Message-ID: Thanks Martin! On Mon, Nov 27, 2017 at 5:05 PM, Doerr, Martin wrote: > Hi Volker, > > looks good. Thanks for fixing. > > Best regards, > Martin > > > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis > Sent: Montag, 27. November 2017 16:55 > To: HotSpot Open Source Developers > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces > > Hi, > > can I please have a review for the following small, ppc64-only change > which fixes CDS on Power: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/8191770/ > https://bugs.openjdk.java.net/browse/JDK-8191770 > > Don't rewrite invokefinal into fast_invokevfinal if running with > DumpSharedSpaces or UseSharedSpaces. > > The Template-Interpreter of the ppc-Port was initially derived from > the SPARC version which didn't had full CDS support at that time, > that's why the guard against DumpSharedSpaces was missing at the place > where invokefinal is rewritten. > > With this change, all the CDS and upcoming AppCDS jtreg pass on > Linux/ppc64, Linux/ppc64le and AIX. > > Thank you and best regards, > Volker From volker.simonis at gmail.com Mon Nov 27 17:17:26 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 27 Nov 2017 18:17:26 +0100 Subject: RFR(S): 8191863: [s390] Fix CDS: some bytecode rewriting doesn't depend on RewriteControl In-Reply-To: <23e5c33654654ed184d1fbc80b54c652@sap.com> References: <23e5c33654654ed184d1fbc80b54c652@sap.com> Message-ID: Thanks Martin! Regards, Volker On Mon, Nov 27, 2017 at 5:05 PM, Doerr, Martin wrote: > Hi Volker, > > looks good. Thanks for fixing. > > Best regards, > Martin > > > -----Original Message----- > From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Volker Simonis > Sent: Montag, 27. November 2017 16:55 > To: HotSpot Open Source Developers > Cc: s390x-port-dev at openjdk.java.net > Subject: RFR(S): 8191863: [s390] Fix CDS: some bytecode rewriting doesn't depend on RewriteControl > > Hi, > > can I please have a review for the following small, s390-only change > which fixes CDS on s390: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/8191863/ > https://bugs.openjdk.java.net/browse/JDK-8191863 > > The problem was that mistakenly rewrote zputfield into fast_zputfield > although the active RewriteControl instance indicated that we > shouldn't rewrite bytecodes. > > With this change, all the CDS and upcoming AppCDS jtreg pass on Linux/s390. > > Thank you and best regards, > Volker From coleen.phillimore at oracle.com Mon Nov 27 18:33:05 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Nov 2017 13:33:05 -0500 Subject: RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API In-Reply-To: <5A1C3066.7050502@oracle.com> References: <5A1C3066.7050502@oracle.com> Message-ID: <96f537c5-c64a-1b66-089f-ba8a4b572f6b@oracle.com> This looks good.?? I think we should make the literal() function in this hashtable a pure virtual function and ShouldNotReachHere to not allow it for these classes derived from oop. BTW, should we expect a StringTable and ProtectionDomainEntryTable change as well?? The latter is missing the SATB barrier at the moment. Coleen On 11/27/17 10:33 AM, Erik ?sterlund wrote: > Hi, > > The ResolvedMethodTable has weak oop references in it. Currently it > uses explicit SATB enqueueing for G1 to make the weak semantics work. > > This should be refactored to use the Access API instead. The previous > raw loads should be ON_PHANTOM_OOP | AS_NO_KEEPALIVE and the loads > followed by explicit G1 SATB enqueueing should be ON_PHANTOM_OOP. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8191904/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8191904 > > Thanks, > /Erik From thomas.stuefe at gmail.com Mon Nov 27 18:36:51 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 27 Nov 2017 19:36:51 +0100 Subject: RFR(XXS) 8190729: Adjustment to anonymous metadata space chunk allocation algorithm In-Reply-To: <96f500fa-7628-bbc0-637f-c819480f7d46@redhat.com> References: <96f500fa-7628-bbc0-637f-c819480f7d46@redhat.com> Message-ID: Hi Zhengyu, looks good. (I wonder whether if you just could have given the SpaceManager a back pointer to its enclosing Metaspace instead of handing down _space_type and mdType, but then, those are cleanups we can do later.) In SpaceManager, could you please make _space_type - and _mdtype too - const? Why do you do this only for non-class metaspace? Could please you embellish the comment in calc_chunk_size() a bit? Would it be possible to have a regression test for this one, maybe as part of the NMT tests? So that if we change the allocator logic in the future, we can be sure not to reintroduce that bug. To me, it would be okay to do this in a follow up item, if you are concerned about the jdk10 code freeze. Thank you, Kind Regards, Thomas On Mon, Nov 27, 2017 at 6:09 PM, Zhengyu Gu wrote: > Hi, > > To follow up recent discussion of anonymous metadata space memory usage, I > would like submit this simple fix for review. > > By continuing allocating anonymous metadata space from SpecializeChunk > pool, up to 4 chunks, it reduces the waste from 60+% to about 30%. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190729 > Webrev: http://cr.openjdk.java.net/~zgu/8190729/webrev.00/ > > Test: > > hotspot_tier1_runtime on Linux x64 (fastdebug and release) > > > Thanks, > > -Zhengyu > From thomas.stuefe at gmail.com Mon Nov 27 18:47:09 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 27 Nov 2017 19:47:09 +0100 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: <735e0f9b-d634-daf0-b0a4-f2f213e93a6d@redhat.com> References: <0ebd16bb-1330-600b-1dc8-f4a53db8638b@redhat.com> <735e0f9b-d634-daf0-b0a4-f2f213e93a6d@redhat.com> Message-ID: Hi Zhengyu, On Mon, Nov 27, 2017 at 2:57 PM, Zhengyu Gu wrote: > Hi, > > Sorry, I was out for Thanksgiving holiday. > > The prototype was done under JDK-8190729 (https://bugs.openjdk.java.net > /browse/JDK-8190729). > > The patch uses up to 4 SpecializeChunks for anonymous metadata space, then > switches to SmallChunks. It covers well with my testcases, where about > 98.5% metadata space size is under 4K. For occasional big anonymous > metadata spaces, it starts to allocation SmallChunks after 4K. > > The reason that it is on hold, is that, it appears to have missed jdk10 > train (see comments in bug). Under this circumstance, I would love to test > more applications to see size distributions still in neighborhood of the > assumption, or should make it another VM parameter (?). > > Thomas, have you seen the similar size distribution pattern, or otherwise? > > Cannot say for sure. My personal tests are not a big help, they are completely artificial. I dug around in old logs for customer problems but did not find any cases which clearly matched your problem. I had one case with tons of tiny reflection class loaders, but those rarely allocated more than one spec chunk. In any case, I think the 4K limit sounds reasonable. Would be fine to get this into jdk10. Should we later want to change the limit, that would be a simple change and could easily be backported, yes? Thanks, Thomas > > Thanks, > > -Zhengyu > > > > > On 11/24/2017 12:23 PM, Thomas St?fe wrote: > >> On Fri, Nov 24, 2017 at 10:29 AM, Andrew Dinn wrote: >> >> One small additional comment: >>> >>> On 24/11/17 09:18, Andrew Dinn wrote: >>> >>>> On 23/11/17 20:43, Thomas St?fe wrote: >>>> >>>>> ... >>>>> Well, this sounds both simpler and more to the point than my proposal >>>>> >>>> (2). >>> >>>> >>>> Not quite. We know that the "half-eaten-medium-chunk" problem is really >>>> a bad problem for anonymous class loaders and Zhengyu's patch improves >>>> that case. We don't know it is that is the only problem case. Other >>>> loaders may only load a small number of classes -- perhaps 1, maybe 2 -- >>>> and also end up wasting a lot of space. If an app hits that case a lot >>>> then your proposal would allow the user to configure round it. >>>> >>> n.b. I'm not sure we need to worry much about any such apps as this >>> scenario is, arguably, very unlikely? I know, for example, that JBoss >>> Modules uses many classloaders but they rarely load just one or two >>> classes. Once you get to 3 or 4 classes I think the current behaviour >>> will be unlikely to increase waste because larger chunks means less >>> fragmentation. Are OSGi loaders likely to load just one or two classes >>> for a significant number of loaders? >>> >>> >>> I do not think so. I think you are right, this is less pressing once we >> get >> Zhengyus patch. >> I will add the switch when there is some time, I still think it may be >> good >> to have. >> >> Kind Regards, Thomas >> >> >> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> Senior Principal Software Engineer >>> Red Hat UK Ltd >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >>> >>> From zgu at redhat.com Mon Nov 27 19:11:45 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Nov 2017 14:11:45 -0500 Subject: Any new ideas on JDK-8187338 (Per anonymous class class loader data is costly)? In-Reply-To: References: <0ebd16bb-1330-600b-1dc8-f4a53db8638b@redhat.com> <735e0f9b-d634-daf0-b0a4-f2f213e93a6d@redhat.com> Message-ID: <09e446c2-5f3f-b13c-5638-357f4ca66d27@redhat.com> Hi Thomas, On 11/27/2017 01:47 PM, Thomas St?fe wrote: > Hi Zhengyu, > > On Mon, Nov 27, 2017 at 2:57 PM, Zhengyu Gu > wrote: > > Hi, > > Sorry, I was out for Thanksgiving holiday. > > > The prototype was done under JDK-8190729 > (https://bugs.openjdk.java.net/browse/JDK-8190729 > ). > > The patch uses up to 4 SpecializeChunks for anonymous metadata > space, then switches to SmallChunks. It covers well with my > testcases, where about 98.5% metadata space size is under 4K. For > occasional big anonymous metadata spaces, it starts to allocation > SmallChunks after 4K. > > The reason that it is on hold, is that, it appears to have missed > jdk10 train (see comments in bug). Under this circumstance, I would > love to test more applications to see size distributions still in > neighborhood of the assumption, or should make it another VM > parameter (?). > > Thomas, have you seen the similar size distribution pattern, or > otherwise? > > > Cannot say for sure. My personal tests are not a big help, they are > completely artificial. > > I dug around in old logs for customer problems but did not find any > cases which clearly matched your problem. I had one case with tons of > tiny reflection class loaders, but those rarely allocated more than one > spec chunk. Yes, I saw similar pattern with DelegatingClassLoader, however, I did not address it in this patch. I filed 8191924 (https://bugs.openjdk.java.net/browse/JDK-8191924) to track it separately. > > In any case, I think the 4K limit sounds reasonable. Would be fine to > get this into jdk10. Should we later want to change the limit, that > would be a simple change and could easily be backported, yes? Yes, the changes is rather confined and should be easy to backport. However, I am not sure it can get into jdk10, as it is target to jdk11. Thanks, -Zhengyu > > Thanks, Thomas > > > Thanks, > > -Zhengyu > > > > > On 11/24/2017 12:23 PM, Thomas St?fe wrote: > > On Fri, Nov 24, 2017 at 10:29 AM, Andrew Dinn > wrote: > > One small additional comment: > > On 24/11/17 09:18, Andrew Dinn wrote: > > On 23/11/17 20:43, Thomas St?fe wrote: > > ... > Well, this sounds both simpler and more to the point > than my proposal > > (2). > > > Not quite. We know that the "half-eaten-medium-chunk" > problem is really > a bad problem for anonymous class loaders and Zhengyu's > patch improves > that case. We don't know it is that is the only problem > case. Other > loaders may only load a small number of classes -- > perhaps 1, maybe 2 -- > and also end up wasting a lot of space. If an app hits > that case a lot > then your proposal would allow the user to configure > round it. > > n.b. I'm not sure we need to worry much about any such apps > as this > scenario is, arguably, very unlikely? I know, for example, > that JBoss > Modules uses many classloaders but they rarely load just one > or two > classes. Once you get to 3 or 4 classes I think the current > behaviour > will be unlikely to increase waste because larger chunks > means less > fragmentation. Are OSGi loaders likely to load just one or > two classes > for a significant number of loaders? > > > I do not think so. I think you are right, this is less pressing > once we get > Zhengyus patch. > I will add the switch when there is some time, I still think it > may be good > to have. > > Kind Regards, Thomas > > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration > No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, > Eric Shander > > From jiangli.zhou at oracle.com Mon Nov 27 19:22:45 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 27 Nov 2017 11:22:45 -0800 Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces In-Reply-To: References: Message-ID: Hi Volker, This looks good. Thanks, Jiangli > On Nov 27, 2017, at 7:55 AM, Volker Simonis wrote: > > Hi, > > can I please have a review for the following small, ppc64-only change > which fixes CDS on Power: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/8191770/ > https://bugs.openjdk.java.net/browse/JDK-8191770 > > Don't rewrite invokefinal into fast_invokevfinal if running with > DumpSharedSpaces or UseSharedSpaces. > > The Template-Interpreter of the ppc-Port was initially derived from > the SPARC version which didn't had full CDS support at that time, > that's why the guard against DumpSharedSpaces was missing at the place > where invokefinal is rewritten. > > With this change, all the CDS and upcoming AppCDS jtreg pass on > Linux/ppc64, Linux/ppc64le and AIX. > > Thank you and best regards, > Volker From zgu at redhat.com Mon Nov 27 19:38:26 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Nov 2017 14:38:26 -0500 Subject: RFR(XXS) 8190729: Adjustment to anonymous metadata space chunk allocation algorithm In-Reply-To: References: <96f500fa-7628-bbc0-637f-c819480f7d46@redhat.com> Message-ID: Hi Thomas, Thanks for the quick review. On 11/27/2017 01:36 PM, Thomas St?fe wrote: > Hi Zhengyu, > > looks good. > > (I wonder whether if you just could have given the SpaceManager a back > pointer to its enclosing Metaspace instead of handing down _space_type > and mdType, but then, those are cleanups we can do later.) > > In SpaceManager, could you please make _space_type - and _mdtype too - > const? Fixed. > > Why do you do this only for non-class metaspace? Cause I have yet seen any anonymous class space above 1K, I would rather leave them alone. > > Could please you embellish the comment in calc_chunk_size() a bit? Done. > > Would it be possible to have a regression test for this one, maybe as > part of the NMT tests? So that if we change the allocator logic in the > future, we can be sure not to reintroduce that bug. To me, it would be > okay to do this in a follow up item, if you are concerned about the > jdk10 code freeze. Probably gtest or JVM internal test (?), I will have to learn how to write one. Updated webrev: http://cr.openjdk.java.net/~zgu/8190729/webrev.01/ Thanks, -Zhengyu > Thank you, > > Kind Regards, Thomas > > > On Mon, Nov 27, 2017 at 6:09 PM, Zhengyu Gu > wrote: > > Hi, > > To follow up recent discussion of anonymous metadata space memory > usage, I would like submit this simple fix for review. > > By continuing allocating anonymous metadata space from > SpecializeChunk pool, up to 4 chunks, it reduces the waste from 60+% > to about 30%. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190729 > > Webrev: http://cr.openjdk.java.net/~zgu/8190729/webrev.00/ > > > Test: > > hotspot_tier1_runtime on Linux x64 (fastdebug and release) > > > Thanks, > > -Zhengyu > > From jiangli.zhou at oracle.com Mon Nov 27 19:51:17 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 27 Nov 2017 11:51:17 -0800 Subject: RFR(S): 8191863: [s390] Fix CDS: some bytecode rewriting doesn't depend on RewriteControl In-Reply-To: References: Message-ID: This change matches with other platforms. Looks good. Thanks, Jiangli > On Nov 27, 2017, at 7:55 AM, Volker Simonis wrote: > > Hi, > > can I please have a review for the following small, s390-only change > which fixes CDS on s390: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/8191863/ > https://bugs.openjdk.java.net/browse/JDK-8191863 > > The problem was that mistakenly rewrote zputfield into fast_zputfield > although the active RewriteControl instance indicated that we > shouldn't rewrite bytecodes. > > With this change, all the CDS and upcoming AppCDS jtreg pass on Linux/s390. > > Thank you and best regards, > Volker From thomas.stuefe at gmail.com Mon Nov 27 19:59:48 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 27 Nov 2017 20:59:48 +0100 Subject: RFR(XXS) 8190729: Adjustment to anonymous metadata space chunk allocation algorithm In-Reply-To: References: <96f500fa-7628-bbc0-637f-c819480f7d46@redhat.com> Message-ID: Hi Zhengyu, On Mon, Nov 27, 2017 at 8:38 PM, Zhengyu Gu wrote: > Hi Thomas, > > Thanks for the quick review. > > On 11/27/2017 01:36 PM, Thomas St?fe wrote: > >> Hi Zhengyu, >> >> looks good. >> >> (I wonder whether if you just could have given the SpaceManager a back >> pointer to its enclosing Metaspace instead of handing down _space_type and >> mdType, but then, those are cleanups we can do later.) >> >> In SpaceManager, could you please make _space_type - and _mdtype too - >> const? >> > Fixed. > > >> Why do you do this only for non-class metaspace? >> > > Cause I have yet seen any anonymous class space above 1K, I would rather > leave them alone. > > Also it occurred to me that the use of "SpecializedChunk" enum implies non-class metaspace, otherwise we would have to use "ClassSpecializedChunk" (they currently have identical values, but that may change). So, in its current form, this patch is clearly bound to Non-Class metaspace. I think the change makes sense and is minimal invasive. But I still wish we could do things simpler, maybe as part of a future cleanup? All this information we hand down to the SpaceManager is just there to help him to decide on a chunk-size-progression strategy. If we could come up with a more general way to specify such a strategy (e.g. - from the top of my head - a list of size-threshold-to-next-chunk-size tupels) - SpaceManager would not need any special knowledge about mdType, space type, chunk sizes etc. and would in turn become quite a bit simpler. > >> Could please you embellish the comment in calc_chunk_size() a bit? >> > Done. > > Thanks, comment is good. > >> Would it be possible to have a regression test for this one, maybe as >> part of the NMT tests? So that if we change the allocator logic in the >> future, we can be sure not to reintroduce that bug. To me, it would be okay >> to do this in a follow up item, if you are concerned about the jdk10 code >> freeze. >> > > Probably gtest or JVM internal test (?), I will have to learn how to write > one. > > > jtreg tests would be the most fitting. Quite easy to write actually. Some examples are here: /test/hotspot/jtreg/runtime/NMT/ > Updated webrev: http://cr.openjdk.java.net/~zgu/8190729/webrev.01/ > > Thanks, > > -Zhengyu > > Thanks. To me, change looks good. No need for a new review. ..Thomas > > > Thank you, >> >> Kind Regards, Thomas >> >> >> On Mon, Nov 27, 2017 at 6:09 PM, Zhengyu Gu > zgu at redhat.com>> wrote: >> >> Hi, >> >> To follow up recent discussion of anonymous metadata space memory >> usage, I would like submit this simple fix for review. >> >> By continuing allocating anonymous metadata space from >> SpecializeChunk pool, up to 4 chunks, it reduces the waste from 60+% >> to about 30%. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190729 >> >> Webrev: http://cr.openjdk.java.net/~zgu/8190729/webrev.00/ >> >> >> Test: >> >> hotspot_tier1_runtime on Linux x64 (fastdebug and release) >> >> >> Thanks, >> >> -Zhengyu >> >> >> From kim.barrett at oracle.com Mon Nov 27 20:21:55 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Nov 2017 15:21:55 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> Message-ID: > On Nov 27, 2017, at 10:19 AM, coleen.phillimore at oracle.com wrote: > > > My question was why there's a command line option, which seems like nobody on earth should use it. Yes, we don't need to zap for product, only for debug. So remove the CLA and instead #ifdef ASSERT the zapping. I?d be okay with that. Another CLA bites the dust. From coleen.phillimore at oracle.com Mon Nov 27 20:43:43 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Nov 2017 15:43:43 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> Message-ID: <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> On 11/27/17 3:21 PM, Kim Barrett wrote: >> On Nov 27, 2017, at 10:19 AM, coleen.phillimore at oracle.com wrote: >> >> >> My question was why there's a command line option, which seems like nobody on earth should use it. Yes, we don't need to zap for product, only for debug. > So remove the CLA and instead #ifdef ASSERT the zapping. Yes. > > I?d be okay with that. Another CLA bites the dust. What looks like a pointless one at that. Coleen > > From zgu at redhat.com Mon Nov 27 20:59:38 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Nov 2017 15:59:38 -0500 Subject: RFR(XXS) 8190729: Adjustment to anonymous metadata space chunk allocation algorithm In-Reply-To: References: <96f500fa-7628-bbc0-637f-c819480f7d46@redhat.com> Message-ID: <8d316bce-6248-03dc-ab25-9cafb5b9229a@redhat.com> > > > > jtreg tests would be the most fitting. Quite easy to write actually. > Some examples are here: > > /test/hotspot/jtreg/runtime/NMT/ Okay, I filed 8191931 (https://bugs.openjdk.java.net/browse/JDK-8191931) for the test. Thanks, -Zhengyu > > Updated webrev: http://cr.openjdk.java.net/~zgu/8190729/webrev.01/ > > > Thanks, > > -Zhengyu > > > Thanks. To me, change looks good. No need for a new review. > > ..Thomas > > > > Thank you, > > Kind Regards, Thomas > > > On Mon, Nov 27, 2017 at 6:09 PM, Zhengyu Gu >> wrote: > > Hi, > > To follow up recent discussion of anonymous metadata space > memory > usage, I would like submit this simple fix for review. > > By continuing allocating anonymous metadata space from > SpecializeChunk pool, up to 4 chunks, it reduces the waste > from 60+% > to about 30%. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190729 > > > > Webrev: http://cr.openjdk.java.net/~zgu/8190729/webrev.00/ > > > > > Test: > > hotspot_tier1_runtime on Linux x64 (fastdebug and release) > > > Thanks, > > -Zhengyu > > > From zgu at redhat.com Mon Nov 27 21:18:25 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Nov 2017 16:18:25 -0500 Subject: [jdk8u-dev] RFR 8187629: NMT: Memory miscounting in compiler (C2) Message-ID: <4a0232ea-3dfc-a3b2-e571-0dee4a39201f@redhat.com> Please review this 8u backport. The only conflict is copyright year in resourceArea.hpp, after fixing file paths. Bug: https://bugs.openjdk.java.net/browse/JDK-8187629 Original changeset: http://hg.openjdk.java.net/jdk10/master/rev/5390057a4489 Webrev: http://cr.openjdk.java.net/~zgu/8187629/webrev.8u/ Thanks, -Zhengyu From coleen.phillimore at oracle.com Mon Nov 27 22:04:44 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Nov 2017 17:04:44 -0500 Subject: RFR(XXS) 8190729: Adjustment to anonymous metadata space chunk allocation algorithm In-Reply-To: <96f500fa-7628-bbc0-637f-c819480f7d46@redhat.com> References: <96f500fa-7628-bbc0-637f-c819480f7d46@redhat.com> Message-ID: Hi, this is a bit bigger than XXS but it looks good to me.?? Only one nit: + if (_space_type == Metaspace::AnonymousMetaspaceType + && _mdtype == Metaspace::NonClassType + && sum_count_in_chunks_in_use(SpecializedIndex) < _anon_metadata_specialize_chunk_limit + && word_size + Metachunk::overhead() <= SpecializedChunk) { + return SpecializedChunk; + } + I think the coding style is that the && are on the right hand side.?? In any case, I'll sponsor it for you.? Can you commit, and regenerate the webrev with the commit message??? So I can use wget to get the patch. thanks! Coleen On 11/27/17 12:09 PM, Zhengyu Gu wrote: > Hi, > > To follow up recent discussion of anonymous metadata space memory > usage, I would like submit this simple fix for review. > > By continuing allocating anonymous metadata space from SpecializeChunk > pool, up to 4 chunks, it reduces the waste from 60+% to about 30%. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190729 > Webrev: http://cr.openjdk.java.net/~zgu/8190729/webrev.00/ > > Test: > > ? hotspot_tier1_runtime on Linux x64 (fastdebug and release) > > > Thanks, > > -Zhengyu From zgu at redhat.com Mon Nov 27 22:25:30 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Nov 2017 17:25:30 -0500 Subject: RFR(XXS) 8190729: Adjustment to anonymous metadata space chunk allocation algorithm In-Reply-To: References: <96f500fa-7628-bbc0-637f-c819480f7d46@redhat.com> Message-ID: <3d366929-b487-9eed-2721-d58a4ebf1e46@redhat.com> Hi Coleen, I fixed the style and generated committed webrev: http://cr.openjdk.java.net/~zgu/8190729/webrev.02/ Thanks a lot! -Zhengyu On 11/27/2017 05:04 PM, coleen.phillimore at oracle.com wrote: > > Hi, this is a bit bigger than XXS but it looks good to me. Only one nit: > > + if (_space_type == Metaspace::AnonymousMetaspaceType > + && _mdtype == Metaspace::NonClassType > + && sum_count_in_chunks_in_use(SpecializedIndex) < > _anon_metadata_specialize_chunk_limit > + && word_size + Metachunk::overhead() <= SpecializedChunk) { > + return SpecializedChunk; > + } > + > > > I think the coding style is that the && are on the right hand side. In > any case, I'll sponsor it for you. Can you commit, and regenerate the > webrev with the commit message? So I can use wget to get the patch. > > thanks! > Coleen > > On 11/27/17 12:09 PM, Zhengyu Gu wrote: >> Hi, >> >> To follow up recent discussion of anonymous metadata space memory >> usage, I would like submit this simple fix for review. >> >> By continuing allocating anonymous metadata space from SpecializeChunk >> pool, up to 4 chunks, it reduces the waste from 60+% to about 30%. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190729 >> Webrev: http://cr.openjdk.java.net/~zgu/8190729/webrev.00/ >> >> Test: >> >> hotspot_tier1_runtime on Linux x64 (fastdebug and release) >> >> >> Thanks, >> >> -Zhengyu > From magnus.ihse.bursie at oracle.com Mon Nov 27 23:11:13 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 28 Nov 2017 00:11:13 +0100 Subject: RFR: JDK-8177956 Add TEST_VM_OPTS as convenience for run-test arguments Message-ID: <674c5289-5b8c-d1c3-30ac-107f79d6f4e2@oracle.com> From the bug report: A common scenario is adding vm arguments when running tests. While this can be accomplished by JTREG="VM_OPTIONS=-Xfoo", this is a lot to type for a common case. In the future, when gtest accepts vm arguments as well, a separate, similar but yet different GTEST="VM_OPTIONS=-Xfoo" would be needed. A new "global" TEST_VM_OPTS=X should behave as if VM_OPTIONS=X were present on all applicable test framework option control variables. My solution also adds a new "global" TEST_OPTS, where TEST_VM_OPTS=-Xfoo behaves identical to TEST_OPTS="VM_OPTIONS=-Xfoo", but which also allows other global settings. It also adds support for VM_OPTIONS to gtest, and it improves error resilience in gtest result parsing. Bug: https://bugs.openjdk.java.net/browse/JDK-8177956 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8177956-add-TEST_OPTS/webrev.01 /Magnus From erik.joelsson at oracle.com Mon Nov 27 23:44:54 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Nov 2017 15:44:54 -0800 Subject: RFR: JDK-8177956 Add TEST_VM_OPTS as convenience for run-test arguments In-Reply-To: <674c5289-5b8c-d1c3-30ac-107f79d6f4e2@oracle.com> References: <674c5289-5b8c-d1c3-30ac-107f79d6f4e2@oracle.com> Message-ID: Looks good. /Erik On 2017-11-27 15:11, Magnus Ihse Bursie wrote: > From the bug report: > > A common scenario is adding vm arguments when running tests. While > this can be accomplished by JTREG="VM_OPTIONS=-Xfoo", this is a lot to > type for a common case. In the future, when gtest accepts vm arguments > as well, a separate, similar but yet different > GTEST="VM_OPTIONS=-Xfoo" would be needed. > > A new "global" TEST_VM_OPTS=X should behave as if VM_OPTIONS=X were > present on all applicable test framework option control variables. > > My solution also adds a new "global" TEST_OPTS, where > TEST_VM_OPTS=-Xfoo behaves identical to TEST_OPTS="VM_OPTIONS=-Xfoo", > but which also allows other global settings. It also adds support for > VM_OPTIONS to gtest, and it improves error resilience in gtest result > parsing. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8177956 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8177956-add-TEST_OPTS/webrev.01 > > /Magnus > From kim.barrett at oracle.com Mon Nov 27 23:48:18 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Nov 2017 18:48:18 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> Message-ID: > On Nov 27, 2017, at 3:43 PM, coleen.phillimore at oracle.com wrote: > > > > On 11/27/17 3:21 PM, Kim Barrett wrote: >>> On Nov 27, 2017, at 10:19 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> My question was why there's a command line option, which seems like nobody on earth should use it. Yes, we don't need to zap for product, only for debug. >> So remove the CLA and instead #ifdef ASSERT the zapping. > > Yes. >> >> I?d be okay with that. Another CLA bites the dust. > > What looks like a pointless one at that. > > Coleen New webrev with ZapJNIHandleArea removed. full: http://cr.openjdk.java.net/~kbarrett/8191870/open.01/ incr: http://cr.openjdk.java.net/~kbarrett/8191870/open.01.inc/ From kim.barrett at oracle.com Tue Nov 28 00:33:45 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Nov 2017 19:33:45 -0500 Subject: RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API In-Reply-To: <5A1C3066.7050502@oracle.com> References: <5A1C3066.7050502@oracle.com> Message-ID: <2D76D4BB-CAFA-4148-823C-A15409546890@oracle.com> > On Nov 27, 2017, at 10:33 AM, Erik ?sterlund wrote: > > Hi, > > The ResolvedMethodTable has weak oop references in it. Currently it uses explicit SATB enqueueing for G1 to make the weak semantics work. > > This should be refactored to use the Access API instead. The previous raw loads should be ON_PHANTOM_OOP | AS_NO_KEEPALIVE and the loads followed by explicit G1 SATB enqueueing should be ON_PHANTOM_OOP. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8191904/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8191904 > > Thanks, > /Erik ============================================================================== src/hotspot/share/prims/resolvedMethodTable.cpp 44 // The ACCESS_PEEK peeks at the oop without keeping it alive. ACCESS_PEEK => AS_NO_KEEPALIVE. ============================================================================== src/hotspot/share/prims/resolvedMethodTable.cpp 43 oop ResolvedMethodEntry::object_peek() { Maybe the function should be called object_no_keepalive(), for consistency with the access decorator. ============================================================================== src/hotspot/share/prims/resolvedMethodTable.cpp 43 oop ResolvedMethodEntry::object_peek() { 44 // The ACCESS_PEEK peeks at the oop without keeping it alive. 45 // This is dangerous in general but is okay in this specific 46 // case. A subsequent oop_load keeps the oop alive if it it matched 47 // a target object before leaking out. I think the comment is misleading. There is nothing about this specific function that makes it "okay"; what makes it okay is that each use is careful about how it uses the result. ============================================================================== src/hotspot/share/prims/resolvedMethodTable.cpp Many (though not all) uses of object_peek occur in conjunction with a call to vmtarget for the peeked object. It might be worth adding a helper for that case, to reduce the number of peek calls that need to be monitored to ensure the peeked value doesn't escape. Hm, but what happens to the vmtarget if the peeked object were to die? If the vmtarget dies too (or might die too), then this might not help after all. ============================================================================== From kim.barrett at oracle.com Tue Nov 28 01:31:06 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Nov 2017 20:31:06 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <5A17E399.5080201@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> <5A14525D.4030006@oracle.com> <1b967127-668e-f57d-2992-7680bb924396@oracle.com> <5A17E399.5080201@oracle.com> Message-ID: <8AFCED0F-694D-4A3A-972D-2927D9198159@oracle.com> > On Nov 24, 2017, at 4:17 AM, Erik ?sterlund wrote: > > Hi Kim, > > On 2017-11-23 21:23, Kim Barrett wrote: >> However, while re-exploring that code path, I did notice something >> that bothered me. >> >> ModRefBarrierSet::AccessBarrier<...>::oop_atomic_cmpxchg_in_heap >> bs->template write_ref_field_pre(addr); >> oop result = Raw::oop_atomic_cmpxchg(...); >> if (result == compare_value) { >> bs->template write_ref_field_post(...); >> } >> return result; >> >> does an extra load for G1, to apply the pre-barrier. The old code >> applied the pre-barrier to the result obtained from the raw cmpxchg. > > In my Access API, I want the notion of pre and post write barriers introduced on ModRef level to be respected as just that - pre and post write barriers. Previous code assumed that pre-write barrier really has nothing to do with whether it comes before or after the write - instead it was assumed that a pre-write barrier is equivalent to the SATB barrier, to the extent that in some places the pre-write barrier is used as an implementation for Reference.get for G1 (a weak load!), because it happens to be a SATB barrier and has nothing to do with happening before a write. > > So to on the ModRef level assume that pre-write barriers can be performed *after* the write, because we know it is an SATB barrier, is an abstraction crime. That is why I apply it before the write instead like we do for stores - because it is a pre-write barrier (and if it wasn't expensive in the context of a store, I see no point in optimizing it in the context of an atomic CAS). If a specific GC wants to apply it after as a micro optimization, then they should override the ModRef implementation for their CAS to do that. > > To apply the pre-write barrier *after* the write for CAS specifically, is an optimization to get rid of a relaxed load from a conservatively fenced atomic operation, in a cold runtime path. That seemed like not a good idea to micro optimize and violate abstractions for to me. If we really want to optimize that code path, I see more point in applying the xor shift filter to not perform the expensive StoreLoad fence and card fiddling for writes within the same old region in the runtime path of the post-write barrier, as we do in compiled code. > > I hope you agree that performing the pre-write barrier as a post-write barrier for the rather chilly runtime CAS is a bad idea and not an optimization that is worth it. I think this is a misunderstanding of the API. pre/post here don't refer to any strict ordering of operations wrto the store; they refer to the pre/post-store value at the location. (Some of our collectors impose a strict ordering requirement between the store and the post-barrier, but that isn't a general requirement for all collectors. The collectors with such a requirement must generate appropriate code to ensure the ordering. There does appear to be a general requirement that no safepoints can occur anywhere in there, but that's all.) I don't think it should be surprising that the pre-barrier got used for SATB support in ways that don't match the notional ordering constraint, since I don't think that constraint was ever intended. The pre-barrier API was added as part of supporting G1, and we have no examples of non-SATB collectors that do anything interesting with the pre-barrier. To treat the pre-barrier as anything other than SATB support is premature generalization without supporting use-cases or exemplars. So I see this change as an unnecessary pessimization based on an incorrect over-generalization. Perhaps there are some poorly chosen names (actually, I wouldn't want to defend some of the names), but that's not a reason to change the semantics and thereby generate worse code for the sole user of this functionality. And while I agree that this specific pessimization probably doesn't have any measurable performance impact, I'm now very worried about what other similar changes may have been made. From kim.barrett at oracle.com Tue Nov 28 02:48:14 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Nov 2017 21:48:14 -0500 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: <8AFCED0F-694D-4A3A-972D-2927D9198159@oracle.com> References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> <5A14525D.4030006@oracle.com> <1b967127-668e-f57d-2992-7680bb924396@oracle.com> <5A17E399.5080201@oracle.com> <8AFCED0F-694D-4A3A-972D-2927D9198159@oracle.com> Message-ID: > On Nov 27, 2017, at 8:31 PM, Kim Barrett wrote: > >> On Nov 24, 2017, at 4:17 AM, Erik ?sterlund wrote: >> >> Hi Kim, >> >> On 2017-11-23 21:23, Kim Barrett wrote: >>> However, while re-exploring that code path, I did notice something >>> that bothered me. >>> >>> ModRefBarrierSet::AccessBarrier<...>::oop_atomic_cmpxchg_in_heap >>> bs->template write_ref_field_pre(addr); >>> oop result = Raw::oop_atomic_cmpxchg(...); >>> if (result == compare_value) { >>> bs->template write_ref_field_post(...); >>> } >>> return result; >>> >>> does an extra load for G1, to apply the pre-barrier. The old code >>> applied the pre-barrier to the result obtained from the raw cmpxchg. >> >> In my Access API, I want the notion of pre and post write barriers introduced on ModRef level to be respected as just that - pre and post write barriers. Previous code assumed that pre-write barrier really has nothing to do with whether it comes before or after the write - instead it was assumed that a pre-write barrier is equivalent to the SATB barrier, to the extent that in some places the pre-write barrier is used as an implementation for Reference.get for G1 (a weak load!), because it happens to be a SATB barrier and has nothing to do with happening before a write. >> >> So to on the ModRef level assume that pre-write barriers can be performed *after* the write, because we know it is an SATB barrier, is an abstraction crime. That is why I apply it before the write instead like we do for stores - because it is a pre-write barrier (and if it wasn't expensive in the context of a store, I see no point in optimizing it in the context of an atomic CAS). If a specific GC wants to apply it after as a micro optimization, then they should override the ModRef implementation for their CAS to do that. >> >> To apply the pre-write barrier *after* the write for CAS specifically, is an optimization to get rid of a relaxed load from a conservatively fenced atomic operation, in a cold runtime path. That seemed like not a good idea to micro optimize and violate abstractions for to me. If we really want to optimize that code path, I see more point in applying the xor shift filter to not perform the expensive StoreLoad fence and card fiddling for writes within the same old region in the runtime path of the post-write barrier, as we do in compiled code. >> >> I hope you agree that performing the pre-write barrier as a post-write barrier for the rather chilly runtime CAS is a bad idea and not an optimization that is worth it. > > I think this is a misunderstanding of the API. pre/post here don't > refer to any strict ordering of operations wrto the store; they refer > to the pre/post-store value at the location. (Some of our collectors > impose a strict ordering requirement between the store and the > post-barrier, but that isn't a general requirement for all collectors. > The collectors with such a requirement must generate appropriate code > to ensure the ordering. There does appear to be a general requirement > that no safepoints can occur anywhere in there, but that's all.) > > I don't think it should be surprising that the pre-barrier got used > for SATB support in ways that don't match the notional ordering > constraint, since I don't think that constraint was ever intended. The > pre-barrier API was added as part of supporting G1, and we have no > examples of non-SATB collectors that do anything interesting with the > pre-barrier. To treat the pre-barrier as anything other than SATB > support is premature generalization without supporting use-cases or > exemplars. > > So I see this change as an unnecessary pessimization based on an > incorrect over-generalization. Perhaps there are some poorly chosen > names (actually, I wouldn't want to defend some of the names), but > that's not a reason to change the semantics and thereby generate worse > code for the sole user of this functionality. > > And while I agree that this specific pessimization probably doesn't > have any measurable performance impact, I'm now very worried about > what other similar changes may have been made. Hm, let me retract some of that. The above describes how I think it should work. I don't agree with the strict ordering interpretation of pre/post. However, it seems the C++ implementation of the G1 pre-barrier has always (so far as I can tell) read and enqueued the value at the given address. The compiled code may be different, with (for example) GraphKit::pre_barrier having a pre_val argument for the old value, in case it is already available, so that it doesn't need to be reloaded. And re-examining the C++ impl of Unsafe_CompareAndExchangeObject, I misread the old code this last time through. It wasn't applying the pre-barrier to the result obtained from the raw cmpxchg. In fact, it's not applying the pre-barrier at all, as I originally thought. Doesn't that make this and other similar operations formerly broken for G1? From david.holmes at oracle.com Tue Nov 28 06:50:42 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Nov 2017 16:50:42 +1000 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. In-Reply-To: <5A184729.4090107@oracle.com> References: <5A184729.4090107@oracle.com> Message-ID: Hi Erik, Does "phantom" here have any relationship to PhantomReference? Meta-question on access API: if RootAccess::oop_load(addr); keeps the value alive, what can cause the value to be allowed to go dead again? Thanks, David On 25/11/2017 2:22 AM, Erik ?sterlund wrote: > Hi, > > When creating a ciInstanceKlass handle, G1 might need a SATB barrier to > keep "peeked" weak klass pointers alive during marking. > This should now be done with the Access API instead of manual calls to > the G1 SATB barrier. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8191567 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ > > Thanks, > /Erik From goetz.lindenmaier at sap.com Tue Nov 28 07:06:52 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 28 Nov 2017 07:06:52 +0000 Subject: RFR(S): 8191863: [s390] Fix CDS: some bytecode rewriting doesn't depend on RewriteControl In-Reply-To: References: Message-ID: <8f6e77df23fe4a649f204e11855a3496@sap.com> Hi Volker, change looks good, thanks for fixing! Best regards, Goetz. > -----Original Message----- > From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] > On Behalf Of Volker Simonis > Sent: Montag, 27. November 2017 16:55 > To: HotSpot Open Source Developers > Cc: s390x-port-dev at openjdk.java.net > Subject: RFR(S): 8191863: [s390] Fix CDS: some bytecode rewriting doesn't > depend on RewriteControl > > Hi, > > can I please have a review for the following small, s390-only change > which fixes CDS on s390: > > http://cr.openjdk.java.net/~simonis/webrevs/2017/8191863/ > https://bugs.openjdk.java.net/browse/JDK-8191863 > > The problem was that mistakenly rewrote zputfield into fast_zputfield > although the active RewriteControl instance indicated that we > shouldn't rewrite bytecodes. > > With this change, all the CDS and upcoming AppCDS jtreg pass on Linux/s390. > > Thank you and best regards, > Volker From per.liden at oracle.com Tue Nov 28 07:53:21 2017 From: per.liden at oracle.com (Per Liden) Date: Tue, 28 Nov 2017 08:53:21 +0100 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. In-Reply-To: References: <5A184729.4090107@oracle.com> Message-ID: <84bae716-9308-e372-5a13-f0c4d348b6a1@oracle.com> Hi David, On 2017-11-28 07:50, David Holmes wrote: > Hi Erik, > > Does "phantom" here have any relationship to PhantomReference? Yes, in the sense that this root oop has the same strength as the referent field in a PhantomReference. All non-strong root oops in the VM (StringTable, JNIWeakHandles, etc) are "phantom oops". Internally in the VM they are unfortunately sometimes referred to as "weak roots". With the access API, we're trying to move away from using "weak" for these since "weak" is the strength of the referent in a Soft/Weak/FinalReference. > > Meta-question on access API: if > > RootAccess::oop_load(addr); > > keeps the value alive, what can cause the value to be allowed to go dead > again? After a GC, if all existing pointers to this object are phantom oops, then the object is phantom-reachable and those phantom oops will be declared dead and cleared (i.e. same criteria as when a j.l.r.PhantomReference is enqueued). cheers, Per > > Thanks, > David > > On 25/11/2017 2:22 AM, Erik ?sterlund wrote: >> Hi, >> >> When creating a ciInstanceKlass handle, G1 might need a SATB barrier >> to keep "peeked" weak klass pointers alive during marking. >> This should now be done with the Access API instead of manual calls to >> the G1 SATB barrier. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8191567 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ >> >> Thanks, >> /Erik From volker.simonis at gmail.com Tue Nov 28 09:49:48 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 28 Nov 2017 10:49:48 +0100 Subject: RFR(S): 8191863: [s390] Fix CDS: some bytecode rewriting doesn't depend on RewriteControl In-Reply-To: <8f6e77df23fe4a649f204e11855a3496@sap.com> References: <8f6e77df23fe4a649f204e11855a3496@sap.com> Message-ID: Hi Jiangli, Goetz, thanks for the review! Regards, Volker On Tue, Nov 28, 2017 at 8:06 AM, Lindenmaier, Goetz wrote: > Hi Volker, > > change looks good, thanks for fixing! > > Best regards, > Goetz. > >> -----Original Message----- >> From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] >> On Behalf Of Volker Simonis >> Sent: Montag, 27. November 2017 16:55 >> To: HotSpot Open Source Developers >> Cc: s390x-port-dev at openjdk.java.net >> Subject: RFR(S): 8191863: [s390] Fix CDS: some bytecode rewriting doesn't >> depend on RewriteControl >> >> Hi, >> >> can I please have a review for the following small, s390-only change >> which fixes CDS on s390: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2017/8191863/ >> https://bugs.openjdk.java.net/browse/JDK-8191863 >> >> The problem was that mistakenly rewrote zputfield into fast_zputfield >> although the active RewriteControl instance indicated that we >> shouldn't rewrite bytecodes. >> >> With this change, all the CDS and upcoming AppCDS jtreg pass on Linux/s390. >> >> Thank you and best regards, >> Volker From adinn at redhat.com Tue Nov 28 09:53:59 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 28 Nov 2017 09:53:59 +0000 Subject: [jdk8u-dev] RFR 8187629: NMT: Memory miscounting in compiler (C2) In-Reply-To: <4a0232ea-3dfc-a3b2-e571-0dee4a39201f@redhat.com> References: <4a0232ea-3dfc-a3b2-e571-0dee4a39201f@redhat.com> Message-ID: <1ce70092-9844-dcd9-e760-9d77ad55a06c@redhat.com> On 27/11/17 21:18, Zhengyu Gu wrote: > Please review this 8u backport. The only conflict is copyright year in > resourceArea.hpp, after fixing file paths. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187629 > > Original changeset: > http://hg.openjdk.java.net/jdk10/master/rev/5390057a4489 > > Webrev: http://cr.openjdk.java.net/~zgu/8187629/webrev.8u/ Yes, looks good. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From volker.simonis at gmail.com Tue Nov 28 09:56:18 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 28 Nov 2017 10:56:18 +0100 Subject: RFR(S): 8191770: [ppc64] Fix CDS: don't rewrite invokefinal if DumpSharedSpaces In-Reply-To: References: Message-ID: Hi Jiangli, thanks for the review! Regards, Volker On Mon, Nov 27, 2017 at 8:22 PM, Jiangli Zhou wrote: > Hi Volker, > > This looks good. > > Thanks, > Jiangli > >> On Nov 27, 2017, at 7:55 AM, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for the following small, ppc64-only change >> which fixes CDS on Power: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2017/8191770/ >> https://bugs.openjdk.java.net/browse/JDK-8191770 >> >> Don't rewrite invokefinal into fast_invokevfinal if running with >> DumpSharedSpaces or UseSharedSpaces. >> >> The Template-Interpreter of the ppc-Port was initially derived from >> the SPARC version which didn't had full CDS support at that time, >> that's why the guard against DumpSharedSpaces was missing at the place >> where invokefinal is rewritten. >> >> With this change, all the CDS and upcoming AppCDS jtreg pass on >> Linux/ppc64, Linux/ppc64le and AIX. >> >> Thank you and best regards, >> Volker > From adinn at redhat.com Tue Nov 28 10:00:03 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 28 Nov 2017 10:00:03 +0000 Subject: RFR(XXS) 8190729: Adjustment to anonymous metadata space chunk allocation algorithm In-Reply-To: References: <96f500fa-7628-bbc0-637f-c819480f7d46@redhat.com> Message-ID: On 27/11/17 19:38, Zhengyu Gu wrote: > On 11/27/2017 01:36 PM, Thomas St?fe wrote: >> >> Why do you do this only for non-class metaspace? > > Cause I have yet seen any anonymous class space above 1K, I would rather > leave them alone. That's no surprise. An InstanceKlass is ~450 bytes plus whatever (little) space is taken up by the oopmap, vtable and itable. So, even two classes will likely fit into a 1K chunk and one certainly will. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Tue Nov 28 10:01:05 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 28 Nov 2017 10:01:05 +0000 Subject: RFR(XXS) 8190729: Adjustment to anonymous metadata space chunk allocation algorithm In-Reply-To: <3d366929-b487-9eed-2721-d58a4ebf1e46@redhat.com> References: <96f500fa-7628-bbc0-637f-c819480f7d46@redhat.com> <3d366929-b487-9eed-2721-d58a4ebf1e46@redhat.com> Message-ID: On 27/11/17 22:25, Zhengyu Gu wrote: > I fixed the style and generated committed webrev: > > http://cr.openjdk.java.net/~zgu/8190729/webrev.02/ Looks good. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From thomas.stuefe at gmail.com Tue Nov 28 10:16:46 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 28 Nov 2017 11:16:46 +0100 Subject: [jdk8u-dev] RFR 8187629: NMT: Memory miscounting in compiler (C2) In-Reply-To: <4a0232ea-3dfc-a3b2-e571-0dee4a39201f@redhat.com> References: <4a0232ea-3dfc-a3b2-e571-0dee4a39201f@redhat.com> Message-ID: On Mon, Nov 27, 2017 at 10:18 PM, Zhengyu Gu wrote: > Please review this 8u backport. The only conflict is copyright year in > resourceArea.hpp, after fixing file paths. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187629 > > Original changeset: http://hg.openjdk.java.net/jdk > 10/master/rev/5390057a4489 > > Webrev: http://cr.openjdk.java.net/~zgu/8187629/webrev.8u/ > > Thanks, > > -Zhengyu > +1 Regards, Thomas From erik.osterlund at oracle.com Tue Nov 28 10:52:17 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 28 Nov 2017 11:52:17 +0100 Subject: RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API In-Reply-To: <2D76D4BB-CAFA-4148-823C-A15409546890@oracle.com> References: <5A1C3066.7050502@oracle.com> <2D76D4BB-CAFA-4148-823C-A15409546890@oracle.com> Message-ID: <5A1D3FE1.4080702@oracle.com> Hi Kim, Thank you for the review. Incremental webrev: http://cr.openjdk.java.net/~eosterlund/8191904/webrev.00_01/ Full webrev: http://cr.openjdk.java.net/~eosterlund/8191904/webrev.01/ On 2017-11-28 01:33, Kim Barrett wrote: >> On Nov 27, 2017, at 10:33 AM, Erik ?sterlund wrote: >> >> Hi, >> >> The ResolvedMethodTable has weak oop references in it. Currently it uses explicit SATB enqueueing for G1 to make the weak semantics work. >> >> This should be refactored to use the Access API instead. The previous raw loads should be ON_PHANTOM_OOP | AS_NO_KEEPALIVE and the loads followed by explicit G1 SATB enqueueing should be ON_PHANTOM_OOP. >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8191904/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8191904 >> >> Thanks, >> /Erik > ============================================================================== > src/hotspot/share/prims/resolvedMethodTable.cpp > 44 // The ACCESS_PEEK peeks at the oop without keeping it alive. > > ACCESS_PEEK => AS_NO_KEEPALIVE. Fixed. > ============================================================================== > src/hotspot/share/prims/resolvedMethodTable.cpp > 43 oop ResolvedMethodEntry::object_peek() { > > Maybe the function should be called object_no_keepalive(), for > consistency with the access decorator. Fixed. > ============================================================================== > src/hotspot/share/prims/resolvedMethodTable.cpp > 43 oop ResolvedMethodEntry::object_peek() { > 44 // The ACCESS_PEEK peeks at the oop without keeping it alive. > 45 // This is dangerous in general but is okay in this specific > 46 // case. A subsequent oop_load keeps the oop alive if it it matched > 47 // a target object before leaking out. > > I think the comment is misleading. There is nothing about this > specific function that makes it "okay"; what makes it okay is that > each use is careful about how it uses the result. Fixed (hopefully). > ============================================================================== > src/hotspot/share/prims/resolvedMethodTable.cpp > > Many (though not all) uses of object_peek occur in conjunction with a > call to vmtarget for the peeked object. It might be worth adding a > helper for that case, to reduce the number of peek calls that need to > be monitored to ensure the peeked value doesn't escape. I counted two cases where we from a "peeked" value only looked at vmtarget and 3 cases where we did more than that. So it seemed like too much to introduce an abstraction that "peeked" and fetched the vmtarget for only two uses. Do you agree? > Hm, but what happens to the vmtarget if the peeked object were to die? > If the vmtarget dies too (or might die too), then this might not help > after all. That is true. Thanks, /Erik From erik.osterlund at oracle.com Tue Nov 28 11:21:28 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 28 Nov 2017 12:21:28 +0100 Subject: RFR: 8189871: Refactor GC barriers to use declarative semantics In-Reply-To: References: <5A048993.2000002@oracle.com> <5fac9436-f120-14e1-98c9-9cc9454a0b54@oracle.com> <5A0C718A.5080401@oracle.com> <43790CB8-9D03-4502-B58D-E2E815CF8304@oracle.com> <5A0EED7D.6070207@oracle.com> <74635C96-675B-4DB3-8B3F-319E84810B30@oracle.com> <906D1527-372B-47F4-9C94-E4756C88E88C@oracle.com> <5A14525D.4030006@oracle.com> <1b967127-668e-f57d-2992-7680bb924396@oracle.com> <5A17E399.5080201@oracle.com> <8AFCED0F-694D-4A3A-972D-2927D9198159@oracle.com> Message-ID: <5A1D46B8.8080605@oracle.com> Hi Kim, Since you retracted part of your first email, I will answer this email instead. On 2017-11-28 03:48, Kim Barrett wrote: >> On Nov 27, 2017, at 8:31 PM, Kim Barrett wrote: >> >>> On Nov 24, 2017, at 4:17 AM, Erik ?sterlund wrote: >>> >>> Hi Kim, >>> >>> On 2017-11-23 21:23, Kim Barrett wrote: >>>> However, while re-exploring that code path, I did notice something >>>> that bothered me. >>>> >>>> ModRefBarrierSet::AccessBarrier<...>::oop_atomic_cmpxchg_in_heap >>>> bs->template write_ref_field_pre(addr); >>>> oop result = Raw::oop_atomic_cmpxchg(...); >>>> if (result == compare_value) { >>>> bs->template write_ref_field_post(...); >>>> } >>>> return result; >>>> >>>> does an extra load for G1, to apply the pre-barrier. The old code >>>> applied the pre-barrier to the result obtained from the raw cmpxchg. >>> In my Access API, I want the notion of pre and post write barriers introduced on ModRef level to be respected as just that - pre and post write barriers. Previous code assumed that pre-write barrier really has nothing to do with whether it comes before or after the write - instead it was assumed that a pre-write barrier is equivalent to the SATB barrier, to the extent that in some places the pre-write barrier is used as an implementation for Reference.get for G1 (a weak load!), because it happens to be a SATB barrier and has nothing to do with happening before a write. >>> >>> So to on the ModRef level assume that pre-write barriers can be performed *after* the write, because we know it is an SATB barrier, is an abstraction crime. That is why I apply it before the write instead like we do for stores - because it is a pre-write barrier (and if it wasn't expensive in the context of a store, I see no point in optimizing it in the context of an atomic CAS). If a specific GC wants to apply it after as a micro optimization, then they should override the ModRef implementation for their CAS to do that. >>> >>> To apply the pre-write barrier *after* the write for CAS specifically, is an optimization to get rid of a relaxed load from a conservatively fenced atomic operation, in a cold runtime path. That seemed like not a good idea to micro optimize and violate abstractions for to me. If we really want to optimize that code path, I see more point in applying the xor shift filter to not perform the expensive StoreLoad fence and card fiddling for writes within the same old region in the runtime path of the post-write barrier, as we do in compiled code. >>> >>> I hope you agree that performing the pre-write barrier as a post-write barrier for the rather chilly runtime CAS is a bad idea and not an optimization that is worth it. >> I think this is a misunderstanding of the API. pre/post here don't >> refer to any strict ordering of operations wrto the store; they refer >> to the pre/post-store value at the location. (Some of our collectors >> impose a strict ordering requirement between the store and the >> post-barrier, but that isn't a general requirement for all collectors. >> The collectors with such a requirement must generate appropriate code >> to ensure the ordering. There does appear to be a general requirement >> that no safepoints can occur anywhere in there, but that's all.) >> >> I don't think it should be surprising that the pre-barrier got used >> for SATB support in ways that don't match the notional ordering >> constraint, since I don't think that constraint was ever intended. The >> pre-barrier API was added as part of supporting G1, and we have no >> examples of non-SATB collectors that do anything interesting with the >> pre-barrier. To treat the pre-barrier as anything other than SATB >> support is premature generalization without supporting use-cases or >> exemplars. >> >> So I see this change as an unnecessary pessimization based on an >> incorrect over-generalization. Perhaps there are some poorly chosen >> names (actually, I wouldn't want to defend some of the names), but >> that's not a reason to change the semantics and thereby generate worse >> code for the sole user of this functionality. >> >> And while I agree that this specific pessimization probably doesn't >> have any measurable performance impact, I'm now very worried about >> what other similar changes may have been made. > Hm, let me retract some of that. > > The above describes how I think it should work. I don't agree with > the strict ordering interpretation of pre/post. Okay. > However, it seems the C++ implementation of the G1 pre-barrier has > always (so far as I can tell) read and enqueued the value at the given > address. Yes, only the compiled code changes that. More about that in next paragraph... > The compiled code may be different, with (for example) > GraphKit::pre_barrier having a pre_val argument for the old value, in > case it is already available, so that it doesn't need to be reloaded. The example you mention has built an abstraction to make the reordering of pre-write barriers okay. The abstraction is a function called can_move_pre_barrier, that checks if for a given BarrierSet it is okay to move the pre-write barrier to after the write despite being a "pre" write barrier. G1 says that is an okay thing to do in that function, and only because of that is it okay to move it as a micro optimization. In summary, that optimization uses my interpretation of pre-write barriers, and has an explicit abstraction for moving it past the write. I do not think we want to move the pre-write barrier past the write without such an abstraction (we have not before), and I do not think we should have such an abstraction in the runtime path. > And re-examining the C++ impl of Unsafe_CompareAndExchangeObject, I > misread the old code this last time through. It wasn't applying the > pre-barrier to the result obtained from the raw cmpxchg. In fact, it's > not applying the pre-barrier at all, as I originally thought. Doesn't > that make this and other similar operations formerly broken for G1? I recall that code was a bit confusing. You had a boolean on the oopDesc::atomic_compare_exchange_oop operation that said whether you wanted to perform a pre-write barrier or not inside of the CAS (with an implicit default value of false, which was the opposite of what all uses except one callsite required). If you did apply the pre-barrier, it would pass in the exchange_value to the update_barrier_set_pre function, which might look like it would do something, but that value was in fact just dismissed by all GCs, and G1 would instead reload the value before the store. And then you had to manually apply the post-write barrier after the CAS call if it was successful. And the corresponding operation for oop arrays with the same name naturally had completely different semantics. There was some corresponding atomic_exchange_oop operation, that was indeed broken, but nobody used it. So I believe it did work (true was passed in for whether to perform the pre-write barrier for Unsafe_CompareAndExchange), but it was confusing indeed, and was very much down to the user of the APIs to manually make sure barriers are executed. Thanks, /Erik From rahul.v.raghavan at oracle.com Tue Nov 28 12:04:01 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Tue, 28 Nov 2017 17:34:01 +0530 Subject: RFR: 8187676: Disable harmless uninitialized warnings for two files In-Reply-To: <1a8dd6cc-8cf2-bb0e-af09-ea53324c85e3@oracle.com> References: <2031be3e-2623-dde1-fff2-2d6cd6e41de9@oracle.com> <7512e87d-4e28-27a1-5e10-5cdfa794cdf4@oracle.com> <4f5b0427-54bf-2b85-0a94-bb41049d2676@oracle.com> <1a8dd6cc-8cf2-bb0e-af09-ea53324c85e3@oracle.com> Message-ID: <7cd41397-6f67-5bca-f08d-d85d73bcd631@oracle.com> Hi, Further to below email thread - https://bugs.openjdk.java.net/browse/JDK-8187676 https://bugs.openjdk.java.net/browse/JDK-8160404 Please note 8187676 task was blocked by related 8160404. But as mentioned in latest jbs comments of 8160404, found the build warning with gcc7 persists with latest 8160404-patch. More work to be done for complete, correct fix of 8160404. But for now will request to defer 8160404 task to jdk11. Since 8160404 is taking more time, as Erik suggested earlier, can we please go ahead, get approval and disable the gcc warnings for now as part of 8187676 fix - http://cr.openjdk.java.net/~ehelin/8187676/00/ and re-enable later as part of 8160404 patch. Understood that now only the problems highlighted by JDK-8187676/8160404 is stopping hotspot from compiling with more recent versions of GCC. Also as Erik mentioned earlier, disabling these uninitialized warnings seems to be harmless. Thanks, Rahul On Thursday 21 September 2017 02:32 PM, Erik Helin wrote: > Ok, lets wait for Rahul's patches. Rahul, when you post your patches, CC > me and I can check if gcc 7.1.1 still complains :) > > Thanks, > Erik > > On 09/19/2017 06:25 PM, Vladimir Kozlov wrote: >> I would prefer to have general solution Rahul is working on because >> code is general - not only x86 is affected. >> >> Thanks, >> Vladimir >> >> On 9/19/17 7:59 AM, Rahul Raghavan wrote: >>> Hi Erik, >>> >>> Please note that this 8187676 seems to be related to 8160404. >>> ??? https://bugs.openjdk.java.net/browse/JDK-8160404 >>> ??? (RelocationHolder constructors have bugs) >>> >>> As per the latest notes comments added for 8160404-jbs, I will submit >>> webrev/RFR soon and will request help confirm similar issues with >>> latest gcc7 gets solved. >>> >>> Thanks, >>> Rahul >>> >>> On Tuesday 19 September 2017 07:07 PM, Erik Helin wrote: >>>> Hi all, >>>> >>>> with gcc 7.1.1 from Fedora 26 on x86-64 there are warnings about the >>>> potential usage of maybe uninitialized memory in >>>> src/hotspot/cpu/x86/assembler_x86.cpp and in >>>> src/hotspot/cpu/x86/interp_masm_x86.cpp. >>>> >>>> The problems arises from the class RelocationHolder in >>>> src/hotspot/share/code/relocInfo.hpp which has the private fields: >>>> ?? enum { _relocbuf_size = 5 }; >>>> ?? void* _relocbuf[ _relocbuf_size ]; >>>> >>>> and the default constructor for RelocationHolder does not initialize >>>> the elements of _relocbuf. I _think_ this is an optimization, >>>> RelocationHolder is used *a lot* and setting the elements of >>>> RelocationHolder::_relocbuf to NULL (or some other value) in the >>>> default constructor might result in a performance penalty. Have a >>>> look in >>>> build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/adfiles >>>> and you will see that RelocationHolder is used all over the place :) >>>> >>>> AFAICS all users of RelocationHolder::_relocbuf take care to not use >>>> uninitialized memory, which means that this warning is wrong, so I >>>> suggest we disable the warning -Wmaybe-uninitialized for >>>> src/hotspot/cpu/x86/assembler_x86.cpp. >>>> >>>> The problem continues because the class Address in >>>> src/hotspot/cpu/x86/assembler_x86.hpp has a private field, >>>> `RelocationHolder _rspec;` and the default constructor for Address >>>> does not initialize _rspec._relocbuf (most likely for performance >>>> reasons). The class Address also has a default copy constructor, >>>> which will copy all the elements of _rspec._relocbuf, which will >>>> result in a read of uninitialized memory. However, this is a benign >>>> usage of uninitialized memory, since we take no action based on the >>>> content of the uninitialized memory (it is just copied byte for byte). >>>> >>>> So, in this case too, I suggest we disable the warning >>>> -Wuninitialized for src/hotspot/cpu/x86/assembler_x86.hpp. >>>> >>>> What do you think? >>>> >>>> Patch: >>>> http://cr.openjdk.java.net/~ehelin/8187676/00/ >>>> >>>> --- old/make/hotspot/lib/JvmOverrideFiles.gmk??? 2017-09-19 >>>> 15:11:45.036108983 +0200 >>>> +++ new/make/hotspot/lib/JvmOverrideFiles.gmk??? 2017-09-19 >>>> 15:11:44.692107277 +0200 >>>> @@ -32,6 +32,8 @@ >>>> ? ifeq ($(TOOLCHAIN_TYPE), gcc) >>>> ??? BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := >>>> -fno-var-tracking-assignments -O0 >>>> ??? BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := >>>> -fno-var-tracking-assignments >>>> +? BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized >>>> +? BUILD_LIBJVM_interp_masm_x86.cpp_CXXFLAGS := -Wno-uninitialized >>>> ? endif >>>> >>>> ? ifeq ($(OPENJDK_TARGET_OS), linux) >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8187676 >>>> >>>> Testing: >>>> - Compiles with: >>>> ?? - gcc 7.1.1 and glibc 2.25 on Fedora 26 >>>> ?? - gcc 4.9.2 and glibc 2.12 on OEL 6.4 >>>> - JPRT >>>> >>>> Thanks, >>>> Erik From erik.osterlund at oracle.com Tue Nov 28 12:26:24 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 28 Nov 2017 13:26:24 +0100 Subject: RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API In-Reply-To: <96f537c5-c64a-1b66-089f-ba8a4b572f6b@oracle.com> References: <5A1C3066.7050502@oracle.com> <96f537c5-c64a-1b66-089f-ba8a4b572f6b@oracle.com> Message-ID: <5A1D55F0.1050209@oracle.com> Hi Coleen, On 2017-11-27 19:33, coleen.phillimore at oracle.com wrote: > This looks good. Thank you for the review. > I think we should make the literal() function in this hashtable a pure > virtual function and ShouldNotReachHere to not allow it for these > classes derived from oop. That might be a good idea indeed. > BTW, should we expect a StringTable and ProtectionDomainEntryTable > change as well? The latter is missing the SATB barrier at the moment. StringTable changes are coming up indeed. About the ProtectionDomainEntryTable, I have not prepared a patch yet. From looking at it briefly, it did look like we were only ever "peeking" at the value and never exposing it. So should probably just use RootAccess::oop_load all over. This will not translate to any actual barrier on any collector, but is probably a good abstraction to have anyway. If you want this, I will prepare a patch for it. Thanks, /Erik > Coleen > > On 11/27/17 10:33 AM, Erik ?sterlund wrote: >> Hi, >> >> The ResolvedMethodTable has weak oop references in it. Currently it >> uses explicit SATB enqueueing for G1 to make the weak semantics work. >> >> This should be refactored to use the Access API instead. The previous >> raw loads should be ON_PHANTOM_OOP | AS_NO_KEEPALIVE and the loads >> followed by explicit G1 SATB enqueueing should be ON_PHANTOM_OOP. >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8191904/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8191904 >> >> Thanks, >> /Erik > From zgu at redhat.com Tue Nov 28 13:04:59 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Nov 2017 08:04:59 -0500 Subject: RFR(XXS) 8190729: Adjustment to anonymous metadata space chunk allocation algorithm In-Reply-To: References: <96f500fa-7628-bbc0-637f-c819480f7d46@redhat.com> <3d366929-b487-9eed-2721-d58a4ebf1e46@redhat.com> Message-ID: <00a0c814-e0af-b8d9-89af-c2d6737f8932@redhat.com> Thanks for the review, Andrew! -Zhengyu On 11/28/2017 05:01 AM, Andrew Dinn wrote: > On 27/11/17 22:25, Zhengyu Gu wrote: >> I fixed the style and generated committed webrev: >> >> http://cr.openjdk.java.net/~zgu/8190729/webrev.02/ > Looks good. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From zgu at redhat.com Tue Nov 28 13:10:41 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Nov 2017 08:10:41 -0500 Subject: [jdk8u-dev] RFR 8187629: NMT: Memory miscounting in compiler (C2) In-Reply-To: References: <4a0232ea-3dfc-a3b2-e571-0dee4a39201f@redhat.com> Message-ID: <2259875d-d87c-017f-6345-14783eafe3b2@redhat.com> Thanks for the review, Thomas. -Zhengyu On 11/28/2017 05:16 AM, Thomas St?fe wrote: > > > On Mon, Nov 27, 2017 at 10:18 PM, Zhengyu Gu > wrote: > > Please review this 8u backport. The only conflict is copyright year > in resourceArea.hpp, after fixing file paths. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8187629 > > > Original changeset: > http://hg.openjdk.java.net/jdk10/master/rev/5390057a4489 > > > Webrev: http://cr.openjdk.java.net/~zgu/8187629/webrev.8u/ > > > Thanks, > > -Zhengyu > > > +1 > > Regards, Thomas > From zgu at redhat.com Tue Nov 28 13:10:59 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 28 Nov 2017 08:10:59 -0500 Subject: [jdk8u-dev] RFR 8187629: NMT: Memory miscounting in compiler (C2) In-Reply-To: <1ce70092-9844-dcd9-e760-9d77ad55a06c@redhat.com> References: <4a0232ea-3dfc-a3b2-e571-0dee4a39201f@redhat.com> <1ce70092-9844-dcd9-e760-9d77ad55a06c@redhat.com> Message-ID: Thanks for the review, Andrew. -Zhengyu On 11/28/2017 04:53 AM, Andrew Dinn wrote: > On 27/11/17 21:18, Zhengyu Gu wrote: >> Please review this 8u backport. The only conflict is copyright year in >> resourceArea.hpp, after fixing file paths. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8187629 >> >> Original changeset: >> http://hg.openjdk.java.net/jdk10/master/rev/5390057a4489 >> >> Webrev: http://cr.openjdk.java.net/~zgu/8187629/webrev.8u/ > Yes, looks good. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From thomas.schatzl at oracle.com Tue Nov 28 13:12:46 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 28 Nov 2017 14:12:46 +0100 Subject: RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API In-Reply-To: <5A1D55F0.1050209@oracle.com> References: <5A1C3066.7050502@oracle.com> <96f537c5-c64a-1b66-089f-ba8a4b572f6b@oracle.com> <5A1D55F0.1050209@oracle.com> Message-ID: <1511874766.2867.2.camel@oracle.com> Hi, On Tue, 2017-11-28 at 13:26 +0100, Erik ?sterlund wrote: > Hi Coleen, > > On 2017-11-27 19:33, coleen.phillimore at oracle.com wrote: > > This looks good. > > Thank you for the review. > > > I think we should make the literal() function in this hashtable a > > pure virtual function and ShouldNotReachHere to not allow it for > > these classes derived from oop. > > That might be a good idea indeed. > > > BTW, should we expect a StringTable and ProtectionDomainEntryTable > > change as well? The latter is missing the SATB barrier at the > > moment. > > StringTable changes are coming up indeed. About the > ProtectionDomainEntryTable, I have not prepared a patch yet. From > looking at it briefly, it did look like we were only ever "peeking" > at the value and never exposing it. So should probably just use > RootAccess::oop_load all over. > This will not translate to any actual barrier on any collector, but > is probably a good abstraction to have anyway. If you want this, I > will prepare a patch for it. If I understand its use correctly (still wrapping my head around this), since some of your other changes also add this abstraction "where it is not needed" it would be nice to have. Thanks, Thomas From glaubitz at physik.fu-berlin.de Tue Nov 28 13:36:54 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 28 Nov 2017 14:36:54 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 Message-ID: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> Hi! During my recent tests, I noticed that Zero fails to build on both ppc32 and ppc64 with the following error message: Optimizing the exploded image /home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/jdk/bin/java -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -cp /home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/buildtools/tools_jigsaw_classes --add-exports java.base/jdk.internal.module=ALL-UNNAMED build.tools.jigsaw.AddPackagesAttribute /home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/jdk uintx CodeCacheExpansionSize=32768 is outside the allowed range [ 65536 ... 18446744073709551615 ] Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. ExplodedImageOptimize.gmk:40: recipe for target '/home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/jdk/_packages_attribute.done' failed make[3]: *** [/home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/jdk/_packages_attribute.done] Error 1 make[3]: Leaving directory '/home/glaubitz/openjdk/hs/make' make/Main.gmk:361: recipe for target 'exploded-image-optimize' failed make[2]: *** [exploded-image-optimize] Error 2 make[2]: Leaving directory '/home/glaubitz/openjdk/hs Looking at ./src/hotspot/share/runtime/globals.hpp, CodeCacheExpansionSize is set to be 32768 bytes: define_pd_global(intx, CodeCacheExpansionSize, 32*K); Interestingly, I have not run into this issue with Zero on x86_64 or SPARC with other architectures currently being tested. Could it be that the value of CodeCacheExpansionSize has a minimum limit on ppc*? If yes, should we just increase it to 64k? Or maybe we have to find the place where it enforces the value on ppc* to be unconditionally 64k? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From daniel.daugherty at oracle.com Tue Nov 28 13:45:05 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 28 Nov 2017 08:45:05 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> Message-ID: <4ec9ed56-84c6-e4cc-b6e7-52902c5d6c9f@oracle.com> On 11/27/17 6:48 PM, Kim Barrett wrote: >> On Nov 27, 2017, at 3:43 PM, coleen.phillimore at oracle.com wrote: >> >> >> >> On 11/27/17 3:21 PM, Kim Barrett wrote: >>>> On Nov 27, 2017, at 10:19 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> My question was why there's a command line option, which seems like nobody on earth should use it. Yes, we don't need to zap for product, only for debug. >>> So remove the CLA and instead #ifdef ASSERT the zapping. >> Yes. >>> I?d be okay with that. Another CLA bites the dust. >> What looks like a pointless one at that. >> >> Coleen > New webrev with ZapJNIHandleArea removed. > > full: http://cr.openjdk.java.net/~kbarrett/8191870/open.01/ src/hotspot/share/runtime/globals.hpp ??? No comments. src/hotspot/share/runtime/jniHandles.cpp ??? No comments. src/hotspot/share/runtime/jniHandles.hpp ??? No comments. src/hotspot/share/runtime/sharedRuntime.cpp ??? No comments. src/hotspot/share/utilities/globalDefinitions.hpp ??? No comments. Thumbs up. Dan > incr: http://cr.openjdk.java.net/~kbarrett/8191870/open.01.inc/ > From erik.osterlund at oracle.com Tue Nov 28 14:12:43 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 28 Nov 2017 15:12:43 +0100 Subject: RFR (S): 8191904: Refactor weak oops in ResolvedMethodTable to use the Access API In-Reply-To: <1511874766.2867.2.camel@oracle.com> References: <5A1C3066.7050502@oracle.com> <96f537c5-c64a-1b66-089f-ba8a4b572f6b@oracle.com> <5A1D55F0.1050209@oracle.com> <1511874766.2867.2.camel@oracle.com> Message-ID: <5A1D6EDB.8050709@oracle.com> Hi Thomas, On 2017-11-28 14:12, Thomas Schatzl wrote: > Hi, > > On Tue, 2017-11-28 at 13:26 +0100, Erik ?sterlund wrote: >> Hi Coleen, >> >> On 2017-11-27 19:33, coleen.phillimore at oracle.com wrote: >>> This looks good. >> Thank you for the review. >> >>> I think we should make the literal() function in this hashtable a >>> pure virtual function and ShouldNotReachHere to not allow it for >>> these classes derived from oop. >> That might be a good idea indeed. >> >>> BTW, should we expect a StringTable and ProtectionDomainEntryTable >>> change as well? The latter is missing the SATB barrier at the >>> moment. >> StringTable changes are coming up indeed. About the >> ProtectionDomainEntryTable, I have not prepared a patch yet. From >> looking at it briefly, it did look like we were only ever "peeking" >> at the value and never exposing it. So should probably just use >> RootAccess::oop_load all over. >> This will not translate to any actual barrier on any collector, but >> is probably a good abstraction to have anyway. If you want this, I >> will prepare a patch for it. > If I understand its use correctly (still wrapping my head around this), > since some of your other changes also add this abstraction "where it is > not needed" it would be nice to have. Okay, will sort out. Thanks, /Erik > Thanks, > Thomas > From erik.osterlund at oracle.com Tue Nov 28 14:16:04 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 28 Nov 2017 15:16:04 +0100 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> Message-ID: <5A1D6FA4.7010304@oracle.com> Hi Kim, Still looks good. Thanks, /Erik On 2017-11-28 00:48, Kim Barrett wrote: >> On Nov 27, 2017, at 3:43 PM, coleen.phillimore at oracle.com wrote: >> >> >> >> On 11/27/17 3:21 PM, Kim Barrett wrote: >>>> On Nov 27, 2017, at 10:19 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> My question was why there's a command line option, which seems like nobody on earth should use it. Yes, we don't need to zap for product, only for debug. >>> So remove the CLA and instead #ifdef ASSERT the zapping. >> Yes. >>> I?d be okay with that. Another CLA bites the dust. >> What looks like a pointless one at that. >> >> Coleen > New webrev with ZapJNIHandleArea removed. > > full: http://cr.openjdk.java.net/~kbarrett/8191870/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8191870/open.01.inc/ > From tobias.hartmann at oracle.com Tue Nov 28 14:15:12 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Nov 2017 15:15:12 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> Message-ID: Hi Adrian, seems like this is due to my fix for JDK-8179026 [1] which now enforces the CodeCacheExpansionSize to be >= os::vm_page_size(). I did this because in CodeCache::initialize() we align the size anyway: CodeCacheExpansionSize = align_up(CodeCacheExpansionSize, os::vm_page_size()); Since other platforms define 32*K as their default value as well, it might be best to just set the lower limit to 32*K instead of os::vm_page_size() and let above alignment code take care of adjusting the size. Thanks, Tobias [1] http://hg.openjdk.java.net/jdk/hs/rev/7f40c1cdde28 On 28.11.2017 14:36, John Paul Adrian Glaubitz wrote: > Hi! > > During my recent tests, I noticed that Zero fails to build on both ppc32 > and ppc64 with the following error message: > > Optimizing the exploded image > /home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/jdk/bin/java -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 > -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -cp > /home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/buildtools/tools_jigsaw_classes --add-exports > java.base/jdk.internal.module=ALL-UNNAMED build.tools.jigsaw.AddPackagesAttribute > /home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/jdk > uintx CodeCacheExpansionSize=32768 is outside the allowed range [ 65536 ... 18446744073709551615 ] > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > ExplodedImageOptimize.gmk:40: recipe for target > '/home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/jdk/_packages_attribute.done' failed > make[3]: *** [/home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/jdk/_packages_attribute.done] Error 1 > make[3]: Leaving directory '/home/glaubitz/openjdk/hs/make' > make/Main.gmk:361: recipe for target 'exploded-image-optimize' failed > make[2]: *** [exploded-image-optimize] Error 2 > make[2]: Leaving directory '/home/glaubitz/openjdk/hs > > Looking at ./src/hotspot/share/runtime/globals.hpp, CodeCacheExpansionSize > is set to be 32768 bytes: > > define_pd_global(intx, CodeCacheExpansionSize,?????? 32*K); > > Interestingly, I have not run into this issue with Zero on x86_64 or SPARC > with other architectures currently being tested. Could it be that the > value of CodeCacheExpansionSize has a minimum limit on ppc*? If yes, should > we just increase it to 64k? > > Or maybe we have to find the place where it enforces the value on ppc* to > be unconditionally 64k? > > Thanks, > Adrian > From glaubitz at physik.fu-berlin.de Tue Nov 28 14:21:59 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 28 Nov 2017 15:21:59 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> Message-ID: <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> Hi Tobias! On 11/28/2017 03:15 PM, Tobias Hartmann wrote: > seems like this is due to my fix for JDK-8179026 [1] which now enforces the CodeCacheExpansionSize to be >= > os::vm_page_size(). I did this because in CodeCache::initialize() we align the size anyway: > > CodeCacheExpansionSize = align_up(CodeCacheExpansionSize, os::vm_page_size()); > > Since other platforms define 32*K as their default value as well, it might be best to just set the lower limit to 32*K > instead of os::vm_page_size() and let above alignment code take care of adjusting the size. Thanks a lot for your quick reply! Good to know that this regression was just introduced recently, I already thought I missed some other ppc-specific patch. So, looking at your changeset: > http://hg.openjdk.java.net/jdk/hs/rev/7f40c1cdde28#l3.1 Should we just set the sizes there from the fixed values defined in globals.hpp for all the cases where it's set to os::vm_page_size() or just for CodeCacheMinBlockLength? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From tobias.hartmann at oracle.com Tue Nov 28 14:31:19 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Nov 2017 15:31:19 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> Message-ID: <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> Hi Adrian, On 28.11.2017 15:21, John Paul Adrian Glaubitz wrote: > Should we just set the sizes there from the fixed values defined in globals.hpp > for all the cases where it's set to os::vm_page_size() or just for > CodeCacheMinBlockLength? I think we should just fix it for CodeCacheExpansionSize - range(os::vm_page_size(), max_uintx) \ + range(32*K, max_uintx) \ The default values for the other flags are much larger than vm_page_size() and definitely should be. I can take care of fixing this - since I also broke it :) Thanks for reporting! Best regards, Tobias From glaubitz at physik.fu-berlin.de Tue Nov 28 14:37:02 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 28 Nov 2017 15:37:02 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> Message-ID: <4fba866c-3168-a4c5-5558-2c46e1498492@physik.fu-berlin.de> On 11/28/2017 03:31 PM, Tobias Hartmann wrote: > I think we should just fix it for CodeCacheExpansionSize > > - range(os::vm_page_size(), max_uintx) \ > + range(32*K, max_uintx) \ > > The default values for the other flags are much larger than vm_page_size() and definitely should be. Alternatively, wouldn't it make more sense to set CodeCacheExpansionSize in globals.hpp to os::vm_page_size()? I mean, then your change would still be in and we still would fix the problem. > I can take care of fixing this - since I also broke it :) Ok, let me test the change first real quick just to be safe. > Thanks for reporting! Thanks for being so quick fixing it! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From coleen.phillimore at oracle.com Tue Nov 28 14:58:56 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Nov 2017 09:58:56 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> Message-ID: On 11/27/17 6:48 PM, Kim Barrett wrote: >> On Nov 27, 2017, at 3:43 PM, coleen.phillimore at oracle.com wrote: >> >> >> >> On 11/27/17 3:21 PM, Kim Barrett wrote: >>>> On Nov 27, 2017, at 10:19 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> My question was why there's a command line option, which seems like nobody on earth should use it. Yes, we don't need to zap for product, only for debug. >>> So remove the CLA and instead #ifdef ASSERT the zapping. >> Yes. >>> I?d be okay with that. Another CLA bites the dust. >> What looks like a pointless one at that. >> >> Coleen > New webrev with ZapJNIHandleArea removed. > > full: http://cr.openjdk.java.net/~kbarrett/8191870/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8191870/open.01.inc/ > http://cr.openjdk.java.net/~kbarrett/8191870/open.01/src/hotspot/share/runtime/jniHandles.hpp.udiff.html I think you need PRODUCT_RETURN for zap() in case the optimized target still builds.? Otherwise, looks good. Coleen From tobias.hartmann at oracle.com Tue Nov 28 15:01:41 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Nov 2017 16:01:41 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: <4fba866c-3168-a4c5-5558-2c46e1498492@physik.fu-berlin.de> References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> <4fba866c-3168-a4c5-5558-2c46e1498492@physik.fu-berlin.de> Message-ID: > Alternatively, wouldn't it make more sense to set CodeCacheExpansionSize > in globals.hpp to os::vm_page_size()? I mean, then your change would > still be in and we still would fix the problem. Yes, but to be on the safe side, we should fix the 32*K defaults on all platforms: http://cr.openjdk.java.net/~thartmann/8191996/webrev.01/ > Ok, let me test the change first real quick just to be safe. Thanks! Please let me know if there are still problems. > Thanks for being so quick fixing it! Sure, I've filed JDK-8191996 and will send the fix for review soon. Best regards, Tobias From glaubitz at physik.fu-berlin.de Tue Nov 28 15:07:35 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 28 Nov 2017 16:07:35 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> <4fba866c-3168-a4c5-5558-2c46e1498492@physik.fu-berlin.de> Message-ID: Hi Tobias! On 11/28/2017 04:01 PM, Tobias Hartmann wrote: > >> Alternatively, wouldn't it make more sense to set CodeCacheExpansionSize >> in globals.hpp to os::vm_page_size()? I mean, then your change would >> still be in and we still would fix the problem. > > Yes, but to be on the safe side, we should fix the 32*K defaults on all platforms: > http://cr.openjdk.java.net/~thartmann/8191996/webrev.01/ > >> Ok, let me test the change first real quick just to be safe. > > Thanks! Please let me know if there are still problems. Will test the change on all relevant targets now. Might take a bit longer, but I'll report back as soon as possible. >> Thanks for being so quick fixing it! > > Sure, I've filed JDK-8191996 and will send the fix for review soon. Ok, thanks. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Tue Nov 28 15:12:08 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 28 Nov 2017 16:12:08 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> <4fba866c-3168-a4c5-5558-2c46e1498492@physik.fu-berlin.de> Message-ID: <7a5e290b-dbab-9339-8425-50863d31caa5@physik.fu-berlin.de> On 11/28/2017 04:07 PM, John Paul Adrian Glaubitz wrote: > Will test the change on all relevant targets now. Might take a bit > longer, but I'll report back as soon as possible. Looks like you're missing an include here: if test `/usr/bin/wc -l < /home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_basicLock.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_biasedLocking.o:\n" * For target hotspot_variant-zero_libjvm_objs_biasedLocking.o: (/bin/grep -v -e "^Note: including file:" < /home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_biasedLocking.o.log || true) | /usr/bin/head -n 12 In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/utilities/debug.hpp:30:0, from /home/glaubitz/openjdk/hs/src/hotspot/share/utilities/globalDefinitions.hpp:29, from /home/glaubitz/openjdk/hs/src/hotspot/share/utilities/align.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/globals.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/memory/allocation.hpp:28, from /home/glaubitz/openjdk/hs/src/hotspot/share/logging/logLevel.hpp:27, from /home/glaubitz/openjdk/hs/src/hotspot/share/logging/log.hpp:27, from /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/biasedLocking.cpp:26: /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/globals.hpp:93:54: error: ?os? has not been declared define_pd_global(intx, CodeCacheExpansionSize, os::vm_page_size()); -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From tobias.hartmann at oracle.com Tue Nov 28 15:36:41 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Nov 2017 16:36:41 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: <7a5e290b-dbab-9339-8425-50863d31caa5@physik.fu-berlin.de> References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> <4fba866c-3168-a4c5-5558-2c46e1498492@physik.fu-berlin.de> <7a5e290b-dbab-9339-8425-50863d31caa5@physik.fu-berlin.de> Message-ID: On 28.11.2017 16:12, John Paul Adrian Glaubitz wrote: > Looks like you're missing an include here: > > if test `/usr/bin/wc -l < > /home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_basicLock.o.log` > -gt 12; then /bin/echo "?? ... (rest of output omitted)" ; fi > /usr/bin/printf "* For target hotspot_variant-zero_libjvm_objs_biasedLocking.o:\n" > * For target hotspot_variant-zero_libjvm_objs_biasedLocking.o: > (/bin/grep -v -e "^Note: including file:" /home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_biasedLocking.o.log > || true) | /usr/bin/head -n 12 > In file included from /home/glaubitz/openjdk/hs/src/hotspot/share/utilities/debug.hpp:30:0, > ???????????????? from /home/glaubitz/openjdk/hs/src/hotspot/share/utilities/globalDefinitions.hpp:29, > ???????????????? from /home/glaubitz/openjdk/hs/src/hotspot/share/utilities/align.hpp:28, > ???????????????? from /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/globals.hpp:28, > ???????????????? from /home/glaubitz/openjdk/hs/src/hotspot/share/memory/allocation.hpp:28, > ???????????????? from /home/glaubitz/openjdk/hs/src/hotspot/share/logging/logLevel.hpp:27, > ???????????????? from /home/glaubitz/openjdk/hs/src/hotspot/share/logging/log.hpp:27, > ???????????????? from /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/biasedLocking.cpp:26: > /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/globals.hpp:93:54: error: ?os? has not been declared > ?define_pd_global(intx, CodeCacheExpansionSize,?????? os::vm_page_size()); Thanks, I've just noticed this as well but it seems we cannot include runtime/os.hpp from globals.hpp without introducing circular dependencies.. I guess it's best to go with the straight forward fix of setting the min value to 32*K: http://cr.openjdk.java.net/~thartmann/8191996/webrev.00/ What do you think? Best regards, Tobias From glaubitz at physik.fu-berlin.de Tue Nov 28 15:43:08 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 28 Nov 2017 16:43:08 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> <4fba866c-3168-a4c5-5558-2c46e1498492@physik.fu-berlin.de> <7a5e290b-dbab-9339-8425-50863d31caa5@physik.fu-berlin.de> Message-ID: On 11/28/2017 04:36 PM, Tobias Hartmann wrote: > Thanks, I've just noticed this as well but it seems we cannot include runtime/os.hpp from globals.hpp without > introducing circular dependencies.. Hmm, we might be able to reorder some include directions. I will have a look at this. > I guess it's best to go with the straight forward fix of setting the min value to 32*K: > http://cr.openjdk.java.net/~thartmann/8191996/webrev.00/ I guess that works, too, but I'm not too happy with it unless we have made sure there isn't really any other option. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From tobias.hartmann at oracle.com Tue Nov 28 17:45:34 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Nov 2017 18:45:34 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> <4fba866c-3168-a4c5-5558-2c46e1498492@physik.fu-berlin.de> <7a5e290b-dbab-9339-8425-50863d31caa5@physik.fu-berlin.de> Message-ID: <0437c6d7-6558-84fb-c70b-57a1e5ce0e19@oracle.com> On 28.11.2017 16:43, John Paul Adrian Glaubitz wrote: > Hmm, we might be able to reorder some include directions. I will have a look > at this. I've tried this but I don't think it's easily possible. > I guess that works, too, but I'm not too happy with it unless we have made sure > there isn't really any other option. Right, I agree but we still need to fix this quickly because it blocks integration. I've sent a RFR: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-November/027723.html If it turns out that there is a better way, we can still push a follow-up fix. With respect to behavior there is no difference because the default size gets aligned to page-size anyway. Thanks, Tobias From dean.long at oracle.com Tue Nov 28 18:00:46 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 28 Nov 2017 10:00:46 -0800 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes Message-ID: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8191437 http://cr.openjdk.java.net/~dlong/8191437/webrev.hs/ http://cr.openjdk.java.net/~dlong/8191437/webrev.graal/ This change adds support for thread local handshakes to Graal for x64 and SPARC.? Graal generates a different instruction encoding on x64 than C1/C2, so I had to account for that difference in sharedRuntime_x86_64.cpp.? I'm including the Graal changes because I would like to push them together with the HotSpot changes. dl From kim.barrett at oracle.com Tue Nov 28 19:00:22 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Nov 2017 14:00:22 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: <4ec9ed56-84c6-e4cc-b6e7-52902c5d6c9f@oracle.com> References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> <4ec9ed56-84c6-e4cc-b6e7-52902c5d6c9f@oracle.com> Message-ID: > On Nov 28, 2017, at 8:45 AM, Daniel D. Daugherty wrote: > > On 11/27/17 6:48 PM, Kim Barrett wrote: >>> On Nov 27, 2017, at 3:43 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> >>> On 11/27/17 3:21 PM, Kim Barrett wrote: >>>>> On Nov 27, 2017, at 10:19 AM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> My question was why there's a command line option, which seems like nobody on earth should use it. Yes, we don't need to zap for product, only for debug. >>>> So remove the CLA and instead #ifdef ASSERT the zapping. >>> Yes. >>>> I?d be okay with that. Another CLA bites the dust. >>> What looks like a pointless one at that. >>> >>> Coleen >> New webrev with ZapJNIHandleArea removed. >> >> full: http://cr.openjdk.java.net/~kbarrett/8191870/open.01/ > > src/hotspot/share/runtime/globals.hpp > No comments. > > src/hotspot/share/runtime/jniHandles.cpp > No comments. > > src/hotspot/share/runtime/jniHandles.hpp > No comments. > > src/hotspot/share/runtime/sharedRuntime.cpp > No comments. > > src/hotspot/share/utilities/globalDefinitions.hpp > No comments. > > Thumbs up. Thanks, Dan. > > Dan > >> incr: http://cr.openjdk.java.net/~kbarrett/8191870/open.01.inc/ From kim.barrett at oracle.com Tue Nov 28 19:00:35 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Nov 2017 14:00:35 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: <5A1D6FA4.7010304@oracle.com> References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> <5A1D6FA4.7010304@oracle.com> Message-ID: <9B3E5B04-E897-4210-9E64-A2129232ECA5@oracle.com> > On Nov 28, 2017, at 9:16 AM, Erik ?sterlund wrote: > > Hi Kim, > > Still looks good. Thanks, Erik. > > Thanks, > /Erik > > On 2017-11-28 00:48, Kim Barrett wrote: >>> On Nov 27, 2017, at 3:43 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> >>> On 11/27/17 3:21 PM, Kim Barrett wrote: >>>>> On Nov 27, 2017, at 10:19 AM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> My question was why there's a command line option, which seems like nobody on earth should use it. Yes, we don't need to zap for product, only for debug. >>>> So remove the CLA and instead #ifdef ASSERT the zapping. >>> Yes. >>>> I?d be okay with that. Another CLA bites the dust. >>> What looks like a pointless one at that. >>> >>> Coleen >> New webrev with ZapJNIHandleArea removed. >> >> full: http://cr.openjdk.java.net/~kbarrett/8191870/open.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8191870/open.01.inc/ From kim.barrett at oracle.com Tue Nov 28 19:02:35 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Nov 2017 14:02:35 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> Message-ID: > On Nov 28, 2017, at 9:58 AM, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~kbarrett/8191870/open.01/src/hotspot/share/runtime/jniHandles.hpp.udiff.html > > I think you need PRODUCT_RETURN for zap() in case the optimized target still builds. Otherwise, looks good. > > Coleen I think PRODUCT_RETURN would break optimize builds. The definition of zap in the .cpp file is wrapped in #ifdef ASSERT. NOT_DEBUG_RETURN's definition is conditional on ASSERT. So those match. Using PRODUCT_RETURN would require the .cpp definition to be wrapped in #ifndef PRODUCT. But that combination would make zapping happen for optimize builds, which I think is wrong. From harold.seigel at oracle.com Tue Nov 28 19:04:13 2017 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 28 Nov 2017 14:04:13 -0500 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields In-Reply-To: References: Message-ID: Hi Sean, The hotspot changes look good! Thanks, Harold On 11/22/2017 9:37 AM, Sean Mullan wrote: > Please review this change to remove the pre-JDK 1.2 SecurityManager > methods that have been deprecated since JDK 1.2 and marked for removal > in JDK 9. These methods are fragile, error-prone and have been > obsolete since the SecurityManager was revamped in JDK 1.2. The > methods to be removed are: getInCheck, classDepth, classLoaderDepth, > currentClassLoader, currentLoadedClass, inClass, and inClassLoader. > > In addition, the deprecated and error-prone checkMemberAccess method > (which was deprecated in JDK 8 and marked for removal in JDK 9) has > been changed to throw SecurityException if the caller has not been > granted AllPermission. This makes the method less likely it will be > used incorrectly while still allowing some more time before it is > removed. > > http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/ > > Thanks, > Sean From coleen.phillimore at oracle.com Tue Nov 28 19:37:27 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Nov 2017 14:37:27 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> Message-ID: <607fe622-0a54-d078-6eb7-366c9e646176@oracle.com> On 11/28/17 2:02 PM, Kim Barrett wrote: >> On Nov 28, 2017, at 9:58 AM, coleen.phillimore at oracle.com wrote: >> >> http://cr.openjdk.java.net/~kbarrett/8191870/open.01/src/hotspot/share/runtime/jniHandles.hpp.udiff.html >> >> I think you need PRODUCT_RETURN for zap() in case the optimized target still builds. Otherwise, looks good. >> >> Coleen > I think PRODUCT_RETURN would break optimize builds. > > The definition of zap in the .cpp file is wrapped in #ifdef ASSERT. > NOT_DEBUG_RETURN's definition is conditional on ASSERT. So those > match. > > Using PRODUCT_RETURN would require the .cpp definition to be wrapped > in #ifndef PRODUCT. But that combination would make zapping happen for > optimize builds, which I think is wrong. > > Oh, yes, you're right.? I get that confused. Thanks, Coleen From mandy.chung at oracle.com Tue Nov 28 19:41:42 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 28 Nov 2017 11:41:42 -0800 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields In-Reply-To: References: Message-ID: <97def149-d3dc-bbe9-939c-5f2d7ffd8eba@oracle.com> On 11/22/17 6:37 AM, Sean Mullan wrote: > Please review this change to remove the pre-JDK 1.2 SecurityManager > methods that have been deprecated since JDK 1.2 and marked for removal > in JDK 9. These methods are fragile, error-prone and have been > obsolete since the SecurityManager was revamped in JDK 1.2. The > methods to be removed are: getInCheck, classDepth, classLoaderDepth, > currentClassLoader, currentLoadedClass, inClass, and inClassLoader. > > In addition, the deprecated and error-prone checkMemberAccess method > (which was deprecated in JDK 8 and marked for removal in JDK 9) has > been changed to throw SecurityException if the caller has not been > granted AllPermission. This makes the method less likely it will be > used incorrectly while still allowing some more time before it is > removed. > > http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/ > src/java.desktop/share/classes/sun/applet/AppletSecurity.java ?111???? private static final StackWalker walker = ?112???????? StackWalker.getInstance(RETAIN_CLASS_REFERENCE); This call will do a stack-based permission check.? So it needs to be wrapped with doPrivileged. Otherwise, looks fine. Just to mention this:? AppletSecurity does not really need the currentClassLoader method. AppletSecurity::currentAppletClassLoader could be reimplemented to use StackWalker to walk the stack once (replacing the call to currentClassLoader and getClassContext) to find AppletClassLoader. OTOH it does not worth making more change since applets are going away. Mandy From coleen.phillimore at oracle.com Tue Nov 28 20:14:39 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Nov 2017 15:14:39 -0500 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields In-Reply-To: References: Message-ID: <9e9a0f39-dd90-0347-a034-cf9a884c9ce6@oracle.com> Yes, I agree.? They look great.? Thank you for doing this! Coleen On 11/28/17 2:04 PM, harold seigel wrote: > Hi Sean, > > The hotspot changes look good! > > Thanks, Harold > > > On 11/22/2017 9:37 AM, Sean Mullan wrote: >> Please review this change to remove the pre-JDK 1.2 SecurityManager >> methods that have been deprecated since JDK 1.2 and marked for >> removal in JDK 9. These methods are fragile, error-prone and have >> been obsolete since the SecurityManager was revamped in JDK 1.2. The >> methods to be removed are: getInCheck, classDepth, classLoaderDepth, >> currentClassLoader, currentLoadedClass, inClass, and inClassLoader. >> >> In addition, the deprecated and error-prone checkMemberAccess method >> (which was deprecated in JDK 8 and marked for removal in JDK 9) has >> been changed to throw SecurityException if the caller has not been >> granted AllPermission. This makes the method less likely it will be >> used incorrectly while still allowing some more time before it is >> removed. >> >> http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/ >> >> Thanks, >> Sean > From kim.barrett at oracle.com Tue Nov 28 20:31:30 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Nov 2017 15:31:30 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: <607fe622-0a54-d078-6eb7-366c9e646176@oracle.com> References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> <607fe622-0a54-d078-6eb7-366c9e646176@oracle.com> Message-ID: <6842601E-807E-44C6-8235-D58F1233C141@oracle.com> > On Nov 28, 2017, at 2:37 PM, coleen.phillimore at oracle.com wrote: > > > > On 11/28/17 2:02 PM, Kim Barrett wrote: >>> On Nov 28, 2017, at 9:58 AM, coleen.phillimore at oracle.com wrote: >>> >>> http://cr.openjdk.java.net/~kbarrett/8191870/open.01/src/hotspot/share/runtime/jniHandles.hpp.udiff.html >>> >>> I think you need PRODUCT_RETURN for zap() in case the optimized target still builds. Otherwise, looks good. >>> >>> Coleen >> I think PRODUCT_RETURN would break optimize builds. >> >> The definition of zap in the .cpp file is wrapped in #ifdef ASSERT. >> NOT_DEBUG_RETURN's definition is conditional on ASSERT. So those >> match. >> >> Using PRODUCT_RETURN would require the .cpp definition to be wrapped >> in #ifndef PRODUCT. But that combination would make zapping happen for >> optimize builds, which I think is wrong. >> >> > > Oh, yes, you're right. I get that confused. > Thanks, > Coleen Thanks for reviewing. From david.holmes at oracle.com Tue Nov 28 21:11:16 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Nov 2017 07:11:16 +1000 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: <7a5e290b-dbab-9339-8425-50863d31caa5@physik.fu-berlin.de> References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> <4fba866c-3168-a4c5-5558-2c46e1498492@physik.fu-berlin.de> <7a5e290b-dbab-9339-8425-50863d31caa5@physik.fu-berlin.de> Message-ID: <64d1e8e4-7ac4-d617-2384-6bfa1cfe12fc@oracle.com> > define_pd_global(intx, CodeCacheExpansionSize, os::vm_page_size()); I thought the values here had to be constants ?? The appropriate level of initialization may not have happened when this default value would be assigned! David On 29/11/2017 1:12 AM, John Paul Adrian Glaubitz wrote: > On 11/28/2017 04:07 PM, John Paul Adrian Glaubitz wrote: >> Will test the change on all relevant targets now. Might take a bit >> longer, but I'll report back as soon as possible. > > Looks like you're missing an include here: > > if test `/usr/bin/wc -l < > /home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_basicLock.o.log` > -gt 12; then /bin/echo "?? ... (rest of output omitted)" ; fi > /usr/bin/printf "* For target > hotspot_variant-zero_libjvm_objs_biasedLocking.o:\n" > * For target hotspot_variant-zero_libjvm_objs_biasedLocking.o: > (/bin/grep -v -e "^Note: including file:" < > /home/glaubitz/openjdk/hs/build/linux-ppc64-normal-zero-release/make-support/failure-logs/hotspot_variant-zero_libjvm_objs_biasedLocking.o.log > || true) | /usr/bin/head -n 12 > In file included from > /home/glaubitz/openjdk/hs/src/hotspot/share/utilities/debug.hpp:30:0, > ???????????????? from > /home/glaubitz/openjdk/hs/src/hotspot/share/utilities/globalDefinitions.hpp:29, > > ???????????????? from > /home/glaubitz/openjdk/hs/src/hotspot/share/utilities/align.hpp:28, > ???????????????? from > /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/globals.hpp:28, > ???????????????? from > /home/glaubitz/openjdk/hs/src/hotspot/share/memory/allocation.hpp:28, > ???????????????? from > /home/glaubitz/openjdk/hs/src/hotspot/share/logging/logLevel.hpp:27, > ???????????????? from > /home/glaubitz/openjdk/hs/src/hotspot/share/logging/log.hpp:27, > ???????????????? from > /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/biasedLocking.cpp:26: > /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/globals.hpp:93:54: > error: ?os? has not been declared > ?define_pd_global(intx, CodeCacheExpansionSize,?????? os::vm_page_size()); > From david.holmes at oracle.com Tue Nov 28 21:22:37 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Nov 2017 07:22:37 +1000 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. In-Reply-To: <84bae716-9308-e372-5a13-f0c4d348b6a1@oracle.com> References: <5A184729.4090107@oracle.com> <84bae716-9308-e372-5a13-f0c4d348b6a1@oracle.com> Message-ID: <23b84b9e-fab6-f2f3-8cc7-bc8d67a17c7f@oracle.com> Hi Per, On 28/11/2017 5:53 PM, Per Liden wrote: > Hi David, > > On 2017-11-28 07:50, David Holmes wrote: >> Hi Erik, >> >> Does "phantom" here have any relationship to PhantomReference? > > Yes, in the sense that this root oop has the same strength as the > referent field in a PhantomReference. All non-strong root oops in the VM > (StringTable, JNIWeakHandles, etc) are "phantom oops". Internally in the > VM they are unfortunately sometimes referred to as "weak roots". With > the access API, we're trying to move away from using "weak" for these > since "weak" is the strength of the referent in a Soft/Weak/FinalReference. Ah I see. I hadn't realized we were mis-using "weak" that way. >> >> Meta-question on access API: if >> >> RootAccess::oop_load(addr); >> >> keeps the value alive, what can cause the value to be allowed to go dead >> again? > > After a GC, if all existing pointers to this object are phantom oops, > then the object is phantom-reachable and those phantom oops will be > declared dead and cleared (i.e. same criteria as when a > j.l.r.PhantomReference is enqueued). Sorry this is going OT wrt the actual code review but I'm a bit confused. If the above RootAccess marks the oop as PhantomReachable then GC can remove it and it wasn't kept alive after all ?? If the above makes it stronger than PhantomReachable then GC won't be able to remove it, but then how does it return to only being PhantomReachable? Thanks, David > cheers, > Per > >> >> Thanks, >> David >> >> On 25/11/2017 2:22 AM, Erik ?sterlund wrote: >>> Hi, >>> >>> When creating a ciInstanceKlass handle, G1 might need a SATB barrier >>> to keep "peeked" weak klass pointers alive during marking. >>> This should now be done with the Access API instead of manual calls to >>> the G1 SATB barrier. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8191567 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ >>> >>> Thanks, >>> /Erik From glaubitz at physik.fu-berlin.de Tue Nov 28 21:39:46 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 28 Nov 2017 22:39:46 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: <64d1e8e4-7ac4-d617-2384-6bfa1cfe12fc@oracle.com> References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> <4fba866c-3168-a4c5-5558-2c46e1498492@physik.fu-berlin.de> <7a5e290b-dbab-9339-8425-50863d31caa5@physik.fu-berlin.de> <64d1e8e4-7ac4-d617-2384-6bfa1cfe12fc@oracle.com> Message-ID: On 11/28/2017 10:11 PM, David Holmes wrote: >>?? define_pd_global(intx, CodeCacheExpansionSize, os::vm_page_size()); > > I thought the values here had to be constants ?? The appropriate level of initialization may not have happened when this default value would be assigned! Does this apply to all the initialization values set here? > http://hg.openjdk.java.net/jdk/hs/rev/7f40c1cdde28#l3.1 Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From david.holmes at oracle.com Tue Nov 28 23:34:29 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Nov 2017 09:34:29 +1000 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> <4fba866c-3168-a4c5-5558-2c46e1498492@physik.fu-berlin.de> <7a5e290b-dbab-9339-8425-50863d31caa5@physik.fu-berlin.de> <64d1e8e4-7ac4-d617-2384-6bfa1cfe12fc@oracle.com> Message-ID: <407272d1-8269-4ffe-1df4-92016df14831@oracle.com> On 29/11/2017 7:39 AM, John Paul Adrian Glaubitz wrote: > On 11/28/2017 10:11 PM, David Holmes wrote: >>> ?? define_pd_global(intx, CodeCacheExpansionSize, os::vm_page_size()); >> >> I thought the values here had to be constants ?? The appropriate level of initialization may not have happened when this default value would be assigned! > > Does this apply to all the initialization values set here? > >> http://hg.openjdk.java.net/jdk/hs/rev/7f40c1cdde28#l3.1 I'd certainly want to investigate exactly when in the initialization sequence these will get evaluated. I think range usage may be safer than default value, but this needs examining! David ----- > Adrian > From vladimir.kozlov at oracle.com Tue Nov 28 23:51:46 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Nov 2017 15:51:46 -0800 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line Message-ID: http://cr.openjdk.java.net/~kvn/8191788/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8191788 This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have --limit-modules option. Unfortunately tests start failing on SPARC where Graal (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] reversed 8190975 changes to fix that problem. This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM only when Graal is used: when it is explicitly specified with -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is true. I tested the fix with failed tests from JDK-8190975 which are mostly AppCDS tests in test/runtime/appcds/jigsaw and also test/jdk/java/lang/String/concat/WithSecurityManager.java I think this fix may break upgradeable status of Graal (for Oracle Labs version of Graal). But it should be fine since it is only used with --limit-modules which is not used by Labs. Thanks, Vladimir [1] http://hg.openjdk.java.net/jdk/hs/rev/8deb7919d118 [2] http://hg.openjdk.java.net/jdk/hs/rev/b38d8aadcada From vladimir.kozlov at oracle.com Wed Nov 29 00:12:23 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Nov 2017 16:12:23 -0800 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> Message-ID: <31460920-f4c8-4e50-d127-161e46f07896@oracle.com> On 11/28/17 10:00 AM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8191437 > > http://cr.openjdk.java.net/~dlong/8191437/webrev.hs/ VM changes looks fine to me. > > http://cr.openjdk.java.net/~dlong/8191437/webrev.graal/ > > > This change adds support for thread local handshakes to Graal for x64 and SPARC.? Graal generates a > different instruction encoding on x64 than C1/C2, so I had to account for that difference in I assume it works in all cases now (C1, C2, Graal generated code) ? > sharedRuntime_x86_64.cpp.? I'm including the Graal changes because I would like to push them > together with the HotSpot changes. I would still suggest to do review and testing in Labs. Thanks, Vladimir > > > dl > From dean.long at oracle.com Wed Nov 29 00:49:51 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 28 Nov 2017 16:49:51 -0800 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: <31460920-f4c8-4e50-d127-161e46f07896@oracle.com> References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> <31460920-f4c8-4e50-d127-161e46f07896@oracle.com> Message-ID: On 11/28/17 4:12 PM, Vladimir Kozlov wrote: > On 11/28/17 10:00 AM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8191437 >> >> http://cr.openjdk.java.net/~dlong/8191437/webrev.hs/ > > VM changes looks fine to me. > Thanks Vladimir. >> >> http://cr.openjdk.java.net/~dlong/8191437/webrev.graal/ >> >> >> This change adds support for thread local handshakes to Graal for x64 >> and SPARC.? Graal generates a different instruction encoding on x64 >> than C1/C2, so I had to account for that difference in > > I assume it works in all cases now (C1, C2, Graal generated code) ? Yes. > >> sharedRuntime_x86_64.cpp.? I'm including the Graal changes because I >> would like to push them together with the HotSpot changes. > > I would still suggest to do review and testing in Labs. > Yes, I waited until it was reviewed and pushed upstream to Graal before sending out this RFR. dl > Thanks, > Vladimir > >> >> >> dl >> From vladimir.kozlov at oracle.com Wed Nov 29 03:22:30 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Nov 2017 19:22:30 -0800 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> <31460920-f4c8-4e50-d127-161e46f07896@oracle.com> Message-ID: <850cec4d-5d3a-91df-3f5e-4c54a157c5df@oracle.com> On 11/28/17 4:49 PM, dean.long at oracle.com wrote: > On 11/28/17 4:12 PM, Vladimir Kozlov wrote: > >> On 11/28/17 10:00 AM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8191437 >>> >>> http://cr.openjdk.java.net/~dlong/8191437/webrev.hs/ >> >> VM changes looks fine to me. >> > > Thanks Vladimir. > >>> >>> http://cr.openjdk.java.net/~dlong/8191437/webrev.graal/ >>> >>> >>> This change adds support for thread local handshakes to Graal for x64 and SPARC.? Graal generates a different >>> instruction encoding on x64 than C1/C2, so I had to account for that difference in >> >> I assume it works in all cases now (C1, C2, Graal generated code) ? > > Yes. > >> >>> sharedRuntime_x86_64.cpp.? I'm including the Graal changes because I would like to push them together with the >>> HotSpot changes. >> >> I would still suggest to do review and testing in Labs. >> > > Yes, I waited until it was reviewed and pushed upstream to Graal before sending out this RFR. Good. Thanks, Vladimir > > dl > >> Thanks, >> Vladimir >> >>> >>> >>> dl >>> > From david.holmes at oracle.com Wed Nov 29 04:57:41 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Nov 2017 14:57:41 +1000 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: References: Message-ID: <9ca3556e-e8d2-a444-a3ce-5bb4557b5802@oracle.com> Hi Vladimir, On 29/11/2017 9:51 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8191788/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8191788 > > This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler > to tests which have --limit-modules option. Unfortunately tests start > failing on SPARC where Graal (jdk.internal.vm.compiler) is not > available. JDK-8191653 [2] reversed 8190975 changes to fix that problem. > > This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM > only when Graal is used: when it is explicitly specified with > -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is > true. This seems a reasonable way to handle this - at least for now. Typo: 3379 // and --limit-modules are spcified. spcified -> specified Thanks, David ----- > I tested the fix with failed tests from JDK-8190975 which are mostly > AppCDS tests in test/runtime/appcds/jigsaw and also > test/jdk/java/lang/String/concat/WithSecurityManager.java > > I think this fix may break upgradeable status of Graal (for Oracle Labs > version of Graal). > But it should be fine since it is only used with --limit-modules which > is not used by Labs. > > Thanks, > Vladimir > > [1] http://hg.openjdk.java.net/jdk/hs/rev/8deb7919d118 > [2] http://hg.openjdk.java.net/jdk/hs/rev/b38d8aadcada From calvin.cheung at oracle.com Wed Nov 29 06:15:39 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 28 Nov 2017 22:15:39 -0800 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: References: Message-ID: <5A1E508B.8090709@oracle.com> Hi Vladimir, Fix looks good to me. Could you break up lines #3386 (104 chars) and #3391 (146 chars)? No need to send another webrev for the above change. thanks, Calvin On 11/28/17, 3:51 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8191788/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8191788 > > This is redo of JDK-8190975 [1] fix which added > jdk.internal.vm.compiler to tests which have --limit-modules option. > Unfortunately tests start failing on SPARC where Graal > (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] reversed > 8190975 changes to fix that problem. > > This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM > only when Graal is used: when it is explicitly specified with > -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is > true. > > I tested the fix with failed tests from JDK-8190975 which are mostly > AppCDS tests in test/runtime/appcds/jigsaw and also > test/jdk/java/lang/String/concat/WithSecurityManager.java > > I think this fix may break upgradeable status of Graal (for Oracle > Labs version of Graal). > But it should be fine since it is only used with --limit-modules which > is not used by Labs. > > Thanks, > Vladimir > > [1] http://hg.openjdk.java.net/jdk/hs/rev/8deb7919d118 > [2] http://hg.openjdk.java.net/jdk/hs/rev/b38d8aadcada From vladimir.kozlov at oracle.com Wed Nov 29 07:45:54 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Nov 2017 23:45:54 -0800 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: <9ca3556e-e8d2-a444-a3ce-5bb4557b5802@oracle.com> References: <9ca3556e-e8d2-a444-a3ce-5bb4557b5802@oracle.com> Message-ID: <3987545f-87ff-5970-c946-381fe03a5a5b@oracle.com> Thank you, David On 11/28/17 8:57 PM, David Holmes wrote: > Hi Vladimir, > > On 29/11/2017 9:51 AM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8191788 >> >> This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have --limit-modules option. >> Unfortunately tests start failing on SPARC where Graal (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] >> reversed 8190975 changes to fix that problem. >> >> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM only when Graal is used: when it is explicitly >> specified with -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is true. > > This seems a reasonable way to handle this - at least for now. > > Typo: > > 3379???? // and --limit-modules are spcified. > > spcified -> specified Will fix. Vladimir > > Thanks, > David > ----- > >> I tested the fix with failed tests from JDK-8190975 which are mostly AppCDS tests in test/runtime/appcds/jigsaw and >> also test/jdk/java/lang/String/concat/WithSecurityManager.java >> >> I think this fix may break upgradeable status of Graal (for Oracle Labs version of Graal). >> But it should be fine since it is only used with --limit-modules which is not used by Labs. >> >> Thanks, >> Vladimir >> >> [1] http://hg.openjdk.java.net/jdk/hs/rev/8deb7919d118 >> [2] http://hg.openjdk.java.net/jdk/hs/rev/b38d8aadcada From vladimir.kozlov at oracle.com Wed Nov 29 07:49:32 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Nov 2017 23:49:32 -0800 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: <5A1E508B.8090709@oracle.com> References: <5A1E508B.8090709@oracle.com> Message-ID: <6f82dc58-9d91-bba8-16ad-3582036f1f6d@oracle.com> Thank you, Calvin On 11/28/17 10:15 PM, Calvin Cheung wrote: > Hi Vladimir, > > Fix looks good to me. > > Could you break up lines #3386 (104 chars) and #3391 (146 chars)? I will do that. Vladimir > No need to send another webrev for the above change. > > thanks, > Calvin > > On 11/28/17, 3:51 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8191788 >> >> This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have --limit-modules option. >> Unfortunately tests start failing on SPARC where Graal (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] >> reversed 8190975 changes to fix that problem. >> >> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM only when Graal is used: when it is explicitly >> specified with -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is true. >> >> I tested the fix with failed tests from JDK-8190975 which are mostly AppCDS tests in test/runtime/appcds/jigsaw and >> also test/jdk/java/lang/String/concat/WithSecurityManager.java >> >> I think this fix may break upgradeable status of Graal (for Oracle Labs version of Graal). >> But it should be fine since it is only used with --limit-modules which is not used by Labs. >> >> Thanks, >> Vladimir >> >> [1] http://hg.openjdk.java.net/jdk/hs/rev/8deb7919d118 >> [2] http://hg.openjdk.java.net/jdk/hs/rev/b38d8aadcada From tobias.hartmann at oracle.com Wed Nov 29 08:06:39 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 29 Nov 2017 09:06:39 +0100 Subject: CodeCacheExpansionSize too small for Zero on ppc32/ppc64 In-Reply-To: <407272d1-8269-4ffe-1df4-92016df14831@oracle.com> References: <492b50ac-edc6-e248-2350-11af5183a152@physik.fu-berlin.de> <5a559cfd-aa0d-8c23-d5a8-0e0f16a0150d@physik.fu-berlin.de> <9b1791a3-987e-651b-a37a-1aa3371612df@oracle.com> <4fba866c-3168-a4c5-5558-2c46e1498492@physik.fu-berlin.de> <7a5e290b-dbab-9339-8425-50863d31caa5@physik.fu-berlin.de> <64d1e8e4-7ac4-d617-2384-6bfa1cfe12fc@oracle.com> <407272d1-8269-4ffe-1df4-92016df14831@oracle.com> Message-ID: Hi, On 29.11.2017 00:34, David Holmes wrote: >>> I thought the values here had to be constants ?? The appropriate level of initialization may not have happened when >>> this default value would be assigned! Yes, I came to the same conclusion. I've fixed it by using a constant lower bound: http://hg.openjdk.java.net/jdk/hs/rev/646ed97b7e0d > I'd certainly want to investigate exactly when in the initialization sequence these will get evaluated. I think range > usage may be safer than default value, but this needs examining! Yes, I think the range usage is okay because it's only evaluated during argument processing (Arguments::process_argument()). We have existing uses in range checks: http://hg.openjdk.java.net/jdk/hs/file/5a449dbca6d0/src/hotspot/share/runtime/globals.hpp#l643 Thanks, Tobias From glaubitz at physik.fu-berlin.de Wed Nov 29 08:18:41 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 09:18:41 +0100 Subject: Zero crashing on ARM Message-ID: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> Hello! During my tests, I noticed that Zero is crashing on ARM (Debian armel): (sid_armel-dchroot)glaubitz at abel:~/openjdk/hs$ gdb /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/jdk/bin/java GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-linux-gnueabi". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/jdk/bin/java...(no debugging symbols found)...done. (gdb) r Starting program: /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/jdk/bin/java [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1". [New Thread 0xb6682470 (LWP 16442)] Thread 2 "java" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb6682470 (LWP 16442)] OSContainer::init () at /home/glaubitz/openjdk/hs/src/hotspot/os/linux/osContainer_linux.cpp:372 372 memory->set_subsystem_path(base); (gdb) bt #0 OSContainer::init () at /home/glaubitz/openjdk/hs/src/hotspot/os/linux/osContainer_linux.cpp:372 #1 0xb6bee5dc in os::pd_init_container_support () at /home/glaubitz/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:4908 #2 0xb67fdf7c in os::init_container_support () at /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/os.hpp:152 #3 Arguments::parse_vm_init_args (java_tool_options_args=java_tool_options_args at entry=0xb6681b64, java_options_args=java_options_args at entry=0xb6681b80, cmd_line_args=cmd_line_args at entry=0xb6681e40) at /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/arguments.cpp:2379 #4 0xb67fe1d0 in Arguments::parse (initial_cmd_args=initial_cmd_args at entry=0xb6681e40) at /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/arguments.cpp:4049 #5 0xb6cc97d4 in Threads::create_vm (args=args at entry=0xb6681e40, canTryAgain=canTryAgain at entry=0xb6681dbf) at /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3974 #6 0xb6a98a5c in JNI_CreateJavaVM_inner (args=0xb6681e40, penv=0xb6681e3c, vm=0xb6681e38) at /home/glaubitz/openjdk/hs/src/hotspot/share/prims/jni.cpp:3917 #7 JNI_CreateJavaVM (vm=0xb6681e38, penv=0xb6681e3c, args=0xb6681e40) at /home/glaubitz/openjdk/hs/src/hotspot/share/prims/jni.cpp:4012 #8 0xb6f605a4 in InitializeJVM (ifn=, penv=0xb6681e34, pvm=0xb6681e30) at /home/glaubitz/openjdk/hs/src/java.base/share/native/libjli/java.c:1478 #9 JavaMain (_args=) at /home/glaubitz/openjdk/hs/src/java.base/share/native/libjli/java.c:411 #10 0xb6f81338 in start_thread () from /lib/arm-linux-gnueabi/libpthread.so.0 #11 0xb6ed10cc in ?? () from /lib/arm-linux-gnueabi/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) It also crashes on SuperH (Debian sh4) but I cannot provide a backtrace in this case due to limitations of QEMU and GDB on SuperH currently being incomplete. But I guess that fixing the issue on ARM will also fix the issue on SuperH. I haven't done any debugging yet, but any input is welcome :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From robbin.ehn at oracle.com Wed Nov 29 08:23:17 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 29 Nov 2017 09:23:17 +0100 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> Message-ID: <7388ef34-681b-db6d-f6b5-f4c44519721b@oracle.com> On 2017-11-28 19:00, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8191437 > > http://cr.openjdk.java.net/~dlong/8191437/webrev.hs/ Looks good, thanks for fixing! /Robbin > > http://cr.openjdk.java.net/~dlong/8191437/webrev.graal/ > > > This change adds support for thread local handshakes to Graal for x64 and SPARC.? Graal generates a different instruction encoding on x64 than C1/C2, so I had to account for that difference in sharedRuntime_x86_64.cpp.? I'm including the Graal changes because I would like to push them together with the HotSpot changes. > > > dl > From Alan.Bateman at oracle.com Wed Nov 29 09:05:30 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Nov 2017 09:05:30 +0000 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: References: Message-ID: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> On 28/11/2017 23:51, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8191788/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8191788 > > This is redo of JDK-8190975 [1] fix which added > jdk.internal.vm.compiler to tests which have --limit-modules option. > Unfortunately tests start failing on SPARC where Graal > (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] reversed > 8190975 changes to fix that problem. > > This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM > only when Graal is used: when it is explicitly specified with > -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is > true. > > I tested the fix with failed tests from JDK-8190975 which are mostly > AppCDS tests in test/runtime/appcds/jigsaw and also > test/jdk/java/lang/String/concat/WithSecurityManager.java > > I think this fix may break upgradeable status of Graal (for Oracle > Labs version of Graal). > But it should be fine since it is only used with --limit-modules which > is not used by Labs. If jdk.internal.vm.compiler is not observable on SPARC then shouldn't the tests have `@requires jdk.internal.vm.compiler` and jtreg will skip the test on that platform? Just asking as augmenting the value passed to --limit-modules is very strange. It's normal for XX options to augment the set of modules that resolved (+EnableJVMCI implies `--add-modules jdk.internal.vm.ci` for example) but doing this for --limit-modules suggests the VM is doing something to mask an issue with the way that the tests are run. -Alan From david.holmes at oracle.com Wed Nov 29 10:11:43 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Nov 2017 20:11:43 +1000 Subject: RFR: 8191860: Add perfData.inline.hpp In-Reply-To: References: Message-ID: <42d91c8c-2d02-6eac-ec5d-457d34dee241@oracle.com> Hi Stefan, On 24/11/2017 11:21 PM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to create a perfData.inline.hpp file and move > inline functions in perfData.hpp that depend on functions in other > .inline.hpp files. > > http://cr.openjdk.java.net/~stefank/8191860/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8191860 > > Note 1: I consider growableArray.hpp to be an .inline.hpp in disguise, > since it includes allocation.inline.hpp. Is that why you didn't #include it instead of forward declaring: + template class GrowableArray; ? > Note 2: Some .hpp files that used to include perfData.hpp now explicitly > includes allocation.inline.hpp. We should deal with that, but in another > RFE. Yes we should deal with that - but the fanout from these changes can get huge. I don't relish trying to refactor arguments.hpp into arguments.inline.hpp for example. Cheers, David > thanks, > StefanK From david.holmes at oracle.com Wed Nov 29 10:25:28 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Nov 2017 20:25:28 +1000 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> Message-ID: On 28/11/2017 6:43 AM, coleen.phillimore at oracle.com wrote: > On 11/27/17 3:21 PM, Kim Barrett wrote: >>> On Nov 27, 2017, at 10:19 AM, coleen.phillimore at oracle.com wrote: >>> My question was why there's a command line option, which seems like >>> nobody on earth should use it.? Yes, we don't need to zap for >>> product, only for debug. >> So remove the CLA and instead #ifdef ASSERT the zapping. > > Yes. Okay we _really_ need to establish the ground rules for when you can just delete a CLA without going through any deprecation process or filing a CSR! David ----- >> >> I?d be okay with that.? Another CLA bites the dust. > > What looks like a pointless one at that. > > Coleen >> >> > From sgehwolf at redhat.com Wed Nov 29 10:33:30 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 29 Nov 2017 11:33:30 +0100 Subject: Zero crashing on ARM In-Reply-To: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> Message-ID: <1511951610.4026.10.camel@redhat.com> Hi, It appears that platform has a different format wrt to cgroups. What do you get when run with os+container debug logging? /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/jdk/bin/java -Xlog:os+container=debug Do you see "Incompatible str containing cgroup and memory" messages? Contents of /proc/self/mountinfo and /proc/self/cgroup would be useful to know too. Thanks, Severin On Wed, 2017-11-29 at 09:18 +0100, John Paul Adrian Glaubitz wrote: > Hello! > > During my tests, I noticed that Zero is crashing on ARM (Debian armel): > > (sid_armel-dchroot)glaubitz at abel:~/openjdk/hs$ gdb /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/jdk/bin/java > GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git > Copyright (C) 2016 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "arm-linux-gnueabi". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > . > Find the GDB manual and other documentation resources online at: > . > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/jdk/bin/java...(no debugging symbols found)...done. > (gdb) r > Starting program: /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/jdk/bin/java > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/arm-linux-gnueabi/libthread_db.so.1". > [New Thread 0xb6682470 (LWP 16442)] > > Thread 2 "java" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb6682470 (LWP 16442)] > OSContainer::init () at /home/glaubitz/openjdk/hs/src/hotspot/os/linux/osContainer_linux.cpp:372 > 372 memory->set_subsystem_path(base); > (gdb) bt > #0 OSContainer::init () at /home/glaubitz/openjdk/hs/src/hotspot/os/linux/osContainer_linux.cpp:372 > #1 0xb6bee5dc in os::pd_init_container_support () at /home/glaubitz/openjdk/hs/src/hotspot/os/linux/os_linux.cpp:4908 > #2 0xb67fdf7c in os::init_container_support () at /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/os.hpp:152 > #3 Arguments::parse_vm_init_args (java_tool_options_args=java_tool_options_args at entry=0xb6681b64, java_options_args=java_options_args at entry=0xb6681b80, > cmd_line_args=cmd_line_args at entry=0xb6681e40) at /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/arguments.cpp:2379 > #4 0xb67fe1d0 in Arguments::parse (initial_cmd_args=initial_cmd_args at entry=0xb6681e40) at /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/arguments.cpp:4049 > #5 0xb6cc97d4 in Threads::create_vm (args=args at entry=0xb6681e40, canTryAgain=canTryAgain at entry=0xb6681dbf) at > /home/glaubitz/openjdk/hs/src/hotspot/share/runtime/thread.cpp:3974 > #6 0xb6a98a5c in JNI_CreateJavaVM_inner (args=0xb6681e40, penv=0xb6681e3c, vm=0xb6681e38) at /home/glaubitz/openjdk/hs/src/hotspot/share/prims/jni.cpp:3917 > #7 JNI_CreateJavaVM (vm=0xb6681e38, penv=0xb6681e3c, args=0xb6681e40) at /home/glaubitz/openjdk/hs/src/hotspot/share/prims/jni.cpp:4012 > #8 0xb6f605a4 in InitializeJVM (ifn=, penv=0xb6681e34, pvm=0xb6681e30) at > /home/glaubitz/openjdk/hs/src/java.base/share/native/libjli/java.c:1478 > #9 JavaMain (_args=) at /home/glaubitz/openjdk/hs/src/java.base/share/native/libjli/java.c:411 > #10 0xb6f81338 in start_thread () from /lib/arm-linux-gnueabi/libpthread.so.0 > #11 0xb6ed10cc in ?? () from /lib/arm-linux-gnueabi/libc.so.6 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > (gdb) > > It also crashes on SuperH (Debian sh4) but I cannot provide a backtrace in this > case due to limitations of QEMU and GDB on SuperH currently being incomplete. But > I guess that fixing the issue on ARM will also fix the issue on SuperH. > > I haven't done any debugging yet, but any input is welcome :). > > Adrian > From stefan.karlsson at oracle.com Wed Nov 29 10:52:34 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 29 Nov 2017 11:52:34 +0100 Subject: RFR: 8191860: Add perfData.inline.hpp In-Reply-To: <42d91c8c-2d02-6eac-ec5d-457d34dee241@oracle.com> References: <42d91c8c-2d02-6eac-ec5d-457d34dee241@oracle.com> Message-ID: <6ce735d0-b7b5-ae79-376c-da86e7b15705@oracle.com> Hi David, On 2017-11-29 11:11, David Holmes wrote: > Hi Stefan, > > On 24/11/2017 11:21 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to create a perfData.inline.hpp file and move >> inline functions in perfData.hpp that depend on functions in other >> .inline.hpp files. >> >> http://cr.openjdk.java.net/~stefank/8191860/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8191860 >> >> Note 1: I consider growableArray.hpp to be an .inline.hpp in disguise, >> since it includes allocation.inline.hpp. > > Is that why you didn't #include it instead of forward declaring: > > + template class GrowableArray; > > ? Yes, this was the initial motivation. However, I do think its nice to only forward declare classes, where it's possible, so that we don't have to bring in dependencies against other header files unnecessarily. This is extra important given that a lot of our header files transitively include more than they need. > >> Note 2: Some .hpp files that used to include perfData.hpp now >> explicitly includes allocation.inline.hpp. We should deal with that, >> but in another RFE. > > Yes we should deal with that - but the fanout from these changes can get > huge. I don't relish trying to refactor arguments.hpp into > arguments.inline.hpp for example. I've created a RFE and a set of patches to do this clean-up: https://bugs.openjdk.java.net/browse/JDK-8192061 I'll send it out shortly. Thanks, StefanK > > Cheers, > David > >> thanks, >> StefanK From doug.simon at oracle.com Wed Nov 29 10:56:44 2017 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 29 Nov 2017 11:56:44 +0100 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> References: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> Message-ID: <3BD68E18-134C-4EA8-8861-8BD57C35FA57@oracle.com> > On 29 Nov 2017, at 10:05, Alan Bateman wrote: > > On 28/11/2017 23:51, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8191788 >> >> This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have --limit-modules option. Unfortunately tests start failing on SPARC where Graal (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] reversed 8190975 changes to fix that problem. >> >> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM only when Graal is used: when it is explicitly specified with -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is true. >> >> I tested the fix with failed tests from JDK-8190975 which are mostly AppCDS tests in test/runtime/appcds/jigsaw and also test/jdk/java/lang/String/concat/WithSecurityManager.java >> >> I think this fix may break upgradeable status of Graal (for Oracle Labs version of Graal). >> But it should be fine since it is only used with --limit-modules which is not used by Labs. > If jdk.internal.vm.compiler is not observable on SPARC then shouldn't the tests have `@requires jdk.internal.vm.compiler` and jtreg will skip the test on that platform? > > Just asking as augmenting the value passed to --limit-modules is very strange. It's normal for XX options to augment the set of modules that resolved (+EnableJVMCI implies `--add-modules jdk.internal.vm.ci` for example) but doing this for --limit-modules suggests the VM is doing something to mask an issue with the way that the tests are run. As much as I understand the issue, I agree. This seems like something that should be addressed in the test(s) instead of in the VM. -Doug From adinn at redhat.com Wed Nov 29 11:15:33 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 29 Nov 2017 11:15:33 +0000 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> Message-ID: Hi Dean, On 28/11/17 18:00, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8191437 > > http://cr.openjdk.java.net/~dlong/8191437/webrev.hs/ > > http://cr.openjdk.java.net/~dlong/8191437/webrev.graal/ > > > This change adds support for thread local handshakes to Graal for x64 > and SPARC.? Graal generates a different instruction encoding on x64 than > C1/C2, so I had to account for that difference in > sharedRuntime_x86_64.cpp.? I'm including the Graal changes because I > would like to push them together with the HotSpot changes. Is there a reason for rejecting use of thread local handshakes in the Graal AArch64 code rather than just adding support for it? The changes to make AArch64 implement this are targetted for 10 and in review on aarch64-port-dev https://bugs.openjdk.java.net/browse/JDK-8189596 http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2017-November/005104.html regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From per.liden at oracle.com Wed Nov 29 11:17:38 2017 From: per.liden at oracle.com (Per Liden) Date: Wed, 29 Nov 2017 12:17:38 +0100 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. In-Reply-To: <23b84b9e-fab6-f2f3-8cc7-bc8d67a17c7f@oracle.com> References: <5A184729.4090107@oracle.com> <84bae716-9308-e372-5a13-f0c4d348b6a1@oracle.com> <23b84b9e-fab6-f2f3-8cc7-bc8d67a17c7f@oracle.com> Message-ID: <67b482bd-cd01-0097-50b4-4b6090583926@oracle.com> Hi David, On 11/28/2017 10:22 PM, David Holmes wrote: > Hi Per, > > On 28/11/2017 5:53 PM, Per Liden wrote: >> Hi David, >> >> On 2017-11-28 07:50, David Holmes wrote: >>> Hi Erik, >>> >>> Does "phantom" here have any relationship to PhantomReference? >> >> Yes, in the sense that this root oop has the same strength as the >> referent field in a PhantomReference. All non-strong root oops in the >> VM (StringTable, JNIWeakHandles, etc) are "phantom oops". Internally >> in the VM they are unfortunately sometimes referred to as "weak >> roots". With the access API, we're trying to move away from using >> "weak" for these since "weak" is the strength of the referent in a >> Soft/Weak/FinalReference. > > Ah I see. I hadn't realized we were mis-using "weak" that way. > >>> >>> Meta-question on access API: if >>> >>> RootAccess::oop_load(addr); >>> >>> keeps the value alive, what can cause the value to be allowed to go dead >>> again? >> >> After a GC, if all existing pointers to this object are phantom oops, >> then the object is phantom-reachable and those phantom oops will be >> declared dead and cleared (i.e. same criteria as when a >> j.l.r.PhantomReference is enqueued). > > Sorry this is going OT wrt the actual code review but I'm a bit > confused. If the above RootAccess marks the oop as PhantomReachable then > GC can remove it and it wasn't kept alive after all ?? If the above > makes it stronger than PhantomReachable then GC won't be able to remove > it, but then how does it return to only being PhantomReachable? Unless the access has the AS_NO_KEEPALIVE decorator, a call to RootAccess<>::oop_load() will always make the object strongly reachable or return NULL. The ON_WEAK_OOP_REF/ON_PHANTOM_OOP_REF tells that access barrier that this oop is subject to resurrection restrictions. This means that special care needs to be taken when loading this oop, because the object it points to might already have been declared weak- or phantom-reachable, but this oop has not yet been cleared (set to NULL). In this case, the access barrier will step in, detect the situation and return NULL anyway, essentially making it look like the oop has been cleared. At some point later, when the GC is doing weak/phantom reference processing, the logically dead oops will actually be cleared (set to NULL). /Per > > Thanks, > David > >> cheers, >> Per >> >>> >>> Thanks, >>> David >>> >>> On 25/11/2017 2:22 AM, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> When creating a ciInstanceKlass handle, G1 might need a SATB barrier >>>> to keep "peeked" weak klass pointers alive during marking. >>>> This should now be done with the Access API instead of manual calls to >>>> the G1 SATB barrier. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8191567 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ >>>> >>>> Thanks, >>>> /Erik From aph at redhat.com Wed Nov 29 11:19:44 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Nov 2017 11:19:44 +0000 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> Message-ID: <915e431d-c33e-5690-6d9f-6bd6d4ab0b8d@redhat.com> On 29/11/17 11:15, Andrew Dinn wrote: > Is there a reason for rejecting use of thread local handshakes in the > Graal AArch64 code rather than just adding support for it? The changes > to make AArch64 implement this are targetted for 10 and in review on > aarch64-port-dev They're not in review, they're in. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stefan.karlsson at oracle.com Wed Nov 29 11:21:57 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 29 Nov 2017 12:21:57 +0100 Subject: RFR: 8192061: Clean up allocation.inline.hpp includes Message-ID: <1348b2d2-e1b5-73ee-7312-b4ca6f5fe4e1@oracle.com> Hi all, Please review this patchset to clean up our includes of allocation.inline.hpp and move usages of its functions out from header files into .cpp and .inline.hpp files. http://cr.openjdk.java.net/~stefank/8192061/webrev.01.all I've split this patch into multiple separate patches and tried to group them according to HotSpot area, to make it easier to review. I can also create separate bugs for this, if that's preferable. GC: http://cr.openjdk.java.net/~stefank/8192061/webrev.01.00.GC.g1ConcurrentRefine/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.01.GC.spaceCounters/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.02.GC.g1ParScanThreadState.hpp/ RT: http://cr.openjdk.java.net/~stefank/8192061/webrev.01.03.GC.adaptivePaddedAverage/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.04.RT.diagnosticArgument/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.05.RT.methodHandles/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.06.RT.constantPool/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.07.RT.sharedPathsMiscInfo/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.08.RT.generateOopMap/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.09.RT.objectMonitor/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.10.RT.arguments/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.11.RT.osThread/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.12.resourceArea/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.13.RT.array/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.14.RT.test_logMessage/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.15.RT.park/ SHARED: http://cr.openjdk.java.net/~stefank/8192061/webrev.01.16.SHARED.growableArray/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.17.SHARED.removeIncludes/ http://cr.openjdk.java.net/~stefank/8192061/webrev.01.18.SHARED.precompiled/ Thanks, StefanK From david.holmes at oracle.com Wed Nov 29 11:26:11 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Nov 2017 21:26:11 +1000 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> References: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> Message-ID: <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com> On 29/11/2017 7:05 PM, Alan Bateman wrote: > On 28/11/2017 23:51, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8191788 >> >> This is redo of JDK-8190975 [1] fix which added >> jdk.internal.vm.compiler to tests which have --limit-modules option. >> Unfortunately tests start failing on SPARC where Graal >> (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] reversed >> 8190975 changes to fix that problem. >> >> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM >> only when Graal is used: when it is explicitly specified with >> -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is >> true. >> >> I tested the fix with failed tests from JDK-8190975 which are mostly >> AppCDS tests in test/runtime/appcds/jigsaw and also >> test/jdk/java/lang/String/concat/WithSecurityManager.java >> >> I think this fix may break upgradeable status of Graal (for Oracle >> Labs version of Graal). >> But it should be fine since it is only used with --limit-modules which >> is not used by Labs. > If jdk.internal.vm.compiler is not observable on SPARC then shouldn't > the tests have `@requires jdk.internal.vm.compiler` and jtreg will skip > the test on that platform? I didn't know @requires supported modules that way! Even so we'd also have to reapply the original fix for JDK-8190975 to update --limit-modules. > Just asking as augmenting the value passed to --limit-modules is very > strange. It's normal for XX options to augment the set of modules that > resolved (+EnableJVMCI implies `--add-modules jdk.internal.vm.ci` for > example) but doing this for --limit-modules suggests the VM is doing > something to mask an issue with the way that the tests are run. The current approach basically prevents anyone using JVMCI from shooting themselves in the foot by setting --limit-modules in a way that excludes the jdk.internal.vm.compiler module. In essence we want to ensure that if using JVMCI then all the requisite pieces will be available. But perhaps we are doing this the wrong way: how do --limit-modules and --add-modules combine? We could add jdk.internal.vm.compiler rather than expanding the limit-set. But the end result would seem the same. Thanks, David > > -Alan From david.holmes at oracle.com Wed Nov 29 11:33:21 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Nov 2017 21:33:21 +1000 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. In-Reply-To: <67b482bd-cd01-0097-50b4-4b6090583926@oracle.com> References: <5A184729.4090107@oracle.com> <84bae716-9308-e372-5a13-f0c4d348b6a1@oracle.com> <23b84b9e-fab6-f2f3-8cc7-bc8d67a17c7f@oracle.com> <67b482bd-cd01-0097-50b4-4b6090583926@oracle.com> Message-ID: Hi Per, Sorry one follow up ... On 29/11/2017 9:17 PM, Per Liden wrote: > Hi David, > > On 11/28/2017 10:22 PM, David Holmes wrote: >> Hi Per, >> >> On 28/11/2017 5:53 PM, Per Liden wrote: >>> Hi David, >>> >>> On 2017-11-28 07:50, David Holmes wrote: >>>> Hi Erik, >>>> >>>> Does "phantom" here have any relationship to PhantomReference? >>> >>> Yes, in the sense that this root oop has the same strength as the >>> referent field in a PhantomReference. All non-strong root oops in the >>> VM (StringTable, JNIWeakHandles, etc) are "phantom oops". Internally >>> in the VM they are unfortunately sometimes referred to as "weak >>> roots". With the access API, we're trying to move away from using >>> "weak" for these since "weak" is the strength of the referent in a >>> Soft/Weak/FinalReference. >> >> Ah I see. I hadn't realized we were mis-using "weak" that way. >> >>>> >>>> Meta-question on access API: if >>>> >>>> RootAccess::oop_load(addr); >>>> >>>> keeps the value alive, what can cause the value to be allowed to go >>>> dead >>>> again? >>> >>> After a GC, if all existing pointers to this object are phantom oops, >>> then the object is phantom-reachable and those phantom oops will be >>> declared dead and cleared (i.e. same criteria as when a >>> j.l.r.PhantomReference is enqueued). >> >> Sorry this is going OT wrt the actual code review but I'm a bit >> confused. If the above RootAccess marks the oop as PhantomReachable then >> GC can remove it and it wasn't kept alive after all ?? If the above >> makes it stronger than PhantomReachable then GC won't be able to remove >> it, but then how does it return to only being PhantomReachable? > > Unless the access has the AS_NO_KEEPALIVE decorator, a call to > RootAccess<>::oop_load() will always make the object strongly reachable > or return NULL. OKay, but for how long will it remain strongly reachable? Just till the end of the current GC cycle, or the start of the next, or ... ? Thanks, David > The ON_WEAK_OOP_REF/ON_PHANTOM_OOP_REF tells that access barrier that > this oop is subject to resurrection restrictions. This means that > special care needs to be taken when loading this oop, because the object > it points to might already have been declared weak- or > phantom-reachable, but this oop has not yet been cleared (set to NULL). > In this case, the access barrier will step in, detect the situation and > return NULL anyway, essentially making it look like the oop has been > cleared. At some point later, when the GC is doing weak/phantom > reference processing, the logically dead oops will actually be cleared > (set to NULL). > > /Per > >> >> Thanks, >> David >> >>> cheers, >>> Per >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 25/11/2017 2:22 AM, Erik ?sterlund wrote: >>>>> Hi, >>>>> >>>>> When creating a ciInstanceKlass handle, G1 might need a SATB barrier >>>>> to keep "peeked" weak klass pointers alive during marking. >>>>> This should now be done with the Access API instead of manual calls to >>>>> the G1 SATB barrier. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8191567 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ >>>>> >>>>> Thanks, >>>>> /Erik From glaubitz at physik.fu-berlin.de Wed Nov 29 11:49:43 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 12:49:43 +0100 Subject: Zero crashing on ARM In-Reply-To: <1511951610.4026.10.camel@redhat.com> References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> <1511951610.4026.10.camel@redhat.com> Message-ID: <1bc3c5ba-acff-b07c-b067-2fa20dcabf03@physik.fu-berlin.de> Hi Severin! On 11/29/2017 11:33 AM, Severin Gehwolf wrote: > It appears that platform has a different format wrt to cgroups. What do > you get when run with os+container debug logging? > > /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/jdk/bin/java -Xlog:os+container=debug It doesn't get that far, unfortunately: (sid_armel-dchroot)glaubitz at abel:~/openjdk/hs$ /home/glaubitz/openjdk/hs/build/linux-arm-normal-zero-release/jdk/bin/java -Xlog:os+container=debug Segmentation fault (sid_armel-dchroot)glaubitz at abel:~/openjdk/hs$ > Do you see "Incompatible str containing cgroup and memory" messages? > Contents of /proc/self/mountinfo and /proc/self/cgroup would be useful > to know too. I don't have access to these (it's one of Debian's porterboxes): (sid_armel-dchroot)glaubitz at abel:~/openjdk/hs$ /proc/self/mountinfo -bash: /proc/self/mountinfo: Permission denied (sid_armel-dchroot)glaubitz at abel:~/openjdk/hs$ /proc/self/cgroup -bash: /proc/self/cgroup: Permission denied (sid_armel-dchroot)glaubitz at abel:~/openjdk/hs$ Would that cause the problem? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Wed Nov 29 12:00:11 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 13:00:11 +0100 Subject: Zero crashing on ARM In-Reply-To: <1bc3c5ba-acff-b07c-b067-2fa20dcabf03@physik.fu-berlin.de> References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> <1511951610.4026.10.camel@redhat.com> <1bc3c5ba-acff-b07c-b067-2fa20dcabf03@physik.fu-berlin.de> Message-ID: <2f164cea-2f6d-87d1-3976-0aaf8d28e315@physik.fu-berlin.de> On 11/29/2017 12:49 PM, John Paul Adrian Glaubitz wrote: > I don't have access to these (it's one of Debian's porterboxes): Here's the /proc data from the emulated sh4 porterbox: (sid-sh4-sbuild)glaubitz at nofan:/local_scratch/glaubitz/openjdk/hs$ cat /proc/self/mountinfo 216 82 0:48 / /dev/shm rw,relatime shared:138 - tmpfs none rw 225 82 8:5 / /local_scratch rw,relatime shared:33 - ext4 /dev/sda5 rw,data=ordered 232 82 0:4 / /proc rw,nosuid,nodev,noexec,relatime shared:13 - proc proc rw 233 225 0:4 / /local_scratch/sid-sh4-sbuild/proc rw,nosuid,nodev,noexec,relatime shared:13 - proc proc rw 221 82 0:18 / /sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw 222 225 0:18 / /local_scratch/sid-sh4-sbuild/sys rw,nosuid,nodev,noexec,relatime shared:7 - sysfs sysfs rw 256 82 0:6 / /dev rw,nosuid,relatime shared:2 - devtmpfs udev rw,size=8136004k,nr_inodes=2034001,mode=755 257 225 0:6 / /local_scratch/sid-sh4-sbuild/dev rw,nosuid,relatime shared:2 - devtmpfs udev rw,size=8136004k,nr_inodes=2034001,mode=755 (sid-sh4-sbuild)glaubitz at nofan:/local_scratch/glaubitz/openjdk/hs$ cat /proc/self/cgroup 10:perf_event:/ 9:cpuset:/ 8:pids:/user.slice/user-0.slice/session-c102.scope 7:net_cls,net_prio:/ 6:cpu,cpuacct:/user.slice/user-0.slice/session-c102.scope 5:blkio:/user.slice/user-0.slice/session-c102.scope 4:devices:/user.slice/user-0.slice/session-c102.scope 3:memory:/user.slice/user-0.slice/session-c102.scope 2:freezer:/ 1:name=systemd:/user.slice/user-0.slice/session-c102.scope (sid-sh4-sbuild)glaubitz at nofan:/local_scratch/glaubitz/openjdk/hs$ /local_scratch/glaubitz/openjdk/hs/build/linux-sh-normal-zero-release/jdk/bin/java qemu: uncaught target signal 11 (Segmentation fault) - core dumped Segmentation fault (sid-sh4-sbuild)glaubitz at nofan:/local_scratch/glaubitz/openjdk/hs$ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Wed Nov 29 12:19:43 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 13:19:43 +0100 Subject: Zero crashing on ARM In-Reply-To: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> Message-ID: On 11/29/2017 09:18 AM, John Paul Adrian Glaubitz wrote: > During my tests, I noticed that Zero is crashing on ARM (Debian armel): Will now also test Server and Zero on ARMv7. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From Alan.Bateman at oracle.com Wed Nov 29 12:37:50 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 29 Nov 2017 12:37:50 +0000 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com> References: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com> Message-ID: <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com> On 29/11/2017 11:26, David Holmes wrote: > > The current approach basically prevents anyone using JVMCI from > shooting themselves in the foot by setting --limit-modules in a way > that excludes the jdk.internal.vm.compiler module. In essence we want > to ensure that if using JVMCI then all the requisite pieces will be > available. But perhaps we are doing this the wrong way: how do > --limit-modules and --add-modules combine? We could add > jdk.internal.vm.compiler rather than expanding the limit-set. But the > end result would seem the same. The VM shouldn't augment the value specified to --limit-modules so I think we need to do back to the original issue and find a better solution. Is JDK-8190975 the real issue that we should be looking at? Is it just the two tests listed? In the case of BootAppendTests then it can check if the module is observable before specifying it to --limit-modules when creating the child VM. WithSecurityManager might need additional work or maybe it can drop the use of --limit-modules. As regards using --limit-modules and --add-modules together then it is possible, the details are in JEP 261. -Alan. From glaubitz at physik.fu-berlin.de Wed Nov 29 12:39:59 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 13:39:59 +0100 Subject: Zero crashing on ARM In-Reply-To: References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> Message-ID: On 11/29/2017 01:19 PM, John Paul Adrian Glaubitz wrote: > On 11/29/2017 09:18 AM, John Paul Adrian Glaubitz wrote: >> During my tests, I noticed that Zero is crashing on ARM (Debian armel): > Will now also test Server and Zero on ARMv7. Ok, it's not ARM-specific, crashes on x86_64 as well. Must be related to the chroot environment. This should definitely be fixed as otherwise distributions won't be able to build OpenJDK inside a chroot environment. (sid-amd64-sbuild)root at trlin:/usr/src/hs# gdb /usr/src/hs/build/linux-x86_64-normal-zero-release/jdk/bin/java GNU gdb (Debian 7.12-6+b1) 7.12.0.20161007-git Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/src/hs/build/linux-x86_64-normal-zero-release/jdk/bin/java...(no debugging symbols found)...done. (gdb) r Starting program: /usr/src/hs/build/linux-x86_64-normal-zero-release/jdk/bin/java [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff7fe1700 (LWP 116310)] Thread 2 "java" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7fe1700 (LWP 116310)] OSContainer::init () at /usr/src/hs/src/hotspot/os/linux/osContainer_linux.cpp:374 374 cpuset->set_subsystem_path(base); (gdb) bt #0 OSContainer::init () at /usr/src/hs/src/hotspot/os/linux/osContainer_linux.cpp:374 #1 0x00007ffff6d00dca in os::pd_init_container_support () at /usr/src/hs/src/hotspot/os/linux/os_linux.cpp:4908 #2 0x00007ffff690ddfd in os::init_container_support () at /usr/src/hs/src/hotspot/share/runtime/os.hpp:152 #3 Arguments::parse_vm_init_args (java_tool_options_args=java_tool_options_args at entry=0x7ffff7fe0a90, java_options_args=0x7ffff7fe0ac0, cmd_line_args=cmd_line_args at entry=0x7ffff7fe0ef0) at /usr/src/hs/src/hotspot/share/runtime/arguments.cpp:2379 #4 0x00007ffff690e101 in Arguments::parse (initial_cmd_args=initial_cmd_args at entry=0x7ffff7fe0ef0) at /usr/src/hs/src/hotspot/share/runtime/arguments.cpp:4049 #5 0x00007ffff6de15cd in Threads::create_vm (args=0x7ffff7fe0ef0, canTryAgain=canTryAgain at entry=0x7ffff7fe0e27) at /usr/src/hs/src/hotspot/share/runtime/thread.cpp:3974 #6 0x00007ffff6babfd1 in JNI_CreateJavaVM_inner (args=, penv=0x7ffff7fe0ee8, vm=0x7ffff7fe0ee0) at /usr/src/hs/src/hotspot/share/prims/jni.cpp:3917 #7 JNI_CreateJavaVM (vm=0x7ffff7fe0ee0, penv=0x7ffff7fe0ee8, args=) at /usr/src/hs/src/hotspot/share/prims/jni.cpp:4012 #8 0x00007ffff7795e34 in InitializeJVM (ifn=, penv=0x7ffff7fe0ee8, pvm=0x7ffff7fe0ee0) at /usr/src/hs/src/java.base/share/native/libjli/java.c:1478 #9 JavaMain (_args=) at /usr/src/hs/src/java.base/share/native/libjli/java.c:411 #10 0x00007ffff79a9517 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #11 0x00007ffff72d782f in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From per.liden at oracle.com Wed Nov 29 12:41:34 2017 From: per.liden at oracle.com (Per Liden) Date: Wed, 29 Nov 2017 13:41:34 +0100 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. In-Reply-To: References: <5A184729.4090107@oracle.com> <84bae716-9308-e372-5a13-f0c4d348b6a1@oracle.com> <23b84b9e-fab6-f2f3-8cc7-bc8d67a17c7f@oracle.com> <67b482bd-cd01-0097-50b4-4b6090583926@oracle.com> Message-ID: Hi David, On 2017-11-29 12:33, David Holmes wrote: > Hi Per, > > Sorry one follow up ... > > On 29/11/2017 9:17 PM, Per Liden wrote: >> Hi David, >> >> On 11/28/2017 10:22 PM, David Holmes wrote: >>> Hi Per, >>> >>> On 28/11/2017 5:53 PM, Per Liden wrote: >>>> Hi David, >>>> >>>> On 2017-11-28 07:50, David Holmes wrote: >>>>> Hi Erik, >>>>> >>>>> Does "phantom" here have any relationship to PhantomReference? >>>> >>>> Yes, in the sense that this root oop has the same strength as the >>>> referent field in a PhantomReference. All non-strong root oops in the >>>> VM (StringTable, JNIWeakHandles, etc) are "phantom oops". Internally >>>> in the VM they are unfortunately sometimes referred to as "weak >>>> roots". With the access API, we're trying to move away from using >>>> "weak" for these since "weak" is the strength of the referent in a >>>> Soft/Weak/FinalReference. >>> >>> Ah I see. I hadn't realized we were mis-using "weak" that way. >>> >>>>> >>>>> Meta-question on access API: if >>>>> >>>>> RootAccess::oop_load(addr); >>>>> >>>>> keeps the value alive, what can cause the value to be allowed to go >>>>> dead >>>>> again? >>>> >>>> After a GC, if all existing pointers to this object are phantom oops, >>>> then the object is phantom-reachable and those phantom oops will be >>>> declared dead and cleared (i.e. same criteria as when a >>>> j.l.r.PhantomReference is enqueued). >>> >>> Sorry this is going OT wrt the actual code review but I'm a bit >>> confused. If the above RootAccess marks the oop as PhantomReachable then >>> GC can remove it and it wasn't kept alive after all ?? If the above >>> makes it stronger than PhantomReachable then GC won't be able to remove >>> it, but then how does it return to only being PhantomReachable? >> >> Unless the access has the AS_NO_KEEPALIVE decorator, a call to >> RootAccess<>::oop_load() will always make the object strongly >> reachable or return NULL. > > OKay, but for how long will it remain strongly reachable? Just till the > end of the current GC cycle, or the start of the next, or ... ? The object will be considered strongly reachable until the start of the next GC cycle. During the next GC cycle the reachability of the object will be reevaluated again. Does that clarify things? /Per > > Thanks, > David > >> The ON_WEAK_OOP_REF/ON_PHANTOM_OOP_REF tells that access barrier that >> this oop is subject to resurrection restrictions. This means that >> special care needs to be taken when loading this oop, because the >> object it points to might already have been declared weak- or >> phantom-reachable, but this oop has not yet been cleared (set to >> NULL). In this case, the access barrier will step in, detect the >> situation and return NULL anyway, essentially making it look like the >> oop has been cleared. At some point later, when the GC is doing >> weak/phantom reference processing, the logically dead oops will >> actually be cleared (set to NULL). >> >> /Per >> >>> >>> Thanks, >>> David >>> >>>> cheers, >>>> Per >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 25/11/2017 2:22 AM, Erik ?sterlund wrote: >>>>>> Hi, >>>>>> >>>>>> When creating a ciInstanceKlass handle, G1 might need a SATB barrier >>>>>> to keep "peeked" weak klass pointers alive during marking. >>>>>> This should now be done with the Access API instead of manual >>>>>> calls to >>>>>> the G1 SATB barrier. >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8191567 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> /Erik From glaubitz at physik.fu-berlin.de Wed Nov 29 13:01:38 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 14:01:38 +0100 Subject: Zero crashing on ARM In-Reply-To: References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> Message-ID: <985632c8-d1df-33c9-7228-ee0fa93491a5@physik.fu-berlin.de> On 11/29/2017 01:39 PM, John Paul Adrian Glaubitz wrote: > On 11/29/2017 01:19 PM, John Paul Adrian Glaubitz wrote: >> On 11/29/2017 09:18 AM, John Paul Adrian Glaubitz wrote: >>> During my tests, I noticed that Zero is crashing on ARM (Debian armel): >> Will now also test Server and Zero on ARMv7. > > Ok, it's not ARM-specific, crashes on x86_64 as well. Must be related > to the chroot environment. This should definitely be fixed as otherwise > distributions won't be able to build OpenJDK inside a chroot environment. It also affects the Server variant on x86_64, I have filed 8192154 [1]. Adrian > [1] https://bugs.openjdk.java.net/browse/JDK-8192154 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From coleen.phillimore at oracle.com Wed Nov 29 13:15:31 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 29 Nov 2017 08:15:31 -0500 Subject: RFR: 8192061: Clean up allocation.inline.hpp includes In-Reply-To: <1348b2d2-e1b5-73ee-7312-b4ca6f5fe4e1@oracle.com> References: <1348b2d2-e1b5-73ee-7312-b4ca6f5fe4e1@oracle.com> Message-ID: <68e0ac11-0081-e645-32ed-84d524fa3db7@oracle.com> Hi Stefan,? I looked at the whole review and it's not hard to review.? I love these sort of changes. Have you tested this on all platforms that we support?? I was wondering if SAP should do the same.? It seems like sort of a big change to get in by Friday but not impossible. Thanks, Coleen On 11/29/17 6:21 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patchset to clean up our includes of > allocation.inline.hpp and move usages of its functions out from header > files into .cpp and .inline.hpp files. > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.all > > I've split this patch into multiple separate patches and tried to > group them according to HotSpot area, to make it easier to review. I > can also create separate bugs for this, if that's preferable. > > GC: > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.00.GC.g1ConcurrentRefine/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.01.GC.spaceCounters/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.02.GC.g1ParScanThreadState.hpp/ > > > RT: > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.03.GC.adaptivePaddedAverage/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.04.RT.diagnosticArgument/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.05.RT.methodHandles/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.06.RT.constantPool/ > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.07.RT.sharedPathsMiscInfo/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.08.RT.generateOopMap/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.09.RT.objectMonitor/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.10.RT.arguments/ > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.11.RT.osThread/ > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.12.resourceArea/ > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.13.RT.array/ > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.14.RT.test_logMessage/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.15.RT.park/ > > SHARED: > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.16.SHARED.growableArray/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.17.SHARED.removeIncludes/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.18.SHARED.precompiled/ > > > Thanks, > StefanK From glaubitz at physik.fu-berlin.de Wed Nov 29 13:30:24 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 14:30:24 +0100 Subject: JVM crashing insides chroots - was: Re: Zero crashing on ARM In-Reply-To: <985632c8-d1df-33c9-7228-ee0fa93491a5@physik.fu-berlin.de> References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> <985632c8-d1df-33c9-7228-ee0fa93491a5@physik.fu-berlin.de> Message-ID: On 11/29/2017 02:01 PM, John Paul Adrian Glaubitz wrote: > It also affects the Server variant on x86_64, I have filed 8192154 [1]. > Severin had the right idea. Passing "-XX:-UseContainerSupport" resolves the issue. However, I think that shouldn't be necessary in case of chroots, should it? In any case, it will potentially cause issues with chroots as they are used on Linux distributions for building packages. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From erik.osterlund at oracle.com Wed Nov 29 13:35:30 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 29 Nov 2017 14:35:30 +0100 Subject: RFR: 8192061: Clean up allocation.inline.hpp includes In-Reply-To: <1348b2d2-e1b5-73ee-7312-b4ca6f5fe4e1@oracle.com> References: <1348b2d2-e1b5-73ee-7312-b4ca6f5fe4e1@oracle.com> Message-ID: Hi Stefan, Nice. Noticed though that in sharedPathsMiscInfo.hpp, it seems like you accidentally (I assume) added an include of allocation.inline.hpp. http://cr.openjdk.java.net/~stefank/8192061/webrev.01.16.SHARED.growableArray/src/hotspot/share/classfile/sharedPathsMiscInfo.hpp.sdiff.html Thanks, /Erik On 2017-11-29 12:21, Stefan Karlsson wrote: > Hi all, > > Please review this patchset to clean up our includes of > allocation.inline.hpp and move usages of its functions out from header > files into .cpp and .inline.hpp files. > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.all > > I've split this patch into multiple separate patches and tried to > group them according to HotSpot area, to make it easier to review. I > can also create separate bugs for this, if that's preferable. > > GC: > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.00.GC.g1ConcurrentRefine/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.01.GC.spaceCounters/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.02.GC.g1ParScanThreadState.hpp/ > > > RT: > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.03.GC.adaptivePaddedAverage/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.04.RT.diagnosticArgument/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.05.RT.methodHandles/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.06.RT.constantPool/ > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.07.RT.sharedPathsMiscInfo/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.08.RT.generateOopMap/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.09.RT.objectMonitor/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.10.RT.arguments/ > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.11.RT.osThread/ > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.12.resourceArea/ > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.13.RT.array/ > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.14.RT.test_logMessage/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.15.RT.park/ > > SHARED: > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.16.SHARED.growableArray/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.17.SHARED.removeIncludes/ > > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.18.SHARED.precompiled/ > > > Thanks, > StefanK From sgehwolf at redhat.com Wed Nov 29 13:49:37 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 29 Nov 2017 14:49:37 +0100 Subject: JVM crashing insides chroots - was: Re: Zero crashing on ARM In-Reply-To: References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> <985632c8-d1df-33c9-7228-ee0fa93491a5@physik.fu-berlin.de> Message-ID: <1511963377.4026.45.camel@redhat.com> On Wed, 2017-11-29 at 14:30 +0100, John Paul Adrian Glaubitz wrote: > On 11/29/2017 02:01 PM, John Paul Adrian Glaubitz wrote: > > It also affects the Server variant on x86_64, I have filed 8192154 [1]. > > > > Severin had the right idea. Passing "-XX:-UseContainerSupport" resolves > the issue. However, I think that shouldn't be necessary in case of chroots, > should it? > > In any case, it will potentially cause issues with chroots as they are used > on Linux distributions for building packages. Agreed. It needs to be fixed. The default is +UseContainerSupport after all. Thanks, Severin From glaubitz at physik.fu-berlin.de Wed Nov 29 13:56:54 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 14:56:54 +0100 Subject: JVM crashing insides chroots - was: Re: Zero crashing on ARM In-Reply-To: <1511963377.4026.45.camel@redhat.com> References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> <985632c8-d1df-33c9-7228-ee0fa93491a5@physik.fu-berlin.de> <1511963377.4026.45.camel@redhat.com> Message-ID: <802ced95-953d-08d3-a28f-b79588754e3b@physik.fu-berlin.de> On 11/29/2017 02:49 PM, Severin Gehwolf wrote: >> In any case, it will potentially cause issues with chroots as they are used >> on Linux distributions for building packages. > > Agreed. It needs to be fixed. The default is +UseContainerSupport after > all. It seems to have huge performance impact, too: (sid-amd64-sbuild)root at trlin:/usr/src/hs# time /usr/bin/java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK 64-Bit Server VM (build 9.0.1+11-Debian-1, mixed mode) real 0m0.101s user 0m0.128s sys 0m0.019s (sid-amd64-sbuild)root at trlin:/usr/src/hs# time /usr/src/hs/build/linux-x86_64-normal-zero-release/jdk/bin/java -XX:-UseContainerSupport -version openjdk version "10-internal" OpenJDK Runtime Environment (build 10-internal+0-adhoc.root.hs) OpenJDK 64-Bit Zero VM (build 10-internal+0-adhoc.root.hs, interpreted mode) real 0m26.010s user 0m25.551s sys 0m0.380s (sid-amd64-sbuild)root at trlin:/usr/src/hs# -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From stefan.karlsson at oracle.com Wed Nov 29 14:01:06 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 29 Nov 2017 15:01:06 +0100 Subject: RFR: 8192061: Clean up allocation.inline.hpp includes In-Reply-To: References: <1348b2d2-e1b5-73ee-7312-b4ca6f5fe4e1@oracle.com> Message-ID: Hi Erik, On 2017-11-29 14:35, Erik ?sterlund wrote: > Hi Stefan, > > Nice. Noticed though that in sharedPathsMiscInfo.hpp, it seems like you > accidentally (I assume) added an include of allocation.inline.hpp. > http://cr.openjdk.java.net/~stefank/8192061/webrev.01.16.SHARED.growableArray/src/hotspot/share/classfile/sharedPathsMiscInfo.hpp.sdiff.html Yes, you are right. I used to have the patches in a different order and accidentally left/introduced this include. I'll rerun my build tests with this removed. Thanks, StefanK > > > Thanks, > /Erik > > On 2017-11-29 12:21, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patchset to clean up our includes of >> allocation.inline.hpp and move usages of its functions out from header >> files into .cpp and .inline.hpp files. >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.all >> >> I've split this patch into multiple separate patches and tried to >> group them according to HotSpot area, to make it easier to review. I >> can also create separate bugs for this, if that's preferable. >> >> GC: >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.00.GC.g1ConcurrentRefine/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.01.GC.spaceCounters/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.02.GC.g1ParScanThreadState.hpp/ >> >> >> RT: >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.03.GC.adaptivePaddedAverage/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.04.RT.diagnosticArgument/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.05.RT.methodHandles/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.06.RT.constantPool/ >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.07.RT.sharedPathsMiscInfo/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.08.RT.generateOopMap/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.09.RT.objectMonitor/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.10.RT.arguments/ >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.11.RT.osThread/ >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.12.resourceArea/ >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.13.RT.array/ >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.14.RT.test_logMessage/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.15.RT.park/ >> >> SHARED: >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.16.SHARED.growableArray/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.17.SHARED.removeIncludes/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.18.SHARED.precompiled/ >> >> >> Thanks, >> StefanK > From stefan.karlsson at oracle.com Wed Nov 29 14:03:03 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 29 Nov 2017 15:03:03 +0100 Subject: RFR: 8192061: Clean up allocation.inline.hpp includes In-Reply-To: <68e0ac11-0081-e645-32ed-84d524fa3db7@oracle.com> References: <1348b2d2-e1b5-73ee-7312-b4ca6f5fe4e1@oracle.com> <68e0ac11-0081-e645-32ed-84d524fa3db7@oracle.com> Message-ID: Hi Coleen, On 2017-11-29 14:15, coleen.phillimore at oracle.com wrote: > > Hi Stefan,? I looked at the whole review and it's not hard to review.? I > love these sort of changes. Thanks! > > Have you tested this on all platforms that we support? Yes, and I've also built open-only bits. ? I was wondering > if SAP should do the same.? It seems like sort of a big change to get in > by Friday but not impossible. I think this should go in as soon as possible. Thanks, StefanK > > Thanks, > Coleen > > On 11/29/17 6:21 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patchset to clean up our includes of >> allocation.inline.hpp and move usages of its functions out from header >> files into .cpp and .inline.hpp files. >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.all >> >> I've split this patch into multiple separate patches and tried to >> group them according to HotSpot area, to make it easier to review. I >> can also create separate bugs for this, if that's preferable. >> >> GC: >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.00.GC.g1ConcurrentRefine/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.01.GC.spaceCounters/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.02.GC.g1ParScanThreadState.hpp/ >> >> >> RT: >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.03.GC.adaptivePaddedAverage/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.04.RT.diagnosticArgument/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.05.RT.methodHandles/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.06.RT.constantPool/ >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.07.RT.sharedPathsMiscInfo/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.08.RT.generateOopMap/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.09.RT.objectMonitor/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.10.RT.arguments/ >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.11.RT.osThread/ >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.12.resourceArea/ >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.13.RT.array/ >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.14.RT.test_logMessage/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.15.RT.park/ >> >> SHARED: >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.16.SHARED.growableArray/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.17.SHARED.removeIncludes/ >> >> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.18.SHARED.precompiled/ >> >> >> Thanks, >> StefanK > From bob.vandette at oracle.com Wed Nov 29 14:06:34 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 29 Nov 2017 09:06:34 -0500 Subject: Zero crashing on ARM In-Reply-To: <985632c8-d1df-33c9-7228-ee0fa93491a5@physik.fu-berlin.de> References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> <985632c8-d1df-33c9-7228-ee0fa93491a5@physik.fu-berlin.de> Message-ID: <318B222F-7224-4952-9FD3-56BE1FB6D5AA@oracle.com> I?ll take that bug. It looks related to the new cgroup support that I just added under https://bugs.openjdk.java.net/browse/JDK-8146115 . Bob. > On Nov 29, 2017, at 8:01 AM, John Paul Adrian Glaubitz wrote: > > On 11/29/2017 01:39 PM, John Paul Adrian Glaubitz wrote: >> On 11/29/2017 01:19 PM, John Paul Adrian Glaubitz wrote: >>> On 11/29/2017 09:18 AM, John Paul Adrian Glaubitz wrote: >>>> During my tests, I noticed that Zero is crashing on ARM (Debian armel): >>> Will now also test Server and Zero on ARMv7. >> Ok, it's not ARM-specific, crashes on x86_64 as well. Must be related >> to the chroot environment. This should definitely be fixed as otherwise >> distributions won't be able to build OpenJDK inside a chroot environment. > It also affects the Server variant on x86_64, I have filed 8192154 [1]. > > Adrian > >> [1] https://bugs.openjdk.java.net/browse/JDK-8192154 > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From sgehwolf at redhat.com Wed Nov 29 14:08:00 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 29 Nov 2017 15:08:00 +0100 Subject: JVM crashing insides chroots - was: Re: Zero crashing on ARM In-Reply-To: <802ced95-953d-08d3-a28f-b79588754e3b@physik.fu-berlin.de> References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> <985632c8-d1df-33c9-7228-ee0fa93491a5@physik.fu-berlin.de> <1511963377.4026.45.camel@redhat.com> <802ced95-953d-08d3-a28f-b79588754e3b@physik.fu-berlin.de> Message-ID: <1511964480.4026.47.camel@redhat.com> On Wed, 2017-11-29 at 14:56 +0100, John Paul Adrian Glaubitz wrote: > On 11/29/2017 02:49 PM, Severin Gehwolf wrote: > > > In any case, it will potentially cause issues with chroots as they are used > > > on Linux distributions for building packages. > > > > Agreed. It needs to be fixed. The default is +UseContainerSupport after > > all. > > It seems to have huge performance impact, too: > > (sid-amd64-sbuild)root at trlin:/usr/src/hs# time /usr/bin/java -version > openjdk version "9.0.1" > OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) > OpenJDK 64-Bit Server VM (build 9.0.1+11-Debian-1, mixed mode) > > real 0m0.101s > user 0m0.128s > sys 0m0.019s > (sid-amd64-sbuild)root at trlin:/usr/src/hs# time /usr/src/hs/build/linux-x86_64-normal-zero-release/jdk/bin/java -XX:-UseContainerSupport -version > openjdk version "10-internal" > OpenJDK Runtime Environment (build 10-internal+0-adhoc.root.hs) > OpenJDK 64-Bit Zero VM (build 10-internal+0-adhoc.root.hs, interpreted mode) > > real 0m26.010s > user 0m25.551s > sys 0m0.380s > (sid-amd64-sbuild)root at trlin:/usr/src/hs# You are comparing a JIT server JVM with Zero. That's expected ;-) Thanks, Severin From glaubitz at physik.fu-berlin.de Wed Nov 29 14:08:15 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 15:08:15 +0100 Subject: RFR: 8192123: Zero should use compiler built-ins for atomics on linux-arm Message-ID: <8b1622f1-e4b9-4b2d-304f-ecedb8445728@physik.fu-berlin.de> Hi! Like it has already been done for linux-m68k in JDK-8187227, Zero should also be patched on linux-arm to use compiler built-ins for the atomic functions in hotspot/os_cpu/linux_zero/assembler_linux_zero.cpp. Since the compiler built-ins for cmpxchg() work exactly like the current ARM-specific implementation in Zero, there is no need anymore to carry our own implementation but rather rely on gcc which helps simplifying the code. I have successfully tested this change in the following targets: - Linux ARMv4T - Linux ARMv7 My change also removes a single empty line to make the formatting more consistent. Hope this is ok. The webrev can be found in [1]. Thanks, Adrian > [1] http://cr.openjdk.java.net/~glaubitz/8192123/webrev.00/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Wed Nov 29 14:12:29 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 15:12:29 +0100 Subject: JVM crashing insides chroots - was: Re: Zero crashing on ARM In-Reply-To: <1511964480.4026.47.camel@redhat.com> References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> <985632c8-d1df-33c9-7228-ee0fa93491a5@physik.fu-berlin.de> <1511963377.4026.45.camel@redhat.com> <802ced95-953d-08d3-a28f-b79588754e3b@physik.fu-berlin.de> <1511964480.4026.47.camel@redhat.com> Message-ID: On 11/29/2017 03:08 PM, Severin Gehwolf wrote: > You are comparing a JIT server JVM with Zero. That's expected ;-) Well, sorry, that was by accident, I didn't mean to run Server. However, there is definitely a performance regression in Zero and I expect it's due to the container stuff: (sid-sh4-sbuild)glaubitz at nofan:/local_scratch/glaubitz/openjdk/hs$ time /usr/bin/java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK Zero VM (build 9.0.1+11-Debian-1, interpreted mode) real 0m0.572s user 0m0.572s sys 0m0.004s (sid-sh4-sbuild)glaubitz at nofan:/local_scratch/glaubitz/openjdk/hs$ time /local_scratch/glaubitz/openjdk/hs/build/linux-sh-normal-zero-release/jdk/bin/java -XX:-UseContain> qemu: Unsupported syscall: 318 Unsupported setsockopt level=1 optname=15 openjdk version "10-internal" OpenJDK Runtime Environment (build 10-internal+0-adhoc.glaubitz.hs) OpenJDK Zero VM (build 10-internal+0-adhoc.glaubitz.hs, interpreted mode) real 1m49.166s user 1m49.019s sys 0m0.152s (sid-sh4-sbuild)glaubitz at nofan:/local_scratch/glaubitz/openjdk/hs$ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Wed Nov 29 14:16:50 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 15:16:50 +0100 Subject: JVM crashing insides chroots - was: Re: Zero crashing on ARM In-Reply-To: References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> <985632c8-d1df-33c9-7228-ee0fa93491a5@physik.fu-berlin.de> <1511963377.4026.45.camel@redhat.com> <802ced95-953d-08d3-a28f-b79588754e3b@physik.fu-berlin.de> <1511964480.4026.47.camel@redhat.com> Message-ID: <47fd2abd-87e9-ac42-8aad-1079d67dec5c@physik.fu-berlin.de> On 11/29/2017 03:12 PM, John Paul Adrian Glaubitz wrote: > On 11/29/2017 03:08 PM, Severin Gehwolf wrote: >> You are comparing a JIT server JVM with Zero. That's expected ;-) > > Well, sorry, that was by accident, I didn't mean to run Server. For completeness' sake, here's the Server variant: (sid-amd64-sbuild)root at trlin:/usr/src/hs# time /usr/bin/java -version openjdk version "9.0.1" OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) OpenJDK 64-Bit Server VM (build 9.0.1+11-Debian-1, mixed mode) real 0m0.101s user 0m0.112s sys 0m0.032s (sid-amd64-sbuild)root at trlin:/usr/src/hs# time /usr/src/hs/build/linux-x86_64-normal-server-release/jdk/bin/java -XX:-UseContainerSupport -version openjdk version "10-internal" OpenJDK Runtime Environment (build 10-internal+0-adhoc.root.hs) OpenJDK 64-Bit Server VM (build 10-internal+0-adhoc.root.hs, mixed mode) real 0m1.080s user 0m3.622s sys 0m0.591s (sid-amd64-sbuild)root at trlin:/usr/src/hs# -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From dmitry.samersoff at bell-sw.com Wed Nov 29 14:30:13 2017 From: dmitry.samersoff at bell-sw.com (Dmitry Samersov) Date: Wed, 29 Nov 2017 17:30:13 +0300 Subject: RFR(preliminary): JDK-8190428 Minimal Constant Dynamic support for AArch64 In-Reply-To: References: Message-ID: <14f01d52-49e6-08d9-f5fa-c37499a104c1@bell-sw.com> Everybody, Please review a port of Minimal Constant Dynamic patch to AArch64 platform. http://cr.openjdk.java.net/~dsamersoff/JDK-8190428.condy/webrev.03/ Any comments are much appreciated. -Dmitry From dmitry.samersoff at bell-sw.com Wed Nov 29 14:32:09 2017 From: dmitry.samersoff at bell-sw.com (Dmitry Samersov) Date: Wed, 29 Nov 2017 17:32:09 +0300 Subject: RFR: 8189596: AArch64: implementation for Thread-local handshakes In-Reply-To: <47862e40-9f57-a0d6-a20c-6fd5ac5c1177@redhat.com> References: <1106e61c-cb89-429a-cf09-22c61ceb6418@redhat.com> <35d56da3-3167-2567-e129-bb3cb2e97886@redhat.com> <5A17F64B.3000101@oracle.com> <47862e40-9f57-a0d6-a20c-6fd5ac5c1177@redhat.com> Message-ID: Andrew, Thank you for the explanation. -Dmitry On 27.11.2017 18:47, Andrew Haley wrote: > On 27/11/17 15:30, Dmitry Samersov wrote: >> Andrew, >> >>> http://cr.openjdk.java.net/~aph/8189596-2 >> >> 1. interp_masm_aarch64.cpp >> >> 456 if (needs_thread_local_poll) { >> >> It might be better to put the code related to needs_thread_local_poll >> into the single block for better readability. >> >> Approx : >> >> if (needs_thread_local_poll) { >> NOT_PRODUCT(block_comment("Thread-local Safepoint poll")); >> ldr(rscratch2, Address(rthread, Thread::polling_page_offset())); >> tbz(rscratch2, exact_log2(SafepointMechanism::poll_bit()), notsafepoint); >> >> lea(rscratch2, ExternalAddress((address)safepoint_table)); >> ldr(rscratch2, Address(rscratch2, rscratch1, Address::uxtw(3))); >> br(rscratch2); >> >> } >> >> bind(notsafepoint); > > I didn't want to do that because I wanted to put the uncommon case out > of line. In any case, I don't think it warrants a respin. > >> 2. macroAssembler_aarch64.cpp >> >> 321 safepoint_poll(slow_path); >> >> It might be better to put global poll code to a separate function, to >> avoid double checking of SafepointMechanism::uses_thread_local_poll(); > > We don't need to do it for efficiency because GCC already knows how to > do that. I can't think of any other reason we'd want to change it. > >> 3. templateInterpreterGenerator_aarch64.cpp : 1382 >> >> 1382 __ safepoint_poll_acquire(L); >> >> Do we really need acquire here? > > I believe so,, for the reason discussed upthread. We need to do it > whenever transitioning from native to Java state. > From coleen.phillimore at oracle.com Wed Nov 29 14:51:18 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 29 Nov 2017 09:51:18 -0500 Subject: RFR: 8192061: Clean up allocation.inline.hpp includes In-Reply-To: References: <1348b2d2-e1b5-73ee-7312-b4ca6f5fe4e1@oracle.com> <68e0ac11-0081-e645-32ed-84d524fa3db7@oracle.com> Message-ID: On 11/29/17 9:03 AM, Stefan Karlsson wrote: > Hi Coleen, > > On 2017-11-29 14:15, coleen.phillimore at oracle.com wrote: >> >> Hi Stefan,? I looked at the whole review and it's not hard to >> review.? I love these sort of changes. > > Thanks! > >> >> Have you tested this on all platforms that we support? > > Yes, and I've also built open-only bits. > > ? I was wondering >> if SAP should do the same.? It seems like sort of a big change to get >> in by Friday but not impossible. > > I think this should go in as soon as possible. Okay with me.? Thanks for all the testing. Coleen > > Thanks, > StefanK > >> >> Thanks, >> Coleen >> >> On 11/29/17 6:21 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patchset to clean up our includes of >>> allocation.inline.hpp and move usages of its functions out from >>> header files into .cpp and .inline.hpp files. >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.all >>> >>> I've split this patch into multiple separate patches and tried to >>> group them according to HotSpot area, to make it easier to review. I >>> can also create separate bugs for this, if that's preferable. >>> >>> GC: >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.00.GC.g1ConcurrentRefine/ >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.01.GC.spaceCounters/ >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.02.GC.g1ParScanThreadState.hpp/ >>> >>> >>> RT: >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.03.GC.adaptivePaddedAverage/ >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.04.RT.diagnosticArgument/ >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.05.RT.methodHandles/ >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.06.RT.constantPool/ >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.07.RT.sharedPathsMiscInfo/ >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.08.RT.generateOopMap/ >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.09.RT.objectMonitor/ >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.10.RT.arguments/ >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.11.RT.osThread/ >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.12.resourceArea/ >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.13.RT.array/ >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.14.RT.test_logMessage/ >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.15.RT.park/ >>> >>> SHARED: >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.16.SHARED.growableArray/ >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.17.SHARED.removeIncludes/ >>> >>> http://cr.openjdk.java.net/~stefank/8192061/webrev.01.18.SHARED.precompiled/ >>> >>> >>> Thanks, >>> StefanK >> From sean.mullan at oracle.com Wed Nov 29 15:03:58 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 29 Nov 2017 10:03:58 -0500 Subject: RFR: 8186535: Remove deprecated pre-1.2 SecurityManager methods and fields In-Reply-To: <97def149-d3dc-bbe9-939c-5f2d7ffd8eba@oracle.com> References: <97def149-d3dc-bbe9-939c-5f2d7ffd8eba@oracle.com> Message-ID: <0964267f-757c-86d5-f927-298a8f842aa4@oracle.com> On 11/28/17 2:41 PM, mandy chung wrote: > > > On 11/22/17 6:37 AM, Sean Mullan wrote: >> Please review this change to remove the pre-JDK 1.2 SecurityManager >> methods that have been deprecated since JDK 1.2 and marked for removal >> in JDK 9. These methods are fragile, error-prone and have been >> obsolete since the SecurityManager was revamped in JDK 1.2. The >> methods to be removed are: getInCheck, classDepth, classLoaderDepth, >> currentClassLoader, currentLoadedClass, inClass, and inClassLoader. >> >> In addition, the deprecated and error-prone checkMemberAccess method >> (which was deprecated in JDK 8 and marked for removal in JDK 9) has >> been changed to throw SecurityException if the caller has not been >> granted AllPermission. This makes the method less likely it will be >> used incorrectly while still allowing some more time before it is >> removed. >> >> http://cr.openjdk.java.net/~mullan/webrevs/8186535/webrev.00/ >> > > src/java.desktop/share/classes/sun/applet/AppletSecurity.java > ?111???? private static final StackWalker walker = > ?112???????? StackWalker.getInstance(RETAIN_CLASS_REFERENCE); > > This call will do a stack-based permission check.? So it needs to be > wrapped with doPrivileged. Yes, Alan had the same comment. I have wrapped it in doPrivileged. > Otherwise, looks fine. > > Just to mention this:? AppletSecurity does not really need the > currentClassLoader method. AppletSecurity::currentAppletClassLoader > could be reimplemented to use StackWalker to walk the stack once > (replacing the call to currentClassLoader and getClassContext) to find > AppletClassLoader. OTOH it does not worth making more change since > applets are going away. Ok. Good point though. --Sean From aph at redhat.com Wed Nov 29 15:04:54 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Nov 2017 15:04:54 +0000 Subject: RFR: 8192123: Zero should use compiler built-ins for atomics on linux-arm In-Reply-To: <8b1622f1-e4b9-4b2d-304f-ecedb8445728@physik.fu-berlin.de> References: <8b1622f1-e4b9-4b2d-304f-ecedb8445728@physik.fu-berlin.de> Message-ID: <707713f8-2d2b-f85e-ba8e-d32ee4a16615@redhat.com> On 29/11/17 14:08, John Paul Adrian Glaubitz wrote: > Since the compiler built-ins for cmpxchg() work exactly like the current ARM-specific > implementation in Zero, there is no need anymore to carry our own implementation but > rather rely on gcc which helps simplifying the code. > > I have successfully tested this change in the following targets: > > - Linux ARMv4T > - Linux ARMv7 > > My change also removes a single empty line to make the formatting more > consistent. Hope this is ok. Hmm. This doesn't fix a bug, and there's a non-zero probability of introducing one. I guess it should be OK, but this is a combination of performance improvement (possibly) and cleanup. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Nov 29 15:25:42 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Nov 2017 15:25:42 +0000 Subject: RFR(preliminary): JDK-8190428 Minimal Constant Dynamic support for AArch64 In-Reply-To: <14f01d52-49e6-08d9-f5fa-c37499a104c1@bell-sw.com> References: <14f01d52-49e6-08d9-f5fa-c37499a104c1@bell-sw.com> Message-ID: <4b1a8079-a579-6c64-cb59-e30ff4f86d65@redhat.com> On 29/11/17 14:30, Dmitry Samersov wrote: > Everybody, > > Please review a port of Minimal Constant Dynamic patch to AArch64 platform. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8190428.condy/webrev.03/ > > Any comments are much appreciated. These lines should not be in macroAssembler: 1778 void MacroAssembler::load_float(Address src) { 1779 ldrs(v0, src); 1780 } 1781 1782 void MacroAssembler::load_double(Address src) { 1783 ldrd(v0, src); 1784 } 1785 598 // Load float value from 'address'. The value is loaded onto the FPU stack. 599 void load_float(Address src); 600 void load_double(Address src); 601 I realize that we're not at all consistent about this stuff, but we don't need it in macroAssembler. It can go in interp_masm. This is a bit odd: 464 { // Check for the null sentinel. 465 // If we just called the VM, that already did the mapping for us, 466 // but it's harmless to retry. 467 Label notNull; 468 469 // Store null_sentinel address to get its value later 470 __ movptr(rarg, (uintptr_t)Universe::the_null_sentinel_addr()); 471 __ ldr(tmp, rarg); I think this one should be ldr(tmp, Address(rarg)); 472 __ cmp(result, tmp); 473 __ br(Assembler::NE, notNull); 474 __ mov(result, 0); // NULL object reference 475 __ bind(notNull); 476 The rest of it looks fine. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From coleen.phillimore at oracle.com Wed Nov 29 15:39:56 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 29 Nov 2017 10:39:56 -0500 Subject: RFR: 8192123: Zero should use compiler built-ins for atomics on linux-arm In-Reply-To: <707713f8-2d2b-f85e-ba8e-d32ee4a16615@redhat.com> References: <8b1622f1-e4b9-4b2d-304f-ecedb8445728@physik.fu-berlin.de> <707713f8-2d2b-f85e-ba8e-d32ee4a16615@redhat.com> Message-ID: <6991e542-cf59-0930-dd34-fec9ae61727d@oracle.com> On 11/29/17 10:04 AM, Andrew Haley wrote: > On 29/11/17 14:08, John Paul Adrian Glaubitz wrote: >> Since the compiler built-ins for cmpxchg() work exactly like the current ARM-specific >> implementation in Zero, there is no need anymore to carry our own implementation but >> rather rely on gcc which helps simplifying the code. >> >> I have successfully tested this change in the following targets: >> >> - Linux ARMv4T >> - Linux ARMv7 >> >> My change also removes a single empty line to make the formatting more >> consistent. Hope this is ok. > Hmm. This doesn't fix a bug, and there's a non-zero probability of > introducing one. I guess it should be OK, but this is a combination > of performance improvement (possibly) and cleanup. > Please save this change for JDK 11. Thanks, Coleen From glaubitz at physik.fu-berlin.de Wed Nov 29 15:45:30 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 16:45:30 +0100 Subject: RFR: 8192123: Zero should use compiler built-ins for atomics on linux-arm In-Reply-To: <6991e542-cf59-0930-dd34-fec9ae61727d@oracle.com> References: <8b1622f1-e4b9-4b2d-304f-ecedb8445728@physik.fu-berlin.de> <707713f8-2d2b-f85e-ba8e-d32ee4a16615@redhat.com> <6991e542-cf59-0930-dd34-fec9ae61727d@oracle.com> Message-ID: On 11/29/2017 04:39 PM, coleen.phillimore at oracle.com wrote: >> Hmm.? This doesn't fix a bug, and there's a non-zero probability of >> introducing one.? I guess it should be OK, but this is a combination >> of performance improvement (possibly) and cleanup. >> > Please save this change for JDK 11. I just made the same obvious change as I did for m68k. Is there really a risk of introducing a regression? It only affects Zero after all which is not officially supported, is it? The supported ARMv7 Server build is not affected as this change is below the linux_zero directory. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From mandy.chung at oracle.com Wed Nov 29 16:15:18 2017 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 29 Nov 2017 08:15:18 -0800 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com> References: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com> <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com> Message-ID: <5b1d87ec-5386-59fe-3547-3d741297db69@oracle.com> On 11/29/17 4:37 AM, Alan Bateman wrote: > On 29/11/2017 11:26, David Holmes wrote: >> >> The current approach basically prevents anyone using JVMCI from >> shooting themselves in the foot by setting --limit-modules in a way >> that excludes the jdk.internal.vm.compiler module. In essence we want >> to ensure that if using JVMCI then all the requisite pieces will be >> available. But perhaps we are doing this the wrong way: how do >> --limit-modules and --add-modules combine? We could add >> jdk.internal.vm.compiler rather than expanding the limit-set. But the >> end result would seem the same. > The VM shouldn't augment the value specified to --limit-modules so I > think we need to do back to the original issue and find a better > solution. Is JDK-8190975 the real issue that we should be looking at? > Is it just the two tests listed? In the case of BootAppendTests then > it can check if the module is observable before specifying it to > --limit-modules when creating the child VM. WithSecurityManager might > need additional work or maybe it can drop the use of --limit-modules. > I agree that augmenting --limit-modules doesn't seem the right solution here. Would @modules jdk.internal.vm.compiler be a temporary workaround so that this test will not run on SPARC where the module is not present? Mandy From aph at redhat.com Wed Nov 29 16:16:54 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Nov 2017 16:16:54 +0000 Subject: RFR: 8192123: Zero should use compiler built-ins for atomics on linux-arm In-Reply-To: References: <8b1622f1-e4b9-4b2d-304f-ecedb8445728@physik.fu-berlin.de> <707713f8-2d2b-f85e-ba8e-d32ee4a16615@redhat.com> <6991e542-cf59-0930-dd34-fec9ae61727d@oracle.com> Message-ID: <84581646-0d6e-f709-1618-cdf3c5848546@redhat.com> On 29/11/17 15:45, John Paul Adrian Glaubitz wrote: > On 11/29/2017 04:39 PM, coleen.phillimore at oracle.com wrote: >>> Hmm. This doesn't fix a bug, and there's a non-zero probability of >>> introducing one. I guess it should be OK, but this is a combination >>> of performance improvement (possibly) and cleanup. >>> >> Please save this change for JDK 11. > > I just made the same obvious change as I did for m68k. Is there really > a risk of introducing a regression? There's always a risk with any change. In this case, we know that the kernel builtin is very stable, and we don't know that every version of GCC will always use the kernel builtin. > It only affects Zero after all which is not officially supported, is it? > > The supported ARMv7 Server build is not affected as this change is > below the linux_zero directory. Yea, but there's still a risk, supported or not. It can surely wait until 11. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.kozlov at oracle.com Wed Nov 29 17:02:05 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Nov 2017 09:02:05 -0800 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> References: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> Message-ID: <009a8c21-f0e6-9986-82b3-ec77454a6baf@oracle.com> Hi Alan, On 11/29/17 1:05 AM, Alan Bateman wrote: > On 28/11/2017 23:51, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8191788/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8191788 >> >> This is redo of JDK-8190975 [1] fix which added jdk.internal.vm.compiler to tests which have --limit-modules option. >> Unfortunately tests start failing on SPARC where Graal (jdk.internal.vm.compiler) is not available. JDK-8191653 [2] >> reversed 8190975 changes to fix that problem. >> >> This fix adds jdk.internal.vm.compiler to --limit-modules list in JVM only when Graal is used: when it is explicitly >> specified with -Djvmci.Compiler=graal or in default case and when UseJVMCICompiler is true. >> >> I tested the fix with failed tests from JDK-8190975 which are mostly AppCDS tests in test/runtime/appcds/jigsaw and >> also test/jdk/java/lang/String/concat/WithSecurityManager.java >> >> I think this fix may break upgradeable status of Graal (for Oracle Labs version of Graal). >> But it should be fine since it is only used with --limit-modules which is not used by Labs. > If jdk.internal.vm.compiler is not observable on SPARC then shouldn't the tests have `@requires > jdk.internal.vm.compiler` and jtreg will skip the test on that platform? No, these testes (listed above) has nothing to do with Graal. So we can't guard them based on presence of Graal. That was the problem and that is why original 8190975 fix had to be reversed. > > Just asking as augmenting the value passed to --limit-modules is very strange. It's normal for XX options to augment the > set of modules that resolved (+EnableJVMCI implies `--add-modules jdk.internal.vm.ci` for example) but doing this for > --limit-modules suggests the VM is doing something to mask an issue with the way that the tests are run. Just reminder - Graal is upgradeable module [1]. We can't do for it what we do for JVMCI as you pointed. [1] https://bugs.openjdk.java.net/browse/JDK-8177845 Thanks, Vladimir > > -Alan From vladimir.kozlov at oracle.com Wed Nov 29 17:27:29 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Nov 2017 09:27:29 -0800 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com> References: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com> <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com> Message-ID: <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com> On 11/29/17 4:37 AM, Alan Bateman wrote: > On 29/11/2017 11:26, David Holmes wrote: >> >> The current approach basically prevents anyone using JVMCI from shooting themselves in the foot by setting >> --limit-modules in a way that excludes the jdk.internal.vm.compiler module. In essence we want to ensure that if using >> JVMCI then all the requisite pieces will be available. But perhaps we are doing this the wrong way: how do >> --limit-modules and --add-modules combine? We could add jdk.internal.vm.compiler rather than expanding the limit-set. >> But the end result would seem the same. > The VM shouldn't augment the value specified to --limit-modules so I think we need to do back to the original issue and > find a better solution. Is JDK-8190975 the real issue that we should be looking at? Is it just the two tests listed? In > the case of BootAppendTests then it can check if the module is observable before specifying it to --limit-modules when > creating the child VM. WithSecurityManager might need additional work or maybe it can drop the use of --limit-modules. There are more AppCDS tests which failed too. Originally they we in closed repo and not listed. But now they are in open: http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/test/hotspot/jtreg/runtime/appcds/jigsaw 16 tests. > > As regards using --limit-modules and --add-modules together then it is possible, the details are in JEP 261. I tried to add jdk.internal.vm.compiler to --add-modules instead of --limit-modules. But it fails because it will require to add all Graal's "required" modules too: http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/src/jdk.internal.vm.compiler/share/classes/module-info.java#l26 If it acceptable I can do that instead. But I insist that we should do that in JVM. I don't want to skip tests on SPARC which have nothing to do with Graal. Thanks, Vladimir > > -Alan. From dean.long at oracle.com Wed Nov 29 17:55:41 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 29 Nov 2017 09:55:41 -0800 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: <7388ef34-681b-db6d-f6b5-f4c44519721b@oracle.com> References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> <7388ef34-681b-db6d-f6b5-f4c44519721b@oracle.com> Message-ID: Thanks Robbin! dl On 11/29/17 12:23 AM, Robbin Ehn wrote: > On 2017-11-28 19:00, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8191437 >> >> http://cr.openjdk.java.net/~dlong/8191437/webrev.hs/ > > Looks good, thanks for fixing! > > /Robbin > >> >> http://cr.openjdk.java.net/~dlong/8191437/webrev.graal/ >> >> >> This change adds support for thread local handshakes to Graal for x64 >> and SPARC.? Graal generates a different instruction encoding on x64 >> than C1/C2, so I had to account for that difference in >> sharedRuntime_x86_64.cpp.? I'm including the Graal changes because I >> would like to push them together with the HotSpot changes. >> >> >> dl >> From dean.long at oracle.com Wed Nov 29 18:38:43 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 29 Nov 2017 10:38:43 -0800 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> Message-ID: On 11/29/17 3:15 AM, Andrew Dinn wrote: > Hi Dean, > > On 28/11/17 18:00, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8191437 >> >> http://cr.openjdk.java.net/~dlong/8191437/webrev.hs/ >> >> http://cr.openjdk.java.net/~dlong/8191437/webrev.graal/ >> >> >> This change adds support for thread local handshakes to Graal for x64 >> and SPARC.? Graal generates a different instruction encoding on x64 than >> C1/C2, so I had to account for that difference in >> sharedRuntime_x86_64.cpp.? I'm including the Graal changes because I >> would like to push them together with the HotSpot changes. > Is there a reason for rejecting use of thread local handshakes in the > Graal AArch64 code rather than just adding support for it? The changes > to make AArch64 implement this are targetted for 10 and in review on > aarch64-port-dev > > https://bugs.openjdk.java.net/browse/JDK-8189596 > > http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2017-November/005104.html > > regards, I didn't feel like I had the time or testing setup to do the aarch64 Graal support myself,? but yes I could have asked the aarch64 community for help.? My bad. The x64 and SPARC changes have already gone into Graal.? Does it make sense to file a pull request at https://github.com/graalvm/graal for aarch64 support? dl > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From jiangli.zhou at oracle.com Wed Nov 29 19:46:55 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 29 Nov 2017 11:46:55 -0800 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com> References: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com> <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com> <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com> Message-ID: <9053DF41-2560-437B-B374-1DC8587AB2F5@oracle.com> > On Nov 29, 2017, at 9:27 AM, Vladimir Kozlov wrote: > > On 11/29/17 4:37 AM, Alan Bateman wrote: >> On 29/11/2017 11:26, David Holmes wrote: >>> >>> The current approach basically prevents anyone using JVMCI from shooting themselves in the foot by setting --limit-modules in a way that excludes the jdk.internal.vm.compiler module. In essence we want to ensure that if using JVMCI then all the requisite pieces will be available. But perhaps we are doing this the wrong way: how do --limit-modules and --add-modules combine? We could add jdk.internal.vm.compiler rather than expanding the limit-set. But the end result would seem the same. >> The VM shouldn't augment the value specified to --limit-modules so I think we need to do back to the original issue and find a better solution. Is JDK-8190975 the real issue that we should be looking at? Is it just the two tests listed? In the case of BootAppendTests then it can check if the module is observable before specifying it to --limit-modules when creating the child VM. WithSecurityManager might need additional work or maybe it can drop the use of --limit-modules. > > There are more AppCDS tests which failed too. Originally they we in closed repo and not listed. But now they are in open: > > http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/test/hotspot/jtreg/runtime/appcds/jigsaw > > 16 tests. > >> As regards using --limit-modules and --add-modules together then it is possible, the details are in JEP 261. > > I tried to add jdk.internal.vm.compiler to --add-modules instead of --limit-modules. But it fails because it will require to add all Graal's "required" modules too: > > http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/src/jdk.internal.vm.compiler/share/classes/module-info.java#l26 > > If it acceptable I can do that instead. > > But I insist that we should do that in JVM. I don't want to skip tests on SPARC which have nothing to do with Graal. I agree with Vladimir. Skipping these tests on SPARC is not applaudable in this case as they are not Graal specific tests. Thanks, Jiangli > > Thanks, > Vladimir > >> -Alan. From jiangli.zhou at oracle.com Wed Nov 29 19:46:55 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 29 Nov 2017 11:46:55 -0800 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com> References: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com> <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com> <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com> Message-ID: <28EEE53F-D02D-432C-B2AC-D88EE45D8FE4@oracle.com> > On Nov 29, 2017, at 9:27 AM, Vladimir Kozlov wrote: > > On 11/29/17 4:37 AM, Alan Bateman wrote: >> On 29/11/2017 11:26, David Holmes wrote: >>> >>> The current approach basically prevents anyone using JVMCI from shooting themselves in the foot by setting --limit-modules in a way that excludes the jdk.internal.vm.compiler module. In essence we want to ensure that if using JVMCI then all the requisite pieces will be available. But perhaps we are doing this the wrong way: how do --limit-modules and --add-modules combine? We could add jdk.internal.vm.compiler rather than expanding the limit-set. But the end result would seem the same. >> The VM shouldn't augment the value specified to --limit-modules so I think we need to do back to the original issue and find a better solution. Is JDK-8190975 the real issue that we should be looking at? Is it just the two tests listed? In the case of BootAppendTests then it can check if the module is observable before specifying it to --limit-modules when creating the child VM. WithSecurityManager might need additional work or maybe it can drop the use of --limit-modules. > > There are more AppCDS tests which failed too. Originally they we in closed repo and not listed. But now they are in open: > > http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/test/hotspot/jtreg/runtime/appcds/jigsaw > > 16 tests. > >> As regards using --limit-modules and --add-modules together then it is possible, the details are in JEP 261. > > I tried to add jdk.internal.vm.compiler to --add-modules instead of --limit-modules. But it fails because it will require to add all Graal's "required" modules too: > > http://hg.openjdk.java.net/jdk/hs/file/461e9c898e80/src/jdk.internal.vm.compiler/share/classes/module-info.java#l26 > > If it acceptable I can do that instead. > > But I insist that we should do that in JVM. I don't want to skip tests on SPARC which have nothing to do with Graal. I agree with Vladimir. Skipping these tests on SPARC is not applaudable in this case as they are not Graal specific tests. Thanks, Jiangli > > Thanks, > Vladimir > >> -Alan. From dean.long at oracle.com Wed Nov 29 20:14:19 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 29 Nov 2017 12:14:19 -0800 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> Message-ID: On 11/29/17 10:38 AM, dean.long at oracle.com wrote: > On 11/29/17 3:15 AM, Andrew Dinn wrote: > >> Hi Dean, >> >> On 28/11/17 18:00, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8191437 >>> >>> http://cr.openjdk.java.net/~dlong/8191437/webrev.hs/ >>> >>> http://cr.openjdk.java.net/~dlong/8191437/webrev.graal/ >>> >>> >>> This change adds support for thread local handshakes to Graal for x64 >>> and SPARC.? Graal generates a different instruction encoding on x64 >>> than >>> C1/C2, so I had to account for that difference in >>> sharedRuntime_x86_64.cpp.? I'm including the Graal changes because I >>> would like to push them together with the HotSpot changes. >> Is there a reason for rejecting use of thread local handshakes in the >> Graal AArch64 code rather than just adding support for it? The changes >> to make AArch64 implement this are targetted for 10 and in review on >> aarch64-port-dev >> >> ?? https://bugs.openjdk.java.net/browse/JDK-8189596 >> >> http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2017-November/005104.html >> >> >> regards, > > I didn't feel like I had the time or testing setup to do the aarch64 > Graal support myself,? but yes I could have asked the aarch64 > community for help.? My bad. > The x64 and SPARC changes have already gone into Graal.? Does it make > sense to file a pull request at https://github.com/graalvm/graal for > aarch64 support? > Aarch64 support is building, at least: https://github.com/dean-long/graal/tree/aarch64-tls-poll dl > dl > >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From dean.long at oracle.com Wed Nov 29 21:07:52 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 29 Nov 2017 13:07:52 -0800 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> Message-ID: <35287daa-9896-afc3-96bd-abbd65651cae@oracle.com> On 11/29/17 12:14 PM, dean.long at oracle.com wrote: > On 11/29/17 10:38 AM, dean.long at oracle.com wrote: > >> On 11/29/17 3:15 AM, Andrew Dinn wrote: >> >>> Hi Dean, >>> >>> On 28/11/17 18:00, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8191437 >>>> >>>> http://cr.openjdk.java.net/~dlong/8191437/webrev.hs/ >>>> >>>> http://cr.openjdk.java.net/~dlong/8191437/webrev.graal/ >>>> >>>> >>>> This change adds support for thread local handshakes to Graal for x64 >>>> and SPARC.? Graal generates a different instruction encoding on x64 >>>> than >>>> C1/C2, so I had to account for that difference in >>>> sharedRuntime_x86_64.cpp.? I'm including the Graal changes because I >>>> would like to push them together with the HotSpot changes. >>> Is there a reason for rejecting use of thread local handshakes in the >>> Graal AArch64 code rather than just adding support for it? The changes >>> to make AArch64 implement this are targetted for 10 and in review on >>> aarch64-port-dev >>> >>> ?? https://bugs.openjdk.java.net/browse/JDK-8189596 >>> >>> http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2017-November/005104.html >>> >>> >>> regards, >> >> I didn't feel like I had the time or testing setup to do the aarch64 >> Graal support myself,? but yes I could have asked the aarch64 >> community for help.? My bad. >> The x64 and SPARC changes have already gone into Graal.? Does it make >> sense to file a pull request at https://github.com/graalvm/graal for >> aarch64 support? >> > > Aarch64 support is building, at least: > > https://github.com/dean-long/graal/tree/aarch64-tls-poll > Pull request: https://github.com/graalvm/graal/pull/265 I could use some Aarch64 reviewers and testers. dl > dl > >> dl >> >>> >>> Andrew Dinn >>> ----------- >>> Senior Principal Software Engineer >>> Red Hat UK Ltd >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >> > From bob.vandette at oracle.com Wed Nov 29 21:43:10 2017 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 29 Nov 2017 16:43:10 -0500 Subject: RFR: 8192154 - JVM crashes inside some chroot environments on linux Message-ID: Please review this robustness fix to the Container support recently added to Hotspot. BUG: https://bugs.openjdk.java.net/browse/JDK-8192154 WEBREV: http://cr.openjdk.java.net/~bobv/8192154/webrev/ In the event that there is a partial setup of the cgroup subsystems, it?s possible that the VM will crash. The change moves NULL checking earlier in the scanning of the cgroup subsystems. Tested with jtreg container tests and Mach5. Bob. From glaubitz at physik.fu-berlin.de Wed Nov 29 22:17:22 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 29 Nov 2017 23:17:22 +0100 Subject: RFR: 8192154 - JVM crashes inside some chroot environments on linux In-Reply-To: References: Message-ID: <4f653a72-3f3a-d1f5-d077-3b881b94aabd@physik.fu-berlin.de> On 11/29/2017 10:43 PM, Bob Vandette wrote: > Tested with jtreg container tests and Mach5. I can confirm this change fixes the issue for me for the cases were I first discovered it. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From mandy.chung at oracle.com Wed Nov 29 22:44:07 2017 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 29 Nov 2017 14:44:07 -0800 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com> References: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com> <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com> <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com> Message-ID: Vladimir and I discussed this offline. java --limit-modules should have the same set of observable modules as running on an image that is created with jlink.? When running with -XX:+UseJVMCICompiler on a runtime image with just java.base, it will fail in the same way as running with java --limit-modules java.base -XX:+UseJVMCICompiler. These tests are written to run on a runtime image with java.base only should be updated to get it run with -XX:+UseJVMCICompiler.? I will take a look and see how we can refactor the tests to support such testing configuration.?? In the meantime, Vladimir suggests to exclude these tests when running with -XX:+UseJVMCICompiler (specifying @requires). Mandy From vladimir.kozlov at oracle.com Wed Nov 29 23:19:06 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Nov 2017 15:19:06 -0800 Subject: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line In-Reply-To: References: <25153d88-5ce9-34dd-e8d9-38dffc646f2f@oracle.com> <87f1dbbc-5b8b-be18-9a37-1568b0490521@oracle.com> <857e84fd-c86a-5c9b-1fdc-2b151874f000@oracle.com> <16aa4140-7843-b468-e24c-493bd89c2d65@oracle.com> Message-ID: <85ed009a-5c31-80fb-b8ae-1f889843e6e7@oracle.com> Yes, it was my limited understanding what --limit-modules is. We should not add modules "under cover" when --limit-modules is used. User should known all required modules *explicitly* to create correct image with jlink based on result of runs with --limit-modules flag. Since it is limited set of tests which use --limit-modules (11 in hotspot, 23 in jdk and few in closed) I will exclude these tests from running with Graal as JIT by adding @require to them: @requires !vm.graal.enabled We may revisit this later in a future when Graal become default JIT compiler (it should be supported on platforms at that time). Thanks, Vladimir On 11/29/17 2:44 PM, mandy chung wrote: > Vladimir and I discussed this offline. java --limit-modules should have the same set of observable > modules as running on an image that is created with jlink.? When running with -XX:+UseJVMCICompiler > on a runtime image with just java.base, it will fail in the same way as running with java > --limit-modules java.base -XX:+UseJVMCICompiler. These tests are written to run on a runtime image > with java.base only should be updated to get it run with -XX:+UseJVMCICompiler.? I will take a look > and see how we can refactor the tests to support such testing configuration.?? In the meantime, > Vladimir suggests to exclude these tests when running with -XX:+UseJVMCICompiler (specifying > @requires). > > Mandy From david.holmes at oracle.com Thu Nov 30 04:40:55 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Nov 2017 14:40:55 +1000 Subject: JVM crashing insides chroots - was: Re: Zero crashing on ARM In-Reply-To: <47fd2abd-87e9-ac42-8aad-1079d67dec5c@physik.fu-berlin.de> References: <327e6ff0-de5b-ff37-213f-30dbb6672520@physik.fu-berlin.de> <985632c8-d1df-33c9-7228-ee0fa93491a5@physik.fu-berlin.de> <1511963377.4026.45.camel@redhat.com> <802ced95-953d-08d3-a28f-b79588754e3b@physik.fu-berlin.de> <1511964480.4026.47.camel@redhat.com> <47fd2abd-87e9-ac42-8aad-1079d67dec5c@physik.fu-berlin.de> Message-ID: <9aca39b2-c7eb-ce41-8cb2-37da56dc8ce4@oracle.com> Hi Adrian, You are running from an exploded build. Try "make images" and retest using build/linux-x86_64-normal-server-release/images/jdk/bin/java David On 30/11/2017 12:16 AM, John Paul Adrian Glaubitz wrote: > On 11/29/2017 03:12 PM, John Paul Adrian Glaubitz wrote: >> On 11/29/2017 03:08 PM, Severin Gehwolf wrote: >>> You are comparing a JIT server JVM with Zero. That's expected ;-) >> >> Well, sorry, that was by accident, I didn't mean to run Server. > For completeness' sake, here's the Server variant: > > (sid-amd64-sbuild)root at trlin:/usr/src/hs# time /usr/bin/java -version > openjdk version "9.0.1" > OpenJDK Runtime Environment (build 9.0.1+11-Debian-1) > OpenJDK 64-Bit Server VM (build 9.0.1+11-Debian-1, mixed mode) > > real??? 0m0.101s > user??? 0m0.112s > sys???? 0m0.032s > (sid-amd64-sbuild)root at trlin:/usr/src/hs# time > /usr/src/hs/build/linux-x86_64-normal-server-release/jdk/bin/java > -XX:-UseContainerSupport -version > openjdk version "10-internal" > OpenJDK Runtime Environment (build 10-internal+0-adhoc.root.hs) > OpenJDK 64-Bit Server VM (build 10-internal+0-adhoc.root.hs, mixed mode) > > real??? 0m1.080s > user??? 0m3.622s > sys???? 0m0.591s > (sid-amd64-sbuild)root at trlin:/usr/src/hs# > From david.holmes at oracle.com Thu Nov 30 04:45:50 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Nov 2017 14:45:50 +1000 Subject: RFR (S): 8191567: Refactor ciInstanceKlass G1 keep alive barrier to use Access API. In-Reply-To: References: <5A184729.4090107@oracle.com> <84bae716-9308-e372-5a13-f0c4d348b6a1@oracle.com> <23b84b9e-fab6-f2f3-8cc7-bc8d67a17c7f@oracle.com> <67b482bd-cd01-0097-50b4-4b6090583926@oracle.com> Message-ID: On 29/11/2017 10:41 PM, Per Liden wrote: > Hi David, > > On 2017-11-29 12:33, David Holmes wrote: >> Hi Per, >> >> Sorry one follow up ... >> >> On 29/11/2017 9:17 PM, Per Liden wrote: >>> Hi David, >>> >>> On 11/28/2017 10:22 PM, David Holmes wrote: >>>> Hi Per, >>>> >>>> On 28/11/2017 5:53 PM, Per Liden wrote: >>>>> Hi David, >>>>> >>>>> On 2017-11-28 07:50, David Holmes wrote: >>>>>> Hi Erik, >>>>>> >>>>>> Does "phantom" here have any relationship to PhantomReference? >>>>> >>>>> Yes, in the sense that this root oop has the same strength as the >>>>> referent field in a PhantomReference. All non-strong root oops in the >>>>> VM (StringTable, JNIWeakHandles, etc) are "phantom oops". Internally >>>>> in the VM they are unfortunately sometimes referred to as "weak >>>>> roots". With the access API, we're trying to move away from using >>>>> "weak" for these since "weak" is the strength of the referent in a >>>>> Soft/Weak/FinalReference. >>>> >>>> Ah I see. I hadn't realized we were mis-using "weak" that way. >>>> >>>>>> >>>>>> Meta-question on access API: if >>>>>> >>>>>> RootAccess::oop_load(addr); >>>>>> >>>>>> keeps the value alive, what can cause the value to be allowed to go >>>>>> dead >>>>>> again? >>>>> >>>>> After a GC, if all existing pointers to this object are phantom oops, >>>>> then the object is phantom-reachable and those phantom oops will be >>>>> declared dead and cleared (i.e. same criteria as when a >>>>> j.l.r.PhantomReference is enqueued). >>>> >>>> Sorry this is going OT wrt the actual code review but I'm a bit >>>> confused. If the above RootAccess marks the oop as PhantomReachable >>>> then >>>> GC can remove it and it wasn't kept alive after all ?? If the above >>>> makes it stronger than PhantomReachable then GC won't be able to remove >>>> it, but then how does it return to only being PhantomReachable? >>> >>> Unless the access has the AS_NO_KEEPALIVE decorator, a call to >>> RootAccess<>::oop_load() will always make the object strongly >>> reachable or return NULL. >> >> OKay, but for how long will it remain strongly reachable? Just till the >> end of the current GC cycle, or the start of the next, or ... ? > > The object will be considered strongly reachable until the start of the > next GC cycle. During the next GC cycle the reachability of the object > will be reevaluated again. > > Does that clarify things? Yes - thanks for your patience :) David > > /Per > >> >> Thanks, >> David >> >>> The ON_WEAK_OOP_REF/ON_PHANTOM_OOP_REF tells that access barrier that >>> this oop is subject to resurrection restrictions. This means that >>> special care needs to be taken when loading this oop, because the >>> object it points to might already have been declared weak- or >>> phantom-reachable, but this oop has not yet been cleared (set to >>> NULL). In this case, the access barrier will step in, detect the >>> situation and return NULL anyway, essentially making it look like the >>> oop has been cleared. At some point later, when the GC is doing >>> weak/phantom reference processing, the logically dead oops will >>> actually be cleared (set to NULL). >>> >>> /Per >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> cheers, >>>>> Per >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 25/11/2017 2:22 AM, Erik ?sterlund wrote: >>>>>>> Hi, >>>>>>> >>>>>>> When creating a ciInstanceKlass handle, G1 might need a SATB barrier >>>>>>> to keep "peeked" weak klass pointers alive during marking. >>>>>>> This should now be done with the Access API instead of manual >>>>>>> calls to >>>>>>> the G1 SATB barrier. >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8191567 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~eosterlund/8191567/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> /Erik From kim.barrett at oracle.com Thu Nov 30 05:27:49 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 30 Nov 2017 00:27:49 -0500 Subject: RFR: 8191870: Remove badJNIHandle In-Reply-To: References: <5CA7805F-D608-48FC-B289-EE81852263FB@oracle.com> <6678b53c-4492-3ec8-ea69-36dc4dda2bb2@oracle.com> Message-ID: <52BEA1AA-B48F-47BF-BA91-030719FC485E@oracle.com> > On Nov 29, 2017, at 5:25 AM, David Holmes wrote: > > On 28/11/2017 6:43 AM, coleen.phillimore at oracle.com wrote: >> On 11/27/17 3:21 PM, Kim Barrett wrote: >>>> On Nov 27, 2017, at 10:19 AM, coleen.phillimore at oracle.com wrote: >>>> My question was why there's a command line option, which seems like nobody on earth should use it. Yes, we don't need to zap for product, only for debug. >>> So remove the CLA and instead #ifdef ASSERT the zapping. >> Yes. > > Okay we _really_ need to establish the ground rules for when you can just delete a CLA without going through any deprecation process or filing a CSR! Yes, that would be good to have. > David > ----- > >>> >>> I?d be okay with that. Another CLA bites the dust. >> What looks like a pointless one at that. >> Coleen From david.holmes at oracle.com Thu Nov 30 07:29:34 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 30 Nov 2017 17:29:34 +1000 Subject: RFR: 8192154 - JVM crashes inside some chroot environments on linux In-Reply-To: References: Message-ID: Hi Bob, On 30/11/2017 7:43 AM, Bob Vandette wrote: > Please review this robustness fix to the Container support recently added to Hotspot. > > BUG: > https://bugs.openjdk.java.net/browse/JDK-8192154 > > WEBREV: > http://cr.openjdk.java.net/~bobv/8192154/webrev/ > > In the event that there is a partial setup of the cgroup subsystems, it?s > possible that the VM will crash. > > The change moves NULL checking earlier in the scanning of the cgroup subsystems. The change looks good. BTW: 326 if (mntinfo != NULL) fclose(mntinfo); 391 if (cgroup != NULL) fclose(cgroup); in both cases the value can't be NULL as in that case you've already returned from the function. Thanks, David > Tested with jtreg container tests and Mach5. > > Bob. > > From sgehwolf at redhat.com Thu Nov 30 08:53:38 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 30 Nov 2017 09:53:38 +0100 Subject: RFR: 8192154 - JVM crashes inside some chroot environments on linux In-Reply-To: References: Message-ID: <1512032018.4363.1.camel@redhat.com> On Wed, 2017-11-29 at 16:43 -0500, Bob Vandette wrote: > Please review this robustness fix to the Container support recently added to Hotspot. > > BUG: > https://bugs.openjdk.java.net/browse/JDK-8192154 > > WEBREV: > http://cr.openjdk.java.net/~bobv/8192154/webrev/ > > In the event that there is a partial setup of the cgroup subsystems, it?s > possible that the VM will crash. > > The change moves NULL checking earlier in the scanning of the cgroup subsystems. > > Tested with jtreg container tests and Mach5. This looks fine to me. I'm not a Reviewer. Thanks, Severin From stefan.johansson at oracle.com Thu Nov 30 13:30:57 2017 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 30 Nov 2017 14:30:57 +0100 Subject: RFR: 8192807: testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fail due to new method in Platform.java Message-ID: Hi, Please review this small fix for tier1 failure reported in: https://bugs.openjdk.java.net/browse/JDK-8192807 Webrev: http://cr.openjdk.java.net/~sjohanss/8192807/00/ Summary: The newly added method in Platform.java was not added to a MethodGroup in the test. This change adds the method to the IGNORED group and also adds output to the assertion to simplify debugging in the future. Testing: * The affected test both locally and through M5 (running now). Thanks, Stefan From thomas.schatzl at oracle.com Thu Nov 30 13:40:14 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 30 Nov 2017 14:40:14 +0100 Subject: RFR: 8192807: testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fail due to new method in Platform.java In-Reply-To: References: Message-ID: <1512049214.2422.8.camel@oracle.com> Hi, On Thu, 2017-11-30 at 14:30 +0100, Stefan Johansson wrote: > Hi, > > Please review this small fix for tier1 failure reported in: > https://bugs.openjdk.java.net/browse/JDK-8192807 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8192807/00/ > > Summary: > The newly added method in Platform.java was not added to a > MethodGroup in the test. This change adds the method to the IGNORED > group and also adds output to the assertion to simplify debugging in > the future. > > Testing: > * The affected test both locally and through M5 (running now). ship it. :) Thanks, Thomas From jesper.wilhelmsson at oracle.com Thu Nov 30 13:42:24 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 30 Nov 2017 14:42:24 +0100 Subject: RFR: 8192807: testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fail due to new method in Platform.java In-Reply-To: References: Message-ID: Looks good! Thanks for fixing the issue AND improving the error message for the next time! /Jesper > On 30 Nov 2017, at 14:30, Stefan Johansson wrote: > > Hi, > > Please review this small fix for tier1 failure reported in: > https://bugs.openjdk.java.net/browse/JDK-8192807 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8192807/00/ > > Summary: > The newly added method in Platform.java was not added to a MethodGroup in the test. This change adds the method to the IGNORED group and also adds output to the assertion to simplify debugging in the future. > > Testing: > * The affected test both locally and through M5 (running now). > > Thanks, > Stefan > From aph at redhat.com Thu Nov 30 14:32:55 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Nov 2017 14:32:55 +0000 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: <35287daa-9896-afc3-96bd-abbd65651cae@oracle.com> References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> <35287daa-9896-afc3-96bd-abbd65651cae@oracle.com> Message-ID: <7e3cccc2-c3eb-6b4e-1985-0b60c7eb4fc5@redhat.com> On 29/11/17 21:07, dean.long at oracle.com wrote: > https://github.com/graalvm/graal/pull/265 > > I could use some Aarch64 reviewers and testers. I'm going to build this now. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ioi.lam at oracle.com Thu Nov 30 15:37:16 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 30 Nov 2017 07:37:16 -0800 Subject: RFR: 8192807: testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java fail due to new method in Platform.java In-Reply-To: References: Message-ID: Thanks for fixing this. I am so sorry for checking in something that broke tier1 :-( - Ioi On 11/30/17 5:42 AM, jesper.wilhelmsson at oracle.com wrote: > Looks good! > > Thanks for fixing the issue AND improving the error message for the next time! > /Jesper > >> On 30 Nov 2017, at 14:30, Stefan Johansson wrote: >> >> Hi, >> >> Please review this small fix for tier1 failure reported in: >> https://bugs.openjdk.java.net/browse/JDK-8192807 >> >> Webrev: >> http://cr.openjdk.java.net/~sjohanss/8192807/00/ >> >> Summary: >> The newly added method in Platform.java was not added to a MethodGroup in the test. This change adds the method to the IGNORED group and also adds output to the assertion to simplify debugging in the future. >> >> Testing: >> * The affected test both locally and through M5 (running now). >> >> Thanks, >> Stefan >> From aph at redhat.com Thu Nov 30 16:51:58 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Nov 2017 16:51:58 +0000 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: <35287daa-9896-afc3-96bd-abbd65651cae@oracle.com> References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> <35287daa-9896-afc3-96bd-abbd65651cae@oracle.com> Message-ID: On 29/11/17 21:07, dean.long at oracle.com wrote: > Pull request: > > https://github.com/graalvm/graal/pull/265 > > I could use some Aarch64 reviewers and testers. One thing breaks, and we need this hunk instead: diff -r 4c25d37d8557 src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotSafepointOp.java --- a/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotSafepointOp.java Thu Nov 30 16:08:13 2017 +0100 +++ b/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotSafepointOp.java Thu Nov 30 16:48:18 2017 +0000 @@ -94,4 +105,14 @@ } } + private static void emitThreadLocalPoll(CompilationResultBuilder crb, AArch64MacroAssembler masm, GraalHotSpotVMConfig config, boolean onReturn, Register thread, Register scratch, LIRFrameState state) { + assert config.threadPollingPageOffset >= 0; + masm.ldr(64, scratch, masm.makeAddress(thread, config.threadPollingPageOffset, 8)); + crb.recordMark(onReturn ? config.MARKID_POLL_RETURN_FAR : config.MARKID_POLL_FAR); + if (state != null) { + crb.recordInfopoint(masm.position(), state, InfopointReason.SAFEPOINT); + } + masm.ldr(32, zr, AArch64Address.createBaseRegisterOnlyAddress(scratch)); + } + } The only difference from what you pushed in MARKID_POLL_*FAR instead of MARKID_POLL_*NEAR. This is because we don't support MARKID_POLL_NEAR relocs in jvmci. They can't happen, anyway: that's effectively dead code in AArch64's Graal. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dean.long at oracle.com Thu Nov 30 17:05:35 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 30 Nov 2017 09:05:35 -0800 Subject: RFR(S) 8191437: AOT doesn't work easily after thread local handshakes In-Reply-To: References: <699ebcf8-101d-05b5-5fe9-dd91fd992fee@oracle.com> <35287daa-9896-afc3-96bd-abbd65651cae@oracle.com> Message-ID: On 11/30/17 8:51 AM, Andrew Haley wrote: > On 29/11/17 21:07, dean.long at oracle.com wrote: >> Pull request: >> >> https://github.com/graalvm/graal/pull/265 >> >> I could use some Aarch64 reviewers and testers. > One thing breaks, and we need this hunk instead: > > diff -r 4c25d37d8557 src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotSafepointOp.java > --- a/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotSafepointOp.java Thu Nov 30 16:08:13 2017 +0100 > +++ b/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.aarch64/src/org/graalvm/compiler/hotspot/aarch64/AArch64HotSpotSafepointOp.java Thu Nov 30 16:48:18 2017 +0000 > @@ -94,4 +105,14 @@ > } > } > > + private static void emitThreadLocalPoll(CompilationResultBuilder crb, AArch64MacroAssembler masm, GraalHotSpotVMConfig config, boolean onReturn, Register thread, Register scratch, LIRFrameState state) { > + assert config.threadPollingPageOffset >= 0; > + masm.ldr(64, scratch, masm.makeAddress(thread, config.threadPollingPageOffset, 8)); > + crb.recordMark(onReturn ? config.MARKID_POLL_RETURN_FAR : config.MARKID_POLL_FAR); > + if (state != null) { > + crb.recordInfopoint(masm.position(), state, InfopointReason.SAFEPOINT); > + } > + masm.ldr(32, zr, AArch64Address.createBaseRegisterOnlyAddress(scratch)); > + } > + > } > > The only difference from what you pushed in MARKID_POLL_*FAR instead > of MARKID_POLL_*NEAR. > > This is because we don't support MARKID_POLL_NEAR relocs in jvmci. > They can't happen, anyway: that's effectively dead code in AArch64's > Graal. That makes sense.? Thanks for testing and fixing it. dl > Thanks. > From jcbeyler at google.com Thu Nov 30 21:09:58 2017 From: jcbeyler at google.com (JC Beyler) Date: Thu, 30 Nov 2017 13:09:58 -0800 Subject: TLAB Refills for x86 Message-ID: Hi all, The TLAB and the inline contiguous allocations handling are different for each architecture. On certain architectures, TLAB is never actually never refilled (ref: https://bugs.openjdk.java.net/browse/JDK-8190862). The idea behind the implementation for x86 is to separate TLAB usage to contiguous allocations in eden space. Bug: https://bugs.openjdk.java.net/browse/JDK-8191027 WebRev: http://cr.openjdk.java.net/~rasbold/8191027/webrev.02/ Does anyone see any issues with this webrev? Thanks for your help, Jc