From Pengfei.Li at arm.com Mon Sep 3 05:49:46 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 3 Sep 2018 05:49:46 +0000 Subject: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: <97407ba1-7aec-0893-b540-7e1472ce9529@oracle.com> References: <97407ba1-7aec-0893-b540-7e1472ce9529@oracle.com> Message-ID: Hi Vladimir, Dean, Thanks for your review. > I don't see where negation is coming from for 'X % 2 == 0' expression. > It should be only 2 instructions: 'cmp (X and 1), 0' The 'cmp (X and 1), 0' is just what we expected. But there's redundant conditional negation coming from the possibly negative X handling in "X % 2". For instance, X = -5, "X % 2" should be -1. So only "(X and 1)" operation is not enough. We have to negate the result. > I will look on it next week. But it would be nice if you can provide small test to show this issue. I've already provided a case of "if (a%2 == 0) { ... }" in JBS description. What code generated and what can be optimized are listed there. You could see https://bugs.openjdk.java.net/browse/JDK-8210152 for details. You could also see the test case for this optimization I attached below. > It looks like your matching may allow more patterns than expected. I was expecting it to look for < 0 or >= 0 for the conditional negation, but I don't see it. Yes. I didn't limit the if condition to <0 or >= 0 so it will match more patterns. But nothing is going wrong if this ideal transformation applies on more cases. In pseudo code, if someone writes: if ( some_condition ) { x = -x; } if ( x == 0 ) { do_something(); } The negation in 1st if-clause could always be eliminated whatever the condition is. -- Thanks, Pengfei -- my test case attached below -- public class Foo { public static void main(String[] args) { int[] dividends = { 0, 17, 1553, -90, -35789, 0x80000000 }; for (int i = 0; i < dividends.length; i++) { int x = dividends[i]; System.out.println(testDivisible(x)); System.out.println(testModulo(x)); testCondNeg(x); } return; } public static int testDivisible(int x) { // Modulo result is only for zero check if (x % 4 == 0) { return 444; } return 555; } public static int testModulo(int x) { int y = x % 4; if (y == 0) { return 222; } // Modulo result is used elsewhere System.out.println(y); return 333; } public static void testCondNeg(int x) { // Pure conditional negation if (printAndIfNeg(x)) { x = -x; } if (x == 0) { System.out.println("zero!"); } } static boolean printAndIfNeg(int x) { System.out.println(x); return x <= 0; } } From david.holmes at oracle.com Mon Sep 3 06:44:31 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Sep 2018 16:44:31 +1000 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> Message-ID: Hi Kim, I know this has been pushed now but if we're going to re-jiggle the Thread hierarchy then we can maybe do better. I never liked the introduction of NamedThread and it seems even more superfluous now - all threads can/should have names, there's really no reason why the WatcherThread or JfrSamplerThread should be special in this regard. Arguably you don't need NonJavaThread as if you don't derive from JavaThread then you are by definition a non-JavaThread - but if this classification makes things easier so be it. IIRC we only use is_Java_thread() due to a lack of RTTI in our C++ usage. Is that likely to change going forward? Meanwhile should is_Java_thread() be pure virtual in Thread and overridden in JavaThread and NonJavaThread ? Cheers, David On 27/08/2018 9:09 AM, Kim Barrett wrote: > Please review this change to improve the iteration over > non-JavaThreads. This change introduces a new base class > NonJavaThread, which should be a base for any Thread class that isn't > a JavaThread. The recently introduced iteration over NamedThreads > (JDK-8209850) is moved to this new class. This allows the > re-implementation of Threads::non_java_threads_do using that list. > > Note: Perhaps CollectedHeap::gc_threads_do could be replaced by a > Threads::gc_threads_do that is implemented as an iteration over the > non-JavaThreads with a filter to select GC-related thread types. That > isn't being done as part of this change though. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8209850 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8209976/open.00/ > > Testing: > mach5 tier1-3, hs-tier4-5 in conjunction with a fix for JDK-8209975. > Local testing of just this change. > From david.holmes at oracle.com Mon Sep 3 07:12:46 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Sep 2018 17:12:46 +1000 Subject: RFR: 8210131: vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code In-Reply-To: <39905239-72B3-46A9-B31E-3B01FA5B9BAB@oracle.com> References: <39905239-72B3-46A9-B31E-3B01FA5B9BAB@oracle.com> Message-ID: <6fdb131a-3701-6875-e435-5bacd4cba3ac@oracle.com> Hi Kim, On 31/08/2018 12:15 PM, Kim Barrett wrote: > Please review this small change to GetCurrentThreadCpuTimerInfo and > GetCurrentThreadCpuTime JVMTI operations, allowing them to be called > from any NamedThread. This is consistent with the behavior from > JDK-8203948; there is no obvious reason for these operations to have > any thread context restriction. > > These functions are documented as being callable from heap callbacks > like ObjectFree, which can be called from an "internal thread or the > thread that called the [heap] iteration function". However, unlike > other, similar functions, these two were requiring the current thread > to be either a JavaThread or the VMThread. For other such functions, > JDK-6278106 had added Concurrent GC threads, and JDK-8203948 > generalized that to any NamedThread (or JavaThread). This change > makes these functions behave similarly. As previously discussed** we could just relax the thread constraint completely here. For most JVM TI callbacks the caller must be a JavaThread, but for callbacksafe cases it can nominally be any thread. I don't like the fact NamedThread is getting used to imply a capability that is totally unrelated to being named. **Though if you saw my initial comment on the bug you'll also realize I can't make up my mind whether to enumerate allowed threads or not. :) Cheers, David > This is needed to allow such callbacks to be invoked from a GC worker > thread, such as is now done for G1 (JDK-8072498), and probably other > collectors in the future. (See comments for JDK-8203948 for a > discussion of why ZGC didn't run into this problem.) > > This change also removes the failing test from the problem list. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8210131 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8210131/open.00/ > > Testing: > mach5 tier1-3, hs-tier4-6. > Local (linux-x64) jtreg:hotspot_gc, and manually ran the failing test. > Examined the generated jvmtiEnter[Trace].cpp file and verified the > change to the generated code was as expected. > From david.holmes at oracle.com Mon Sep 3 07:19:28 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Sep 2018 17:19:28 +1000 Subject: RFR: JDK-6657100 Rename sparcWorks to solstudio in HotSpot In-Reply-To: <4bd22bee-8d4c-8a1d-441b-03207355380c@oracle.com> References: <4bd22bee-8d4c-8a1d-441b-03207355380c@oracle.com> Message-ID: <20a1b3c0-066c-401c-3b12-db2f06d6b671@oracle.com> On 30/08/2018 10:36 PM, Magnus Ihse Bursie wrote: > Hi folks, > > This bug report goes all the way back to 2008. :-) So instead of just > letting it go on to it's second decade of existence, I went about and > fixed it. Ummm but now it's called Oracle Developer Studio. David > By now, not many references to sparcWorks exists anymore, so this is > almost trivial. > > I've verified by grep that no more "sparcworks" are present in the repo, > neither in hotspot nor anywhere else. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6657100 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-6657100-rename-sparcWorks-to-solstudio/webrev.01 > > > /Magnus From goetz.lindenmaier at sap.com Mon Sep 3 12:27:56 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 3 Sep 2018 12:27:56 +0000 Subject: RFR: 8208171: PPC64: Enrich SLP support In-Reply-To: <346da54af45243c4bdaf475f118a450d@sap.com> References: <346da54af45243c4bdaf475f118a450d@sap.com> Message-ID: <9553d65d98f74f37a35b49a1e39f015e@sap.com> Hi Michihiro, I had a look at your change. First, this should have been reviewed on hotspot-compiler-dev. It is clearly a compiler change. http://mail.openjdk.java.net/mailman/listinfo says that hotspot-dev is for "Technical discussion about the development of the HotSpot virtual machine that's not specific to any particular component" while hotspot-compiler-dev is for "Technical discussion about the development of the HotSpot bytecode compilers" Also, I can not find all of the mail traffic in http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/thread.html. Is this a problem of the pipermail server? For some reason this webrev lacks the links to browse the diffs. Do you need to use a more recent webrev? You can obtain it with hg clone http://hg.openjdk.java.net/code-tools/webrev/ . Why do you rename vnoreg to vnoregi? Besides that the change is fine, thanks for implementing this! Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 28. August 2018 19:35 > To: Gustavo Romero ; Michihiro Horie > > Cc: Lindenmaier, Goetz ; hotspot- > dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker > > Subject: RE: RFR: 8208171: PPC64: Enrich SLP support > > Hi Michihiro, > > thank you for implementing it. I have just taken a first look at your > webrev.01. > > It looks basically good. Only the Power version check seems to be incorrect. > VM_Version::has_popcntb() checks for Power5. > I believe most instructions are available with Power7. > Some ones (vsubudm, ..., vmmuluwm, vpopcntw) were introduced with > Power8? > We should check this carefully. > > Also, indentation in register_ppc.hpp could get improved. > > Thanks and best regard, > Martin > > > -----Original Message----- > From: Gustavo Romero > Sent: Donnerstag, 26. Juli 2018 16:02 > To: Michihiro Horie > Cc: Lindenmaier, Goetz ; hotspot- > dev at openjdk.java.net; Doerr, Martin ; ppc-aix- > port-dev at openjdk.java.net; Simonis, Volker > Subject: Re: RFR: 8208171: PPC64: Enrich SLP support > > Hi Michi, > > On 07/26/2018 01:43 AM, Michihiro Horie wrote: > > I updated webrev: > > http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ > > Thanks for providing an updated webrev and for fixing indentation and > function > order in assembler_ppc.inline.hpp as well. I have no further comments :) > > > Best Regards, > Gustavo > > > > > Best regards, > > -- > > Michihiro, > > IBM Research - Tokyo > > > > Inactive hide details for Gustavo Romero ---2018/07/25 23:05:32---Hi Michi, > On 07/25/2018 02:43 AM, Michihiro Horie wrote:Gustavo Romero --- > 2018/07/25 23:05:32---Hi Michi, On 07/25/2018 02:43 AM, Michihiro Horie > wrote: > > > > From: Gustavo Romero > > To: Michihiro Horie/Japan/IBM at IBMJP, ppc-aix-port- > dev at openjdk.java.net, hotspot-dev at openjdk.java.net > > Cc: goetz.lindenmaier at sap.com, volker.simonis at sap.com, "Doerr, Martin" > > > Date: 2018/07/25 23:05 > > Subject: Re: RFR: 8208171: PPC64: Enrich SLP support > > > > ------------------------------------------------------------------------------------------- > ---------------------------------------------------------------------------------------------- > ---------------------------------------------------------------------------------------------- > ---------------------------------------------------------------------------------------------- > ---------------------------------------------------------------------------------------------- > ---------------------------------------------------------------------------------------------- > ---------------------------------------------------------------------------------------------- > ---------------------------------------------------------------------------------------------- > ---------------------------------------------------------------------------------------------- > ---------------------------------------------------------------------------------------------- > ----------------------------------------------------- > > > > > > > > Hi Michi, > > > > On 07/25/2018 02:43 AM, Michihiro Horie wrote: > > > Dear all, > > > > > > Would you review the following change? > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208171 > > > Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00 > > > > > > This change adds support for vectorized arithmetic calculation with SLP. > > > > > > The to_vr function is added to convert VSR to VR. Currently, vecX is > associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, > which are exactly overlapped with VRs. Instruction APIs receiving VRs use the > to_vr via vecX. Another thing is the change in sqrtF_reg to enable the > matching with SqrtVF. I think the change in sqrtF_reg would be fine due to > the ConvD2FNode::Value in convertnode.cpp. > > > > Looks good. Just a few comments: > > > > - In vmul4F_reg() would it be reasonable to use xvmulsp instead of > vmaddfp in > > order to avoid the splat? > > > > - Although all instructions added by your change where introduced in ISA > 2.06, > > so POWER7 and above are OK, as I see probes for > PowerArchictecturePPC64=6|5 in > > vm_version_ppc.cpp (line 64), I'm wondering if there is any control point > to > > guarantee that these instructions won't be emitted on a CPU that does > not > > support them. > > > > - I think that in general string in format %{} are in upper case. For instance, > > this the current output on optoassembly for vmul4F: > > > > 2941835 5b4 ADDI R24, R24, #64 > > 2941836 5b8 vmaddfp VSR32,VSR32,VSR36 ! mul packed4F > > 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector > > > > I think it would be better to be in upper case instead. I also think that if > > the node match emits more than one instruction all instructions must be > listed > > in format %{}, since it's meant for detailed debugging. Finally I think it > > would be better to replace \t! by \t// in that string (unless I'm missing any > > special meaning for that char). So for vmul4F it would be something like: > > > > 2941835 5b4 ADDI R24, R24, #64 > > VSPLTISW VSR34, 0 // Splat 0 imm in VSR34 > > 2941836 5b8 VMADDFP VSR32,VSR32,VSR36,VSR34 // Mul packed4F > > 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector > > > > > > But feel free to change anything just after you get additional reviews :) > > > > > > > I confirmed this change with JTREG. In addition, I used attached micro > benchmarks. > > > /(See attached file: slp_microbench.zip)/ > > > > Thanks for sharing it. > > Btw, another option to host it would be in the CR > > server, in http://cr.openjdk.java.net/~mhorie/8208171 > > > > > > Best regards, > > Gustavo > > > > > > > > Best regards, > > > -- > > > Michihiro, > > > IBM Research - Tokyo > > > > > > > > > From gromero at linux.vnet.ibm.com Mon Sep 3 12:56:44 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 3 Sep 2018 09:56:44 -0300 Subject: RFR: 8208171: PPC64: Enrich SLP support In-Reply-To: <9553d65d98f74f37a35b49a1e39f015e@sap.com> References: <346da54af45243c4bdaf475f118a450d@sap.com> <9553d65d98f74f37a35b49a1e39f015e@sap.com> Message-ID: <48ee8bca-fd73-7854-84fd-20b836c00651@linux.vnet.ibm.com> Hi Goetz, On 09/03/2018 09:27 AM, Lindenmaier, Goetz wrote: > Also, I can not find all of the mail traffic in > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/thread.html. > Is this a problem of the pipermail server? > > For some reason this webrev lacks the links to browse the diffs. > Do you need to use a more recent webrev? You can obtain it with > hg clone http://hg.openjdk.java.net/code-tools/webrev/ . Yes, probably it was a problem of the pipermail or in some relay. I noted the same thing, i.e. at least one Michi reply arrived to me but missed a ML. The initial discussion is here: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-July/003613.html I understand Martin reviewed the last webrev in that thread, which is http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ (taken from http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-July/003615.html) Martin's review of webrev.01: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/033958.html and Michi's reply to Martin's review of webrev.01: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-August/003632.html (with webrev.02, taken from http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-August/003632.html). and your last review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-September/030419.html HTH. Best regards, Gustavo > Why do you rename vnoreg to vnoregi? > > Besides that the change is fine, thanks for implementing this! > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Doerr, Martin >> Sent: Dienstag, 28. August 2018 19:35 >> To: Gustavo Romero ; Michihiro Horie >> >> Cc: Lindenmaier, Goetz ; hotspot- >> dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker >> >> Subject: RE: RFR: 8208171: PPC64: Enrich SLP support >> >> Hi Michihiro, >> >> thank you for implementing it. I have just taken a first look at your >> webrev.01. >> >> It looks basically good. Only the Power version check seems to be incorrect. >> VM_Version::has_popcntb() checks for Power5. >> I believe most instructions are available with Power7. >> Some ones (vsubudm, ..., vmmuluwm, vpopcntw) were introduced with >> Power8? >> We should check this carefully. >> >> Also, indentation in register_ppc.hpp could get improved. >> >> Thanks and best regard, >> Martin >> >> >> -----Original Message----- >> From: Gustavo Romero >> Sent: Donnerstag, 26. Juli 2018 16:02 >> To: Michihiro Horie >> Cc: Lindenmaier, Goetz ; hotspot- >> dev at openjdk.java.net; Doerr, Martin ; ppc-aix- >> port-dev at openjdk.java.net; Simonis, Volker >> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >> >> Hi Michi, >> >> On 07/26/2018 01:43 AM, Michihiro Horie wrote: >>> I updated webrev: >>> http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ >> >> Thanks for providing an updated webrev and for fixing indentation and >> function >> order in assembler_ppc.inline.hpp as well. I have no further comments :) >> >> >> Best Regards, >> Gustavo >> >>> >>> Best regards, >>> -- >>> Michihiro, >>> IBM Research - Tokyo >>> >>> Inactive hide details for Gustavo Romero ---2018/07/25 23:05:32---Hi Michi, >> On 07/25/2018 02:43 AM, Michihiro Horie wrote:Gustavo Romero --- >> 2018/07/25 23:05:32---Hi Michi, On 07/25/2018 02:43 AM, Michihiro Horie >> wrote: >>> >>> From: Gustavo Romero >>> To: Michihiro Horie/Japan/IBM at IBMJP, ppc-aix-port- >> dev at openjdk.java.net, hotspot-dev at openjdk.java.net >>> Cc: goetz.lindenmaier at sap.com, volker.simonis at sap.com, "Doerr, Martin" >> >>> Date: 2018/07/25 23:05 >>> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >>> >>> ------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ----------------------------------------------------- >>> >>> >>> >>> Hi Michi, >>> >>> On 07/25/2018 02:43 AM, Michihiro Horie wrote: >>> > Dear all, >>> > >>> > Would you review the following change? >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8208171 >>> > Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00 >>> > >>> > This change adds support for vectorized arithmetic calculation with SLP. >>> > >>> > The to_vr function is added to convert VSR to VR. Currently, vecX is >> associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, >> which are exactly overlapped with VRs. Instruction APIs receiving VRs use the >> to_vr via vecX. Another thing is the change in sqrtF_reg to enable the >> matching with SqrtVF. I think the change in sqrtF_reg would be fine due to >> the ConvD2FNode::Value in convertnode.cpp. >>> >>> Looks good. Just a few comments: >>> >>> - In vmul4F_reg() would it be reasonable to use xvmulsp instead of >> vmaddfp in >>> order to avoid the splat? >>> >>> - Although all instructions added by your change where introduced in ISA >> 2.06, >>> so POWER7 and above are OK, as I see probes for >> PowerArchictecturePPC64=6|5 in >>> vm_version_ppc.cpp (line 64), I'm wondering if there is any control point >> to >>> guarantee that these instructions won't be emitted on a CPU that does >> not >>> support them. >>> >>> - I think that in general string in format %{} are in upper case. For instance, >>> this the current output on optoassembly for vmul4F: >>> >>> 2941835 5b4 ADDI R24, R24, #64 >>> 2941836 5b8 vmaddfp VSR32,VSR32,VSR36 ! mul packed4F >>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector >>> >>> I think it would be better to be in upper case instead. I also think that if >>> the node match emits more than one instruction all instructions must be >> listed >>> in format %{}, since it's meant for detailed debugging. Finally I think it >>> would be better to replace \t! by \t// in that string (unless I'm missing any >>> special meaning for that char). So for vmul4F it would be something like: >>> >>> 2941835 5b4 ADDI R24, R24, #64 >>> VSPLTISW VSR34, 0 // Splat 0 imm in VSR34 >>> 2941836 5b8 VMADDFP VSR32,VSR32,VSR36,VSR34 // Mul packed4F >>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector >>> >>> >>> But feel free to change anything just after you get additional reviews :) >>> >>> >>> > I confirmed this change with JTREG. In addition, I used attached micro >> benchmarks. >>> > /(See attached file: slp_microbench.zip)/ >>> >>> Thanks for sharing it. >>> Btw, another option to host it would be in the CR >>> server, in http://cr.openjdk.java.net/~mhorie/8208171 >>> >>> >>> Best regards, >>> Gustavo >>> >>> > >>> > Best regards, >>> > -- >>> > Michihiro, >>> > IBM Research - Tokyo >>> > >>> >>> >>> > From erik.osterlund at oracle.com Mon Sep 3 15:27:17 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 3 Sep 2018 17:27:17 +0200 Subject: RFR: 8210236: Prepare ciReceiverTypeData::translate_receiver_data_from for concurrent class unloading In-Reply-To: <37614f02-94d7-b576-5b2b-c50dd4e54e35@oracle.com> References: <37614f02-94d7-b576-5b2b-c50dd4e54e35@oracle.com> Message-ID: <5B8D52D5.6070507@oracle.com> Hi Coleen, Thank you for the review. /Erik On 2018-08-31 15:12, coleen.phillimore at oracle.com wrote: > > This looks good. > Coleen > > On 8/30/18 3:08 PM, Erik ?sterlund wrote: >> Hi, >> >> When concurrently unloading classes, it is possible for MDOs to have >> stale metadata entries in them until the GC comes around to clean it >> up. That is fine, but there is one place where extra care needs to be >> taken: when the compiler interface fetches ReceiverTypeData. This is >> done by memcpy:ing the ReceiverTypeData to a new memory buffer, and >> walking the metadata, patching it with corresponding ci metadata >> classes in the new buffer. The metadata could be stale by now. In >> such scenarios, the rows should be lazily cleaned. Once the ci >> metadata handles are created, they are safe to use in the rest of the >> code. >> >> This patch builds on 8210233 which makes Klass::is_loader_alive() >> concurrency friendly using phantom loads. >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8210236/webrev.00 >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8210236 >> >> Thanks, >> /Erik > From martin.doerr at sap.com Mon Sep 3 17:18:18 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 3 Sep 2018 17:18:18 +0000 Subject: RFR: 8208171: PPC64: Enrich SLP support In-Reply-To: <48ee8bca-fd73-7854-84fd-20b836c00651@linux.vnet.ibm.com> References: <346da54af45243c4bdaf475f118a450d@sap.com> <9553d65d98f74f37a35b49a1e39f015e@sap.com> <48ee8bca-fd73-7854-84fd-20b836c00651@linux.vnet.ibm.com> Message-ID: Hi Gustavo and Michihiro, we noticed jtreg test failures when using this change: compiler/runtime/safepoints/TestRegisterRestoring.java compiler/runtime/Test7196199.java TestRegisterRestoring is a simple test which returns arbitrary results instead of 10000. We didn't see it on all machines, so it might be an issue with saving&restoring VR registers in the signal handler. The machine which I have used has "SUSE Linux Enterprise Server 12 SP3" with kernel 4.4.126-94.22-default. That's what I found out so far. Maybe you have an idea? I also noticed that "-XX:-SuperwordUseVSX" crashes with bad ad file when your patch is applied. Looks like matching the vector nodes needs to be prevented. Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of Gustavo Romero Sent: Montag, 3. September 2018 14:57 To: Lindenmaier, Goetz ; Michihiro Horie Cc: hotspot compiler ; hotspot-dev at openjdk.java.net Subject: Re: RFR: 8208171: PPC64: Enrich SLP support Hi Goetz, On 09/03/2018 09:27 AM, Lindenmaier, Goetz wrote: > Also, I can not find all of the mail traffic in > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/thread.html. > Is this a problem of the pipermail server? > > For some reason this webrev lacks the links to browse the diffs. > Do you need to use a more recent webrev? You can obtain it with > hg clone http://hg.openjdk.java.net/code-tools/webrev/ . Yes, probably it was a problem of the pipermail or in some relay. I noted the same thing, i.e. at least one Michi reply arrived to me but missed a ML. The initial discussion is here: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-July/003613.html I understand Martin reviewed the last webrev in that thread, which is http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ (taken from http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-July/003615.html) Martin's review of webrev.01: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/033958.html and Michi's reply to Martin's review of webrev.01: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-August/003632.html (with webrev.02, taken from http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-August/003632.html). and your last review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-September/030419.html HTH. Best regards, Gustavo > Why do you rename vnoreg to vnoregi? > > Besides that the change is fine, thanks for implementing this! > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Doerr, Martin >> Sent: Dienstag, 28. August 2018 19:35 >> To: Gustavo Romero ; Michihiro Horie >> >> Cc: Lindenmaier, Goetz ; hotspot- >> dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker >> >> Subject: RE: RFR: 8208171: PPC64: Enrich SLP support >> >> Hi Michihiro, >> >> thank you for implementing it. I have just taken a first look at your >> webrev.01. >> >> It looks basically good. Only the Power version check seems to be incorrect. >> VM_Version::has_popcntb() checks for Power5. >> I believe most instructions are available with Power7. >> Some ones (vsubudm, ..., vmmuluwm, vpopcntw) were introduced with >> Power8? >> We should check this carefully. >> >> Also, indentation in register_ppc.hpp could get improved. >> >> Thanks and best regard, >> Martin >> >> >> -----Original Message----- >> From: Gustavo Romero >> Sent: Donnerstag, 26. Juli 2018 16:02 >> To: Michihiro Horie >> Cc: Lindenmaier, Goetz ; hotspot- >> dev at openjdk.java.net; Doerr, Martin ; ppc-aix- >> port-dev at openjdk.java.net; Simonis, Volker >> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >> >> Hi Michi, >> >> On 07/26/2018 01:43 AM, Michihiro Horie wrote: >>> I updated webrev: >>> http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ >> >> Thanks for providing an updated webrev and for fixing indentation and >> function >> order in assembler_ppc.inline.hpp as well. I have no further comments :) >> >> >> Best Regards, >> Gustavo >> >>> >>> Best regards, >>> -- >>> Michihiro, >>> IBM Research - Tokyo >>> >>> Inactive hide details for Gustavo Romero ---2018/07/25 23:05:32---Hi Michi, >> On 07/25/2018 02:43 AM, Michihiro Horie wrote:Gustavo Romero --- >> 2018/07/25 23:05:32---Hi Michi, On 07/25/2018 02:43 AM, Michihiro Horie >> wrote: >>> >>> From: Gustavo Romero >>> To: Michihiro Horie/Japan/IBM at IBMJP, ppc-aix-port- >> dev at openjdk.java.net, hotspot-dev at openjdk.java.net >>> Cc: goetz.lindenmaier at sap.com, volker.simonis at sap.com, "Doerr, Martin" >> >>> Date: 2018/07/25 23:05 >>> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >>> >>> ------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ---------------------------------------------------------------------------------------------- >> ----------------------------------------------------- >>> >>> >>> >>> Hi Michi, >>> >>> On 07/25/2018 02:43 AM, Michihiro Horie wrote: >>> > Dear all, >>> > >>> > Would you review the following change? >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8208171 >>> > Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00 >>> > >>> > This change adds support for vectorized arithmetic calculation with SLP. >>> > >>> > The to_vr function is added to convert VSR to VR. Currently, vecX is >> associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, >> which are exactly overlapped with VRs. Instruction APIs receiving VRs use the >> to_vr via vecX. Another thing is the change in sqrtF_reg to enable the >> matching with SqrtVF. I think the change in sqrtF_reg would be fine due to >> the ConvD2FNode::Value in convertnode.cpp. >>> >>> Looks good. Just a few comments: >>> >>> - In vmul4F_reg() would it be reasonable to use xvmulsp instead of >> vmaddfp in >>> order to avoid the splat? >>> >>> - Although all instructions added by your change where introduced in ISA >> 2.06, >>> so POWER7 and above are OK, as I see probes for >> PowerArchictecturePPC64=6|5 in >>> vm_version_ppc.cpp (line 64), I'm wondering if there is any control point >> to >>> guarantee that these instructions won't be emitted on a CPU that does >> not >>> support them. >>> >>> - I think that in general string in format %{} are in upper case. For instance, >>> this the current output on optoassembly for vmul4F: >>> >>> 2941835 5b4 ADDI R24, R24, #64 >>> 2941836 5b8 vmaddfp VSR32,VSR32,VSR36 ! mul packed4F >>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector >>> >>> I think it would be better to be in upper case instead. I also think that if >>> the node match emits more than one instruction all instructions must be >> listed >>> in format %{}, since it's meant for detailed debugging. Finally I think it >>> would be better to replace \t! by \t// in that string (unless I'm missing any >>> special meaning for that char). So for vmul4F it would be something like: >>> >>> 2941835 5b4 ADDI R24, R24, #64 >>> VSPLTISW VSR34, 0 // Splat 0 imm in VSR34 >>> 2941836 5b8 VMADDFP VSR32,VSR32,VSR36,VSR34 // Mul packed4F >>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector >>> >>> >>> But feel free to change anything just after you get additional reviews :) >>> >>> >>> > I confirmed this change with JTREG. In addition, I used attached micro >> benchmarks. >>> > /(See attached file: slp_microbench.zip)/ >>> >>> Thanks for sharing it. >>> Btw, another option to host it would be in the CR >>> server, in http://cr.openjdk.java.net/~mhorie/8208171 >>> >>> >>> Best regards, >>> Gustavo >>> >>> > >>> > Best regards, >>> > -- >>> > Michihiro, >>> > IBM Research - Tokyo >>> > >>> >>> >>> > From kim.barrett at oracle.com Mon Sep 3 22:06:26 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 3 Sep 2018 18:06:26 -0400 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> Message-ID: > On Sep 3, 2018, at 2:44 AM, David Holmes wrote: > > Hi Kim, > > I know this has been pushed now but if we're going to re-jiggle the Thread hierarchy then we can maybe do better. Thanks for looking anyway. > I never liked the introduction of NamedThread and it seems even more superfluous now - all threads can/should have names, there's really no reason why the WatcherThread or JfrSamplerThread should be special in this regard. NamedThread is described as being for cases where there can be multiple threads of the same class. WatcherThread and JfrSamplerThread can hard-code the name string in the name() implementation. Of course, the same could be said for the VMThread, which *is* a NamedThread. I think the VMThread is a NamedThread because there is some other stuff associated with NamedThread, e.g. the GC id and _processed_thread. There are clearly some oddities in this hierarchy; maybe someone should think about cleaning this up a bit. > Arguably you don't need NonJavaThread as if you don't derive from JavaThread then you are by definition a non-JavaThread - but if this classification makes things easier so be it. NonJavaThread provides a place to hang the iteration over the threads that aren't JavaThreads. So yes, I think it makes this classification easier. If the non-JavaThread list management were in create/destroy wrappers rather than in the constructor and destructor I might feel differently. > IIRC we only use is_Java_thread() due to a lack of RTTI in our C++ usage. Is that likely to change going forward? I don't have any expectation of a change in this area. No, I don't think using a newer language standard and *some* newer (or even existing) features will require such a change. > Meanwhile should is_Java_thread() be pure virtual in Thread and overridden in JavaThread and NonJavaThread ? I tried to make is_JavaThread pure virtual to address Coleen's request to make Thread abstract. That failed because of JDK-8210024. > Cheers, > David > > On 27/08/2018 9:09 AM, Kim Barrett wrote: >> Please review this change to improve the iteration over >> non-JavaThreads. This change introduces a new base class >> NonJavaThread, which should be a base for any Thread class that isn't >> a JavaThread. The recently introduced iteration over NamedThreads >> (JDK-8209850) is moved to this new class. This allows the >> re-implementation of Threads::non_java_threads_do using that list. >> Note: Perhaps CollectedHeap::gc_threads_do could be replaced by a >> Threads::gc_threads_do that is implemented as an iteration over the >> non-JavaThreads with a filter to select GC-related thread types. That >> isn't being done as part of this change though. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8209850 >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8209976/open.00/ >> Testing: >> mach5 tier1-3, hs-tier4-5 in conjunction with a fix for JDK-8209975. >> Local testing of just this change. From kim.barrett at oracle.com Tue Sep 4 01:04:48 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 3 Sep 2018 21:04:48 -0400 Subject: RFR: 8210131: vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code In-Reply-To: <6fdb131a-3701-6875-e435-5bacd4cba3ac@oracle.com> References: <39905239-72B3-46A9-B31E-3B01FA5B9BAB@oracle.com> <6fdb131a-3701-6875-e435-5bacd4cba3ac@oracle.com> Message-ID: <7745AD03-9982-4EE5-AD0C-A2DA809E82AB@oracle.com> > On Sep 3, 2018, at 3:12 AM, David Holmes wrote: > > Hi Kim, > > On 31/08/2018 12:15 PM, Kim Barrett wrote: >> Please review this small change to GetCurrentThreadCpuTimerInfo and >> GetCurrentThreadCpuTime JVMTI operations, allowing them to be called >> from any NamedThread. This is consistent with the behavior from >> JDK-8203948; there is no obvious reason for these operations to have >> any thread context restriction. >> These functions are documented as being callable from heap callbacks >> like ObjectFree, which can be called from an "internal thread or the >> thread that called the [heap] iteration function". However, unlike >> other, similar functions, these two were requiring the current thread >> to be either a JavaThread or the VMThread. For other such functions, >> JDK-6278106 had added Concurrent GC threads, and JDK-8203948 >> generalized that to any NamedThread (or JavaThread). This change >> makes these functions behave similarly. > > As previously discussed** we could just relax the thread constraint completely here. For most JVM TI callbacks the caller must be a JavaThread, but for callbacksafe cases it can nominally be any thread. > > I don't like the fact NamedThread is getting used to imply a capability that is totally unrelated to being named. > > **Though if you saw my initial comment on the bug you'll also realize I can't make up my mind whether to enumerate allowed threads or not. :) NamedThread already has a certain amount of additional protocol, e.g. the GC id and the processed thread (whose purpose I haven't explored). Currently, all NamedThreads except VMThread are specifically GC threads. I think the GC id is probably relevant to the problem at hand, in that only a GC-cognizent thread is going to be making these fairly GC-related callbacks. I won't argue that this is good factoring or naming though. As I said over in the RFR thread for 8209976, this seems like an area that could use some cleanup. I'm not sure where you are thinking that enumeration might be made? Certainly not in the JVMTI spec; it already says "internal thread" and I don't think it should say anything more than that. Maybe you mean in the code? Presently, NamedThread occupies what seems to be the appropriate place. > Cheers, > David > >> This is needed to allow such callbacks to be invoked from a GC worker >> thread, such as is now done for G1 (JDK-8072498), and probably other >> collectors in the future. (See comments for JDK-8203948 for a >> discussion of why ZGC didn't run into this problem.) >> This change also removes the failing test from the problem list. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8210131 >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8210131/open.00/ >> Testing: >> mach5 tier1-3, hs-tier4-6. >> Local (linux-x64) jtreg:hotspot_gc, and manually ran the failing test. >> Examined the generated jvmtiEnter[Trace].cpp file and verified the >> change to the generated code was as expected. From goetz.lindenmaier at sap.com Tue Sep 4 06:12:19 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 4 Sep 2018 06:12:19 +0000 Subject: RFR: 8208171: PPC64: Enrich SLP support In-Reply-To: References: <346da54af45243c4bdaf475f118a450d@sap.com> <9553d65d98f74f37a35b49a1e39f015e@sap.com> <48ee8bca-fd73-7854-84fd-20b836c00651@linux.vnet.ibm.com> Message-ID: <24ecdf108c9c4d77a3a673ecaaca3ab3@sap.com> > > Why do you rename vnoreg to vnoregi? > I followed the way of coding for vsnoreg and vsnoregi, but the renaming > does not look necessary. I would get this part back. Should I also rename > vsnoregi to vsnoreg? I think it would be more consistent, but it's not that important :) Best regards, Goetz. > > > >we noticed jtreg test failures when using this change: > >compiler/runtime/safepoints/TestRegisterRestoring.java > >compiler/runtime/Test7196199.java > > > >TestRegisterRestoring is a simple test which returns arbitrary results instead > of 10000. > > > >We didn't see it on all machines, so it might be an issue with > saving&restoring VR registers in the signal handler. > >The machine which I have used has "SUSE Linux Enterprise Server 12 SP3" > with kernel 4.4.126-94.22-default. > Thank you for letting me know the issue, I will try to reproduce this on a SUSE > machine. > > > >I also noticed that "-XX:-SuperwordUseVSX" crashes with bad ad file when > your patch is applied. Looks like matching the vector nodes needs to be > prevented. > Thank you for pointing out another issue. Currently I do not hit this problem, > but preventing to match the vector nodes makes sense to avoid the crash. I > did not prepare match rules for non-vector nodes, so it might be better to > prepare them similarly like the Replicate* rules, in any case. > > > Gustavo, thanks for the wrap-up! > > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > "Doerr, Martin" ---2018/09/04 02:18:24---Hi Gustavo and Michihiro, we > noticed jtreg test failures when using this change: > > From: "Doerr, Martin" > To: Gustavo Romero , "Lindenmaier, Goetz" > , Michihiro Horie > Cc: hotspot compiler , "hotspot- > dev at openjdk.java.net" > Date: 2018/09/04 02:18 > Subject: RE: RFR: 8208171: PPC64: Enrich SLP support > > ________________________________ > > > > > Hi Gustavo and Michihiro, > > we noticed jtreg test failures when using this change: > compiler/runtime/safepoints/TestRegisterRestoring.java > compiler/runtime/Test7196199.java > > TestRegisterRestoring is a simple test which returns arbitrary results instead > of 10000. > > We didn't see it on all machines, so it might be an issue with saving&restoring > VR registers in the signal handler. > The machine which I have used has "SUSE Linux Enterprise Server 12 SP3" > with kernel 4.4.126-94.22-default. > > That's what I found out so far. Maybe you have an idea? > > I also noticed that "-XX:-SuperwordUseVSX" crashes with bad ad file when > your patch is applied. Looks like matching the vector nodes needs to be > prevented. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of > Gustavo Romero > Sent: Montag, 3. September 2018 14:57 > To: Lindenmaier, Goetz ; Michihiro Horie > > Cc: hotspot compiler ; hotspot- > dev at openjdk.java.net > Subject: Re: RFR: 8208171: PPC64: Enrich SLP support > > Hi Goetz, > > On 09/03/2018 09:27 AM, Lindenmaier, Goetz wrote: > > Also, I can not find all of the mail traffic in > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018- > August/thread.html. > > Is this a problem of the pipermail server? > > > > For some reason this webrev lacks the links to browse the diffs. > > Do you need to use a more recent webrev? You can obtain it with > > hg clone http://hg.openjdk.java.net/code-tools/webrev/ . > > Yes, probably it was a problem of the pipermail or in some relay. > I noted the same thing, i.e. at least one Michi reply arrived > to me but missed a ML. > > The initial discussion is here: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018- > July/003613.html > > I understand Martin reviewed the last webrev in that thread, which is > http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ (taken from > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018- > July/003615.html) > > Martin's review of webrev.01: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018- > August/033958.html > > and Michi's reply to Martin's review of webrev.01: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018- > August/003632.html (with webrev.02, > taken from http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018- > August/003632.html). > > and your last review: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018- > September/030419.html > > > HTH. > > Best regards, > Gustavo > > > Why do you rename vnoreg to vnoregi? > > > > Besides that the change is fine, thanks for implementing this! > > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: Doerr, Martin > >> Sent: Dienstag, 28. August 2018 19:35 > >> To: Gustavo Romero ; Michihiro Horie > >> > >> Cc: Lindenmaier, Goetz ; hotspot- > >> dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, > Volker > >> > >> Subject: RE: RFR: 8208171: PPC64: Enrich SLP support > >> > >> Hi Michihiro, > >> > >> thank you for implementing it. I have just taken a first look at your > >> webrev.01. > >> > >> It looks basically good. Only the Power version check seems to be > incorrect. > >> VM_Version::has_popcntb() checks for Power5. > >> I believe most instructions are available with Power7. > >> Some ones (vsubudm, ..., vmmuluwm, vpopcntw) were introduced with > >> Power8? > >> We should check this carefully. > >> > >> Also, indentation in register_ppc.hpp could get improved. > >> > >> Thanks and best regard, > >> Martin > >> > >> > >> -----Original Message----- > >> From: Gustavo Romero > >> Sent: Donnerstag, 26. Juli 2018 16:02 > >> To: Michihiro Horie > >> Cc: Lindenmaier, Goetz ; hotspot- > >> dev at openjdk.java.net; Doerr, Martin ; ppc-aix- > >> port-dev at openjdk.java.net; Simonis, Volker > >> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support > >> > >> Hi Michi, > >> > >> On 07/26/2018 01:43 AM, Michihiro Horie wrote: > >>> I updated webrev: > >>> http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ > >> > >> Thanks for providing an updated webrev and for fixing indentation and > >> function > >> order in assembler_ppc.inline.hpp as well. I have no further comments :) > >> > >> > >> Best Regards, > >> Gustavo > >> > >>> > >>> Best regards, > >>> -- > >>> Michihiro, > >>> IBM Research - Tokyo > >>> > >>> Inactive hide details for Gustavo Romero ---2018/07/25 23:05:32---Hi > Michi, > >> On 07/25/2018 02:43 AM, Michihiro Horie wrote:Gustavo Romero --- > >> 2018/07/25 23:05:32---Hi Michi, On 07/25/2018 02:43 AM, Michihiro Horie > >> wrote: > >>> > >>> From: Gustavo Romero > >>> To: Michihiro Horie/Japan/IBM at IBMJP, ppc-aix-port- > >> dev at openjdk.java.net, hotspot-dev at openjdk.java.net > >>> Cc: goetz.lindenmaier at sap.com, volker.simonis at sap.com, "Doerr, > Martin" > >> > >>> Date: 2018/07/25 23:05 > >>> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support > >>> > >>> ---------------------------------------------------------------------------------------- > --- > >> ------------------------------------------------------------------------------------------ > ---- > >> ------------------------------------------------------------------------------------------ > ---- > >> ------------------------------------------------------------------------------------------ > ---- > >> ------------------------------------------------------------------------------------------ > ---- > >> ------------------------------------------------------------------------------------------ > ---- > >> ------------------------------------------------------------------------------------------ > ---- > >> ------------------------------------------------------------------------------------------ > ---- > >> ------------------------------------------------------------------------------------------ > ---- > >> ------------------------------------------------------------------------------------------ > ---- > >> ----------------------------------------------------- > >>> > >>> > >>> > >>> Hi Michi, > >>> > >>> On 07/25/2018 02:43 AM, Michihiro Horie wrote: > >>> > Dear all, > >>> > > >>> > Would you review the following change? > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8208171 > >>> > Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00 > >>> > > >>> > This change adds support for vectorized arithmetic calculation with > SLP. > >>> > > >>> > The to_vr function is added to convert VSR to VR. Currently, vecX is > >> associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, > >> which are exactly overlapped with VRs. Instruction APIs receiving VRs use > the > >> to_vr via vecX. Another thing is the change in sqrtF_reg to enable the > >> matching with SqrtVF. I think the change in sqrtF_reg would be fine due > to > >> the ConvD2FNode::Value in convertnode.cpp. > >>> > >>> Looks good. Just a few comments: > >>> > >>> - In vmul4F_reg() would it be reasonable to use xvmulsp instead of > >> vmaddfp in > >>> order to avoid the splat? > >>> > >>> - Although all instructions added by your change where introduced in ISA > >> 2.06, > >>> so POWER7 and above are OK, as I see probes for > >> PowerArchictecturePPC64=6|5 in > >>> vm_version_ppc.cpp (line 64), I'm wondering if there is any control > point > >> to > >>> guarantee that these instructions won't be emitted on a CPU that does > >> not > >>> support them. > >>> > >>> - I think that in general string in format %{} are in upper case. For > instance, > >>> this the current output on optoassembly for vmul4F: > >>> > >>> 2941835 5b4 ADDI R24, R24, #64 > >>> 2941836 5b8 vmaddfp VSR32,VSR32,VSR36 ! mul packed4F > >>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector > >>> > >>> I think it would be better to be in upper case instead. I also think that if > >>> the node match emits more than one instruction all instructions must > be > >> listed > >>> in format %{}, since it's meant for detailed debugging. Finally I think it > >>> would be better to replace \t! by \t// in that string (unless I'm missing > any > >>> special meaning for that char). So for vmul4F it would be something > like: > >>> > >>> 2941835 5b4 ADDI R24, R24, #64 > >>> VSPLTISW VSR34, 0 // Splat 0 imm in VSR34 > >>> 2941836 5b8 VMADDFP VSR32,VSR32,VSR36,VSR34 // Mul packed4F > >>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector > >>> > >>> > >>> But feel free to change anything just after you get additional reviews :) > >>> > >>> > >>> > I confirmed this change with JTREG. In addition, I used attached micro > >> benchmarks. > >>> > /(See attached file: slp_microbench.zip)/ > >>> > >>> Thanks for sharing it. > >>> Btw, another option to host it would be in the CR > >>> server, in http://cr.openjdk.java.net/~mhorie/8208171 > >>> > >>> > >>> Best regards, > >>> Gustavo > >>> > >>> > > >>> > Best regards, > >>> > -- > >>> > Michihiro, > >>> > IBM Research - Tokyo > >>> > > >>> > >>> > >>> > > > > > > > From erik.osterlund at oracle.com Tue Sep 4 08:42:14 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 4 Sep 2018 10:42:14 +0200 Subject: RFR: 8210330: Make CLD claiming allow multiple claim bits Message-ID: <5B8E4566.1020203@oracle.com> Hi, Today, the claim value of a CLD is logically a boolean, stored as an int. Either a CLD is claimed, or not claimed. This is used by the GC to see if oops_do can be skipped on the CLD, because its handles have already been marked. With ZGC supporting concurrent class unloading, the CLD holder can be marked finalizably reachable first, and afterwards strongly reachable. This requires 2 claim bits in the CLD: one for claiming it for strong marking of the oop handles, and one for finalizable marking. Rather than making a separate mechanism for ZGC only, I would like to use these shared claim bits. I think this is a fascility that anyone who has concurrent reference processing and concurrent class unloading will need, it just happens to be that ZGC is the first GC to do that in hotspot. I also have the hypothesis that this can be beneficial for other uses such as the JFR leak profiler, which can have its own claim bits, instead of clearing the claim bit, doing its thing, and then restoring the claim bit to what it was before. As part of this change, I changed the "must_claim" boolean that is passed around to instead take an int for the desired claim value, and made it explicit and not implicit. Webrev: http://cr.openjdk.java.net/~eosterlund/8210330/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210330 Thanks, /Erik From coleen.phillimore at oracle.com Tue Sep 4 12:29:01 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 4 Sep 2018 08:29:01 -0400 Subject: RFR: 8210330: Make CLD claiming allow multiple claim bits In-Reply-To: <5B8E4566.1020203@oracle.com> References: <5B8E4566.1020203@oracle.com> Message-ID: This change looks good to me. Coleen On 9/4/18 4:42 AM, Erik ?sterlund wrote: > Hi, > > Today, the claim value of a CLD is logically a boolean, stored as an > int. Either a CLD is claimed, or not claimed. This is used by the GC > to see if oops_do can be skipped on the CLD, because its handles have > already been marked. > With ZGC supporting concurrent class unloading, the CLD holder can be > marked finalizably reachable first, and afterwards strongly reachable. > This requires 2 claim bits in the CLD: one for claiming it for strong > marking of the oop handles, and one for finalizable marking. > > Rather than making a separate mechanism for ZGC only, I would like to > use these shared claim bits. I think this is a fascility that anyone > who has concurrent reference processing and concurrent class unloading > will need, it just happens to be that ZGC is the first GC to do that > in hotspot. I also have the hypothesis that this can be beneficial for > other uses such as the JFR leak profiler, which can have its own claim > bits, instead of clearing the claim bit, doing its thing, and then > restoring the claim bit to what it was before. > > As part of this change, I changed the "must_claim" boolean that is > passed around to instead take an int for the desired claim value, and > made it explicit and not implicit. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8210330/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8210330 > > Thanks, > /Erik From glaubitz at physik.fu-berlin.de Tue Sep 4 12:51:28 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 4 Sep 2018 14:51:28 +0200 Subject: hg defpath needs updating Message-ID: Hi! I just tried to submit a change to the submit repository but defpath is failing on me. I did actually just update my local defpath copy, but I am still getting: glaubitz at z6:..incoming/submit> hg defpath -du glaubitz ** Unknown exception encountered with possibly-broken third-party extension jcheck ** which supports versions unknown of Mercurial. ** Please disable jcheck and try your action again. ** If that fixes the bug please report it to the extension author. ** Python 2.7.15+ (default, Aug 31 2018, 11:56:52) [GCC 8.2.0] ** Mercurial Distributed SCM (version 4.7) ** Extensions loaded: strip, mq, histedit, purge, jcheck, defpath Traceback (most recent call last): File "/usr/bin/hg", line 41, in dispatch.run() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 90, in run status = dispatch(req) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 213, in dispatch ret = _runcatch(req) or 0 File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 354, in _runcatch return _callcatch(ui, _runcatchfunc) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 362, in _callcatch return scmutil.callcatch(ui, func) File "/usr/lib/python2.7/dist-packages/mercurial/scmutil.py", line 161, in callcatch return func() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 344, in _runcatchfunc return _dispatch(req) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 984, in _dispatch cmdpats, cmdoptions) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 730, in runcommand ret = _runcommand(ui, options, cmd, d) File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 992, in _runcommand return cmdfunc() File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 981, in d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1530, in check return func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1530, in check return func(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/hgext/mq.py", line 3600, in mqcommand return orig(ui, repo, *args, **kwargs) File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1530, in check return func(*args, **kwargs) File "/home/glaubitz/upstream/defpath/defpath.py", line 359, in cmd_defpath return defpath(ui, repo, peer, peer_push, walk_self, opts) File "/home/glaubitz/upstream/defpath/defpath.py", line 292, in defpath except util.Abort, x: AttributeError: 'module' object has no attribute 'Abort' I assume that some classes and functions were moved around in the imported Python libraries again. 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 Sep 4 13:35:17 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 4 Sep 2018 15:35:17 +0200 Subject: Hotspot currently not building on tip Message-ID: Hi! I just tried building Hotspot to test my patch for 8165440 (Add zero support for x86_64-linux-gnux32 target) which failed because of an unrelated problem: === Output from failing command(s) repeated here === /usr/bin/printf "* For target jdk_modules_java.base__the.java.base_batch:\n" * For target jdk_modules_java.base__the.java.base_batch: (/bin/grep -v -e "^Note: including file:" < /data/incoming/jdk/build/linux-x86_64-normal-server-release/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log || true) | /usr/bin/head -n 12 /data/incoming/jdk/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java:287: error: incompatible types: CertStatusRequest cannot be converted to OCSPStatusRequest OCSPStatusRequest ocspReq = (OCSPStatusRequest)request; ^ /data/incoming/jdk/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java:308: error: incompatible types: CertStatusRequest cannot be converted to OCSPStatusRequest OCSPStatusRequest ocspReq = (OCSPStatusRequest)request; ^ /data/incoming/jdk/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java:396: error: extensions has private access in OCSPStatusRequest for (Extension ext : ocspRequest.extensions) { ^ /data/incoming/jdk/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java:601: error: extensions has private access in OCSPStatusRequest extensions = ocspRequest.extensions; ^ if test `/usr/bin/wc -l < /data/incoming/jdk/build/linux-x86_64-normal-server-release/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "\n* All command lines available in /data/incoming/jdk/build/linux-x86_64-normal-server-release/make-support/failure-logs.\n" * All command lines available in /data/incoming/jdk/build/linux-x86_64-normal-server-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === Is this being worked on? Sorry, if this has already been discussed here, I'm out of the loop regarding the current discussion. 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 Tue Sep 4 14:45:11 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 4 Sep 2018 16:45:11 +0200 Subject: RFR: 8210330: Make CLD claiming allow multiple claim bits In-Reply-To: References: <5B8E4566.1020203@oracle.com> Message-ID: <5B8E9A77.9040605@oracle.com> Hi Coleen, Thank you for the review. Per wanted the following naming change: claim_value -> claim, claim() -> try_claim(). And the strong_claim to be 3 instead of 1, so that one does not accidentally set the wrong value when using it from ZGC (strong claimed always implies final claimed too). Hope you are also okay with that. Incremental: http://cr.openjdk.java.net/~eosterlund/8210330/webrev.00_01/ Full: http://cr.openjdk.java.net/~eosterlund/8210330/webrev.01/ Thanks, /Erik On 2018-09-04 14:29, coleen.phillimore at oracle.com wrote: > > This change looks good to me. > Coleen > > On 9/4/18 4:42 AM, Erik ?sterlund wrote: >> Hi, >> >> Today, the claim value of a CLD is logically a boolean, stored as an >> int. Either a CLD is claimed, or not claimed. This is used by the GC >> to see if oops_do can be skipped on the CLD, because its handles have >> already been marked. >> With ZGC supporting concurrent class unloading, the CLD holder can be >> marked finalizably reachable first, and afterwards strongly >> reachable. This requires 2 claim bits in the CLD: one for claiming it >> for strong marking of the oop handles, and one for finalizable marking. >> >> Rather than making a separate mechanism for ZGC only, I would like to >> use these shared claim bits. I think this is a fascility that anyone >> who has concurrent reference processing and concurrent class >> unloading will need, it just happens to be that ZGC is the first GC >> to do that in hotspot. I also have the hypothesis that this can be >> beneficial for other uses such as the JFR leak profiler, which can >> have its own claim bits, instead of clearing the claim bit, doing its >> thing, and then restoring the claim bit to what it was before. >> >> As part of this change, I changed the "must_claim" boolean that is >> passed around to instead take an int for the desired claim value, and >> made it explicit and not implicit. >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8210330/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8210330 >> >> Thanks, >> /Erik > From per.liden at oracle.com Tue Sep 4 14:50:23 2018 From: per.liden at oracle.com (Per Liden) Date: Tue, 4 Sep 2018 16:50:23 +0200 Subject: RFR: 8210330: Make CLD claiming allow multiple claim bits In-Reply-To: <5B8E9A77.9040605@oracle.com> References: <5B8E4566.1020203@oracle.com> <5B8E9A77.9040605@oracle.com> Message-ID: <94e92330-78c9-16e2-8ae2-86a4d72d0cda@oracle.com> Hi Erik, On 09/04/2018 04:45 PM, Erik ?sterlund wrote: > Hi Coleen, > > Thank you for the review. > > Per wanted the following naming change: claim_value -> claim, claim() -> > try_claim(). And the strong_claim to be 3 instead of 1, so that one does > not accidentally set the wrong value when using it from ZGC (strong > claimed always implies final claimed too). Hope you are also okay with > that. Thanks for adjusting that. > > Incremental: > http://cr.openjdk.java.net/~eosterlund/8210330/webrev.00_01/ > > Full: > http://cr.openjdk.java.net/~eosterlund/8210330/webrev.01/ Looks good to me! /Per > > Thanks, > /Erik > > On 2018-09-04 14:29, coleen.phillimore at oracle.com wrote: >> >> This change looks good to me. >> Coleen >> >> On 9/4/18 4:42 AM, Erik ?sterlund wrote: >>> Hi, >>> >>> Today, the claim value of a CLD is logically a boolean, stored as an >>> int. Either a CLD is claimed, or not claimed. This is used by the GC >>> to see if oops_do can be skipped on the CLD, because its handles have >>> already been marked. >>> With ZGC supporting concurrent class unloading, the CLD holder can be >>> marked finalizably reachable first, and afterwards strongly >>> reachable. This requires 2 claim bits in the CLD: one for claiming it >>> for strong marking of the oop handles, and one for finalizable marking. >>> >>> Rather than making a separate mechanism for ZGC only, I would like to >>> use these shared claim bits. I think this is a fascility that anyone >>> who has concurrent reference processing and concurrent class >>> unloading will need, it just happens to be that ZGC is the first GC >>> to do that in hotspot. I also have the hypothesis that this can be >>> beneficial for other uses such as the JFR leak profiler, which can >>> have its own claim bits, instead of clearing the claim bit, doing its >>> thing, and then restoring the claim bit to what it was before. >>> >>> As part of this change, I changed the "must_claim" boolean that is >>> passed around to instead take an int for the desired claim value, and >>> made it explicit and not implicit. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8210330/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8210330 >>> >>> Thanks, >>> /Erik >> > From erik.osterlund at oracle.com Tue Sep 4 14:54:16 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 4 Sep 2018 16:54:16 +0200 Subject: RFR: 8210330: Make CLD claiming allow multiple claim bits In-Reply-To: <94e92330-78c9-16e2-8ae2-86a4d72d0cda@oracle.com> References: <5B8E4566.1020203@oracle.com> <5B8E9A77.9040605@oracle.com> <94e92330-78c9-16e2-8ae2-86a4d72d0cda@oracle.com> Message-ID: <5B8E9C98.4010507@oracle.com> Hi Per, Thanks for the review! /Erik On 2018-09-04 16:50, Per Liden wrote: > Hi Erik, > > On 09/04/2018 04:45 PM, Erik ?sterlund wrote: >> Hi Coleen, >> >> Thank you for the review. >> >> Per wanted the following naming change: claim_value -> claim, claim() >> -> try_claim(). And the strong_claim to be 3 instead of 1, so that >> one does not accidentally set the wrong value when using it from ZGC >> (strong claimed always implies final claimed too). Hope you are also >> okay with that. > > Thanks for adjusting that. > >> >> Incremental: >> http://cr.openjdk.java.net/~eosterlund/8210330/webrev.00_01/ >> >> Full: >> http://cr.openjdk.java.net/~eosterlund/8210330/webrev.01/ > > Looks good to me! > > /Per > >> >> Thanks, >> /Erik >> >> On 2018-09-04 14:29, coleen.phillimore at oracle.com wrote: >>> >>> This change looks good to me. >>> Coleen >>> >>> On 9/4/18 4:42 AM, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> Today, the claim value of a CLD is logically a boolean, stored as >>>> an int. Either a CLD is claimed, or not claimed. This is used by >>>> the GC to see if oops_do can be skipped on the CLD, because its >>>> handles have already been marked. >>>> With ZGC supporting concurrent class unloading, the CLD holder can >>>> be marked finalizably reachable first, and afterwards strongly >>>> reachable. This requires 2 claim bits in the CLD: one for claiming >>>> it for strong marking of the oop handles, and one for finalizable >>>> marking. >>>> >>>> Rather than making a separate mechanism for ZGC only, I would like >>>> to use these shared claim bits. I think this is a fascility that >>>> anyone who has concurrent reference processing and concurrent class >>>> unloading will need, it just happens to be that ZGC is the first GC >>>> to do that in hotspot. I also have the hypothesis that this can be >>>> beneficial for other uses such as the JFR leak profiler, which can >>>> have its own claim bits, instead of clearing the claim bit, doing >>>> its thing, and then restoring the claim bit to what it was before. >>>> >>>> As part of this change, I changed the "must_claim" boolean that is >>>> passed around to instead take an int for the desired claim value, >>>> and made it explicit and not implicit. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8210330/webrev.00/ >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8210330 >>>> >>>> Thanks, >>>> /Erik >>> >> From sgehwolf at redhat.com Tue Sep 4 15:36:45 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 04 Sep 2018 17:36:45 +0200 Subject: [8u] RFR: 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization Message-ID: <6098243100d4f92ade36dc2c2748c8d62d80bf69.camel@redhat.com> Hi, Could I please get reviews of this JDK 8-only change? The issue at hand is that the JDK 8 build seems to be inconsistent with later JDK builds (9+). When somebody passes --with-extra-c{,xx}-flags="-O2" to the OpenJDK build on JDK 9+ the JVM will get compiled with -O3 for a release type build. Not so on JDK 8. It gets compiled with -O2. The reason we are passing extra C flags via configure is to: a) get distro-wide optimization done b) allow for hardened builds. Without the --with-extra-c{,xx}-flags="-O2" flag, libjsig, libsaproc will get compiled with no optimization. That's what I'd like to fix. The proposed patch allows one to force -O2 for the JVM via OPT_EXTRAS make variable if so desired. Omitting OPT_EXTRAS=-O2 allows one to get hotspot libraries optimized with -O2 and better. Thoughts? Bug: https://bugs.openjdk.java.net/browse/JDK-8210352 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/ Thanks, Severin From erik.joelsson at oracle.com Tue Sep 4 15:49:52 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Sep 2018 08:49:52 -0700 Subject: RFR: JDK-6657100 Rename sparcWorks to solstudio in HotSpot In-Reply-To: <20a1b3c0-066c-401c-3b12-db2f06d6b671@oracle.com> References: <4bd22bee-8d4c-8a1d-441b-03207355380c@oracle.com> <20a1b3c0-066c-401c-3b12-db2f06d6b671@oracle.com> Message-ID: On 2018-09-03 00:19, David Holmes wrote: > On 30/08/2018 10:36 PM, Magnus Ihse Bursie wrote: >> Hi folks, >> >> This bug report goes all the way back to 2008. :-) So instead of just >> letting it go on to it's second decade of existence, I went about and >> fixed it. > > Ummm but now it's called Oracle Developer Studio. > Yes, we are aware of that, so ideally we should rename it all over. This bug was about unification however, and now it's at least unified. One could also note that the version we are currently using (12.4) was still called Solaris Studio. The rename happened in later versions. /Erik > David > >> By now, not many references to sparcWorks exists anymore, so this is >> almost trivial. >> >> I've verified by grep that no more "sparcworks" are present in the >> repo, neither in hotspot nor anywhere else. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-6657100 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-6657100-rename-sparcWorks-to-solstudio/webrev.01 >> >> >> /Magnus From glaubitz at physik.fu-berlin.de Tue Sep 4 17:45:04 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Tue, 4 Sep 2018 19:45:04 +0200 Subject: RFR: 8165440: Add zero support for x86_64-linux-gnux32 target Message-ID: Hi! This rather small change adds build support for the x86_64-linux-gnux32 target. x32 is a variant of the x86_64 ABI with 64-bit registers and amd64 instruction set but 32-bit pointers [1]. One of the Linux distributions supporting x32 is Debian, see [2]. The port is not official, but the large majority of packages build fine and the toolchain is in good shape. Another distribution supporting x32 is Gentoo. Please review the change in [3]. I have changed the original patch a bit that Debian uses downstream to make the changes more consistent and cleaner. Thanks, Adrian > [1] https://en.wikipedia.org/wiki/X32_ABI > [2] http://debian-x32.org/ > [2] http://cr.openjdk.java.net/~glaubitz/8165440/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.joelsson at oracle.com Tue Sep 4 17:48:36 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Sep 2018 10:48:36 -0700 Subject: [8u] RFR: 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization In-Reply-To: <6098243100d4f92ade36dc2c2748c8d62d80bf69.camel@redhat.com> References: <6098243100d4f92ade36dc2c2748c8d62d80bf69.camel@redhat.com> Message-ID: <2bb1df86-9abc-770a-1b4b-1ff3b7a1fc93@oracle.com> Hello, I understand your problem, but I'm really not sure I like this solution. What I mostly question is your desire for adding optimization to the libraries nobody has bothered adding optimizations on by default since forever. If this is important to you, then provide a patch adding opt flags to the specific libraries. In general, the OpenJDK build is very conscious about what optimization levels are used wherever it matters, so tinkering with them is likely not a good idea. That said, I think a better fix would be to reorder the arguments so that the OPT flags are added after any extra flags variable. /Erik On 2018-09-04 08:36, Severin Gehwolf wrote: > Hi, > > Could I please get reviews of this JDK 8-only change? > > The issue at hand is that the JDK 8 build seems to be inconsistent with > later JDK builds (9+). When somebody passes > --with-extra-c{,xx}-flags="-O2" to the OpenJDK build on JDK 9+ the JVM > will get compiled with -O3 for a release type build. Not so on JDK 8. > It gets compiled with -O2. The reason we are passing extra C flags via > configure is to: a) get distro-wide optimization done b) allow for > hardened builds. Without the --with-extra-c{,xx}-flags="-O2" flag, > libjsig, libsaproc will get compiled with no optimization. That's what > I'd like to fix. The proposed patch allows one to force -O2 for the JVM > via OPT_EXTRAS make variable if so desired. Omitting OPT_EXTRAS=-O2 > allows one to get hotspot libraries optimized with -O2 and better. > Thoughts? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210352 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/ > > Thanks, > Severin > From mikael.vidstedt at oracle.com Tue Sep 4 19:36:23 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 4 Sep 2018 12:36:23 -0700 Subject: RFR(S): 8210381: Obsolete EmitSync Message-ID: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ * Background (from bug) The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. Cheers, Mikael From vladimir.kozlov at oracle.com Tue Sep 4 19:53:15 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 4 Sep 2018 12:53:15 -0700 Subject: RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> Message-ID: <7eead06f-88da-9482-ada2-9916157652a3@oracle.com> Looks good. What testing you did? Thanks, Vladimir On 9/4/18 12:36 PM, Mikael Vidstedt wrote: > > Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ > > * Background (from bug) > > The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. > > In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Tue Sep 4 20:04:33 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 4 Sep 2018 13:04:33 -0700 Subject: RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <7eead06f-88da-9482-ada2-9916157652a3@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> <7eead06f-88da-9482-ada2-9916157652a3@oracle.com> Message-ID: <21603636-33D2-4E30-89BB-36B7FD5FE1BD@oracle.com> My tier1 build & test job passed. I?ll also try to spend a few minutes seeing if I can verify that the resulting code actually ends up being the same. Cheers, Mikael > On Sep 4, 2018, at 12:53 PM, Vladimir Kozlov wrote: > > Looks good. > > What testing you did? > > Thanks, > Vladimir > > On 9/4/18 12:36 PM, Mikael Vidstedt wrote: >> Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ >> * Background (from bug) >> The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. >> In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. >> Cheers, >> Mikael From jcbeyler at google.com Tue Sep 4 20:28:07 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 4 Sep 2018 13:28:07 -0700 Subject: hg defpath needs updating In-Reply-To: References: Message-ID: Hi John, I had the same issue and the problem was that my mercurial being used was of a too recent version to work. Tim opened: https://bugs.openjdk.java.net/browse/CODETOOLS-7902292 to track it and he has a possible fix that was done for trees.py in the bug. Thanks, Jc On Tue, Sep 4, 2018 at 5:52 AM John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Hi! > > I just tried to submit a change to the submit repository but defpath > is failing on me. I did actually just update my local defpath copy, > but I am still getting: > > glaubitz at z6:..incoming/submit> hg defpath -du glaubitz > ** Unknown exception encountered with possibly-broken third-party > extension jcheck > ** which supports versions unknown of Mercurial. > ** Please disable jcheck and try your action again. > ** If that fixes the bug please report it to the extension author. > ** Python 2.7.15+ (default, Aug 31 2018, 11:56:52) [GCC 8.2.0] > ** Mercurial Distributed SCM (version 4.7) > ** Extensions loaded: strip, mq, histedit, purge, jcheck, defpath > Traceback (most recent call last): > File "/usr/bin/hg", line 41, in > dispatch.run() > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 90, > in run > status = dispatch(req) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 213, > in dispatch > ret = _runcatch(req) or 0 > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 354, > in _runcatch > return _callcatch(ui, _runcatchfunc) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 362, > in _callcatch > return scmutil.callcatch(ui, func) > File "/usr/lib/python2.7/dist-packages/mercurial/scmutil.py", line 161, > in callcatch > return func() > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 344, > in _runcatchfunc > return _dispatch(req) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 984, > in _dispatch > cmdpats, cmdoptions) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 730, > in runcommand > ret = _runcommand(ui, options, cmd, d) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 992, > in _runcommand > return cmdfunc() > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 981, > in > d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) > File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1530, in > check > return func(*args, **kwargs) > File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1530, in > check > return func(*args, **kwargs) > File "/usr/lib/python2.7/dist-packages/hgext/mq.py", line 3600, in > mqcommand > return orig(ui, repo, *args, **kwargs) > File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1530, in > check > return func(*args, **kwargs) > File "/home/glaubitz/upstream/defpath/defpath.py", line 359, in > cmd_defpath > return defpath(ui, repo, peer, peer_push, walk_self, opts) > File "/home/glaubitz/upstream/defpath/defpath.py", line 292, in defpath > except util.Abort, x: > AttributeError: 'module' object has no attribute 'Abort' > > I assume that some classes and functions were moved around in the imported > Python libraries again. > > 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 > -- Thanks, Jc From daniel.daugherty at oracle.com Tue Sep 4 20:40:10 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 4 Sep 2018 16:40:10 -0400 Subject: RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> Message-ID: <7a041851-cdb8-9857-7fa3-1b23381478ac@oracle.com> On 9/4/18 3:36 PM, Mikael Vidstedt wrote: > Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ src/hotspot/cpu/aarch64/aarch64.ad ??? No comments. src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ??? No comments. src/hotspot/cpu/s390/macroAssembler_s390.cpp ??? No comments. src/hotspot/cpu/sparc/macroAssembler_sparc.cpp ??? No comments. src/hotspot/cpu/x86/macroAssembler_x86.cpp ??? No comments. src/hotspot/share/runtime/arguments.cpp ??? No comments. src/hotspot/share/runtime/globals.hpp ??? No comments. General comments: ? - The 'if (EmitSync & 0x01) {' checks are how we disable the ??? use of compiled code for monitors. We use -XX:EmitSync=1 ??? to diagnose things when we wonder if the compiled monitor ??? code is broken. ? - The 'if (EmitSync & 4)' checks are how we disable the use ??? of compiled code for unlocking of monitors; we still use ??? compiled code for locking of monitors. We use -XX:EmitSync=4 ??? to diagnose things when we wonder if the compiled monitor ??? unlock code is broken. ? - BTW, I think s390 is using (EmitSync & 0x01) differently ??? than other platforms. No, I didn't try to figure out exactly ??? how s390 was using that option. This looks like a clean obsoletion of the '-XX:EmitSync=' option so thumbs up from that POV. Use of '-XX:EmitSync=1' for diagnostic purposes is probably limited to a handful of people including me. Use of the '-XX:EmitSync=4' is probably even more rare; I can't remember using it myself. So while I have used the '-XX:EmitSync=' option to debug Java monitor stuff, it has been a long time time... Dan > > * Background (from bug) > > The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. > > In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. > > Cheers, > Mikael > > From david.holmes at oracle.com Tue Sep 4 21:06:51 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Sep 2018 07:06:51 +1000 Subject: [8u] RFR: 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization In-Reply-To: <6098243100d4f92ade36dc2c2748c8d62d80bf69.camel@redhat.com> References: <6098243100d4f92ade36dc2c2748c8d62d80bf69.camel@redhat.com> Message-ID: Hi Severin, On 5/09/2018 1:36 AM, Severin Gehwolf wrote: > Hi, > > Could I please get reviews of this JDK 8-only change? > > The issue at hand is that the JDK 8 build seems to be inconsistent with > later JDK builds (9+). When somebody passes > --with-extra-c{,xx}-flags="-O2" to the OpenJDK build on JDK 9+ the JVM > will get compiled with -O3 for a release type build. Not so on JDK 8. > It gets compiled with -O2. The reason we are passing extra C flags via > configure is to: a) get distro-wide optimization done b) allow for > hardened builds. Without the --with-extra-c{,xx}-flags="-O2" flag, > libjsig, libsaproc will get compiled with no optimization. That's what > I'd like to fix. The proposed patch allows one to force -O2 for the JVM > via OPT_EXTRAS make variable if so desired. Omitting OPT_EXTRAS=-O2 > allows one to get hotspot libraries optimized with -O2 and better. > Thoughts? I don't understand the motivation for this change. Compatibility with future versions is not a usual compatibility we care about. I'd also argue the behaviour in 8 seems more correct. If I set an extra cflag I expect it to be applied to all compilations - cross-compilation would be broken if that were not the case. I don't see why -On should be treated any differently. David > Bug: https://bugs.openjdk.java.net/browse/JDK-8210352 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/ > > Thanks, > Severin > From david.holmes at oracle.com Tue Sep 4 21:13:39 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Sep 2018 07:13:39 +1000 Subject: hg defpath needs updating In-Reply-To: References: Message-ID: <3909890d-aac6-38e1-5b84-1543c6c41a39@oracle.com> Not a hotspot issue in any case. Please direct such issues to ops at openjdk.java.net Cheers, David On 4/09/2018 10:51 PM, John Paul Adrian Glaubitz wrote: > Hi! > > I just tried to submit a change to the submit repository but defpath > is failing on me. I did actually just update my local defpath copy, > but I am still getting: > > glaubitz at z6:..incoming/submit> hg defpath -du glaubitz > ** Unknown exception encountered with possibly-broken third-party extension jcheck > ** which supports versions unknown of Mercurial. > ** Please disable jcheck and try your action again. > ** If that fixes the bug please report it to the extension author. > ** Python 2.7.15+ (default, Aug 31 2018, 11:56:52) [GCC 8.2.0] > ** Mercurial Distributed SCM (version 4.7) > ** Extensions loaded: strip, mq, histedit, purge, jcheck, defpath > Traceback (most recent call last): > File "/usr/bin/hg", line 41, in > dispatch.run() > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 90, in run > status = dispatch(req) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 213, in dispatch > ret = _runcatch(req) or 0 > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 354, in _runcatch > return _callcatch(ui, _runcatchfunc) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 362, in _callcatch > return scmutil.callcatch(ui, func) > File "/usr/lib/python2.7/dist-packages/mercurial/scmutil.py", line 161, in callcatch > return func() > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 344, in _runcatchfunc > return _dispatch(req) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 984, in _dispatch > cmdpats, cmdoptions) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 730, in runcommand > ret = _runcommand(ui, options, cmd, d) > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 992, in _runcommand > return cmdfunc() > File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 981, in > d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) > File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1530, in check > return func(*args, **kwargs) > File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1530, in check > return func(*args, **kwargs) > File "/usr/lib/python2.7/dist-packages/hgext/mq.py", line 3600, in mqcommand > return orig(ui, repo, *args, **kwargs) > File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1530, in check > return func(*args, **kwargs) > File "/home/glaubitz/upstream/defpath/defpath.py", line 359, in cmd_defpath > return defpath(ui, repo, peer, peer_push, walk_self, opts) > File "/home/glaubitz/upstream/defpath/defpath.py", line 292, in defpath > except util.Abort, x: > AttributeError: 'module' object has no attribute 'Abort' > > I assume that some classes and functions were moved around in the imported > Python libraries again. > > Adrian > From david.holmes at oracle.com Tue Sep 4 21:19:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Sep 2018 07:19:32 +1000 Subject: Hotspot currently not building on tip In-Reply-To: References: Message-ID: <3a9beede-d362-6ea3-dee8-5ab3e3dc84c1@oracle.com> Hi Adrian, This isn't an issue with building hotspot. I can't see reports of this anywhere else either, but could be OpenJDK specific (rather than Oracle JDK). All I can suggest is ensuring repos have updated properly and that a fully clean build is attempted. If it persists I suggest emailing security-dev. Cheers, David On 4/09/2018 11:35 PM, John Paul Adrian Glaubitz wrote: > Hi! > > I just tried building Hotspot to test my patch for 8165440 > (Add zero support for x86_64-linux-gnux32 target) which failed > because of an unrelated problem: > > === Output from failing command(s) repeated here === > /usr/bin/printf "* For target jdk_modules_java.base__the.java.base_batch:\n" > * For target jdk_modules_java.base__the.java.base_batch: > (/bin/grep -v -e "^Note: including file:" < /data/incoming/jdk/build/linux-x86_64-normal-server-release/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log || true) | /usr/bin/head -n 12 > /data/incoming/jdk/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java:287: error: incompatible types: CertStatusRequest cannot be converted to OCSPStatusRequest > OCSPStatusRequest ocspReq = (OCSPStatusRequest)request; > ^ > /data/incoming/jdk/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java:308: error: incompatible types: CertStatusRequest cannot be converted to OCSPStatusRequest > OCSPStatusRequest ocspReq = (OCSPStatusRequest)request; > ^ > /data/incoming/jdk/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java:396: error: extensions has private access in OCSPStatusRequest > for (Extension ext : ocspRequest.extensions) { > ^ > /data/incoming/jdk/src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java:601: error: extensions has private access in OCSPStatusRequest > extensions = ocspRequest.extensions; > ^ > if test `/usr/bin/wc -l < /data/incoming/jdk/build/linux-x86_64-normal-server-release/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi > ... (rest of output omitted) > /usr/bin/printf "\n* All command lines available in /data/incoming/jdk/build/linux-x86_64-normal-server-release/make-support/failure-logs.\n" > > * All command lines available in /data/incoming/jdk/build/linux-x86_64-normal-server-release/make-support/failure-logs. > /usr/bin/printf "=== End of repeated output ===\n" > === End of repeated output === > > Is this being worked on? Sorry, if this has already been discussed here, I'm > out of the loop regarding the current discussion. > > Adrian > From david.holmes at oracle.com Tue Sep 4 21:29:06 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Sep 2018 07:29:06 +1000 Subject: RFR: 8165440: Add zero support for x86_64-linux-gnux32 target In-Reply-To: References: Message-ID: <147a5ffd-5eac-244d-60a7-bc8a0b8d5005@oracle.com> Hi Adrian, All changes that touch the build system must be reviewed by build-dev - now cc'd. These changes seem reasonable, though I don't like adding changes in source code for such an obscure (and unsupported!) platform. David On 5/09/2018 3:45 AM, John Paul Adrian Glaubitz wrote: > Hi! > > This rather small change adds build support for the x86_64-linux-gnux32 > target. x32 is a variant of the x86_64 ABI with 64-bit registers and amd64 > instruction set but 32-bit pointers [1]. > > One of the Linux distributions supporting x32 is Debian, see [2]. The > port is not official, but the large majority of packages build fine > and the toolchain is in good shape. Another distribution supporting > x32 is Gentoo. > > Please review the change in [3]. I have changed the original patch > a bit that Debian uses downstream to make the changes more consistent > and cleaner. > > Thanks, > Adrian > >> [1] https://en.wikipedia.org/wiki/X32_ABI >> [2] http://debian-x32.org/ >> [2] http://cr.openjdk.java.net/~glaubitz/8165440/webrev.00/ > From erik.joelsson at oracle.com Tue Sep 4 21:29:20 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Sep 2018 14:29:20 -0700 Subject: [8u] RFR: 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization In-Reply-To: References: <6098243100d4f92ade36dc2c2748c8d62d80bf69.camel@redhat.com> Message-ID: <964b5136-5493-e415-cf3f-1eb8fce95689@oracle.com> On 2018-09-04 14:06, David Holmes wrote: > Hi Severin, > > On 5/09/2018 1:36 AM, Severin Gehwolf wrote: >> Hi, >> >> Could I please get reviews of this JDK 8-only change? >> >> The issue at hand is that the JDK 8 build seems to be inconsistent with >> later JDK builds (9+). When somebody passes >> --with-extra-c{,xx}-flags="-O2" to the OpenJDK build on JDK 9+ the JVM >> will get compiled with -O3 for a release type build. Not so on JDK 8. >> It gets compiled with -O2. The reason we are passing extra C flags via >> configure is to: a) get distro-wide optimization done b) allow for >> hardened builds. Without the --with-extra-c{,xx}-flags="-O2" flag, >> libjsig, libsaproc will get compiled with no optimization. That's what >> I'd like to fix. The proposed patch allows one to force -O2 for the JVM >> via OPT_EXTRAS make variable if so desired. Omitting OPT_EXTRAS=-O2 >> allows one to get hotspot libraries optimized with -O2 and better. >> Thoughts? > > I don't understand the motivation for this change. Compatibility with > future versions is not a usual compatibility we care about. I'd also > argue the behaviour in 8 seems more correct. If I set an extra cflag I > expect it to be applied to all compilations - cross-compilation would > be broken if that were not the case. I don't see why -On should be > treated any differently. > I do agree with you, sort of. All user added flags are applied everywhere. The reason the optimization isn't overridden is because of the order the flags are applied on the command line. In JDK 9 (and in 8 for JDK libs) we apply optimization flags after the custom flags from the user. (For Hotspot in 8 it seems the custom flags are added after the optimization flags.) IIRC we did this intentionally in the "new build" with the reasoning that we are pretty particular with the optimization flags in many cases so a global override is probably not a good idea. The suggested patch, filtering specific -O flags from the user supplied flags does not look good to me. I would however be ok with changing the ordering of flags for libjvm so that the same behavior as in 9 and later (and as for JDK libs in 8) is achieved. /Erik > David > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210352 >> webrev: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/ >> >> Thanks, >> Severin >> From erik.joelsson at oracle.com Tue Sep 4 21:30:41 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 4 Sep 2018 14:30:41 -0700 Subject: RFR: 8165440: Add zero support for x86_64-linux-gnux32 target In-Reply-To: <147a5ffd-5eac-244d-60a7-bc8a0b8d5005@oracle.com> References: <147a5ffd-5eac-244d-60a7-bc8a0b8d5005@oracle.com> Message-ID: <8e04f884-41ea-1770-14ad-6f727c96e405@oracle.com> Looks ok to me. /Erik On 2018-09-04 14:29, David Holmes wrote: > Hi Adrian, > > All changes that touch the build system must be reviewed by build-dev > - now cc'd. > > These changes seem reasonable, though I don't like adding changes in > source code for such an obscure (and unsupported!) platform. > > David > > On 5/09/2018 3:45 AM, John Paul Adrian Glaubitz wrote: >> Hi! >> >> This rather small change adds build support for the x86_64-linux-gnux32 >> target. x32 is a variant of the x86_64 ABI with 64-bit registers and >> amd64 >> instruction set but 32-bit pointers [1]. >> >> One of the Linux distributions supporting x32 is Debian, see [2]. The >> port is not official, but the large majority of packages build fine >> and the toolchain is in good shape. Another distribution supporting >> x32 is Gentoo. >> >> Please review the change in [3]. I have changed the original patch >> a bit that Debian uses downstream to make the changes more consistent >> and cleaner. >> >> Thanks, >> Adrian >> >>> [1] https://en.wikipedia.org/wiki/X32_ABI >>> [2] http://debian-x32.org/ >>> [2] http://cr.openjdk.java.net/~glaubitz/8165440/webrev.00/ >> From david.holmes at oracle.com Tue Sep 4 21:38:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Sep 2018 07:38:02 +1000 Subject: [8u] RFR: 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization In-Reply-To: <964b5136-5493-e415-cf3f-1eb8fce95689@oracle.com> References: <6098243100d4f92ade36dc2c2748c8d62d80bf69.camel@redhat.com> <964b5136-5493-e415-cf3f-1eb8fce95689@oracle.com> Message-ID: <51cb87da-6f33-e6ef-87b3-1376152bea95@oracle.com> On 5/09/2018 7:29 AM, Erik Joelsson wrote: > On 2018-09-04 14:06, David Holmes wrote: >> Hi Severin, >> >> On 5/09/2018 1:36 AM, Severin Gehwolf wrote: >>> Hi, >>> >>> Could I please get reviews of this JDK 8-only change? >>> >>> The issue at hand is that the JDK 8 build seems to be inconsistent with >>> later JDK builds (9+). When somebody passes >>> --with-extra-c{,xx}-flags="-O2" to the OpenJDK build on JDK 9+ the JVM >>> will get compiled with -O3 for a release type build. Not so on JDK 8. >>> It gets compiled with -O2. The reason we are passing extra C flags via >>> configure is to: a) get distro-wide optimization done b) allow for >>> hardened builds. Without the --with-extra-c{,xx}-flags="-O2" flag, >>> libjsig, libsaproc will get compiled with no optimization. That's what >>> I'd like to fix. The proposed patch allows one to force -O2 for the JVM >>> via OPT_EXTRAS make variable if so desired. Omitting OPT_EXTRAS=-O2 >>> allows one to get hotspot libraries optimized with -O2 and better. >>> Thoughts? >> >> I don't understand the motivation for this change. Compatibility with >> future versions is not a usual compatibility we care about. I'd also >> argue the behaviour in 8 seems more correct. If I set an extra cflag I >> expect it to be applied to all compilations - cross-compilation would >> be broken if that were not the case. I don't see why -On should be >> treated any differently. >> > I do agree with you, sort of. All user added flags are applied > everywhere. The reason the optimization isn't overridden is because of > the order the flags are applied on the command line. In JDK 9 (and in 8 > for JDK libs) we apply optimization flags after the custom flags from > the user. (For Hotspot in 8 it seems the custom flags are added after > the optimization flags.) IIRC we did this intentionally in the "new > build" with the reasoning that we are pretty particular with the > optimization flags in many cases so a global override is probably not a > good idea. > > The suggested patch, filtering specific -O flags from the user supplied > flags does not look good to me. I would however be ok with changing the > ordering of flags for libjvm so that the same behavior as in 9 and later > (and as for JDK libs in 8) is achieved. Okay - but such a change should be considered an enhancement request, not a bug fix, and must then go through the enhancement request process for 8u. My concern is that this may fix Severin's issue but may break others who do custom builds of 8u code. The 8u maintainers would have to make the decision to accept this change or not. David > > /Erik >> David >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210352 >>> webrev: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/ >>> >>> Thanks, >>> Severin >>> > From martinrb at google.com Tue Sep 4 23:01:10 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 4 Sep 2018 16:01:10 -0700 Subject: Linux + Clang + execstack In-Reply-To: <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> Message-ID: I think we can all agree that passing flags to the linker to ensure non-executable stack is the right thing to do. But there's a question whether *also* adding something to our assembly language source files will be worth doing. Neither mechanism is sure to work. For the linker flag, we need to be aware of and test for the presence of the linker flag, but we might be using some other linker... Similarly, we might end up using some other assembler, or we might need to mark the assembly source file in a different way than "GNU-stack". On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2018-08-21 02:03, David Holmes wrote: > >> On 21/08/2018 9:39 AM, Arthur Eubanks wrote: >> >>> On Mon, Aug 20, 2018 at 4:18 PM David Holmes >> > wrote: >>> >>> Hi Arthur, >>> >>> cc'ing build-dev as this is currently a build issue. >>> >>> On 21/08/2018 3:11 AM, Arthur Eubanks wrote: >>> > Hi, >>> > >>> > At Google we're trying to build hotspot on Linux with clang. One >>> thing that >>> > happens is that the resulting libjvm.so is stack executable. When >>> running >>> > hotspot we get warnings about the stack being executable. >>> > >>> > Compiling an assembly file into the final .so results in the >>> stack being >>> > executable. In this case the file is linux_x86_64.s. This doesn't >>> happen >>> > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot >>> linker flag >>> > with gcc in flags-ldflags.m4. When using clang that linker flag >>> isn't >>> > passed. >>> > >>> > Doing something like the solution in >>> > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks >>> > fixes the problem without the use of linker flags. >>> >>> You mean the source code directives for the linker? >>> >>> Sorry, I wasn't specific enough, I meant the flags for the assembler. >>> #if defined(__linux__) && defined(__ELF__) >>> .section .note.GNU-stack, "", %progbits >>> #endif >>> >>> >>> I think I prefer to see this handled explicitly in the build as is >>> currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4 >>> to >>> pass the linker flags for gcc and clang? >>> >>> I don't mind this solution, but it seems like the right thing to do is >>> to fix things at the source level and remove extra unnecessary linker flags. >>> >> >> Personally I see this as source code pollution. The concept of executable >> stacks has nothing to do with what is being expressed by the source code, >> or the language used for it. >> >> Just my 2c. I'll defer to build folk ... though they are still on >> vacation at the moment. >> > > I agree with David. The executable stack is a build option. Even if you > change the source code so the compiler/assember does the right thing, we > would still want to keep the compiler option. (Otherwise one day you'll end > up with executable stacks due to someone adding a new asm file and > forgetting the "magic incantation".) > > And, since we will keep the compiler option, there seems little point in > also adding this stuff to the asm files. > > To address your concerns on clang: we should reasonably be giving the same > options to clang. There is no good reason, except for oversight, that this > is not done already. (Cleaning up and unifying the compiler flags is an > ongoing, but slowly moving, process.) So the correct fix is to update > flags-ldflags.m4. > > /Magnus > > > > > >> I removed "-Wl,-z,noexecstack" from the flags after adding the above >>> assembler flags and libjvm.so is still correctly not stack executable. I >>> don't really mind either way though. Maybe it's good to have an extra >>> safeguard in the linker flags. >>> >>> >>> > The jtreg test test/hotspot/jtreg/runtime/exe >>> cstack/TestCheckJDK.java >>> > checks for the stack being executable. >>> > >>> > Any thoughts? If there are no objections, I can propose a patch >>> that works >>> > for both gcc and clang on Linux. Also, I'm not sure how/if macOS >>> handles >>> > this problem given that it uses clang. >>> >>> We don't seem to handle it at all on OS X. Does OS X prevent >>> executable >>> stacks itself? >>> >>> A quick search, according to Wikipedia (https://en.wikipedia.org/wiki >>> /Executable_space_protection#macOS), 64-bit executables on macOS aren't >>> stack or heap executable. Not sure if that information is accurate though. >>> >> >> Seems to be: >> >> https://developer.apple.com/library/archive/documentation/Se >> curity/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html >> >> "macOS and iOS provide two features that can make it harder to exploit >> stack and buffer overflows: address space layout randomization (ASLR) and a >> non-executable stack and heap." >> >> Cheers, >> David >> >> >>> David >>> >>> > From mikael.vidstedt at oracle.com Wed Sep 5 01:37:35 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 4 Sep 2018 18:37:35 -0700 Subject: RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <7a041851-cdb8-9857-7fa3-1b23381478ac@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> <7a041851-cdb8-9857-7fa3-1b23381478ac@oracle.com> Message-ID: <3CB21532-32F5-4453-9E80-57A586B5A8C1@oracle.com> Dan/Vladimir, thanks for the reviews. FWIW, in addition to the build&test job I also did some manual work to compare the disassembly of the resulting libjvm; the C++ compiler seems to agree with my ?manual? dead code elimination (yay!). Cheers, Mikael > On Sep 4, 2018, at 1:40 PM, Daniel D. Daugherty wrote: > > On 9/4/18 3:36 PM, Mikael Vidstedt wrote: >> Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ > > src/hotspot/cpu/aarch64/aarch64.ad > No comments. > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > No comments. > > src/hotspot/cpu/s390/macroAssembler_s390.cpp > No comments. > > src/hotspot/cpu/sparc/macroAssembler_sparc.cpp > No comments. > > src/hotspot/cpu/x86/macroAssembler_x86.cpp > No comments. > > src/hotspot/share/runtime/arguments.cpp > No comments. > > src/hotspot/share/runtime/globals.hpp > No comments. > > > General comments: > > - The 'if (EmitSync & 0x01) {' checks are how we disable the > use of compiled code for monitors. We use -XX:EmitSync=1 > to diagnose things when we wonder if the compiled monitor > code is broken. > - The 'if (EmitSync & 4)' checks are how we disable the use > of compiled code for unlocking of monitors; we still use > compiled code for locking of monitors. We use -XX:EmitSync=4 > to diagnose things when we wonder if the compiled monitor > unlock code is broken. > - BTW, I think s390 is using (EmitSync & 0x01) differently > than other platforms. No, I didn't try to figure out exactly > how s390 was using that option. > > This looks like a clean obsoletion of the '-XX:EmitSync=' > option so thumbs up from that POV. > > Use of '-XX:EmitSync=1' for diagnostic purposes is probably > limited to a handful of people including me. Use of the > '-XX:EmitSync=4' is probably even more rare; I can't remember > using it myself. So while I have used the '-XX:EmitSync=' > option to debug Java monitor stuff, it has been a long time > time... > > Dan > >> >> * Background (from bug) >> >> The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. >> >> In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. >> >> Cheers, >> Mikael >> >> > From martinrb at google.com Wed Sep 5 02:06:53 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 4 Sep 2018 19:06:53 -0700 Subject: Linux + Clang + execstack In-Reply-To: References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> Message-ID: Here's Arthur's patch: 8205457: gcc and clang should use the same ld flags http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/ https://bugs.openjdk.java.net/browse/JDK-8205457 This applies -Wl,-z,noexecstack uniformly to all linker invocations where applicable. TODO: All ld flags on Linux should be treated equally by gcc and clang The test TestCheckJDK and supporting infrastructure should stop advertising itself as only dealing with libraries. Maybe add GNU-stack annotations to all the Linux .s files as well? On Tue, Sep 4, 2018 at 4:01 PM, Martin Buchholz wrote: > I think we can all agree that passing flags to the linker to ensure > non-executable stack is the right thing to do. But there's a question > whether *also* adding something to our assembly language source files will > be worth doing. Neither mechanism is sure to work. For the linker flag, > we need to be aware of and test for the presence of the linker flag, but we > might be using some other linker... Similarly, we might end up using some > other assembler, or we might need to mark the assembly source file in a > different way than "GNU-stack". > > On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> On 2018-08-21 02:03, David Holmes wrote: >> >>> On 21/08/2018 9:39 AM, Arthur Eubanks wrote: >>> >>>> On Mon, Aug 20, 2018 at 4:18 PM David Holmes >>> > wrote: >>>> >>>> Hi Arthur, >>>> >>>> cc'ing build-dev as this is currently a build issue. >>>> >>>> On 21/08/2018 3:11 AM, Arthur Eubanks wrote: >>>> > Hi, >>>> > >>>> > At Google we're trying to build hotspot on Linux with clang. One >>>> thing that >>>> > happens is that the resulting libjvm.so is stack executable. When >>>> running >>>> > hotspot we get warnings about the stack being executable. >>>> > >>>> > Compiling an assembly file into the final .so results in the >>>> stack being >>>> > executable. In this case the file is linux_x86_64.s. This doesn't >>>> happen >>>> > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot >>>> linker flag >>>> > with gcc in flags-ldflags.m4. When using clang that linker flag >>>> isn't >>>> > passed. >>>> > >>>> > Doing something like the solution in >>>> > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks >>>> > fixes the problem without the use of linker flags. >>>> >>>> You mean the source code directives for the linker? >>>> >>>> Sorry, I wasn't specific enough, I meant the flags for the assembler. >>>> #if defined(__linux__) && defined(__ELF__) >>>> .section .note.GNU-stack, "", %progbits >>>> #endif >>>> >>>> >>>> I think I prefer to see this handled explicitly in the build as is >>>> currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4 >>>> to >>>> pass the linker flags for gcc and clang? >>>> >>>> I don't mind this solution, but it seems like the right thing to do is >>>> to fix things at the source level and remove extra unnecessary linker flags. >>>> >>> >>> Personally I see this as source code pollution. The concept of >>> executable stacks has nothing to do with what is being expressed by the >>> source code, or the language used for it. >>> >>> Just my 2c. I'll defer to build folk ... though they are still on >>> vacation at the moment. >>> >> >> I agree with David. The executable stack is a build option. Even if you >> change the source code so the compiler/assember does the right thing, we >> would still want to keep the compiler option. (Otherwise one day you'll end >> up with executable stacks due to someone adding a new asm file and >> forgetting the "magic incantation".) >> >> And, since we will keep the compiler option, there seems little point in >> also adding this stuff to the asm files. >> >> To address your concerns on clang: we should reasonably be giving the >> same options to clang. There is no good reason, except for oversight, that >> this is not done already. (Cleaning up and unifying the compiler flags is >> an ongoing, but slowly moving, process.) So the correct fix is to update >> flags-ldflags.m4. >> >> /Magnus >> >> >> >> >> >>> I removed "-Wl,-z,noexecstack" from the flags after adding the above >>>> assembler flags and libjvm.so is still correctly not stack executable. I >>>> don't really mind either way though. Maybe it's good to have an extra >>>> safeguard in the linker flags. >>>> >>>> >>>> > The jtreg test test/hotspot/jtreg/runtime/exe >>>> cstack/TestCheckJDK.java >>>> > checks for the stack being executable. >>>> > >>>> > Any thoughts? If there are no objections, I can propose a patch >>>> that works >>>> > for both gcc and clang on Linux. Also, I'm not sure how/if macOS >>>> handles >>>> > this problem given that it uses clang. >>>> >>>> We don't seem to handle it at all on OS X. Does OS X prevent >>>> executable >>>> stacks itself? >>>> >>>> A quick search, according to Wikipedia (https://en.wikipedia.org/wiki >>>> /Executable_space_protection#macOS), 64-bit executables on macOS >>>> aren't stack or heap executable. Not sure if that information is accurate >>>> though. >>>> >>> >>> Seems to be: >>> >>> https://developer.apple.com/library/archive/documentation/Se >>> curity/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html >>> >>> "macOS and iOS provide two features that can make it harder to exploit >>> stack and buffer overflows: address space layout randomization (ASLR) and a >>> non-executable stack and heap." >>> >>> Cheers, >>> David >>> >>> >>>> David >>>> >>>> >> > From david.holmes at oracle.com Wed Sep 5 02:16:23 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Sep 2018 12:16:23 +1000 Subject: RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> Message-ID: Hi Mikael, This EmitSync eradication looks good to me. In src/hotspot/cpu/sparc/macroAssembler_sparc.cpp: 2651 Label Egress ; This label seems unused even before your change. Thanks, David On 5/09/2018 5:36 AM, Mikael Vidstedt wrote: > > Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ > > * Background (from bug) > > The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. > > In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Wed Sep 5 02:22:16 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 4 Sep 2018 19:22:16 -0700 Subject: Linux + Clang + execstack In-Reply-To: References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> Message-ID: <05094846-82D9-4B39-879B-311835DAEA96@oracle.com> > On Sep 4, 2018, at 7:06 PM, Martin Buchholz wrote: > > Here's Arthur's patch: > > 8205457: gcc and clang should use the same ld flags > http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/ > https://bugs.openjdk.java.net/browse/JDK-8205457 > > This applies -Wl,-z,noexecstack uniformly to all linker invocations where > applicable. > > TODO: > All ld flags on Linux should be treated equally by gcc and clang > The test TestCheckJDK and supporting infrastructure should stop advertising > itself as only dealing with libraries. > Maybe add GNU-stack annotations to all the Linux .s files as well? I like to think that our .s files are effectively incomplete, and that adding the annotations makes them less incomplete. I am, however, not emotionally attached to this so I?ll leave it up to you and others to decide what to do with it :) (it would also be interesting to see if we can perhaps move some of the .s code to C++ instead) Cheers, Mikael > > > On Tue, Sep 4, 2018 at 4:01 PM, Martin Buchholz wrote: > >> I think we can all agree that passing flags to the linker to ensure >> non-executable stack is the right thing to do. But there's a question >> whether *also* adding something to our assembly language source files will >> be worth doing. Neither mechanism is sure to work. For the linker flag, >> we need to be aware of and test for the presence of the linker flag, but we >> might be using some other linker... Similarly, we might end up using some >> other assembler, or we might need to mark the assembly source file in a >> different way than "GNU-stack". >> >> On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie < >> magnus.ihse.bursie at oracle.com> wrote: >> >>> On 2018-08-21 02:03, David Holmes wrote: >>> >>>> On 21/08/2018 9:39 AM, Arthur Eubanks wrote: >>>> >>>>> On Mon, Aug 20, 2018 at 4:18 PM David Holmes >>>> > wrote: >>>>> >>>>> Hi Arthur, >>>>> >>>>> cc'ing build-dev as this is currently a build issue. >>>>> >>>>> On 21/08/2018 3:11 AM, Arthur Eubanks wrote: >>>>>> Hi, >>>>>> >>>>>> At Google we're trying to build hotspot on Linux with clang. One >>>>> thing that >>>>>> happens is that the resulting libjvm.so is stack executable. When >>>>> running >>>>>> hotspot we get warnings about the stack being executable. >>>>>> >>>>>> Compiling an assembly file into the final .so results in the >>>>> stack being >>>>>> executable. In this case the file is linux_x86_64.s. This doesn't >>>>> happen >>>>>> with gcc because "-Wl,-z,noexecstack" is passed as a hotspot >>>>> linker flag >>>>>> with gcc in flags-ldflags.m4. When using clang that linker flag >>>>> isn't >>>>>> passed. >>>>>> >>>>>> Doing something like the solution in >>>>>> https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks >>>>>> fixes the problem without the use of linker flags. >>>>> >>>>> You mean the source code directives for the linker? >>>>> >>>>> Sorry, I wasn't specific enough, I meant the flags for the assembler. >>>>> #if defined(__linux__) && defined(__ELF__) >>>>> .section .note.GNU-stack, "", %progbits >>>>> #endif >>>>> >>>>> >>>>> I think I prefer to see this handled explicitly in the build as is >>>>> currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4 >>>>> to >>>>> pass the linker flags for gcc and clang? >>>>> >>>>> I don't mind this solution, but it seems like the right thing to do is >>>>> to fix things at the source level and remove extra unnecessary linker flags. >>>>> >>>> >>>> Personally I see this as source code pollution. The concept of >>>> executable stacks has nothing to do with what is being expressed by the >>>> source code, or the language used for it. >>>> >>>> Just my 2c. I'll defer to build folk ... though they are still on >>>> vacation at the moment. >>>> >>> >>> I agree with David. The executable stack is a build option. Even if you >>> change the source code so the compiler/assember does the right thing, we >>> would still want to keep the compiler option. (Otherwise one day you'll end >>> up with executable stacks due to someone adding a new asm file and >>> forgetting the "magic incantation".) >>> >>> And, since we will keep the compiler option, there seems little point in >>> also adding this stuff to the asm files. >>> >>> To address your concerns on clang: we should reasonably be giving the >>> same options to clang. There is no good reason, except for oversight, that >>> this is not done already. (Cleaning up and unifying the compiler flags is >>> an ongoing, but slowly moving, process.) So the correct fix is to update >>> flags-ldflags.m4. >>> >>> /Magnus >>> >>> >>> >>> >>> >>>> I removed "-Wl,-z,noexecstack" from the flags after adding the above >>>>> assembler flags and libjvm.so is still correctly not stack executable. I >>>>> don't really mind either way though. Maybe it's good to have an extra >>>>> safeguard in the linker flags. >>>>> >>>>> >>>>>> The jtreg test test/hotspot/jtreg/runtime/exe >>>>> cstack/TestCheckJDK.java >>>>>> checks for the stack being executable. >>>>>> >>>>>> Any thoughts? If there are no objections, I can propose a patch >>>>> that works >>>>>> for both gcc and clang on Linux. Also, I'm not sure how/if macOS >>>>> handles >>>>>> this problem given that it uses clang. >>>>> >>>>> We don't seem to handle it at all on OS X. Does OS X prevent >>>>> executable >>>>> stacks itself? >>>>> >>>>> A quick search, according to Wikipedia (https://en.wikipedia.org/wiki >>>>> /Executable_space_protection#macOS), 64-bit executables on macOS >>>>> aren't stack or heap executable. Not sure if that information is accurate >>>>> though. >>>>> >>>> >>>> Seems to be: >>>> >>>> https://developer.apple.com/library/archive/documentation/Se >>>> curity/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html >>>> >>>> "macOS and iOS provide two features that can make it harder to exploit >>>> stack and buffer overflows: address space layout randomization (ASLR) and a >>>> non-executable stack and heap." >>>> >>>> Cheers, >>>> David >>>> >>>> >>>>> David >>>>> >>>>> >>> >> From magnus.ihse.bursie at oracle.com Wed Sep 5 06:50:04 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 5 Sep 2018 08:50:04 +0200 Subject: Linux + Clang + execstack In-Reply-To: References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> Message-ID: <3193b432-0068-8e2b-9ad4-f5a6467568a1@oracle.com> On 2018-09-05 01:01, Martin Buchholz wrote: > I think we can all agree that passing flags to the linker to ensure > non-executable stack is the right thing to do. But there's a question > whether *also* adding something to our assembly language source files > will be worth doing.? Neither mechanism is sure to work.? For the > linker flag, we need to be aware of and test for the presence of the > linker flag, but we might be using some other linker... For the gcc toolchain this can not be the case: # Minimum supported linker versions, empty means unspecified TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18" We make sure we have an ld that supports the basic flags we assume. We can add a similar check for the clang toolchain, if you want. Mixing and matching compilers and linkers willy-nilly is not a supported build option, and there's no point in adding extra guards against such a thing. If you do that, and it turns out your build ended up broken, tough sh*t. So I'll insist that adding the linker flag is sufficient to make sure this works, and that modifying the .s files are not necessary and will provide no benefit. /Magnus > Similarly, we might end up using some other assembler, or we might > need to mark the assembly source file in a different way than "GNU-stack". > > On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie > > > wrote: > > On 2018-08-21 02:03, David Holmes wrote: > > On 21/08/2018 9:39 AM, Arthur Eubanks wrote: > > On Mon, Aug 20, 2018 at 4:18 PM David Holmes > > >> wrote: > > ??? Hi Arthur, > > ??? cc'ing build-dev as this is currently a build issue. > > ??? On 21/08/2018 3:11 AM, Arthur Eubanks wrote: > ???? > Hi, > ???? > > ???? > At Google we're trying to build hotspot on Linux > with clang. One > ??? thing that > ???? > happens is that the resulting libjvm.so is stack > executable. When > ??? running > ???? > hotspot we get warnings about the stack being > executable. > ???? > > ???? > Compiling an assembly file into the final .so > results in the > ??? stack being > ???? > executable. In this case the file is > linux_x86_64.s. This doesn't > ??? happen > ???? > with gcc because "-Wl,-z,noexecstack" is passed as > a hotspot > ??? linker flag > ???? > with gcc in flags-ldflags.m4. When using clang that > linker flag isn't > ???? > passed. > ???? > > ???? > Doing something like the solution in > ???? > > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks > > ???? > fixes the problem without the use of linker flags. > > ??? You mean the source code directives for the linker? > > Sorry, I wasn't specific enough, I meant the flags for the > assembler. > #if defined(__linux__) && defined(__ELF__) > .section? ? ? ? .note.GNU-stack, "", %progbits > #endif > > > ??? I think I prefer to see this handled explicitly in the > build as is > ??? currently done. Can we just adjust > ./make/autoconf/flags-ldflags.m4 to > ??? pass the linker flags for gcc and clang? > > I don't mind this solution, but it seems like the right > thing to do is to fix things at the source level and > remove extra unnecessary linker flags. > > > Personally I see this as source code pollution. The concept of > executable stacks has nothing to do with what is being > expressed by the source code, or the language used for it. > > Just my 2c. I'll defer to build folk ... though they are still > on vacation at the moment. > > > I agree with David. The executable stack is a build option. Even > if you change the source code so the compiler/assember does the > right thing, we would still want to keep the compiler option. > (Otherwise one day you'll end up with executable stacks due to > someone adding a new asm file and forgetting the "magic incantation".) > > And, since we will keep the compiler option, there seems little > point in also adding this stuff to the asm files. > > To address your concerns on clang: we should reasonably be giving > the same options to clang. There is no good reason, except for > oversight, that this is not done already. (Cleaning up and > unifying the compiler flags is an ongoing, but slowly moving, > process.) So the correct fix is to update flags-ldflags.m4. > > /Magnus > > > > > > I removed?"-Wl,-z,noexecstack" from the flags after adding > the above assembler flags and libjvm.so is still correctly > not stack executable. I don't really mind either way > though. Maybe it's good to have an extra safeguard in the > linker flags. > > > ???? > The jtreg test > test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java > ???? > checks for the stack being executable. > ???? > > ???? > Any thoughts? If there are no objections, I can > propose a patch > ??? that works > ???? > for both gcc and clang on Linux. Also, I'm not sure > how/if macOS > ??? handles > ???? > this problem given that it uses clang. > > ??? We don't seem to handle it at all on OS X. Does OS X > prevent executable > ??? stacks itself? > > A quick search, according to Wikipedia > (https://en.wikipedia.org/wiki/Executable_space_protection#macOS > ), > 64-bit executables on macOS aren't stack or heap > executable. Not sure if that information is accurate though. > > > Seems to be: > > https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html > > > > "macOS and iOS provide two features that can make it harder to > exploit stack and buffer overflows: address space layout > randomization (ASLR) and a non-executable stack and heap." > > Cheers, > David > > > ??? David > > > From magnus.ihse.bursie at oracle.com Wed Sep 5 06:53:02 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 5 Sep 2018 08:53:02 +0200 Subject: Linux + Clang + execstack In-Reply-To: References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> Message-ID: On 2018-09-05 04:06, Martin Buchholz wrote: > Here's Arthur's patch: > > 8205457: gcc and clang should use the same ld flags > http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/ > > https://bugs.openjdk.java.net/browse/JDK-8205457 > > This applies -Wl,-z,noexecstack uniformly to all linker invocations > where applicable. > > TODO: > All ld flags on Linux should be treated equally by gcc and clang Just FYI: I'm on a long-term mission to clean up the flag handling in the entire build. There's a lot of weird stuff going on with the flags, like "why do we do like this on this platform, and like that on that platform? shouldn't they be the same?". And most of the time, yes, they probably should be the same. But at other times, there's a reason they are different and the difference is a deliberate bug fix. It takes time, effort and a lot of repository archeology to figure that out. /Magnus > The test TestCheckJDK and supporting infrastructure should stop > advertising itself as only dealing with libraries. > Maybe add GNU-stack annotations to all the Linux .s files as well? > > > On Tue, Sep 4, 2018 at 4:01 PM, Martin Buchholz > wrote: > > I think we can all agree that passing flags to the linker to > ensure non-executable stack is the right thing to do.? But there's > a question whether *also* adding something to our assembly > language source files will be worth doing.? Neither mechanism is > sure to work.? For the linker flag, we need to be aware of and > test for the presence of the linker flag, but we might be using > some other linker... Similarly, we might end up using some other > assembler, or we might need to mark the assembly source file in a > different way than "GNU-stack". > > On Tue, Aug 21, 2018 at 4:14 AM, Magnus Ihse Bursie > > wrote: > > On 2018-08-21 02:03, David Holmes wrote: > > On 21/08/2018 9:39 AM, Arthur Eubanks wrote: > > On Mon, Aug 20, 2018 at 4:18 PM David Holmes > > >> wrote: > > ??? Hi Arthur, > > ??? cc'ing build-dev as this is currently a build issue. > > ??? On 21/08/2018 3:11 AM, Arthur Eubanks wrote: > ???? > Hi, > ???? > > ???? > At Google we're trying to build hotspot on > Linux with clang. One > ??? thing that > ???? > happens is that the resulting libjvm.so is > stack executable. When > ??? running > ???? > hotspot we get warnings about the stack being > executable. > ???? > > ???? > Compiling an assembly file into the final .so > results in the > ??? stack being > ???? > executable. In this case the file is > linux_x86_64.s. This doesn't > ??? happen > ???? > with gcc because "-Wl,-z,noexecstack" is passed > as a hotspot > ??? linker flag > ???? > with gcc in flags-ldflags.m4. When using clang > that linker flag isn't > ???? > passed. > ???? > > ???? > Doing something like the solution in > ???? > > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks > > ???? > fixes the problem without the use of linker flags. > > ??? You mean the source code directives for the linker? > > Sorry, I wasn't specific enough, I meant the flags for > the assembler. > #if defined(__linux__) && defined(__ELF__) > .section? ? ? ? .note.GNU-stack, "", %progbits > #endif > > > ??? I think I prefer to see this handled explicitly in > the build as is > ??? currently done. Can we just adjust > ./make/autoconf/flags-ldflags.m4 to > ??? pass the linker flags for gcc and clang? > > I don't mind this solution, but it seems like the > right thing to do is to fix things at the source level > and remove extra unnecessary linker flags. > > > Personally I see this as source code pollution. The > concept of executable stacks has nothing to do with what > is being expressed by the source code, or the language > used for it. > > Just my 2c. I'll defer to build folk ... though they are > still on vacation at the moment. > > > I agree with David. The executable stack is a build option. > Even if you change the source code so the compiler/assember > does the right thing, we would still want to keep the compiler > option. (Otherwise one day you'll end up with executable > stacks due to someone adding a new asm file and forgetting the > "magic incantation".) > > And, since we will keep the compiler option, there seems > little point in also adding this stuff to the asm files. > > To address your concerns on clang: we should reasonably be > giving the same options to clang. There is no good reason, > except for oversight, that this is not done already. (Cleaning > up and unifying the compiler flags is an ongoing, but slowly > moving, process.) So the correct fix is to update > flags-ldflags.m4. > > /Magnus > > > > > > I removed?"-Wl,-z,noexecstack" from the flags after > adding the above assembler flags and libjvm.so is > still correctly not stack executable. I don't really > mind either way though. Maybe it's good to have an > extra safeguard in the linker flags. > > > ???? > The jtreg test > test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java > ???? > checks for the stack being executable. > ???? > > ???? > Any thoughts? If there are no objections, I can > propose a patch > ??? that works > ???? > for both gcc and clang on Linux. Also, I'm not > sure how/if macOS > ??? handles > ???? > this problem given that it uses clang. > > ??? We don't seem to handle it at all on OS X. Does OS > X prevent executable > ??? stacks itself? > > A quick search, according to Wikipedia > (https://en.wikipedia.org/wiki/Executable_space_protection#macOS > ), > 64-bit executables on macOS aren't stack or heap > executable. Not sure if that information is accurate > though. > > > Seems to be: > > https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html > > > > "macOS and iOS provide two features that can make it > harder to exploit stack and buffer overflows: address > space layout randomization (ASLR) and a non-executable > stack and heap." > > Cheers, > David > > > ??? David > > > > From magnus.ihse.bursie at oracle.com Wed Sep 5 07:05:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 5 Sep 2018 09:05:52 +0200 Subject: RFR: 8165440: Add zero support for x86_64-linux-gnux32 target In-Reply-To: <147a5ffd-5eac-244d-60a7-bc8a0b8d5005@oracle.com> References: <147a5ffd-5eac-244d-60a7-bc8a0b8d5005@oracle.com> Message-ID: <0bb5a93b-ea45-fdd1-12aa-980804269958@oracle.com> On 2018-09-04 23:29, David Holmes wrote: > Hi Adrian, > > All changes that touch the build system must be reviewed by build-dev > - now cc'd. This has been discussed at some length in build-dev. But I agree, it's good that also the actual RFR is cc:ed here. The patch, unsurprisingly, LGTM. /Magnus > > These changes seem reasonable, though I don't like adding changes in > source code for such an obscure (and unsupported!) platform. > > David > > On 5/09/2018 3:45 AM, John Paul Adrian Glaubitz wrote: >> Hi! >> >> This rather small change adds build support for the x86_64-linux-gnux32 >> target. x32 is a variant of the x86_64 ABI with 64-bit registers and >> amd64 >> instruction set but 32-bit pointers [1]. >> >> One of the Linux distributions supporting x32 is Debian, see [2]. The >> port is not official, but the large majority of packages build fine >> and the toolchain is in good shape. Another distribution supporting >> x32 is Gentoo. >> >> Please review the change in [3]. I have changed the original patch >> a bit that Debian uses downstream to make the changes more consistent >> and cleaner. >> >> Thanks, >> Adrian >> >>> [1] https://en.wikipedia.org/wiki/X32_ABI >>> [2] http://debian-x32.org/ >>> [2] http://cr.openjdk.java.net/~glaubitz/8165440/webrev.00/ >> From magnus.ihse.bursie at oracle.com Wed Sep 5 07:10:22 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 5 Sep 2018 09:10:22 +0200 Subject: RFR: JDK-6657100 Rename sparcWorks to solstudio in HotSpot In-Reply-To: References: <4bd22bee-8d4c-8a1d-441b-03207355380c@oracle.com> <20a1b3c0-066c-401c-3b12-db2f06d6b671@oracle.com> Message-ID: <15de07b5-39d8-29af-0a6b-ec69dee3ec1b@oracle.com> On 2018-09-04 17:49, Erik Joelsson wrote: > On 2018-09-03 00:19, David Holmes wrote: >> On 30/08/2018 10:36 PM, Magnus Ihse Bursie wrote: >>> Hi folks, >>> >>> This bug report goes all the way back to 2008. :-) So instead of >>> just letting it go on to it's second decade of existence, I went >>> about and fixed it. >> >> Ummm but now it's called Oracle Developer Studio. >> > Yes, we are aware of that, so ideally we should rename it all over. Or maybe we shouldn't. If so, we should also rename "macosx" to "macos". Alternatively, we can accept that the best we can do is to have a name that's not ambiguous, clearly states what it is about, is not misleading (that was one of the main complaints about the old "sparcWorks"; it was not about sparc, it was about solaris). And hope that marketing let us keep our good names in sync with the marketing names used, as long as possible. /Magnus > This bug was about unification however, and now it's at least unified. > One could also note that the version we are currently using (12.4) was > still called Solaris Studio. The rename happened in later versions. > > /Erik >> David >> >>> By now, not many references to sparcWorks exists anymore, so this is >>> almost trivial. >>> >>> I've verified by grep that no more "sparcworks" are present in the >>> repo, neither in hotspot nor anywhere else. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-6657100 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-6657100-rename-sparcWorks-to-solstudio/webrev.01 >>> >>> >>> /Magnus > From glaubitz at physik.fu-berlin.de Wed Sep 5 07:23:02 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 5 Sep 2018 09:23:02 +0200 Subject: RFR: 8165440: Add zero support for x86_64-linux-gnux32 target In-Reply-To: <0bb5a93b-ea45-fdd1-12aa-980804269958@oracle.com> References: <147a5ffd-5eac-244d-60a7-bc8a0b8d5005@oracle.com> <0bb5a93b-ea45-fdd1-12aa-980804269958@oracle.com> Message-ID: You?re right, sorry. I haven?t been around OpenJDK for some weeks and forgot about posting to build-dev when posting. I will push in around 2-3 hours, currently on a train. Adrian > On Sep 5, 2018, at 9:05 AM, Magnus Ihse Bursie wrote: > >> On 2018-09-04 23:29, David Holmes wrote: >> Hi Adrian, >> >> All changes that touch the build system must be reviewed by build-dev - now cc'd. > This has been discussed at some length in build-dev. But I agree, it's good that also the actual RFR is cc:ed here. > > The patch, unsurprisingly, LGTM. > > /Magnus > >> >> These changes seem reasonable, though I don't like adding changes in source code for such an obscure (and unsupported!) platform. >> >> David >> >>> On 5/09/2018 3:45 AM, John Paul Adrian Glaubitz wrote: >>> Hi! >>> >>> This rather small change adds build support for the x86_64-linux-gnux32 >>> target. x32 is a variant of the x86_64 ABI with 64-bit registers and amd64 >>> instruction set but 32-bit pointers [1]. >>> >>> One of the Linux distributions supporting x32 is Debian, see [2]. The >>> port is not official, but the large majority of packages build fine >>> and the toolchain is in good shape. Another distribution supporting >>> x32 is Gentoo. >>> >>> Please review the change in [3]. I have changed the original patch >>> a bit that Debian uses downstream to make the changes more consistent >>> and cleaner. >>> >>> Thanks, >>> Adrian >>> >>>> [1] https://en.wikipedia.org/wiki/X32_ABI >>>> [2] http://debian-x32.org/ >>>> [2] http://cr.openjdk.java.net/~glaubitz/8165440/webrev.00/ >>> > From sgehwolf at redhat.com Wed Sep 5 08:07:32 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 05 Sep 2018 10:07:32 +0200 Subject: [8u] RFR: 8210352: [hotspot] --with-extra-cxx-flags should not lower optimization In-Reply-To: <51cb87da-6f33-e6ef-87b3-1376152bea95@oracle.com> References: <6098243100d4f92ade36dc2c2748c8d62d80bf69.camel@redhat.com> <964b5136-5493-e415-cf3f-1eb8fce95689@oracle.com> <51cb87da-6f33-e6ef-87b3-1376152bea95@oracle.com> Message-ID: <8e78b124d7d609ecae4150c816fb0657f31fa8c9.camel@redhat.com> On Wed, 2018-09-05 at 07:38 +1000, David Holmes wrote: > On 5/09/2018 7:29 AM, Erik Joelsson wrote: > > On 2018-09-04 14:06, David Holmes wrote: > > > Hi Severin, > > > > > > On 5/09/2018 1:36 AM, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could I please get reviews of this JDK 8-only change? > > > > > > > > The issue at hand is that the JDK 8 build seems to be inconsistent with > > > > later JDK builds (9+). When somebody passes > > > > --with-extra-c{,xx}-flags="-O2" to the OpenJDK build on JDK 9+ the JVM > > > > will get compiled with -O3 for a release type build. Not so on JDK 8. > > > > It gets compiled with -O2. The reason we are passing extra C flags via > > > > configure is to: a) get distro-wide optimization done b) allow for > > > > hardened builds. Without the --with-extra-c{,xx}-flags="-O2" flag, > > > > libjsig, libsaproc will get compiled with no optimization. That's what > > > > I'd like to fix. The proposed patch allows one to force -O2 for the JVM > > > > via OPT_EXTRAS make variable if so desired. Omitting OPT_EXTRAS=-O2 > > > > allows one to get hotspot libraries optimized with -O2 and better. > > > > Thoughts? > > > > > > I don't understand the motivation for this change. Compatibility with > > > future versions is not a usual compatibility we care about. I'd also > > > argue the behaviour in 8 seems more correct. If I set an extra cflag I > > > expect it to be applied to all compilations - cross-compilation would > > > be broken if that were not the case. I don't see why -On should be > > > treated any differently. > > > > > > > I do agree with you, sort of. All user added flags are applied > > everywhere. The reason the optimization isn't overridden is because of > > the order the flags are applied on the command line. In JDK 9 (and in 8 > > for JDK libs) we apply optimization flags after the custom flags from > > the user. (For Hotspot in 8 it seems the custom flags are added after > > the optimization flags.) IIRC we did this intentionally in the "new > > build" with the reasoning that we are pretty particular with the > > optimization flags in many cases so a global override is probably not a > > good idea. > > > > The suggested patch, filtering specific -O flags from the user supplied > > flags does not look good to me. I would however be ok with changing the > > ordering of flags for libjvm so that the same behavior as in 9 and later > > (and as for JDK libs in 8) is achieved. > > Okay - but such a change should be considered an enhancement request, > not a bug fix, and must then go through the enhancement request process > for 8u. My concern is that this may fix Severin's issue but may break > others who do custom builds of 8u code. The 8u maintainers would have to > make the decision to accept this change or not. Fair enough. I'll get this process started then. Thanks, Severin > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210352 > > > > webrev: > > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210352/webrev.01/ > > > > > > > > Thanks, > > > > Severin > > > > From martin.doerr at sap.com Wed Sep 5 09:23:29 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 5 Sep 2018 09:23:29 +0000 Subject: RFR(S): 8210381: Obsolete EmitSync In-Reply-To: References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> Message-ID: Hi Mikael, builds on PPC64 and s390 and looks fine. Thanks, Martin -----Original Message----- From: hotspot-dev On Behalf Of David Holmes Sent: Mittwoch, 5. September 2018 04:16 To: Mikael Vidstedt ; HotSpot Open Source Developers Subject: Re: RFR(S): 8210381: Obsolete EmitSync Hi Mikael, This EmitSync eradication looks good to me. In src/hotspot/cpu/sparc/macroAssembler_sparc.cpp: 2651 Label Egress ; This label seems unused even before your change. Thanks, David On 5/09/2018 5:36 AM, Mikael Vidstedt wrote: > > Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ > > * Background (from bug) > > The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. > > In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. > > Cheers, > Mikael > From matthias.baesken at sap.com Wed Sep 5 11:03:05 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 5 Sep 2018 11:03:05 +0000 Subject: RFR : [XS] 8209942: [epsilon] range function for EpsilonTLABElasticity causes compiler warning Message-ID: <6ac4615d86ec4d42b99657285507aa66@sap.com> Hello, when compiling jdk/jdk on Windows, (with VS2017 update level 15.8 and not disabling warnings as errors ) I came across this warning leading to build error : C:/jdk-just-clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): error C2220: warning treated as error - no 'object' file generated C:/jdk-just-clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): warning C4305: 'argument': truncation from 'const intx' to 'double' Would have been helpful to have a compiler flag set that really ***shows the code*** leading to the warning/error (because it comes from heavy macro expansion). The following CR , Reported by ralf.schmelter at sap.com , fixes the issue : The flag -XX:EpsilonTLABElasticity (epsilon_globals.hpp, line 77) expects a double value, but uses max_intx in the allowed range. This leads to a truncation warning in the Windows build. If the value should only be guaranteed to be >= 1, then DBL_MAX should have been used instead. Webrev/bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8209942/ https://bugs.openjdk.java.net/browse/JDK-8209942 Please review . Thanks, Matthias From matthias.baesken at sap.com Wed Sep 5 11:08:48 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 5 Sep 2018 11:08:48 +0000 Subject: RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <3CB21532-32F5-4453-9E80-57A586B5A8C1@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> <7a041851-cdb8-9857-7fa3-1b23381478ac@oracle.com> <3CB21532-32F5-4453-9E80-57A586B5A8C1@oracle.com> Message-ID: Hello , I had a short look at the ppc / s390x changes , looks OK . To be on the safe side I put it into our build/test queue, so we see results for ppc64(le) / s390x as well tomorrow . Best regards, Matthias > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Mikael Vidstedt > Sent: Mittwoch, 5. September 2018 03:38 > To: daniel.daugherty at oracle.com > Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; > HotSpot Open Source Developers ; > aarch64-port-dev at openjdk.java.net > Subject: Re: RFR(S): 8210381: Obsolete EmitSync > > > Dan/Vladimir, thanks for the reviews. > > FWIW, in addition to the build&test job I also did some manual work to > compare the disassembly of the resulting libjvm; the C++ compiler seems to > agree with my ?manual? dead code elimination (yay!). > > Cheers, > Mikael > > > On Sep 4, 2018, at 1:40 PM, Daniel D. Daugherty > wrote: > > > > On 9/4/18 3:36 PM, Mikael Vidstedt wrote: > >> Please review this change which obsoletes the EmitSync flag. In particular, > I could use some help from ppc, aarch64, and s390 maintainers to verify that > the change actually builds and (still) works. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 > > >> Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/we > brev/ > ebrev/> > > > > src/hotspot/cpu/aarch64/aarch64.ad > > No comments. > > > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > > No comments. > > > > src/hotspot/cpu/s390/macroAssembler_s390.cpp > > No comments. > > > > src/hotspot/cpu/sparc/macroAssembler_sparc.cpp > > No comments. > > > > src/hotspot/cpu/x86/macroAssembler_x86.cpp > > No comments. > > > > src/hotspot/share/runtime/arguments.cpp > > No comments. > > > > src/hotspot/share/runtime/globals.hpp > > No comments. > > > > > > General comments: > > > > - The 'if (EmitSync & 0x01) {' checks are how we disable the > > use of compiled code for monitors. We use -XX:EmitSync=1 > > to diagnose things when we wonder if the compiled monitor > > code is broken. > > - The 'if (EmitSync & 4)' checks are how we disable the use > > of compiled code for unlocking of monitors; we still use > > compiled code for locking of monitors. We use -XX:EmitSync=4 > > to diagnose things when we wonder if the compiled monitor > > unlock code is broken. > > - BTW, I think s390 is using (EmitSync & 0x01) differently > > than other platforms. No, I didn't try to figure out exactly > > how s390 was using that option. > > > > This looks like a clean obsoletion of the '-XX:EmitSync=' > > option so thumbs up from that POV. > > > > Use of '-XX:EmitSync=1' for diagnostic purposes is probably > > limited to a handful of people including me. Use of the > > '-XX:EmitSync=4' is probably even more rare; I can't remember > > using it myself. So while I have used the '-XX:EmitSync=' > > option to debug Java monitor stuff, it has been a long time > > time... > > > > Dan > > > >> > >> * Background (from bug) > >> > >> The experimental EmitSync flag can in theory be used to select which > implementation of the synchronization primitives to use. The flag was > convenient when the various implementations were compared a long time > ago. > >> > >> In practice the only implementation that is used and tested today is the > default one. The EmitSync flag no longer serves the purpose it used to, and is > "Unsafe, Unstable" (the documentation of the flag says so explicitly). It > should be obsoleted and later removed. > >> > >> Cheers, > >> Mikael > >> > >> > > From volker.simonis at gmail.com Wed Sep 5 12:11:08 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 5 Sep 2018 14:11:08 +0200 Subject: RFR : [XS] 8209942: [epsilon] range function for EpsilonTLABElasticity causes compiler warning In-Reply-To: <6ac4615d86ec4d42b99657285507aa66@sap.com> References: <6ac4615d86ec4d42b99657285507aa66@sap.com> Message-ID: Hi Matthias, your change looks good to me. Also forwarding to Aleksey who is the initial author of the code. @Aleksey: do you think the fix still keeps the intended semantics? Thank you for fixing this, Volker On Wed, Sep 5, 2018 at 1:03 PM Baesken, Matthias wrote: > > Hello, when compiling jdk/jdk on Windows, (with VS2017 update level 15.8 and not disabling warnings as errors ) > I came across this warning leading to build error : > > C:/jdk-just-clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): error C2220: warning treated as error - no 'object' file generated > C:/jdk-just-clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): warning C4305: 'argument': truncation from 'const intx' to 'double' > > Would have been helpful to have a compiler flag set that really ***shows the code*** leading to the warning/error (because it comes from heavy macro expansion). > > > The following CR , Reported by ralf.schmelter at sap.com , fixes the issue : > > The flag -XX:EpsilonTLABElasticity (epsilon_globals.hpp, line 77) expects a double value, but uses max_intx in the allowed range. > This leads to a truncation warning in the Windows build. If the value should only be guaranteed to be >= 1, then DBL_MAX should have been used instead. > > > Webrev/bug : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8209942/ > > https://bugs.openjdk.java.net/browse/JDK-8209942 > > > Please review . > > > > > Thanks, Matthias From magnus.ihse.bursie at oracle.com Wed Sep 5 12:11:57 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 5 Sep 2018 14:11:57 +0200 Subject: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig Message-ID: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com> When I removed (mostly) all mapfiles for the JDK libraries, building of libjsig started failing on Solaris, and that part was backed out. Here's a new, and improved solution to remove the mapfile for libjsig, even on Solaris. Bug: https://bugs.openjdk.java.net/browse/JDK-8200609 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01 /Magnus From shade at redhat.com Wed Sep 5 12:19:48 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 5 Sep 2018 14:19:48 +0200 Subject: RFR : [XS] 8209942: [epsilon] range function for EpsilonTLABElasticity causes compiler warning In-Reply-To: References: <6ac4615d86ec4d42b99657285507aa66@sap.com> Message-ID: <8cc9b173-c66c-87d7-9a08-1dab1a615330@redhat.com> On 09/05/2018 02:11 PM, Volker Simonis wrote: > Also forwarding to Aleksey who is the initial author of the code. > @Aleksey: do you think the fix still keeps the intended semantics? Yes, it does. Thanks for fixing it. >> http://cr.openjdk.java.net/~mbaesken/webrevs/8209942/ Looks good! -Aleksey From matthias.baesken at sap.com Wed Sep 5 12:28:32 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 5 Sep 2018 12:28:32 +0000 Subject: RFR : [XS] 8209942: [epsilon] range function for EpsilonTLABElasticity causes compiler warning In-Reply-To: References: <6ac4615d86ec4d42b99657285507aa66@sap.com> Message-ID: <64ee4796ac5a427197c0cae739745ff9@sap.com> Hi Volki , The flag EpsilonTLABElasticity is used here : jdk/src/hotspot/share/gc/epsilon/epsilonHeap.cpp 181 size_t size = requested_size; 182 size_t ergo_tlab = requested_size; 183 int64_t time = 0; 184 185 if (EpsilonElasticTLAB) { 186 ergo_tlab = EpsilonThreadLocalData::ergo_tlab_size(thread); 187 188 if (EpsilonElasticTLABDecay) { 189 int64_t last_time = EpsilonThreadLocalData::last_tlab_time(thread); 190 time = (int64_t) os::javaTimeNanos(); 191 192 assert(last_time <= time, "time should be monotonic"); 193 194 // If the thread had not allocated recently, retract the ergonomic size. 195 // This conserves memory when the thread had initial burst of allocations, 196 // and then started allocating only sporadically. 197 if (last_time != 0 && (time - last_time > _decay_time_ns)) { 198 ergo_tlab = 0; 199 EpsilonThreadLocalData::set_ergo_tlab_size(thread, 0); 200 } 201 } 202 203 // If we can fit the allocation under current TLAB size, do so. 204 // Otherwise, we want to elastically increase the TLAB size. 205 fits = (requested_size <= ergo_tlab); 206 if (!fits) { One could check for overflow in the calculation below , but I think this is true for both large DBL or INT ; but it is another issue . 207 size = (size_t) (ergo_tlab * EpsilonTLABElasticity); 208 } 209 } Best regards, Matthias > -----Original Message----- > From: Volker Simonis > Sent: Mittwoch, 5. September 2018 14:11 > To: Baesken, Matthias > Cc: HotSpot Open Source Developers ; > Aleksey Shipilev > Subject: Re: RFR : [XS] 8209942: [epsilon] range function for > EpsilonTLABElasticity causes compiler warning > > Hi Matthias, > > your change looks good to me. > > Also forwarding to Aleksey who is the initial author of the code. > @Aleksey: do you think the fix still keeps the intended semantics? > > Thank you for fixing this, > Volker > On Wed, Sep 5, 2018 at 1:03 PM Baesken, Matthias > wrote: > > > > Hello, when compiling jdk/jdk on Windows, (with VS2017 update level > 15.8 and not disabling warnings as errors ) > > I came across this warning leading to build error : > > > > C:/jdk-just- > clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): error > C2220: warning treated as error - no 'object' file generated > > C:/jdk-just- > clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): warning > C4305: 'argument': truncation from 'const intx' to 'double' > > > > Would have been helpful to have a compiler flag set that really ***shows > the code*** leading to the warning/error (because it comes from heavy > macro expansion). > > > > > > The following CR , Reported by > ralf.schmelter at sap.com , fixes the issue : > > > > The flag -XX:EpsilonTLABElasticity (epsilon_globals.hpp, line 77) expects a > double value, but uses max_intx in the allowed range. > > This leads to a truncation warning in the Windows build. If the value should > only be guaranteed to be >= 1, then DBL_MAX should have been used > instead. > > > > > > Webrev/bug : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8209942/ > > > > https://bugs.openjdk.java.net/browse/JDK-8209942 > > > > > > Please review . > > > > > > > > > > Thanks, Matthias From shade at redhat.com Wed Sep 5 16:08:04 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 5 Sep 2018 18:08:04 +0200 Subject: RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> Message-ID: <9af8d2ed-966c-e5a1-f859-712d02e9ba26@redhat.com> On 09/04/2018 09:36 PM, Mikael Vidstedt wrote: > > Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ Looks okay and safe to me. FWIW: - Cross-build x86_64 -> aarch64 builds fastdebug fine. Runs HelloWorld fine. - Cross-build x86_64 -> armhf builds fastdebug fine. Runs HelloWorld fine. - Zero x86_64 builds fastdebug fine. - Minimal x86_64 builds fastdebug fine. -Aleksey From gromero at linux.vnet.ibm.com Wed Sep 5 16:20:31 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 5 Sep 2018 13:20:31 -0300 Subject: RFR: 8208171: PPC64: Enrich SLP support In-Reply-To: References: <346da54af45243c4bdaf475f118a450d@sap.com> <9553d65d98f74f37a35b49a1e39f015e@sap.com> <48ee8bca-fd73-7854-84fd-20b836c00651@linux.vnet.ibm.com> Message-ID: <0fb73e86-12b8-a5d1-f9bb-5f4963606fbc@linux.vnet.ibm.com> Hi Martin, On 09/03/2018 02:18 PM, Doerr, Martin wrote: > Hi Gustavo and Michihiro, > > we noticed jtreg test failures when using this change: > compiler/runtime/safepoints/TestRegisterRestoring.java > compiler/runtime/Test7196199.java > > TestRegisterRestoring is a simple test which returns arbitrary results instead of 10000. Just to confirm I understood the description correctly: Where you able to check it's returning random values for the array instead of 10_000 or you just checked that test failed? Also, did you pass -XX:-SuperwordUseVSX when it failed? I'm asking because I'm able to fail that test due to a timeout, but not sure if it's the same you got there. Look (I'm using the same kernel as yours): http://cr.openjdk.java.net/~gromero/logs/slp_failure0.txt Thank you. Best regards, Gustavo > We didn't see it on all machines, so it might be an issue with saving&restoring VR registers in the signal handler. > The machine which I have used has "SUSE Linux Enterprise Server 12 SP3" with kernel 4.4.126-94.22-default. > > That's what I found out so far. Maybe you have an idea? > > I also noticed that "-XX:-SuperwordUseVSX" crashes with bad ad file when your patch is applied. Looks like matching the vector nodes needs to be prevented. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of Gustavo Romero > Sent: Montag, 3. September 2018 14:57 > To: Lindenmaier, Goetz ; Michihiro Horie > Cc: hotspot compiler ; hotspot-dev at openjdk.java.net > Subject: Re: RFR: 8208171: PPC64: Enrich SLP support > > Hi Goetz, > > On 09/03/2018 09:27 AM, Lindenmaier, Goetz wrote: >> Also, I can not find all of the mail traffic in >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/thread.html. >> Is this a problem of the pipermail server? >> >> For some reason this webrev lacks the links to browse the diffs. >> Do you need to use a more recent webrev? You can obtain it with >> hg clone http://hg.openjdk.java.net/code-tools/webrev/ . > > Yes, probably it was a problem of the pipermail or in some relay. > I noted the same thing, i.e. at least one Michi reply arrived > to me but missed a ML. > > The initial discussion is here: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-July/003613.html > > I understand Martin reviewed the last webrev in that thread, which is > http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ (taken from > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-July/003615.html) > > Martin's review of webrev.01: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/033958.html > > and Michi's reply to Martin's review of webrev.01: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-August/003632.html (with webrev.02, > taken from http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-August/003632.html). > > and your last review: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-September/030419.html > > > HTH. > > Best regards, > Gustavo > >> Why do you rename vnoreg to vnoregi? >> >> Besides that the change is fine, thanks for implementing this! >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: Doerr, Martin >>> Sent: Dienstag, 28. August 2018 19:35 >>> To: Gustavo Romero ; Michihiro Horie >>> >>> Cc: Lindenmaier, Goetz ; hotspot- >>> dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker >>> >>> Subject: RE: RFR: 8208171: PPC64: Enrich SLP support >>> >>> Hi Michihiro, >>> >>> thank you for implementing it. I have just taken a first look at your >>> webrev.01. >>> >>> It looks basically good. Only the Power version check seems to be incorrect. >>> VM_Version::has_popcntb() checks for Power5. >>> I believe most instructions are available with Power7. >>> Some ones (vsubudm, ..., vmmuluwm, vpopcntw) were introduced with >>> Power8? >>> We should check this carefully. >>> >>> Also, indentation in register_ppc.hpp could get improved. >>> >>> Thanks and best regard, >>> Martin >>> >>> >>> -----Original Message----- >>> From: Gustavo Romero >>> Sent: Donnerstag, 26. Juli 2018 16:02 >>> To: Michihiro Horie >>> Cc: Lindenmaier, Goetz ; hotspot- >>> dev at openjdk.java.net; Doerr, Martin ; ppc-aix- >>> port-dev at openjdk.java.net; Simonis, Volker >>> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >>> >>> Hi Michi, >>> >>> On 07/26/2018 01:43 AM, Michihiro Horie wrote: >>>> I updated webrev: >>>> http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ >>> >>> Thanks for providing an updated webrev and for fixing indentation and >>> function >>> order in assembler_ppc.inline.hpp as well. I have no further comments :) >>> >>> >>> Best Regards, >>> Gustavo >>> >>>> >>>> Best regards, >>>> -- >>>> Michihiro, >>>> IBM Research - Tokyo >>>> >>>> Inactive hide details for Gustavo Romero ---2018/07/25 23:05:32---Hi Michi, >>> On 07/25/2018 02:43 AM, Michihiro Horie wrote:Gustavo Romero --- >>> 2018/07/25 23:05:32---Hi Michi, On 07/25/2018 02:43 AM, Michihiro Horie >>> wrote: >>>> >>>> From: Gustavo Romero >>>> To: Michihiro Horie/Japan/IBM at IBMJP, ppc-aix-port- >>> dev at openjdk.java.net, hotspot-dev at openjdk.java.net >>>> Cc: goetz.lindenmaier at sap.com, volker.simonis at sap.com, "Doerr, Martin" >>> >>>> Date: 2018/07/25 23:05 >>>> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >>>> >>>> ------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ----------------------------------------------------- >>>> >>>> >>>> >>>> Hi Michi, >>>> >>>> On 07/25/2018 02:43 AM, Michihiro Horie wrote: >>>> > Dear all, >>>> > >>>> > Would you review the following change? >>>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8208171 >>>> > Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00 >>>> > >>>> > This change adds support for vectorized arithmetic calculation with SLP. >>>> > >>>> > The to_vr function is added to convert VSR to VR. Currently, vecX is >>> associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, >>> which are exactly overlapped with VRs. Instruction APIs receiving VRs use the >>> to_vr via vecX. Another thing is the change in sqrtF_reg to enable the >>> matching with SqrtVF. I think the change in sqrtF_reg would be fine due to >>> the ConvD2FNode::Value in convertnode.cpp. >>>> >>>> Looks good. Just a few comments: >>>> >>>> - In vmul4F_reg() would it be reasonable to use xvmulsp instead of >>> vmaddfp in >>>> order to avoid the splat? >>>> >>>> - Although all instructions added by your change where introduced in ISA >>> 2.06, >>>> so POWER7 and above are OK, as I see probes for >>> PowerArchictecturePPC64=6|5 in >>>> vm_version_ppc.cpp (line 64), I'm wondering if there is any control point >>> to >>>> guarantee that these instructions won't be emitted on a CPU that does >>> not >>>> support them. >>>> >>>> - I think that in general string in format %{} are in upper case. For instance, >>>> this the current output on optoassembly for vmul4F: >>>> >>>> 2941835 5b4 ADDI R24, R24, #64 >>>> 2941836 5b8 vmaddfp VSR32,VSR32,VSR36 ! mul packed4F >>>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector >>>> >>>> I think it would be better to be in upper case instead. I also think that if >>>> the node match emits more than one instruction all instructions must be >>> listed >>>> in format %{}, since it's meant for detailed debugging. Finally I think it >>>> would be better to replace \t! by \t// in that string (unless I'm missing any >>>> special meaning for that char). So for vmul4F it would be something like: >>>> >>>> 2941835 5b4 ADDI R24, R24, #64 >>>> VSPLTISW VSR34, 0 // Splat 0 imm in VSR34 >>>> 2941836 5b8 VMADDFP VSR32,VSR32,VSR36,VSR34 // Mul packed4F >>>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector >>>> >>>> >>>> But feel free to change anything just after you get additional reviews :) >>>> >>>> >>>> > I confirmed this change with JTREG. In addition, I used attached micro >>> benchmarks. >>>> > /(See attached file: slp_microbench.zip)/ >>>> >>>> Thanks for sharing it. >>>> Btw, another option to host it would be in the CR >>>> server, in http://cr.openjdk.java.net/~mhorie/8208171 >>>> >>>> >>>> Best regards, >>>> Gustavo >>>> >>>> > >>>> > Best regards, >>>> > -- >>>> > Michihiro, >>>> > IBM Research - Tokyo >>>> > >>>> >>>> >>>> >> > From erik.joelsson at oracle.com Wed Sep 5 16:57:06 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 5 Sep 2018 09:57:06 -0700 Subject: RFR : [XS] 8209942: [epsilon] range function for EpsilonTLABElasticity causes compiler warning In-Reply-To: <6ac4615d86ec4d42b99657285507aa66@sap.com> References: <6ac4615d86ec4d42b99657285507aa66@sap.com> Message-ID: On 2018-09-05 04:03, Baesken, Matthias wrote: > Hello, when compiling jdk/jdk on Windows, (with VS2017 update level 15.8 and not disabling warnings as errors ) > I came across this warning leading to build error : > > C:/jdk-just-clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): error C2220: warning treated as error - no 'object' file generated > C:/jdk-just-clone/src/hotspot/share/runtime/flags/jvmFlagRangeList.cpp(341): warning C4305: 'argument': truncation from 'const intx' to 'double' > > Would have been helpful to have a compiler flag set that really ***shows the code*** leading to the warning/error (because it comes from heavy macro expansion). > Do you know of such a flag? If so we certain would like to add it. /Erik From erik.joelsson at oracle.com Wed Sep 5 17:00:09 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 5 Sep 2018 10:00:09 -0700 Subject: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig In-Reply-To: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com> References: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com> Message-ID: Hello, Looks good to me. /Erik On 2018-09-05 05:11, Magnus Ihse Bursie wrote: > When I removed (mostly) all mapfiles for the JDK libraries, building > of libjsig started failing on Solaris, and that part was backed out. > > Here's a new, and improved solution to remove the mapfile for libjsig, > even on Solaris. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200609 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01 > > /Magnus > From martin.doerr at sap.com Wed Sep 5 17:45:22 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 5 Sep 2018 17:45:22 +0000 Subject: RFR: 8208171: PPC64: Enrich SLP support In-Reply-To: <0fb73e86-12b8-a5d1-f9bb-5f4963606fbc@linux.vnet.ibm.com> References: <346da54af45243c4bdaf475f118a450d@sap.com> <9553d65d98f74f37a35b49a1e39f015e@sap.com> <48ee8bca-fd73-7854-84fd-20b836c00651@linux.vnet.ibm.com> <0fb73e86-12b8-a5d1-f9bb-5f4963606fbc@linux.vnet.ibm.com> Message-ID: <6eb4c5c5d42d49bf8564e8bfae1b3e9b@sap.com> Hi Gustavo, thank you for your detailed explanation. I wonder what happens with the registers when VSX gets disabled, but the regs are read again many context switches later. But I guess this is solved somehow. I'm getting different incorrect results every time I run the test on some machines, while other machines always compute the correct result and the test passes. But I found out that the problem shows up with different kernel versions (4.4.0-101-generic, 3.10.0-693.1.1.el7.ppc64le, 4.4.126-94.22-default). So I guess it's rather unlikely that the problem is only caused by the OS. After more investigation, it rather looks like v0 is not preserved across the safepoint: vs32 = v0, vs36 = v4, vs40 = v8 0x00007fff6813e6d0: extsw r15,r17 0x00007fff6813e6d4: rldic r18,r17,2,30 0x00007fff6813e6d8: add r18,r21,r18 0x00007fff6813e6dc: addi r20,r18,16 0x00007fff6813e6e0: addi r18,r18,16 0x00007fff6813e6e4: lxvd2x vs36,0,r18 0x00007fff6813e6e8: vaddfp v4,v4,v0 0x00007fff6813e6ec: rldicr r15,r15,2,61 0x00007fff6813e6f0: add r15,r21,r15 0x00007fff6813e6f4: addi r18,r15,32 0x00007fff6813e6f8: addi r15,r15,32 0x00007fff6813e6fc: lxvd2x vs40,0,r15 ;*faload {reexecute=0 rethrow=0 return_oop=0} ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 21 (line 62) 0x00007fff6813e700: stxvd2x vs36,0,r20 0x00007fff6813e704: vaddfp v4,v8,v0 0x00007fff6813e708: stxvd2x vs36,0,r18 ;*fastore {reexecute=0 rethrow=0 return_oop=0} ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 24 (line 62) 0x00007fff6813e70c: addi r17,r17,8 ;*iinc {reexecute=0 rethrow=0 return_oop=0} ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 25 (line 61) 0x00007fff6813e710: cmpw cr5,r17,r24 0x00007fff6813e714: blt cr5,0x00007fff6813e6d0 ;*goto {reexecute=0 rethrow=0 return_oop=0} ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 28 (line 61) ;; B15: # B14 B16 <- B14 Freq: 12356.3 0x00007fff6813e718: ld r15,288(r16) ; ImmutableOopMap{R21=Oop } ;*goto {reexecute=1 rethrow=0 return_oop=0} ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 28 (line 61) 0x00007fff6813e71c: tdlgei r15,8 ;*goto {reexecute=0 rethrow=0 return_oop=0} ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 28 (line 61) ; {poll} 0x00007fff6813e720: cmpw cr6,r17,r24 0x00007fff6813e724: blt cr6,0x00007fff6813e6d0 At the end of the method, I see v4_float = {10000, 10000, 10000, 10000} on machines on which the test passes. On a machine on which it fails, e.g. v4_float = {0xffffffff, 0x8a296200, 0xffffffff, 0xffffffff} I thought we had already checked saving and restoring vector registers at safepoints, but seems like we have missed something. Best regards, Martin -----Original Message----- From: Gustavo Romero Sent: Mittwoch, 5. September 2018 18:21 To: Doerr, Martin ; Lindenmaier, Goetz ; Michihiro Horie Cc: hotspot compiler ; hotspot-dev at openjdk.java.net Subject: Re: RFR: 8208171: PPC64: Enrich SLP support Hi Martin, On 09/03/2018 02:18 PM, Doerr, Martin wrote: > Hi Gustavo and Michihiro, > > we noticed jtreg test failures when using this change: > compiler/runtime/safepoints/TestRegisterRestoring.java > compiler/runtime/Test7196199.java > > TestRegisterRestoring is a simple test which returns arbitrary results instead of 10000. Just to confirm I understood the description correctly: Where you able to check it's returning random values for the array instead of 10_000 or you just checked that test failed? Also, did you pass -XX:-SuperwordUseVSX when it failed? I'm asking because I'm able to fail that test due to a timeout, but not sure if it's the same you got there. Look (I'm using the same kernel as yours): http://cr.openjdk.java.net/~gromero/logs/slp_failure0.txt Thank you. Best regards, Gustavo > We didn't see it on all machines, so it might be an issue with saving&restoring VR registers in the signal handler. > The machine which I have used has "SUSE Linux Enterprise Server 12 SP3" with kernel 4.4.126-94.22-default. > > That's what I found out so far. Maybe you have an idea? > > I also noticed that "-XX:-SuperwordUseVSX" crashes with bad ad file when your patch is applied. Looks like matching the vector nodes needs to be prevented. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of Gustavo Romero > Sent: Montag, 3. September 2018 14:57 > To: Lindenmaier, Goetz ; Michihiro Horie > Cc: hotspot compiler ; hotspot-dev at openjdk.java.net > Subject: Re: RFR: 8208171: PPC64: Enrich SLP support > > Hi Goetz, > > On 09/03/2018 09:27 AM, Lindenmaier, Goetz wrote: >> Also, I can not find all of the mail traffic in >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/thread.html. >> Is this a problem of the pipermail server? >> >> For some reason this webrev lacks the links to browse the diffs. >> Do you need to use a more recent webrev? You can obtain it with >> hg clone http://hg.openjdk.java.net/code-tools/webrev/ . > > Yes, probably it was a problem of the pipermail or in some relay. > I noted the same thing, i.e. at least one Michi reply arrived > to me but missed a ML. > > The initial discussion is here: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-July/003613.html > > I understand Martin reviewed the last webrev in that thread, which is > http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ (taken from > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-July/003615.html) > > Martin's review of webrev.01: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/033958.html > > and Michi's reply to Martin's review of webrev.01: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-August/003632.html (with webrev.02, > taken from http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-August/003632.html). > > and your last review: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-September/030419.html > > > HTH. > > Best regards, > Gustavo > >> Why do you rename vnoreg to vnoregi? >> >> Besides that the change is fine, thanks for implementing this! >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: Doerr, Martin >>> Sent: Dienstag, 28. August 2018 19:35 >>> To: Gustavo Romero ; Michihiro Horie >>> >>> Cc: Lindenmaier, Goetz ; hotspot- >>> dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker >>> >>> Subject: RE: RFR: 8208171: PPC64: Enrich SLP support >>> >>> Hi Michihiro, >>> >>> thank you for implementing it. I have just taken a first look at your >>> webrev.01. >>> >>> It looks basically good. Only the Power version check seems to be incorrect. >>> VM_Version::has_popcntb() checks for Power5. >>> I believe most instructions are available with Power7. >>> Some ones (vsubudm, ..., vmmuluwm, vpopcntw) were introduced with >>> Power8? >>> We should check this carefully. >>> >>> Also, indentation in register_ppc.hpp could get improved. >>> >>> Thanks and best regard, >>> Martin >>> >>> >>> -----Original Message----- >>> From: Gustavo Romero >>> Sent: Donnerstag, 26. Juli 2018 16:02 >>> To: Michihiro Horie >>> Cc: Lindenmaier, Goetz ; hotspot- >>> dev at openjdk.java.net; Doerr, Martin ; ppc-aix- >>> port-dev at openjdk.java.net; Simonis, Volker >>> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >>> >>> Hi Michi, >>> >>> On 07/26/2018 01:43 AM, Michihiro Horie wrote: >>>> I updated webrev: >>>> http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ >>> >>> Thanks for providing an updated webrev and for fixing indentation and >>> function >>> order in assembler_ppc.inline.hpp as well. I have no further comments :) >>> >>> >>> Best Regards, >>> Gustavo >>> >>>> >>>> Best regards, >>>> -- >>>> Michihiro, >>>> IBM Research - Tokyo >>>> >>>> Inactive hide details for Gustavo Romero ---2018/07/25 23:05:32---Hi Michi, >>> On 07/25/2018 02:43 AM, Michihiro Horie wrote:Gustavo Romero --- >>> 2018/07/25 23:05:32---Hi Michi, On 07/25/2018 02:43 AM, Michihiro Horie >>> wrote: >>>> >>>> From: Gustavo Romero >>>> To: Michihiro Horie/Japan/IBM at IBMJP, ppc-aix-port- >>> dev at openjdk.java.net, hotspot-dev at openjdk.java.net >>>> Cc: goetz.lindenmaier at sap.com, volker.simonis at sap.com, "Doerr, Martin" >>> >>>> Date: 2018/07/25 23:05 >>>> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >>>> >>>> ------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ----------------------------------------------------- >>>> >>>> >>>> >>>> Hi Michi, >>>> >>>> On 07/25/2018 02:43 AM, Michihiro Horie wrote: >>>> > Dear all, >>>> > >>>> > Would you review the following change? >>>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8208171 >>>> > Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00 >>>> > >>>> > This change adds support for vectorized arithmetic calculation with SLP. >>>> > >>>> > The to_vr function is added to convert VSR to VR. Currently, vecX is >>> associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, >>> which are exactly overlapped with VRs. Instruction APIs receiving VRs use the >>> to_vr via vecX. Another thing is the change in sqrtF_reg to enable the >>> matching with SqrtVF. I think the change in sqrtF_reg would be fine due to >>> the ConvD2FNode::Value in convertnode.cpp. >>>> >>>> Looks good. Just a few comments: >>>> >>>> - In vmul4F_reg() would it be reasonable to use xvmulsp instead of >>> vmaddfp in >>>> order to avoid the splat? >>>> >>>> - Although all instructions added by your change where introduced in ISA >>> 2.06, >>>> so POWER7 and above are OK, as I see probes for >>> PowerArchictecturePPC64=6|5 in >>>> vm_version_ppc.cpp (line 64), I'm wondering if there is any control point >>> to >>>> guarantee that these instructions won't be emitted on a CPU that does >>> not >>>> support them. >>>> >>>> - I think that in general string in format %{} are in upper case. For instance, >>>> this the current output on optoassembly for vmul4F: >>>> >>>> 2941835 5b4 ADDI R24, R24, #64 >>>> 2941836 5b8 vmaddfp VSR32,VSR32,VSR36 ! mul packed4F >>>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector >>>> >>>> I think it would be better to be in upper case instead. I also think that if >>>> the node match emits more than one instruction all instructions must be >>> listed >>>> in format %{}, since it's meant for detailed debugging. Finally I think it >>>> would be better to replace \t! by \t// in that string (unless I'm missing any >>>> special meaning for that char). So for vmul4F it would be something like: >>>> >>>> 2941835 5b4 ADDI R24, R24, #64 >>>> VSPLTISW VSR34, 0 // Splat 0 imm in VSR34 >>>> 2941836 5b8 VMADDFP VSR32,VSR32,VSR36,VSR34 // Mul packed4F >>>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector >>>> >>>> >>>> But feel free to change anything just after you get additional reviews :) >>>> >>>> >>>> > I confirmed this change with JTREG. In addition, I used attached micro >>> benchmarks. >>>> > /(See attached file: slp_microbench.zip)/ >>>> >>>> Thanks for sharing it. >>>> Btw, another option to host it would be in the CR >>>> server, in http://cr.openjdk.java.net/~mhorie/8208171 >>>> >>>> >>>> Best regards, >>>> Gustavo >>>> >>>> > >>>> > Best regards, >>>> > -- >>>> > Michihiro, >>>> > IBM Research - Tokyo >>>> > >>>> >>>> >>>> >> > From martin.doerr at sap.com Wed Sep 5 18:10:01 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 5 Sep 2018 18:10:01 +0000 Subject: RFR: 8208171: PPC64: Enrich SLP support In-Reply-To: <6eb4c5c5d42d49bf8564e8bfae1b3e9b@sap.com> References: <346da54af45243c4bdaf475f118a450d@sap.com> <9553d65d98f74f37a35b49a1e39f015e@sap.com> <48ee8bca-fd73-7854-84fd-20b836c00651@linux.vnet.ibm.com> <0fb73e86-12b8-a5d1-f9bb-5f4963606fbc@linux.vnet.ibm.com> <6eb4c5c5d42d49bf8564e8bfae1b3e9b@sap.com> Message-ID: <90edf96036f24d91acfd6b649d65c41b@sap.com> Hi Michihiro, support for POLL_AT_VECTOR_LOOP is required in the handler_blob / RegisterSaver like on x86. We haven't seen any issues with the current code, but I think this is affects jdk11, too. (We could also switch off SuperwordUseVSX for jdk11u.) Do you agree? Best regards, Martin -----Original Message----- From: Doerr, Martin Sent: Mittwoch, 5. September 2018 19:45 To: 'Gustavo Romero' ; Lindenmaier, Goetz ; Michihiro Horie Cc: hotspot compiler ; hotspot-dev at openjdk.java.net Subject: RE: RFR: 8208171: PPC64: Enrich SLP support Hi Gustavo, thank you for your detailed explanation. I wonder what happens with the registers when VSX gets disabled, but the regs are read again many context switches later. But I guess this is solved somehow. I'm getting different incorrect results every time I run the test on some machines, while other machines always compute the correct result and the test passes. But I found out that the problem shows up with different kernel versions (4.4.0-101-generic, 3.10.0-693.1.1.el7.ppc64le, 4.4.126-94.22-default). So I guess it's rather unlikely that the problem is only caused by the OS. After more investigation, it rather looks like v0 is not preserved across the safepoint: vs32 = v0, vs36 = v4, vs40 = v8 0x00007fff6813e6d0: extsw r15,r17 0x00007fff6813e6d4: rldic r18,r17,2,30 0x00007fff6813e6d8: add r18,r21,r18 0x00007fff6813e6dc: addi r20,r18,16 0x00007fff6813e6e0: addi r18,r18,16 0x00007fff6813e6e4: lxvd2x vs36,0,r18 0x00007fff6813e6e8: vaddfp v4,v4,v0 0x00007fff6813e6ec: rldicr r15,r15,2,61 0x00007fff6813e6f0: add r15,r21,r15 0x00007fff6813e6f4: addi r18,r15,32 0x00007fff6813e6f8: addi r15,r15,32 0x00007fff6813e6fc: lxvd2x vs40,0,r15 ;*faload {reexecute=0 rethrow=0 return_oop=0} ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 21 (line 62) 0x00007fff6813e700: stxvd2x vs36,0,r20 0x00007fff6813e704: vaddfp v4,v8,v0 0x00007fff6813e708: stxvd2x vs36,0,r18 ;*fastore {reexecute=0 rethrow=0 return_oop=0} ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 24 (line 62) 0x00007fff6813e70c: addi r17,r17,8 ;*iinc {reexecute=0 rethrow=0 return_oop=0} ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 25 (line 61) 0x00007fff6813e710: cmpw cr5,r17,r24 0x00007fff6813e714: blt cr5,0x00007fff6813e6d0 ;*goto {reexecute=0 rethrow=0 return_oop=0} ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 28 (line 61) ;; B15: # B14 B16 <- B14 Freq: 12356.3 0x00007fff6813e718: ld r15,288(r16) ; ImmutableOopMap{R21=Oop } ;*goto {reexecute=1 rethrow=0 return_oop=0} ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 28 (line 61) 0x00007fff6813e71c: tdlgei r15,8 ;*goto {reexecute=0 rethrow=0 return_oop=0} ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 28 (line 61) ; {poll} 0x00007fff6813e720: cmpw cr6,r17,r24 0x00007fff6813e724: blt cr6,0x00007fff6813e6d0 At the end of the method, I see v4_float = {10000, 10000, 10000, 10000} on machines on which the test passes. On a machine on which it fails, e.g. v4_float = {0xffffffff, 0x8a296200, 0xffffffff, 0xffffffff} I thought we had already checked saving and restoring vector registers at safepoints, but seems like we have missed something. Best regards, Martin -----Original Message----- From: Gustavo Romero Sent: Mittwoch, 5. September 2018 18:21 To: Doerr, Martin ; Lindenmaier, Goetz ; Michihiro Horie Cc: hotspot compiler ; hotspot-dev at openjdk.java.net Subject: Re: RFR: 8208171: PPC64: Enrich SLP support Hi Martin, On 09/03/2018 02:18 PM, Doerr, Martin wrote: > Hi Gustavo and Michihiro, > > we noticed jtreg test failures when using this change: > compiler/runtime/safepoints/TestRegisterRestoring.java > compiler/runtime/Test7196199.java > > TestRegisterRestoring is a simple test which returns arbitrary results instead of 10000. Just to confirm I understood the description correctly: Where you able to check it's returning random values for the array instead of 10_000 or you just checked that test failed? Also, did you pass -XX:-SuperwordUseVSX when it failed? I'm asking because I'm able to fail that test due to a timeout, but not sure if it's the same you got there. Look (I'm using the same kernel as yours): http://cr.openjdk.java.net/~gromero/logs/slp_failure0.txt Thank you. Best regards, Gustavo > We didn't see it on all machines, so it might be an issue with saving&restoring VR registers in the signal handler. > The machine which I have used has "SUSE Linux Enterprise Server 12 SP3" with kernel 4.4.126-94.22-default. > > That's what I found out so far. Maybe you have an idea? > > I also noticed that "-XX:-SuperwordUseVSX" crashes with bad ad file when your patch is applied. Looks like matching the vector nodes needs to be prevented. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of Gustavo Romero > Sent: Montag, 3. September 2018 14:57 > To: Lindenmaier, Goetz ; Michihiro Horie > Cc: hotspot compiler ; hotspot-dev at openjdk.java.net > Subject: Re: RFR: 8208171: PPC64: Enrich SLP support > > Hi Goetz, > > On 09/03/2018 09:27 AM, Lindenmaier, Goetz wrote: >> Also, I can not find all of the mail traffic in >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/thread.html. >> Is this a problem of the pipermail server? >> >> For some reason this webrev lacks the links to browse the diffs. >> Do you need to use a more recent webrev? You can obtain it with >> hg clone http://hg.openjdk.java.net/code-tools/webrev/ . > > Yes, probably it was a problem of the pipermail or in some relay. > I noted the same thing, i.e. at least one Michi reply arrived > to me but missed a ML. > > The initial discussion is here: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-July/003613.html > > I understand Martin reviewed the last webrev in that thread, which is > http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ (taken from > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-July/003615.html) > > Martin's review of webrev.01: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/033958.html > > and Michi's reply to Martin's review of webrev.01: > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-August/003632.html (with webrev.02, > taken from http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-August/003632.html). > > and your last review: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-September/030419.html > > > HTH. > > Best regards, > Gustavo > >> Why do you rename vnoreg to vnoregi? >> >> Besides that the change is fine, thanks for implementing this! >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: Doerr, Martin >>> Sent: Dienstag, 28. August 2018 19:35 >>> To: Gustavo Romero ; Michihiro Horie >>> >>> Cc: Lindenmaier, Goetz ; hotspot- >>> dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker >>> >>> Subject: RE: RFR: 8208171: PPC64: Enrich SLP support >>> >>> Hi Michihiro, >>> >>> thank you for implementing it. I have just taken a first look at your >>> webrev.01. >>> >>> It looks basically good. Only the Power version check seems to be incorrect. >>> VM_Version::has_popcntb() checks for Power5. >>> I believe most instructions are available with Power7. >>> Some ones (vsubudm, ..., vmmuluwm, vpopcntw) were introduced with >>> Power8? >>> We should check this carefully. >>> >>> Also, indentation in register_ppc.hpp could get improved. >>> >>> Thanks and best regard, >>> Martin >>> >>> >>> -----Original Message----- >>> From: Gustavo Romero >>> Sent: Donnerstag, 26. Juli 2018 16:02 >>> To: Michihiro Horie >>> Cc: Lindenmaier, Goetz ; hotspot- >>> dev at openjdk.java.net; Doerr, Martin ; ppc-aix- >>> port-dev at openjdk.java.net; Simonis, Volker >>> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >>> >>> Hi Michi, >>> >>> On 07/26/2018 01:43 AM, Michihiro Horie wrote: >>>> I updated webrev: >>>> http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ >>> >>> Thanks for providing an updated webrev and for fixing indentation and >>> function >>> order in assembler_ppc.inline.hpp as well. I have no further comments :) >>> >>> >>> Best Regards, >>> Gustavo >>> >>>> >>>> Best regards, >>>> -- >>>> Michihiro, >>>> IBM Research - Tokyo >>>> >>>> Inactive hide details for Gustavo Romero ---2018/07/25 23:05:32---Hi Michi, >>> On 07/25/2018 02:43 AM, Michihiro Horie wrote:Gustavo Romero --- >>> 2018/07/25 23:05:32---Hi Michi, On 07/25/2018 02:43 AM, Michihiro Horie >>> wrote: >>>> >>>> From: Gustavo Romero >>>> To: Michihiro Horie/Japan/IBM at IBMJP, ppc-aix-port- >>> dev at openjdk.java.net, hotspot-dev at openjdk.java.net >>>> Cc: goetz.lindenmaier at sap.com, volker.simonis at sap.com, "Doerr, Martin" >>> >>>> Date: 2018/07/25 23:05 >>>> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >>>> >>>> ------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ---------------------------------------------------------------------------------------------- >>> ----------------------------------------------------- >>>> >>>> >>>> >>>> Hi Michi, >>>> >>>> On 07/25/2018 02:43 AM, Michihiro Horie wrote: >>>> > Dear all, >>>> > >>>> > Would you review the following change? >>>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8208171 >>>> > Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00 >>>> > >>>> > This change adds support for vectorized arithmetic calculation with SLP. >>>> > >>>> > The to_vr function is added to convert VSR to VR. Currently, vecX is >>> associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, >>> which are exactly overlapped with VRs. Instruction APIs receiving VRs use the >>> to_vr via vecX. Another thing is the change in sqrtF_reg to enable the >>> matching with SqrtVF. I think the change in sqrtF_reg would be fine due to >>> the ConvD2FNode::Value in convertnode.cpp. >>>> >>>> Looks good. Just a few comments: >>>> >>>> - In vmul4F_reg() would it be reasonable to use xvmulsp instead of >>> vmaddfp in >>>> order to avoid the splat? >>>> >>>> - Although all instructions added by your change where introduced in ISA >>> 2.06, >>>> so POWER7 and above are OK, as I see probes for >>> PowerArchictecturePPC64=6|5 in >>>> vm_version_ppc.cpp (line 64), I'm wondering if there is any control point >>> to >>>> guarantee that these instructions won't be emitted on a CPU that does >>> not >>>> support them. >>>> >>>> - I think that in general string in format %{} are in upper case. For instance, >>>> this the current output on optoassembly for vmul4F: >>>> >>>> 2941835 5b4 ADDI R24, R24, #64 >>>> 2941836 5b8 vmaddfp VSR32,VSR32,VSR36 ! mul packed4F >>>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector >>>> >>>> I think it would be better to be in upper case instead. I also think that if >>>> the node match emits more than one instruction all instructions must be >>> listed >>>> in format %{}, since it's meant for detailed debugging. Finally I think it >>>> would be better to replace \t! by \t// in that string (unless I'm missing any >>>> special meaning for that char). So for vmul4F it would be something like: >>>> >>>> 2941835 5b4 ADDI R24, R24, #64 >>>> VSPLTISW VSR34, 0 // Splat 0 imm in VSR34 >>>> 2941836 5b8 VMADDFP VSR32,VSR32,VSR36,VSR34 // Mul packed4F >>>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector >>>> >>>> >>>> But feel free to change anything just after you get additional reviews :) >>>> >>>> >>>> > I confirmed this change with JTREG. In addition, I used attached micro >>> benchmarks. >>>> > /(See attached file: slp_microbench.zip)/ >>>> >>>> Thanks for sharing it. >>>> Btw, another option to host it would be in the CR >>>> server, in http://cr.openjdk.java.net/~mhorie/8208171 >>>> >>>> >>>> Best regards, >>>> Gustavo >>>> >>>> > >>>> > Best regards, >>>> > -- >>>> > Michihiro, >>>> > IBM Research - Tokyo >>>> > >>>> >>>> >>>> >> > From gromero at linux.vnet.ibm.com Wed Sep 5 18:29:25 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 5 Sep 2018 15:29:25 -0300 Subject: RFR: 8208171: PPC64: Enrich SLP support In-Reply-To: <6eb4c5c5d42d49bf8564e8bfae1b3e9b@sap.com> References: <346da54af45243c4bdaf475f118a450d@sap.com> <9553d65d98f74f37a35b49a1e39f015e@sap.com> <48ee8bca-fd73-7854-84fd-20b836c00651@linux.vnet.ibm.com> <0fb73e86-12b8-a5d1-f9bb-5f4963606fbc@linux.vnet.ibm.com> <6eb4c5c5d42d49bf8564e8bfae1b3e9b@sap.com> Message-ID: <71b0c876-25a2-f757-375f-686477d2d2c7@linux.vnet.ibm.com> Hi Martin, On 09/05/2018 02:45 PM, Doerr, Martin wrote: > Hi Gustavo, > > thank you for your detailed explanation. I wonder what happens with the registers when VSX gets disabled, but the regs are read again many context switches later. But I guess this is solved somehow. No problem! Yes, kernel solves that too: once a VSX instruction is used again and VSX is disabled it generates an exception and the exception handler calls load_up_vsx(): https://github.com/torvalds/linux/blob/master/arch/powerpc/kernel/vector.S#L119 load_up_vsx() calls, by its turn, load_up_fpu() and load_up_vec() to load FP and VEC registers from the thread struct associated to the task that wants to use the VSX facility again. That thread struct contains the correct FP/VEC/VSX registers saved many context switches before when the facilities where disabled. The best description on what happens in this case (valid for VEC and VSX as well) can be found in load_up_fpu() description: https://github.com/torvalds/linux/blob/master/arch/powerpc/kernel/fpu.S#L79-L83 : * This task wants to use the FPU now. * On UP, disable FP for the task which had the FPU previously, * and save its floating-point registers in its thread_struct. * Load up this task's FP registers from its thread_struct, * enable the FPU for the current task and return to the task. Here UP stand for Uni Processor (in case we are running a machine with only 1 CPU). > I'm getting different incorrect results every time I run the test on some machines, while other machines always compute the correct result and the test passes. > > But I found out that the problem shows up with different kernel versions (4.4.0-101-generic, 3.10.0-693.1.1.el7.ppc64le, 4.4.126-94.22-default). So I guess it's rather unlikely that the problem is only caused by the OS. > > After more investigation, it rather looks like v0 is not preserved across the safepoint: > > vs32 = v0, vs36 = v4, vs40 = v8 > > 0x00007fff6813e6d0: extsw r15,r17 > 0x00007fff6813e6d4: rldic r18,r17,2,30 > 0x00007fff6813e6d8: add r18,r21,r18 > 0x00007fff6813e6dc: addi r20,r18,16 > 0x00007fff6813e6e0: addi r18,r18,16 > 0x00007fff6813e6e4: lxvd2x vs36,0,r18 > 0x00007fff6813e6e8: vaddfp v4,v4,v0 > 0x00007fff6813e6ec: rldicr r15,r15,2,61 > 0x00007fff6813e6f0: add r15,r21,r15 > 0x00007fff6813e6f4: addi r18,r15,32 > 0x00007fff6813e6f8: addi r15,r15,32 > 0x00007fff6813e6fc: lxvd2x vs40,0,r15 ;*faload {reexecute=0 rethrow=0 return_oop=0} > ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 21 (line 62) > > 0x00007fff6813e700: stxvd2x vs36,0,r20 > 0x00007fff6813e704: vaddfp v4,v8,v0 > 0x00007fff6813e708: stxvd2x vs36,0,r18 ;*fastore {reexecute=0 rethrow=0 return_oop=0} > ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 24 (line 62) > > 0x00007fff6813e70c: addi r17,r17,8 ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 25 (line 61) > > 0x00007fff6813e710: cmpw cr5,r17,r24 > 0x00007fff6813e714: blt cr5,0x00007fff6813e6d0 ;*goto {reexecute=0 rethrow=0 return_oop=0} > ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 28 (line 61) > > ;; B15: # B14 B16 <- B14 Freq: 12356.3 > > 0x00007fff6813e718: ld r15,288(r16) ; ImmutableOopMap{R21=Oop } > ;*goto {reexecute=1 rethrow=0 return_oop=0} > ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 28 (line 61) > > 0x00007fff6813e71c: tdlgei r15,8 ;*goto {reexecute=0 rethrow=0 return_oop=0} > ; - compiler.runtime.safepoints.TestRegisterRestoring::increment at 28 (line 61) > ; {poll} > 0x00007fff6813e720: cmpw cr6,r17,r24 > 0x00007fff6813e724: blt cr6,0x00007fff6813e6d0 > > > At the end of the method, I see v4_float = {10000, 10000, 10000, 10000} on machines on which the test passes. > On a machine on which it fails, e.g. v4_float = {0xffffffff, 0x8a296200, 0xffffffff, 0xffffffff} > > I thought we had already checked saving and restoring vector registers at safepoints, but seems like we have missed something. OK. So I was not able to reproduce yet... But looks like you pointed out a solution to Michi already, so I'll stay tuned. Thanks. Best regards, Gustavo > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Romero > Sent: Mittwoch, 5. September 2018 18:21 > To: Doerr, Martin ; Lindenmaier, Goetz ; Michihiro Horie > Cc: hotspot compiler ; hotspot-dev at openjdk.java.net > Subject: Re: RFR: 8208171: PPC64: Enrich SLP support > > Hi Martin, > > On 09/03/2018 02:18 PM, Doerr, Martin wrote: >> Hi Gustavo and Michihiro, >> >> we noticed jtreg test failures when using this change: >> compiler/runtime/safepoints/TestRegisterRestoring.java >> compiler/runtime/Test7196199.java >> >> TestRegisterRestoring is a simple test which returns arbitrary results instead of 10000. > > Just to confirm I understood the description correctly: > > Where you able to check it's returning random values for the > array instead of 10_000 or you just checked that test failed? > > Also, did you pass -XX:-SuperwordUseVSX when it failed? I'm > asking because I'm able to fail that test due to a timeout, but not sure > if it's the same you got there. Look (I'm using the same kernel as yours): > > http://cr.openjdk.java.net/~gromero/logs/slp_failure0.txt > > > Thank you. > > Best regards, > Gustavo > >> We didn't see it on all machines, so it might be an issue with saving&restoring VR registers in the signal handler. >> The machine which I have used has "SUSE Linux Enterprise Server 12 SP3" with kernel 4.4.126-94.22-default. >> >> That's what I found out so far. Maybe you have an idea? >> >> I also noticed that "-XX:-SuperwordUseVSX" crashes with bad ad file when your patch is applied. Looks like matching the vector nodes needs to be prevented. >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: hotspot-dev On Behalf Of Gustavo Romero >> Sent: Montag, 3. September 2018 14:57 >> To: Lindenmaier, Goetz ; Michihiro Horie >> Cc: hotspot compiler ; hotspot-dev at openjdk.java.net >> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >> >> Hi Goetz, >> >> On 09/03/2018 09:27 AM, Lindenmaier, Goetz wrote: >>> Also, I can not find all of the mail traffic in >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/thread.html. >>> Is this a problem of the pipermail server? >>> >>> For some reason this webrev lacks the links to browse the diffs. >>> Do you need to use a more recent webrev? You can obtain it with >>> hg clone http://hg.openjdk.java.net/code-tools/webrev/ . >> >> Yes, probably it was a problem of the pipermail or in some relay. >> I noted the same thing, i.e. at least one Michi reply arrived >> to me but missed a ML. >> >> The initial discussion is here: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-July/003613.html >> >> I understand Martin reviewed the last webrev in that thread, which is >> http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ (taken from >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-July/003615.html) >> >> Martin's review of webrev.01: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/033958.html >> >> and Michi's reply to Martin's review of webrev.01: >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-August/003632.html (with webrev.02, >> taken from http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2018-August/003632.html). >> >> and your last review: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-September/030419.html >> >> >> HTH. >> >> Best regards, >> Gustavo >> >>> Why do you rename vnoreg to vnoregi? >>> >>> Besides that the change is fine, thanks for implementing this! >>> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: Doerr, Martin >>>> Sent: Dienstag, 28. August 2018 19:35 >>>> To: Gustavo Romero ; Michihiro Horie >>>> >>>> Cc: Lindenmaier, Goetz ; hotspot- >>>> dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker >>>> >>>> Subject: RE: RFR: 8208171: PPC64: Enrich SLP support >>>> >>>> Hi Michihiro, >>>> >>>> thank you for implementing it. I have just taken a first look at your >>>> webrev.01. >>>> >>>> It looks basically good. Only the Power version check seems to be incorrect. >>>> VM_Version::has_popcntb() checks for Power5. >>>> I believe most instructions are available with Power7. >>>> Some ones (vsubudm, ..., vmmuluwm, vpopcntw) were introduced with >>>> Power8? >>>> We should check this carefully. >>>> >>>> Also, indentation in register_ppc.hpp could get improved. >>>> >>>> Thanks and best regard, >>>> Martin >>>> >>>> >>>> -----Original Message----- >>>> From: Gustavo Romero >>>> Sent: Donnerstag, 26. Juli 2018 16:02 >>>> To: Michihiro Horie >>>> Cc: Lindenmaier, Goetz ; hotspot- >>>> dev at openjdk.java.net; Doerr, Martin ; ppc-aix- >>>> port-dev at openjdk.java.net; Simonis, Volker >>>> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >>>> >>>> Hi Michi, >>>> >>>> On 07/26/2018 01:43 AM, Michihiro Horie wrote: >>>>> I updated webrev: >>>>> http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ >>>> >>>> Thanks for providing an updated webrev and for fixing indentation and >>>> function >>>> order in assembler_ppc.inline.hpp as well. I have no further comments :) >>>> >>>> >>>> Best Regards, >>>> Gustavo >>>> >>>>> >>>>> Best regards, >>>>> -- >>>>> Michihiro, >>>>> IBM Research - Tokyo >>>>> >>>>> Inactive hide details for Gustavo Romero ---2018/07/25 23:05:32---Hi Michi, >>>> On 07/25/2018 02:43 AM, Michihiro Horie wrote:Gustavo Romero --- >>>> 2018/07/25 23:05:32---Hi Michi, On 07/25/2018 02:43 AM, Michihiro Horie >>>> wrote: >>>>> >>>>> From: Gustavo Romero >>>>> To: Michihiro Horie/Japan/IBM at IBMJP, ppc-aix-port- >>>> dev at openjdk.java.net, hotspot-dev at openjdk.java.net >>>>> Cc: goetz.lindenmaier at sap.com, volker.simonis at sap.com, "Doerr, Martin" >>>> >>>>> Date: 2018/07/25 23:05 >>>>> Subject: Re: RFR: 8208171: PPC64: Enrich SLP support >>>>> >>>>> ------------------------------------------------------------------------------------------- >>>> ---------------------------------------------------------------------------------------------- >>>> ---------------------------------------------------------------------------------------------- >>>> ---------------------------------------------------------------------------------------------- >>>> ---------------------------------------------------------------------------------------------- >>>> ---------------------------------------------------------------------------------------------- >>>> ---------------------------------------------------------------------------------------------- >>>> ---------------------------------------------------------------------------------------------- >>>> ---------------------------------------------------------------------------------------------- >>>> ---------------------------------------------------------------------------------------------- >>>> ----------------------------------------------------- >>>>> >>>>> >>>>> >>>>> Hi Michi, >>>>> >>>>> On 07/25/2018 02:43 AM, Michihiro Horie wrote: >>>>> > Dear all, >>>>> > >>>>> > Would you review the following change? >>>>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8208171 >>>>> > Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00 >>>>> > >>>>> > This change adds support for vectorized arithmetic calculation with SLP. >>>>> > >>>>> > The to_vr function is added to convert VSR to VR. Currently, vecX is >>>> associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, >>>> which are exactly overlapped with VRs. Instruction APIs receiving VRs use the >>>> to_vr via vecX. Another thing is the change in sqrtF_reg to enable the >>>> matching with SqrtVF. I think the change in sqrtF_reg would be fine due to >>>> the ConvD2FNode::Value in convertnode.cpp. >>>>> >>>>> Looks good. Just a few comments: >>>>> >>>>> - In vmul4F_reg() would it be reasonable to use xvmulsp instead of >>>> vmaddfp in >>>>> order to avoid the splat? >>>>> >>>>> - Although all instructions added by your change where introduced in ISA >>>> 2.06, >>>>> so POWER7 and above are OK, as I see probes for >>>> PowerArchictecturePPC64=6|5 in >>>>> vm_version_ppc.cpp (line 64), I'm wondering if there is any control point >>>> to >>>>> guarantee that these instructions won't be emitted on a CPU that does >>>> not >>>>> support them. >>>>> >>>>> - I think that in general string in format %{} are in upper case. For instance, >>>>> this the current output on optoassembly for vmul4F: >>>>> >>>>> 2941835 5b4 ADDI R24, R24, #64 >>>>> 2941836 5b8 vmaddfp VSR32,VSR32,VSR36 ! mul packed4F >>>>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector >>>>> >>>>> I think it would be better to be in upper case instead. I also think that if >>>>> the node match emits more than one instruction all instructions must be >>>> listed >>>>> in format %{}, since it's meant for detailed debugging. Finally I think it >>>>> would be better to replace \t! by \t// in that string (unless I'm missing any >>>>> special meaning for that char). So for vmul4F it would be something like: >>>>> >>>>> 2941835 5b4 ADDI R24, R24, #64 >>>>> VSPLTISW VSR34, 0 // Splat 0 imm in VSR34 >>>>> 2941836 5b8 VMADDFP VSR32,VSR32,VSR36,VSR34 // Mul packed4F >>>>> 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector >>>>> >>>>> >>>>> But feel free to change anything just after you get additional reviews :) >>>>> >>>>> >>>>> > I confirmed this change with JTREG. In addition, I used attached micro >>>> benchmarks. >>>>> > /(See attached file: slp_microbench.zip)/ >>>>> >>>>> Thanks for sharing it. >>>>> Btw, another option to host it would be in the CR >>>>> server, in http://cr.openjdk.java.net/~mhorie/8208171 >>>>> >>>>> >>>>> Best regards, >>>>> Gustavo >>>>> >>>>> > >>>>> > Best regards, >>>>> > -- >>>>> > Michihiro, >>>>> > IBM Research - Tokyo >>>>> > >>>>> >>>>> >>>>> >>> >> > From sgehwolf at redhat.com Wed Sep 5 18:36:09 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 05 Sep 2018 20:36:09 +0200 Subject: RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization Message-ID: <944a3ab273c19c25cb3fce81cef929584aa96d66.camel@redhat.com> Hi, On Linux x86 (32 and 64 bit) sharedRuntime{Trans,Trig}.ccp files get compiled with -O0. It appears to be for the same (historical?) reason as for fdlibm files in core-libs. JDK-8210416 is an attempt to make this consistent on all Linux arches (as s390x/ppc64/aarch64 already use that) for fdlibm. This patch does the same for the hotspot copies. Compile it with OPT and -ffp-contract=off instead of no optimization at all. Thoughts? webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 Testing: - make run-test-tier1 (no new failures). - Currently running through submit. - Verified objects get compiled with -O3 -ffp-contract=off in build logs. Thanks, Severin From serguei.spitsyn at oracle.com Wed Sep 5 18:59:36 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 5 Sep 2018 11:59:36 -0700 Subject: RFR: 8210131: vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code In-Reply-To: <32b45126-1a31-1c60-e958-461fa1a6b6c3@oracle.com> References: <39905239-72B3-46A9-B31E-3B01FA5B9BAB@oracle.com> <32b45126-1a31-1c60-e958-461fa1a6b6c3@oracle.com> Message-ID: <3e752930-2eff-2e20-24da-999ed71ab5e7@oracle.com> Hi Kim, The fix looks good to me too. Thank you for taking care about this! One comment below... On 8/31/18 07:19, Daniel D. Daugherty wrote: > On 8/30/18 10:15 PM, Kim Barrett wrote: >> Please review this small change to GetCurrentThreadCpuTimerInfo and >> GetCurrentThreadCpuTime JVMTI operations, allowing them to be called >> from any NamedThread.? This is consistent with the behavior from >> JDK-8203948; there is no obvious reason for these operations to have >> any thread context restriction. >> >> These functions are documented as being callable from heap callbacks >> like ObjectFree, which can be called from an "internal thread or the >> thread that called the [heap] iteration function".? However, unlike >> other, similar functions, these two were requiring the current thread >> to be either a JavaThread or the VMThread.? For other such functions, >> JDK-6278106 had added Concurrent GC threads, and JDK-8203948 >> generalized that to any NamedThread (or JavaThread).? This change >> makes these functions behave similarly. >> >> This is needed to allow such callbacks to be invoked from a GC worker >> thread, such as is now done for G1 (JDK-8072498), and probably other >> collectors in the future.? (See comments for JDK-8203948 for a >> discussion of why ZGC didn't run into this problem.) >> >> This change also removes the failing test from the problem list. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8210131 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8210131/open.00/ > > src/hotspot/share/prims/jvmtiEnter.xsl > ??? No comments. > > test/hotspot/jtreg/ProblemList.txt > ??? No comments. > > > I verified that the XSL changes will only affect the two functions > in question: jvmti_GetCurrentThreadCpuTimerInfo() and > jvmti_GetCurrentThreadCpuTime(). Unfortunately, I can't remember > why that bit of XSL code only applies to those two functions. I was puzzled too but seems to understand it now. The .xsl code limits these function to be defined with the attribute callbacksafe="safe" and also (no 'phase' attribute or phase="live" or phase="start"): ? . . . ? ??? ????? if (this_thread == NULL || !this_thread->is_Java_thread()) { ??? ??? ????? ??????? ????????? if (this_thread == NULL || (!this_thread->is_Java_thread() && !this_thread->is_VM_thread())) { ??????? ??????? ????????? if (!this_thread->is_Java_thread()) { ??????? ????? ???? ? ? . . . This is the list of functions defined in the jvmti.xml with the attribute callbacksafe="safe": % grep -r callbacksafe jvmti.xml | grep function ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? Only the two of the functions above, GetCurrentThreadCpuTimerInfo and GetCurrentThreadCpuTime, have the attribute phase="start". There are no functions in that list with the condition: no phase attribute or phase="live". Thanks, Serguei > > In any case, thumbs up! > > Dan > > >> >> Testing: >> mach5 tier1-3, hs-tier4-6. >> Local (linux-x64) jtreg:hotspot_gc, and manually ran the failing test. >> Examined the generated jvmtiEnter[Trace].cpp file and verified the >> change to the generated code was as expected. >> > From martinrb at google.com Wed Sep 5 18:59:51 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 5 Sep 2018 11:59:51 -0700 Subject: Linux + Clang + execstack In-Reply-To: <3193b432-0068-8e2b-9ad4-f5a6467568a1@oracle.com> References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> <3193b432-0068-8e2b-9ad4-f5a6467568a1@oracle.com> Message-ID: So ... Magnus, are you happy with the current state of the proposed patch? On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > For the gcc toolchain this can not be the case: > # Minimum supported linker versions, empty means unspecified > TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18" > > We make sure we have an ld that supports the basic flags we assume. > feature tests are better than version tests. Because there are various linkers in play (old GNU ld, gold, lld, macosx ld, BSD ld) and we'd like our compilers to work the same way on various platforms, I'm vaguely unhappy with TOOLCHAIN_MINIMUM_LD_VERSION_gcc. It looks like TOOLCHAIN_EXTRACT_LD_VERSION is another place where we conflate toolchains and operating systems. > We can add a similar check for the clang toolchain, if you want. > > Mixing and matching compilers and linkers willy-nilly is not a supported > build option > As always, I am for portability and for toolchain competition. I'd like to be able to build with Intel's icc toolchain. From coleen.phillimore at oracle.com Wed Sep 5 20:29:14 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 5 Sep 2018 16:29:14 -0400 Subject: RFR(S) 8209361: [AOT] Unexpected number of references for JVMTI_HEAP_REFERENCE_CONSTANT_POOL [111-->111]: 0 (expected at least 1) In-Reply-To: <0068f831-ddff-5000-c7fc-7acefffc9756@oracle.com> References: <0068f831-ddff-5000-c7fc-7acefffc9756@oracle.com> Message-ID: <93227a7c-b199-2199-613a-cff3dc560715@oracle.com> Looks good. Coleen On 8/30/18 8:20 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8209361 > http://cr.openjdk.java.net/~dlong/8209361/webrev/ > > Some JCK vm/jvmti/FollowReferences tests fail with AOT.? This is > because code generated by JIT and AOT compilers might not resolve > constant pool entries.? Making the compiled code resolve constant pool > entries would hurt performance.? As far as I can tell, the JVMTI > FollowReferences API is the only place this is visible, so I went with > a localized fix.? The fix looks at unresolved constant pool entries > and treats them as resolved if the class is loaded and accessible.? > Some entries can appear to be resolved early, but this is allowed by > the JVM spec, and it meets all the requirements of a resolved symbolic > reference (it will always return the same concrete class value, JVM > spec section 5.4.3). > > dl > From david.holmes at oracle.com Wed Sep 5 21:00:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Sep 2018 07:00:15 +1000 Subject: RFR(S) 8209361: [AOT] Unexpected number of references for JVMTI_HEAP_REFERENCE_CONSTANT_POOL [111-->111]: 0 (expected at least 1) In-Reply-To: <93227a7c-b199-2199-613a-cff3dc560715@oracle.com> References: <0068f831-ddff-5000-c7fc-7acefffc9756@oracle.com> <93227a7c-b199-2199-613a-cff3dc560715@oracle.com> Message-ID: Hi Dean, Seems to me that if the test is expecting CP entries to be resolved but AOT does not resolve them, then either the test is wrong or AOT is wrong. Pretending they are resolved when not, to make the test pass, does not seem like the right fix. David On 6/09/2018 6:29 AM, coleen.phillimore at oracle.com wrote: > Looks good. > Coleen > > On 8/30/18 8:20 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8209361 >> http://cr.openjdk.java.net/~dlong/8209361/webrev/ >> >> Some JCK vm/jvmti/FollowReferences tests fail with AOT.? This is >> because code generated by JIT and AOT compilers might not resolve >> constant pool entries.? Making the compiled code resolve constant pool >> entries would hurt performance.? As far as I can tell, the JVMTI >> FollowReferences API is the only place this is visible, so I went with >> a localized fix.? The fix looks at unresolved constant pool entries >> and treats them as resolved if the class is loaded and accessible. >> Some entries can appear to be resolved early, but this is allowed by >> the JVM spec, and it meets all the requirements of a resolved symbolic >> reference (it will always return the same concrete class value, JVM >> spec section 5.4.3). >> >> dl >> > From dean.long at oracle.com Wed Sep 5 21:02:48 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 5 Sep 2018 14:02:48 -0700 Subject: RFR(S) 8209361: [AOT] Unexpected number of references for JVMTI_HEAP_REFERENCE_CONSTANT_POOL [111-->111]: 0 (expected at least 1) In-Reply-To: <93227a7c-b199-2199-613a-cff3dc560715@oracle.com> References: <0068f831-ddff-5000-c7fc-7acefffc9756@oracle.com> <93227a7c-b199-2199-613a-cff3dc560715@oracle.com> Message-ID: Thanks Coleen. dl On 9/5/18 1:29 PM, coleen.phillimore at oracle.com wrote: > Looks good. > Coleen > > On 8/30/18 8:20 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8209361 >> http://cr.openjdk.java.net/~dlong/8209361/webrev/ >> >> Some JCK vm/jvmti/FollowReferences tests fail with AOT.? This is >> because code generated by JIT and AOT compilers might not resolve >> constant pool entries.? Making the compiled code resolve constant >> pool entries would hurt performance.? As far as I can tell, the JVMTI >> FollowReferences API is the only place this is visible, so I went >> with a localized fix.? The fix looks at unresolved constant pool >> entries and treats them as resolved if the class is loaded and >> accessible.? Some entries can appear to be resolved early, but this >> is allowed by the JVM spec, and it meets all the requirements of a >> resolved symbolic reference (it will always return the same concrete >> class value, JVM spec section 5.4.3). >> >> dl >> > From dean.long at oracle.com Wed Sep 5 21:28:44 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 5 Sep 2018 14:28:44 -0700 Subject: RFR(S) 8209361: [AOT] Unexpected number of references for JVMTI_HEAP_REFERENCE_CONSTANT_POOL [111-->111]: 0 (expected at least 1) In-Reply-To: References: <0068f831-ddff-5000-c7fc-7acefffc9756@oracle.com> <93227a7c-b199-2199-613a-cff3dc560715@oracle.com> Message-ID: <42343131-bfa8-30d4-9ae7-814693564a93@oracle.com> Hi David. Yes, it might feel wrong if we equate the CP tag with the JVM spec definition of resolved, but I don't feel that is necessary or accurate.? I think it's more accurate to treat the system dictionary as the ultimate authority.? This change brings JVMTI in line with what the compilers have already been doing, it's just that AOT was first to expose the discrepancy.? I prefer to think of these symbolic references as effectively or virtually resolved, rather than pretend. I could probably update the CP entry at the same time, to make it less pretend or add new APIs to make the abstraction more explicit, but I don't think that's necessary.? The JVM spec doesn't talk about CP tags.? It talks about symbolic references and whether they return the same concrete value. dl On 9/5/18 2:00 PM, David Holmes wrote: > Hi Dean, > > Seems to me that if the test is expecting CP entries to be resolved > but AOT does not resolve them, then either the test is wrong or AOT is > wrong. Pretending they are resolved when not, to make the test pass, > does not seem like the right fix. > > David > > On 6/09/2018 6:29 AM, coleen.phillimore at oracle.com wrote: >> Looks good. >> Coleen >> >> On 8/30/18 8:20 PM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8209361 >>> http://cr.openjdk.java.net/~dlong/8209361/webrev/ >>> >>> Some JCK vm/jvmti/FollowReferences tests fail with AOT.? This is >>> because code generated by JIT and AOT compilers might not resolve >>> constant pool entries.? Making the compiled code resolve constant >>> pool entries would hurt performance.? As far as I can tell, the >>> JVMTI FollowReferences API is the only place this is visible, so I >>> went with a localized fix.? The fix looks at unresolved constant >>> pool entries and treats them as resolved if the class is loaded and >>> accessible. Some entries can appear to be resolved early, but this >>> is allowed by the JVM spec, and it meets all the requirements of a >>> resolved symbolic reference (it will always return the same concrete >>> class value, JVM spec section 5.4.3). >>> >>> dl >>> >> From david.holmes at oracle.com Wed Sep 5 21:29:18 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Sep 2018 07:29:18 +1000 Subject: RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: <944a3ab273c19c25cb3fce81cef929584aa96d66.camel@redhat.com> References: <944a3ab273c19c25cb3fce81cef929584aa96d66.camel@redhat.com> Message-ID: Hi Severin, On 6/09/2018 4:36 AM, Severin Gehwolf wrote: > Hi, > > On Linux x86 (32 and 64 bit) sharedRuntime{Trans,Trig}.ccp files get > compiled with -O0. It appears to be for the same (historical?) reason > as for fdlibm files in core-libs. JDK-8210416 is an attempt to make > this consistent on all Linux arches (as s390x/ppc64/aarch64 already use > that) for fdlibm. This patch does the same for the hotspot copies. > Compile it with OPT and -ffp-contract=off instead of no optimization at > all. Thoughts? The code in sharedRuntimeTrig is expected/required to be built the same way as the fdlibm library as it contains the same code. So if it is okay to change the way fdlibm is built then it follows this is okay too. I traced this change to the optimization flags back to 2001 but no details on the exact issue seen with fdlibm. Is -ffp-contract=off a gcc-specific flag? If so this should be a gcc conditional not a linux-x86 one. Thanks, David > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 > > Testing: - make run-test-tier1 (no new failures). > - Currently running through submit. > - Verified objects get compiled with -O3 -ffp-contract=off in > build logs. > > Thanks, > Severin > From mark.reinhold at oracle.com Wed Sep 5 21:32:34 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 5 Sep 2018 14:32:34 -0700 (PDT) Subject: New candidate JEP: 341: Default CDS Archives Message-ID: <20180905213234.24907208C02@eggemoggin.niobe.net> http://openjdk.java.net/jeps/341 - Mark From david.holmes at oracle.com Wed Sep 5 22:00:40 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Sep 2018 08:00:40 +1000 Subject: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig In-Reply-To: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com> References: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com> Message-ID: <5f58ebe6-fcc6-a54a-60e4-ddb13150cda5@oracle.com> Hi Magnus, On 5/09/2018 10:11 PM, Magnus Ihse Bursie wrote: > When I removed (mostly) all mapfiles for the JDK libraries, building of > libjsig started failing on Solaris, and that part was backed out. > > Here's a new, and improved solution to remove the mapfile for libjsig, > even on Solaris. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200609 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01 Why are the forward declarations Solaris-only when the actual function definitions add JNIEXPORT unconditionally? 37 * before including signal.h */ 38 #include "sys/signal.h" Why do we need to include sys/signal.h rather than just (the existing) signal.h? Thanks, David > > /Magnus > From magnus.ihse.bursie at oracle.com Wed Sep 5 22:13:57 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 6 Sep 2018 00:13:57 +0200 Subject: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig In-Reply-To: <5f58ebe6-fcc6-a54a-60e4-ddb13150cda5@oracle.com> References: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com> <5f58ebe6-fcc6-a54a-60e4-ddb13150cda5@oracle.com> Message-ID: <5E03143C-E5E4-4902-A1B8-252B31449B38@oracle.com> > 6 sep. 2018 kl. 00:00 skrev David Holmes : > > Hi Magnus, > >> On 5/09/2018 10:11 PM, Magnus Ihse Bursie wrote: >> When I removed (mostly) all mapfiles for the JDK libraries, building of libjsig started failing on Solaris, and that part was backed out. >> Here's a new, and improved solution to remove the mapfile for libjsig, even on Solaris. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200609 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01 > > Why are the forward declarations Solaris-only when the actual function definitions add JNIEXPORT unconditionally? No other toolchain has a problem when the definition of the functions adds JNIEXPORT (i.e. adds a visibility attribute) to the initial declaration. It's certainly possible to do it for the other platforms, but it's not needed and I thought it didn't add anything to do it for all platforms. This way it's clear that the solstudio compiler is an anomaly. > > 37 * before including signal.h */ > 38 #include "sys/signal.h" > > Why do we need to include sys/signal.h rather than just (the existing) signal.h? Since it includes the definition of the sigaction struct that is needed for the sigaction() prototype. (signal.h includes sys/signal.h for type definitions) /Magnus > > Thanks, > David > >> /Magnus From david.holmes at oracle.com Wed Sep 5 22:21:27 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Sep 2018 08:21:27 +1000 Subject: RFR: JDK-8200609 Proper fix for mapfile removal for libjsig In-Reply-To: <5E03143C-E5E4-4902-A1B8-252B31449B38@oracle.com> References: <82896f62-f810-fce9-6372-682493d0c42e@oracle.com> <5f58ebe6-fcc6-a54a-60e4-ddb13150cda5@oracle.com> <5E03143C-E5E4-4902-A1B8-252B31449B38@oracle.com> Message-ID: <3f8c70f8-53b8-efb4-518c-24f675d6fea5@oracle.com> On 6/09/2018 8:13 AM, Magnus Ihse Bursie wrote: > >> 6 sep. 2018 kl. 00:00 skrev David Holmes : >> >> Hi Magnus, >> >>> On 5/09/2018 10:11 PM, Magnus Ihse Bursie wrote: >>> When I removed (mostly) all mapfiles for the JDK libraries, building of libjsig started failing on Solaris, and that part was backed out. >>> Here's a new, and improved solution to remove the mapfile for libjsig, even on Solaris. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8200609 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8200609-remove-mapfile-for-libjsig/webrev.01 >> >> Why are the forward declarations Solaris-only when the actual function definitions add JNIEXPORT unconditionally? > > No other toolchain has a problem when the definition of the functions adds JNIEXPORT (i.e. adds a visibility attribute) to the initial declaration. > > It's certainly possible to do it for the other platforms, but it's not needed and I thought it didn't add anything to do it for all platforms. This way it's clear that the solstudio compiler is an anomaly. Okay. >> >> 37 * before including signal.h */ >> 38 #include "sys/signal.h" >> >> Why do we need to include sys/signal.h rather than just (the existing) signal.h? > > Since it includes the definition of the sigaction struct that is needed for the sigaction() prototype. (signal.h includes sys/signal.h for type definitions) Doh! Of course. Thanks, David > /Magnus > >> >> Thanks, >> David >> >>> /Magnus > From david.holmes at oracle.com Wed Sep 5 23:37:13 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 6 Sep 2018 09:37:13 +1000 Subject: RFR(S) 8209361: [AOT] Unexpected number of references for JVMTI_HEAP_REFERENCE_CONSTANT_POOL [111-->111]: 0 (expected at least 1) In-Reply-To: <42343131-bfa8-30d4-9ae7-814693564a93@oracle.com> References: <0068f831-ddff-5000-c7fc-7acefffc9756@oracle.com> <93227a7c-b199-2199-613a-cff3dc560715@oracle.com> <42343131-bfa8-30d4-9ae7-814693564a93@oracle.com> Message-ID: <8950957e-8870-a692-d1a4-2912dee884ac@oracle.com> On 6/09/2018 7:28 AM, dean.long at oracle.com wrote: > Hi David. > > Yes, it might feel wrong if we equate the CP tag with the JVM spec > definition of resolved, but I don't feel that is necessary or accurate. Based on what? When the JVM TI spec talks about a "resolved constant pool entry" the only definition for that comes from the JVMS! There is nothing else. > I think it's more accurate to treat the system dictionary as the > ultimate authority.? This change brings JVMTI in line with what the > compilers have already been doing, it's just that AOT was first to > expose the discrepancy.? I prefer to think of these symbolic references > as effectively or virtually resolved, rather than pretend. I'm not aware of any notion of "effectively or virtually resolved". What exactly are the compilers doing here? I don't know where to find the test to determine exactly what the test is doing or why it expects to find occurrences of JVMTI_HEAP_REFERENCE_CONSTANT_POOL, but I again say either the test is wrong in its assumptions, or the compilers are wrong in their actions. I think this needs a much more in-depth investigation and/or explanation. David ----- > I could probably update the CP entry at the same time, to make it less > pretend or add new APIs to make the abstraction more explicit, but I > don't think that's necessary.? The JVM spec doesn't talk about CP tags. > It talks about symbolic references and whether they return the same > concrete value. > > dl > > > On 9/5/18 2:00 PM, David Holmes wrote: >> Hi Dean, >> >> Seems to me that if the test is expecting CP entries to be resolved >> but AOT does not resolve them, then either the test is wrong or AOT is >> wrong. Pretending they are resolved when not, to make the test pass, >> does not seem like the right fix. >> >> David >> >> On 6/09/2018 6:29 AM, coleen.phillimore at oracle.com wrote: >>> Looks good. >>> Coleen >>> >>> On 8/30/18 8:20 PM, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8209361 >>>> http://cr.openjdk.java.net/~dlong/8209361/webrev/ >>>> >>>> Some JCK vm/jvmti/FollowReferences tests fail with AOT.? This is >>>> because code generated by JIT and AOT compilers might not resolve >>>> constant pool entries.? Making the compiled code resolve constant >>>> pool entries would hurt performance.? As far as I can tell, the >>>> JVMTI FollowReferences API is the only place this is visible, so I >>>> went with a localized fix.? The fix looks at unresolved constant >>>> pool entries and treats them as resolved if the class is loaded and >>>> accessible. Some entries can appear to be resolved early, but this >>>> is allowed by the JVM spec, and it meets all the requirements of a >>>> resolved symbolic reference (it will always return the same concrete >>>> class value, JVM spec section 5.4.3). >>>> >>>> dl >>>> >>> > From matthias.baesken at sap.com Thu Sep 6 06:56:01 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 6 Sep 2018 06:56:01 +0000 Subject: RFR(S): 8210381: Obsolete EmitSync In-Reply-To: References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> <7a041851-cdb8-9857-7fa3-1b23381478ac@oracle.com> <3CB21532-32F5-4453-9E80-57A586B5A8C1@oracle.com> Message-ID: Hello, small update from my side - builds were fine with the patch included on our ppc64(le) / s390x platforms . I did not notice any test failures related to the patch . Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Mittwoch, 5. September 2018 13:09 > To: 'Mikael Vidstedt' ; > daniel.daugherty at oracle.com; Doerr, Martin > Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; > HotSpot Open Source Developers ; > aarch64-port-dev at openjdk.java.net > Subject: RE: RFR(S): 8210381: Obsolete EmitSync > > Hello , I had a short look at the ppc / s390x changes , looks OK . > To be on the safe side I put it into our build/test queue, so we see results > for ppc64(le) / s390x as well tomorrow . > > Best regards, Matthias > > > -----Original Message----- > > From: ppc-aix-port-dev > On > > Behalf Of Mikael Vidstedt > > Sent: Mittwoch, 5. September 2018 03:38 > > To: daniel.daugherty at oracle.com > > Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net; > > HotSpot Open Source Developers ; > > aarch64-port-dev at openjdk.java.net > > Subject: Re: RFR(S): 8210381: Obsolete EmitSync > > > > > > Dan/Vladimir, thanks for the reviews. > > > > FWIW, in addition to the build&test job I also did some manual work to > > compare the disassembly of the resulting libjvm; the C++ compiler seems > to > > agree with my ?manual? dead code elimination (yay!). > > > > Cheers, > > Mikael From sgehwolf at redhat.com Thu Sep 6 14:32:17 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 06 Sep 2018 16:32:17 +0200 Subject: RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: References: <944a3ab273c19c25cb3fce81cef929584aa96d66.camel@redhat.com> Message-ID: <0b717d235812e73fea65143545e53aba066c184e.camel@redhat.com> Hi, On Thu, 2018-09-06 at 07:29 +1000, David Holmes wrote: > Hi Severin, > > On 6/09/2018 4:36 AM, Severin Gehwolf wrote: > > Hi, > > > > On Linux x86 (32 and 64 bit) sharedRuntime{Trans,Trig}.ccp files get > > compiled with -O0. It appears to be for the same (historical?) reason > > as for fdlibm files in core-libs. JDK-8210416 is an attempt to make > > this consistent on all Linux arches (as s390x/ppc64/aarch64 already use > > that) for fdlibm. This patch does the same for the hotspot copies. > > Compile it with OPT and -ffp-contract=off instead of no optimization at > > all. Thoughts? > > The code in sharedRuntimeTrig is expected/required to be built the same > way as the fdlibm library as it contains the same code. So if it is okay > to change the way fdlibm is built then it follows this is okay too. I > traced this change to the optimization flags back to 2001 but no details > on the exact issue seen with fdlibm. Right. I should note that ppc64, s390x and aarch64 ports don't have this optimization turned off as those overrides are in a x86 specific block. It appears it hasn't caused issues for these ports so far. Your comment on JDK-8210416 says that it was introduced for an issue on GCC 1.1.1 i386 back in 1998. Wow ;-) > Is -ffp-contract=off a gcc-specific flag? If so this should be a gcc > conditional not a linux-x86 one. clang has it (as noted elsewhere), but I don't know which version. What's the "blessed" clang version for JDK 12? Thanks, Severin > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 > > > > Testing: - make run-test-tier1 (no new failures). > > - Currently running through submit. > > - Verified objects get compiled with -O3 -ffp-contract=off in > > build logs. > > > > Thanks, > > Severin > > From jiangli.zhou at oracle.com Thu Sep 6 19:45:59 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 6 Sep 2018 12:45:59 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> Message-ID: <0f79551e-5f0a-b7f4-cc72-eb84ed8baa14@oracle.com> Hi, The JEP (http://openjdk.java.net/jeps/341) for the default CDS archives is now a candidate. Please see Mark's email, 'New candidate JEP: 341: Default CDS Archives'. Please help test Erik's makefile patch for your platform if it is not built/tested in openjdk mainline to prevent any possible breakage on your side. Any comments/feedbacks on the default CDS archive are highly appreciated! ? http://cr.openjdk.java.net/~jiangli/8202951/webrev.02/ The above webrev is sync'ed with the lasted jdk/jdk repository today. Thanks! Jiangli On 8/30/18 11:26 AM, Jiangli Zhou wrote: > Hi Magnus, > > Sounds good. Will update the message. > > Thanks! > > Jiangli > > > On 8/30/18 3:56 AM, Magnus Ihse Bursie wrote: >> On 2018-08-29 17:45, Erik Joelsson wrote: >>> >>> Hello Magnus, >>> >>> As the author of the build changes I will answer this. >>> >>> On 2018-08-29 04:53, Magnus Ihse Bursie wrote: >>>> On 2018-08-28 18:25, Erik Joelsson wrote: >>>>> Build changes look good to me (but should probably get review from >>>>> someone else). >>>> >>>> I'm (as usually) not as happy as Erik. ;-) >>>> >>>> In Images.gmk, you have added this rule: >>>> ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) >>>> >>>> It took me a while to grasp. You are relying on >>>> $(JIMAGE_TARGET_FILE) to evaluate to bin/java. But that is only >>>> incidentally so. This file is just picked arbitrarily to represent >>>> when the entire image is done, for make. Please use >>>> $(JRE_IMAGE_DIR)/bin/java instead. >>>> >>> I can agree with this part. That was a bit of a hack done in a hurry. >>>> The logic in jdk-options.m4 is broken. If indeed it is not possible >>>> to use cds archive with zero, then things will break since it will >>>> still be built if using --enable-cds-archive! >>>> >>>> What you should do is to set default to true unless using cross >>>> compilation or zero. If the user explicitly sets >>>> --enable-cds-archive, and it's not possible, a fatal error should >>>> be generated. >>>> >>> Here I'm not as sure. I deliberately let it be possible to override >>> the default behavior for zero as someone might want to fix that at >>> some point, you never know. For cross compilation it's just not >>> possible ever so that's different. Maybe my reasoning is invalid. >> >> I see. I still think it would have made more sense, in that case, to >> set the default to false if using zero, but allow override. But I'm >> not going to insist on that. >> >> However, if the problem with zero is not that it's technically >> impossible, just that it's not tested, I think the message should be >> changed from "[no, not possible with JVM variant zero]" to just >> "[no]" with a comment in the configure script that it's off by >> default since it's not tested. >> >> Apart from that, Jiangli's latest webrev looks good. >> >> Jiangli: If you fix it like I suggested, you do not need to respin >> the webrev. >> >> /Magnus >> >>> >>> /Erik >>>> Apart from this, I'm more on Erik's line. :-) >>>> >>>> /Magnus >>>> >>>> >>>> >>>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>>>> Please review the implementation for JEP JDK-8204247 >>>>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of >>>>>> the JEP is to include a default CDS archive in JDK 12 binary >>>>>> distribution (downloadable from http://jdk.java.net/12/). The >>>>>> default CDS archive is generated using the default classlist >>>>>> (resides in the lib/ directory) at JDK build time. Any >>>>>> comments/suggestions are highly appreciated. >>>>>> >>>>>> All makefile changes in the webrev are contributed by Erik >>>>>> Joelsson (many thanks!!). >>>>>> >>>>>> This is a combination of efforts from different teams and >>>>>> individuals. Thanks to everyone who has been involved in the JEP >>>>>> & implementation discussions, testing and bug fixing! >>>>>> >>>>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>>>> >>>>>> Two sanity test cases for the default CDS archive are included >>>>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not >>>>>> intended for in-depth CDS functional testing, which is already >>>>>> covered by the existing cds/appcds tests and all tiered tests >>>>>> executing with the default CDS archive enabled. >>>>>> >>>>>> As part of the webrev, >>>>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also >>>>>> fixed to use larger java heap (JDK-8209739 >>>>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>>>> >>>>>> Tests executed: >>>>>> ?- several rounds of tier1 - tier8 via mach5 >>>>>> ?- JCK lang, api and vm tests via mach5 >>>>>> >>>>>> >>>>>> Thanks! >>>>>> Calvin, Ioi, Jiangli >>>>>> >>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Thu Sep 6 21:17:51 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Sep 2018 07:17:51 +1000 Subject: RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: <0b717d235812e73fea65143545e53aba066c184e.camel@redhat.com> References: <944a3ab273c19c25cb3fce81cef929584aa96d66.camel@redhat.com> <0b717d235812e73fea65143545e53aba066c184e.camel@redhat.com> Message-ID: <9e93e63d-ba1c-9463-0bf0-ec7a3bbf9f42@oracle.com> On 7/09/2018 12:32 AM, Severin Gehwolf wrote: > Hi, > > On Thu, 2018-09-06 at 07:29 +1000, David Holmes wrote: >> Hi Severin, >> >> On 6/09/2018 4:36 AM, Severin Gehwolf wrote: >>> Hi, >>> >>> On Linux x86 (32 and 64 bit) sharedRuntime{Trans,Trig}.ccp files get >>> compiled with -O0. It appears to be for the same (historical?) reason >>> as for fdlibm files in core-libs. JDK-8210416 is an attempt to make >>> this consistent on all Linux arches (as s390x/ppc64/aarch64 already use >>> that) for fdlibm. This patch does the same for the hotspot copies. >>> Compile it with OPT and -ffp-contract=off instead of no optimization at >>> all. Thoughts? >> >> The code in sharedRuntimeTrig is expected/required to be built the same >> way as the fdlibm library as it contains the same code. So if it is okay >> to change the way fdlibm is built then it follows this is okay too. I >> traced this change to the optimization flags back to 2001 but no details >> on the exact issue seen with fdlibm. > > Right. I should note that ppc64, s390x and aarch64 ports don't have > this optimization turned off as those overrides are in a x86 specific > block. It appears it hasn't caused issues for these ports so far. > > Your comment on JDK-8210416 says that it was introduced for an issue on > GCC 1.1.1 i386 back in 1998. Wow ;-) > >> Is -ffp-contract=off a gcc-specific flag? If so this should be a gcc >> conditional not a linux-x86 one. > > clang has it (as noted elsewhere), but I don't know which version. > What's the "blessed" clang version for JDK 12? I've no idea sorry. Once 8210416 has settled on the right approach for the makefiles the same can be applied here. Thanks, David > Thanks, > Severin > >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.01/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210425 >>> >>> Testing: - make run-test-tier1 (no new failures). >>> - Currently running through submit. >>> - Verified objects get compiled with -O3 -ffp-contract=off in >>> build logs. >>> >>> Thanks, >>> Severin >>> > From david.holmes at oracle.com Fri Sep 7 00:07:51 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 7 Sep 2018 10:07:51 +1000 Subject: RFR(S) 8209361: [AOT] Unexpected number of references for JVMTI_HEAP_REFERENCE_CONSTANT_POOL [111-->111]: 0 (expected at least 1) In-Reply-To: <8950957e-8870-a692-d1a4-2912dee884ac@oracle.com> References: <0068f831-ddff-5000-c7fc-7acefffc9756@oracle.com> <93227a7c-b199-2199-613a-cff3dc560715@oracle.com> <42343131-bfa8-30d4-9ae7-814693564a93@oracle.com> <8950957e-8870-a692-d1a4-2912dee884ac@oracle.com> Message-ID: <971e35eb-f8c0-4f19-58d6-eccbbd7f8189@oracle.com> After some side-bar discussions I'm withdrawing my objections to this change. The basic background is that the compilers can perform actions under which the interpreter would have marked a CP entry as resolved, but the compilers leave it unresolved. This is not a problem for either the compilers or the interpreter (if it were to encounter such an entry it would trivially resolve it). Having JVM TI consider a CP entry to a loaded class as being resolved when not marked as such, allows for the case where it "should" have been resolved but wasn't. There is an additional case where the CP entry really is unresolved (ie. no action has happened that would have caused the interpreter to resolve it) but the class is independently already loaded. That will also be reported as resolved but that is not a problem as resolution can be eager or lazy and this mimics eager resolution. It's possible we may have a test somewhere that is relying on implementation knowledge to check for lazy resolution, but if we encounter such a test we will just re-educate it. Thanks for your patience with this Dean. Cheers, David On 6/09/2018 9:37 AM, David Holmes wrote: > On 6/09/2018 7:28 AM, dean.long at oracle.com wrote: >> Hi David. >> >> Yes, it might feel wrong if we equate the CP tag with the JVM spec >> definition of resolved, but I don't feel that is necessary or accurate. > > Based on what? When the JVM TI spec talks about a "resolved constant > pool entry" the only definition for that comes from the JVMS! There is > nothing else. > >> I think it's more accurate to treat the system dictionary as the >> ultimate authority.? This change brings JVMTI in line with what the >> compilers have already been doing, it's just that AOT was first to >> expose the discrepancy.? I prefer to think of these symbolic >> references as effectively or virtually resolved, rather than pretend. > > I'm not aware of any notion of "effectively or virtually resolved". What > exactly are the compilers doing here? > > I don't know where to find the test to determine exactly what the test > is doing or why it expects to find occurrences of > JVMTI_HEAP_REFERENCE_CONSTANT_POOL, but I again say either the test is > wrong in its assumptions, or the compilers are wrong in their actions. > > I think this needs a much more in-depth investigation and/or explanation. > > David > ----- > >> I could probably update the CP entry at the same time, to make it less >> pretend or add new APIs to make the abstraction more explicit, but I >> don't think that's necessary.? The JVM spec doesn't talk about CP >> tags. It talks about symbolic references and whether they return the >> same concrete value. >> >> dl >> >> >> On 9/5/18 2:00 PM, David Holmes wrote: >>> Hi Dean, >>> >>> Seems to me that if the test is expecting CP entries to be resolved >>> but AOT does not resolve them, then either the test is wrong or AOT >>> is wrong. Pretending they are resolved when not, to make the test >>> pass, does not seem like the right fix. >>> >>> David >>> >>> On 6/09/2018 6:29 AM, coleen.phillimore at oracle.com wrote: >>>> Looks good. >>>> Coleen >>>> >>>> On 8/30/18 8:20 PM, dean.long at oracle.com wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8209361 >>>>> http://cr.openjdk.java.net/~dlong/8209361/webrev/ >>>>> >>>>> Some JCK vm/jvmti/FollowReferences tests fail with AOT.? This is >>>>> because code generated by JIT and AOT compilers might not resolve >>>>> constant pool entries.? Making the compiled code resolve constant >>>>> pool entries would hurt performance.? As far as I can tell, the >>>>> JVMTI FollowReferences API is the only place this is visible, so I >>>>> went with a localized fix.? The fix looks at unresolved constant >>>>> pool entries and treats them as resolved if the class is loaded and >>>>> accessible. Some entries can appear to be resolved early, but this >>>>> is allowed by the JVM spec, and it meets all the requirements of a >>>>> resolved symbolic reference (it will always return the same >>>>> concrete class value, JVM spec section 5.4.3). >>>>> >>>>> dl >>>>> >>>> >> From dean.long at oracle.com Fri Sep 7 00:32:32 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 6 Sep 2018 17:32:32 -0700 Subject: RFR(S) 8209361: [AOT] Unexpected number of references for JVMTI_HEAP_REFERENCE_CONSTANT_POOL [111-->111]: 0 (expected at least 1) In-Reply-To: <971e35eb-f8c0-4f19-58d6-eccbbd7f8189@oracle.com> References: <0068f831-ddff-5000-c7fc-7acefffc9756@oracle.com> <93227a7c-b199-2199-613a-cff3dc560715@oracle.com> <42343131-bfa8-30d4-9ae7-814693564a93@oracle.com> <8950957e-8870-a692-d1a4-2912dee884ac@oracle.com> <971e35eb-f8c0-4f19-58d6-eccbbd7f8189@oracle.com> Message-ID: Thanks David! dl On 9/6/18 5:07 PM, David Holmes wrote: > After some side-bar discussions I'm withdrawing my objections to this > change. > > The basic background is that the compilers can perform actions under > which the interpreter would have marked a CP entry as resolved, but > the compilers leave it unresolved. This is not a problem for either > the compilers or the interpreter (if it were to encounter such an > entry it would trivially resolve it). > > Having JVM TI consider a CP entry to a loaded class as being resolved > when not marked as such, allows for the case where it "should" have > been resolved but wasn't. There is an additional case where the CP > entry really is unresolved (ie. no action has happened that would have > caused the interpreter to resolve it) but the class is independently > already loaded. That will also be reported as resolved but that is not > a problem as resolution can be eager or lazy and this mimics eager > resolution. > > It's possible we may have a test somewhere that is relying on > implementation knowledge to check for lazy resolution, but if we > encounter such a test we will just re-educate it. > > Thanks for your patience with this Dean. > > Cheers, > David > > On 6/09/2018 9:37 AM, David Holmes wrote: >> On 6/09/2018 7:28 AM, dean.long at oracle.com wrote: >>> Hi David. >>> >>> Yes, it might feel wrong if we equate the CP tag with the JVM spec >>> definition of resolved, but I don't feel that is necessary or accurate. >> >> Based on what? When the JVM TI spec talks about a "resolved constant >> pool entry" the only definition for that comes from the JVMS! There >> is nothing else. >> >>> I think it's more accurate to treat the system dictionary as the >>> ultimate authority.? This change brings JVMTI in line with what the >>> compilers have already been doing, it's just that AOT was first to >>> expose the discrepancy.? I prefer to think of these symbolic >>> references as effectively or virtually resolved, rather than pretend. >> >> I'm not aware of any notion of "effectively or virtually resolved". >> What exactly are the compilers doing here? >> >> I don't know where to find the test to determine exactly what the >> test is doing or why it expects to find occurrences of >> JVMTI_HEAP_REFERENCE_CONSTANT_POOL, but I again say either the test >> is wrong in its assumptions, or the compilers are wrong in their >> actions. >> >> I think this needs a much more in-depth investigation and/or >> explanation. >> >> David >> ----- >> >>> I could probably update the CP entry at the same time, to make it >>> less pretend or add new APIs to make the abstraction more explicit, >>> but I don't think that's necessary.? The JVM spec doesn't talk about >>> CP tags. It talks about symbolic references and whether they return >>> the same concrete value. >>> >>> dl >>> >>> >>> On 9/5/18 2:00 PM, David Holmes wrote: >>>> Hi Dean, >>>> >>>> Seems to me that if the test is expecting CP entries to be resolved >>>> but AOT does not resolve them, then either the test is wrong or AOT >>>> is wrong. Pretending they are resolved when not, to make the test >>>> pass, does not seem like the right fix. >>>> >>>> David >>>> >>>> On 6/09/2018 6:29 AM, coleen.phillimore at oracle.com wrote: >>>>> Looks good. >>>>> Coleen >>>>> >>>>> On 8/30/18 8:20 PM, dean.long at oracle.com wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8209361 >>>>>> http://cr.openjdk.java.net/~dlong/8209361/webrev/ >>>>>> >>>>>> Some JCK vm/jvmti/FollowReferences tests fail with AOT. This is >>>>>> because code generated by JIT and AOT compilers might not resolve >>>>>> constant pool entries.? Making the compiled code resolve constant >>>>>> pool entries would hurt performance.? As far as I can tell, the >>>>>> JVMTI FollowReferences API is the only place this is visible, so >>>>>> I went with a localized fix.? The fix looks at unresolved >>>>>> constant pool entries and treats them as resolved if the class is >>>>>> loaded and accessible. Some entries can appear to be resolved >>>>>> early, but this is allowed by the JVM spec, and it meets all the >>>>>> requirements of a resolved symbolic reference (it will always >>>>>> return the same concrete class value, JVM spec section 5.4.3). >>>>>> >>>>>> dl >>>>>> >>>>> >>> From mikael.vidstedt at oracle.com Fri Sep 7 01:12:42 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 6 Sep 2018 18:12:42 -0700 Subject: RFR(S): 8210381: Obsolete EmitSync In-Reply-To: References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> <7a041851-cdb8-9857-7fa3-1b23381478ac@oracle.com> <3CB21532-32F5-4453-9E80-57A586B5A8C1@oracle.com> Message-ID: <7BCE4F55-4A3D-4BA4-B3B3-4ADA1E1233FD@oracle.com> Thanks a lot for all the reviews and for the help verifying the change across the platforms! Cheers, Mikael > On Sep 5, 2018, at 11:56 PM, Baesken, Matthias wrote: > > Hello, small update from my side - builds were fine with the patch included on our ppc64(le) / s390x platforms . > I did not notice any test failures related to the patch . > > > Best regards, Matthias > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Mittwoch, 5. September 2018 13:09 >> To: 'Mikael Vidstedt' ; >> daniel.daugherty at oracle.com; Doerr, Martin >> Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; >> HotSpot Open Source Developers ; >> aarch64-port-dev at openjdk.java.net >> Subject: RE: RFR(S): 8210381: Obsolete EmitSync >> >> Hello , I had a short look at the ppc / s390x changes , looks OK . >> To be on the safe side I put it into our build/test queue, so we see results >> for ppc64(le) / s390x as well tomorrow . >> >> Best regards, Matthias >> >>> -----Original Message----- >>> From: ppc-aix-port-dev >> On >>> Behalf Of Mikael Vidstedt >>> Sent: Mittwoch, 5. September 2018 03:38 >>> To: daniel.daugherty at oracle.com >>> Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port- >> dev at openjdk.java.net; >>> HotSpot Open Source Developers ; >>> aarch64-port-dev at openjdk.java.net >>> Subject: Re: RFR(S): 8210381: Obsolete EmitSync >>> >>> >>> Dan/Vladimir, thanks for the reviews. >>> >>> FWIW, in addition to the build&test job I also did some manual work to >>> compare the disassembly of the resulting libjvm; the C++ compiler seems >> to >>> agree with my ?manual? dead code elimination (yay!). >>> >>> Cheers, >>> Mikael > From erik.joelsson at oracle.com Fri Sep 7 17:30:42 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 7 Sep 2018 10:30:42 -0700 Subject: RFR: JDK-8202384: Introduce alternate jvm variant with speculative execution disabled In-Reply-To: <53309106-f59d-f086-e20a-a3d6eb544dda@oracle.com> References: <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com> <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com> <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com> <80471236-7511-45fa-86d4-05a2500c5752@oracle.com> <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com> <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com> <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com> <53309106-f59d-f086-e20a-a3d6eb544dda@oracle.com> Message-ID: <94c29910-6008-cf65-43f0-3c63b0843a32@oracle.com> Hello again, Resurrecting this review. It is now part of proposed JEP and some details have changed. The alternate jvm variant is now called "nonspeculative", and so is activated with the command line flag "-nonspeculative". This is all in line with the proposed JEP. Differences from last webrev are: * The name of the new JVM variant * Removed an unused AC_SUBST Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.07/index.html /Erik On 2018-06-11 23:29, Magnus Ihse Bursie wrote: > > > On 2018-06-11 22:42, Erik Joelsson wrote: >> Hello, >> >> Based on the discussion here, I have reverted back to something more >> similar to webrev.02, but with a few changes. Mainly fixing a bug >> that caused JVM_FEATURES_hardened to not actually be the same as for >> server (if you have custom additions in configure). I also added a >> check so that configure fails if you try to enable either variant >> hardened or feature no-speculative-cti and the flags aren't available. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.05/index.html > ?Looks good to me. Thanks for all the effort! > > /Magnus > >> >> /Erik >> >> On 2018-06-11 00:10, Magnus Ihse Bursie wrote: >>> On 2018-06-08 23:50, Erik Joelsson wrote: >>>> On 2018-06-07 17:30, David Holmes wrote: >>>>> On 8/06/2018 6:11 AM, Erik Joelsson wrote: >>>>>> I just don't think the extra work is warranted or should be >>>>>> prioritized at this point. I also cannot think of a combination >>>>>> of options required for what you are suggesting that wouldn't be >>>>>> confusing to the user. If someone truly feels like these flags >>>>>> are forced on them and can't live with them, we or preferably >>>>>> that person can fix it then. I don't think that's dictatorship. >>>>>> OpenJDK is still open source and anyone can contribute. >>>>> >>>>> I don't see why --enable-hardened-jdk and >>>>> --enable-hardened-hotspot to add to the right flags would be >>>>> either complicated or confusing. >>>>> >>>> For me the confusion surrounds the difference between >>>> --enable-hardened-hotspot and --with-jvm-variants=server, hardened >>>> and making the user understand it. But sure, it is doable. Here is >>>> a new webrev with those two options as I interpret them. Here is >>>> the help text: >>>> >>>> ?--enable-hardened-jdk?? enable hardenening compiler flags for all jdk >>>> ????????????????????????? libraries (except the JVM), typically >>>> disabling >>>> ????????????????????????? speculative cti. [disabled] >>>> ?--enable-hardened-hotspot >>>> ????????????????????????? enable hardenening compiler flags for >>>> hotspot (all >>>> ????????????????????????? jvm variants), typically disabling >>>> speculative cti. >>>> ????????????????????????? To make hardening of hotspot a runtime >>>> choice, >>>> ????????????????????????? consider the "hardened" jvm variant >>>> instead of this >>>> ????????????????????????? option. [disabled] >>>> >>>> Note that this changes the default for jdk libraries to not enable >>>> hardening unless the user requests it. >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/ >>> >>> Hold it, hold it! I'm not sure how we ended up here, but I don't >>> like it at all. :-( >>> >>> I think Eriks initial patch is much better than this. Some arguments >>> in random order to defend this position: >>> >>> 1) Why should we have a configure option to disable security >>> relevant flags for the JDK, if there has been no measured negative >>> effect? We don't do this for any other compiler flags, especially >>> not security relevant ones! >>> >>> I've re-read the entire thread to see if I could understand what >>> could possibly motivate this, but the only thing I can find is David >>> Holmes vague fear that these flags would not be well-tested enough. >>> Let me counter with my own vague guesses: I believe the spectre >>> mitigation methods to have been fully and properly tested, since >>> they are rolled-out massively on all products. And let me complement >>> with my own fear: the PR catastrophe if OpenJDK were *not* built >>> with spectre mitigations, and someone were to exploit that! >>> >>> In fact, I could even argue that "server" should be hardened *by >>> default*, and that we should instead introduce a non-hardened JVM >>> named something akin to "quick-but-dangerous-server" instead. But I >>> realize that a 25% performance hit is hard to swallow, so I won't >>> push this agenda. >>> >>> 2) It is by no means clear that "--enable-hardened-jdk" does not >>> harden all aspects of the JDK! If we should keep the option (which I >>> definitely do not think we should!) it should be renamed to >>> "--enable-hardened-libraries", or something like that. And it should >>> be on by default, so it should be a >>> "--disabled-hardened-jdk-libraries". >>> >>> Also, the general-sounding name "hardened" sounds like it might >>> encompass more things than it does. What if I disabled a hardened >>> jdk build, should I still get stack banging protection? If so, you >>> need to move a lot more security-related flags to this option. (And, >>> just to be absolutely clear: I don't think you should do that.) >>> >>> 3) Having two completely different ways of turning on Spectre >>> protection for hotspot is just utterly confusing! This was a perfect >>> example of how to use the JVM features, just as in the original patch. >>> >>> If you want to have spectre mitigation enabled for both server and >>> client, by default, you would just need to run "configure >>> --with-jvm-variants=server,client >>> --with-jvm-features=no-speculative-cti", which will enable that >>> feature for all variants. That's not really hard *at all* for anyone >>> building OpenJDK. And it's way clearer what will happen, than a >>> --enable-hardened-hotspot. >>> >>> 4) If you are a downstream provider building OpenJDK and you are >>> dead set on not including Spectre mitigations in the JDK libraries, >>> despite being shown to have no negative effects, then you can do >>> just as any other downstream user with highly specialized >>> requirements, and patch the source. I have no sympathies for this; I >>> can't stop it but I don't think there's any reason for us to >>> complicate the code to support this unlikely case. >>> >>> So, to recap, I think the webrev as published in >>> http://cr.openjdk.java.net/~erikj/8202384/webrev.02/ (with >>> "altserver" renamed to "hardened") is the way to go. >>> >>> /Magnus >>> >>> >>> >>>> >>>> /Erik >>> >> > From kim.barrett at oracle.com Fri Sep 7 18:40:17 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 7 Sep 2018 14:40:17 -0400 Subject: RFR: 8210131: vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code In-Reply-To: <3e752930-2eff-2e20-24da-999ed71ab5e7@oracle.com> References: <39905239-72B3-46A9-B31E-3B01FA5B9BAB@oracle.com> <32b45126-1a31-1c60-e958-461fa1a6b6c3@oracle.com> <3e752930-2eff-2e20-24da-999ed71ab5e7@oracle.com> Message-ID: <89C1B736-188E-41F1-87CB-0A6C0D02EA26@oracle.com> > On Sep 5, 2018, at 2:59 PM, serguei.spitsyn at oracle.com wrote: > > Hi Kim, > > The fix looks good to me too. > Thank you for taking care about this! Thanks for the review. > One comment below... > > On 8/31/18 07:19, Daniel D. Daugherty wrote: >> On 8/30/18 10:15 PM, Kim Barrett wrote: >>> [?] >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8210131 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8210131/open.00/ >> >> src/hotspot/share/prims/jvmtiEnter.xsl >> No comments. >> >> test/hotspot/jtreg/ProblemList.txt >> No comments. >> >> >> I verified that the XSL changes will only affect the two functions >> in question: jvmti_GetCurrentThreadCpuTimerInfo() and >> jvmti_GetCurrentThreadCpuTime(). Unfortunately, I can't remember >> why that bit of XSL code only applies to those two functions. > > I was puzzled too but seems to understand it now. Thanks for the explanation. So it seems there might be an opportunity for a little cleanup in the xsl matching code. I?m not going anywhere near that without a good reason. From aph at redhat.com Sat Sep 8 09:26:55 2018 From: aph at redhat.com (Andrew Haley) Date: Sat, 8 Sep 2018 10:26:55 +0100 Subject: RFR: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: <0b717d235812e73fea65143545e53aba066c184e.camel@redhat.com> References: <944a3ab273c19c25cb3fce81cef929584aa96d66.camel@redhat.com> <0b717d235812e73fea65143545e53aba066c184e.camel@redhat.com> Message-ID: <98aee513-8255-5478-942a-e7e6c9e18b0e@redhat.com> On 09/06/2018 03:32 PM, Severin Gehwolf wrote: > Right. I should note that ppc64, s390x and aarch64 ports don't have > this optimization turned off as those overrides are in a x86 specific > block. It appears it hasn't caused issues for these ports so far. That's just dumb luck. We really should turn off the merging of FP operations on all platforms. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Pengfei.Li at arm.com Mon Sep 10 04:24:16 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 10 Sep 2018 04:24:16 +0000 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check Message-ID: Hi Dean / Vladimir / JDK experts, Do you have any further questions or comments on this patch? Or should I make some modifications on it, such as adding some limitations to the matching condition? I appreciate your help. -- Thanks, Pengfei > -----Original Message----- > From: Pengfei Li (Arm Technology China) > Sent: Monday, September 3, 2018 13:50 > To: 'dean.long at oracle.com' ; 'Vladimir Kozlov' > ; hotspot-compiler-dev at openjdk.java.net; > hotspot-dev at openjdk.java.net > Cc: nd > Subject: RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check > > Hi Vladimir, Dean, > > Thanks for your review. > > > I don't see where negation is coming from for 'X % 2 == 0' expression. > > It should be only 2 instructions: 'cmp (X and 1), 0' > The 'cmp (X and 1), 0' is just what we expected. But there's redundant > conditional negation coming from the possibly negative X handling in "X % 2". > For instance, X = -5, "X % 2" should be -1. So only "(X and 1)" operation is not > enough. We have to negate the result. > > > I will look on it next week. But it would be nice if you can provide small test > to show this issue. > I've already provided a case of "if (a%2 == 0) { ... }" in JBS description. What > code generated and what can be optimized are listed there. > You could see https://bugs.openjdk.java.net/browse/JDK-8210152 for details. > You could also see the test case for this optimization I attached below. > > > It looks like your matching may allow more patterns than expected. I was > expecting it to look for < 0 or >= 0 for the conditional negation, but I don't see > it. > Yes. I didn't limit the if condition to <0 or >= 0 so it will match more patterns. > But nothing is going wrong if this ideal transformation applies on more cases. > In pseudo code, if someone writes: > if ( some_condition ) { x = -x; } > if ( x == 0 ) { do_something(); } > The negation in 1st if-clause could always be eliminated whatever the > condition is. > > -- > Thanks, > Pengfei > > > -- my test case attached below -- > public class Foo { > > public static void main(String[] args) { > int[] dividends = { 0, 17, 1553, -90, -35789, 0x80000000 }; > for (int i = 0; i < dividends.length; i++) { > int x = dividends[i]; > System.out.println(testDivisible(x)); > System.out.println(testModulo(x)); > testCondNeg(x); > } > return; > } > > public static int testDivisible(int x) { > // Modulo result is only for zero check > if (x % 4 == 0) { > return 444; > } > return 555; > } > > public static int testModulo(int x) { > int y = x % 4; > if (y == 0) { > return 222; > } > // Modulo result is used elsewhere > System.out.println(y); > return 333; > } > > public static void testCondNeg(int x) { > // Pure conditional negation > if (printAndIfNeg(x)) { > x = -x; > } > if (x == 0) { > System.out.println("zero!"); > } > } > > static boolean printAndIfNeg(int x) { > System.out.println(x); > return x <= 0; > } > } From magnus.ihse.bursie at oracle.com Mon Sep 10 08:27:02 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Sep 2018 10:27:02 +0200 Subject: RFR: JDK-8202384: Introduce alternate jvm variant with speculative execution disabled In-Reply-To: <94c29910-6008-cf65-43f0-3c63b0843a32@oracle.com> References: <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com> <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com> <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com> <80471236-7511-45fa-86d4-05a2500c5752@oracle.com> <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com> <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com> <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com> <53309106-f59d-f086-e20a-a3d6eb544dda@oracle.com> <94c29910-6008-cf65-43f0-3c63b0843a32@oracle.com> Message-ID: <5150e5a0-42b1-940d-6606-1c8041670ff9@oracle.com> On 2018-09-07 19:30, Erik Joelsson wrote: > Hello again, > > Resurrecting this review. It is now part of proposed JEP and some > details have changed. The alternate jvm variant is now called > "nonspeculative", and so is activated with the command line flag > "-nonspeculative". This is all in line with the proposed JEP. > > Differences from last webrev are: > > * The name of the new JVM variant > * Removed an unused AC_SUBST > > Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.07/index.html Looks good to me. But what about the change in GensrcJfr.gmk? (I might have asked about this before...) /Magnus > > /Erik > > > On 2018-06-11 23:29, Magnus Ihse Bursie wrote: >> >> >> On 2018-06-11 22:42, Erik Joelsson wrote: >>> Hello, >>> >>> Based on the discussion here, I have reverted back to something more >>> similar to webrev.02, but with a few changes. Mainly fixing a bug >>> that caused JVM_FEATURES_hardened to not actually be the same as for >>> server (if you have custom additions in configure). I also added a >>> check so that configure fails if you try to enable either variant >>> hardened or feature no-speculative-cti and the flags aren't available. >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.05/index.html >> ?Looks good to me. Thanks for all the effort! >> >> /Magnus >> >>> >>> /Erik >>> >>> On 2018-06-11 00:10, Magnus Ihse Bursie wrote: >>>> On 2018-06-08 23:50, Erik Joelsson wrote: >>>>> On 2018-06-07 17:30, David Holmes wrote: >>>>>> On 8/06/2018 6:11 AM, Erik Joelsson wrote: >>>>>>> I just don't think the extra work is warranted or should be >>>>>>> prioritized at this point. I also cannot think of a combination >>>>>>> of options required for what you are suggesting that wouldn't be >>>>>>> confusing to the user. If someone truly feels like these flags >>>>>>> are forced on them and can't live with them, we or preferably >>>>>>> that person can fix it then. I don't think that's dictatorship. >>>>>>> OpenJDK is still open source and anyone can contribute. >>>>>> >>>>>> I don't see why --enable-hardened-jdk and >>>>>> --enable-hardened-hotspot to add to the right flags would be >>>>>> either complicated or confusing. >>>>>> >>>>> For me the confusion surrounds the difference between >>>>> --enable-hardened-hotspot and --with-jvm-variants=server, hardened >>>>> and making the user understand it. But sure, it is doable. Here is >>>>> a new webrev with those two options as I interpret them. Here is >>>>> the help text: >>>>> >>>>> ?--enable-hardened-jdk?? enable hardenening compiler flags for all >>>>> jdk >>>>> ????????????????????????? libraries (except the JVM), typically >>>>> disabling >>>>> ????????????????????????? speculative cti. [disabled] >>>>> ?--enable-hardened-hotspot >>>>> ????????????????????????? enable hardenening compiler flags for >>>>> hotspot (all >>>>> ????????????????????????? jvm variants), typically disabling >>>>> speculative cti. >>>>> ????????????????????????? To make hardening of hotspot a runtime >>>>> choice, >>>>> ????????????????????????? consider the "hardened" jvm variant >>>>> instead of this >>>>> ????????????????????????? option. [disabled] >>>>> >>>>> Note that this changes the default for jdk libraries to not enable >>>>> hardening unless the user requests it. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/ >>>> >>>> Hold it, hold it! I'm not sure how we ended up here, but I don't >>>> like it at all. :-( >>>> >>>> I think Eriks initial patch is much better than this. Some >>>> arguments in random order to defend this position: >>>> >>>> 1) Why should we have a configure option to disable security >>>> relevant flags for the JDK, if there has been no measured negative >>>> effect? We don't do this for any other compiler flags, especially >>>> not security relevant ones! >>>> >>>> I've re-read the entire thread to see if I could understand what >>>> could possibly motivate this, but the only thing I can find is >>>> David Holmes vague fear that these flags would not be well-tested >>>> enough. Let me counter with my own vague guesses: I believe the >>>> spectre mitigation methods to have been fully and properly tested, >>>> since they are rolled-out massively on all products. And let me >>>> complement with my own fear: the PR catastrophe if OpenJDK were >>>> *not* built with spectre mitigations, and someone were to exploit >>>> that! >>>> >>>> In fact, I could even argue that "server" should be hardened *by >>>> default*, and that we should instead introduce a non-hardened JVM >>>> named something akin to "quick-but-dangerous-server" instead. But I >>>> realize that a 25% performance hit is hard to swallow, so I won't >>>> push this agenda. >>>> >>>> 2) It is by no means clear that "--enable-hardened-jdk" does not >>>> harden all aspects of the JDK! If we should keep the option (which >>>> I definitely do not think we should!) it should be renamed to >>>> "--enable-hardened-libraries", or something like that. And it >>>> should be on by default, so it should be a >>>> "--disabled-hardened-jdk-libraries". >>>> >>>> Also, the general-sounding name "hardened" sounds like it might >>>> encompass more things than it does. What if I disabled a hardened >>>> jdk build, should I still get stack banging protection? If so, you >>>> need to move a lot more security-related flags to this option. >>>> (And, just to be absolutely clear: I don't think you should do that.) >>>> >>>> 3) Having two completely different ways of turning on Spectre >>>> protection for hotspot is just utterly confusing! This was a >>>> perfect example of how to use the JVM features, just as in the >>>> original patch. >>>> >>>> If you want to have spectre mitigation enabled for both server and >>>> client, by default, you would just need to run "configure >>>> --with-jvm-variants=server,client >>>> --with-jvm-features=no-speculative-cti", which will enable that >>>> feature for all variants. That's not really hard *at all* for >>>> anyone building OpenJDK. And it's way clearer what will happen, >>>> than a --enable-hardened-hotspot. >>>> >>>> 4) If you are a downstream provider building OpenJDK and you are >>>> dead set on not including Spectre mitigations in the JDK libraries, >>>> despite being shown to have no negative effects, then you can do >>>> just as any other downstream user with highly specialized >>>> requirements, and patch the source. I have no sympathies for this; >>>> I can't stop it but I don't think there's any reason for us to >>>> complicate the code to support this unlikely case. >>>> >>>> So, to recap, I think the webrev as published in >>>> http://cr.openjdk.java.net/~erikj/8202384/webrev.02/ (with >>>> "altserver" renamed to "hardened") is the way to go. >>>> >>>> /Magnus >>>> >>>> >>>> >>>>> >>>>> /Erik >>>> >>> >> > From erik.joelsson at oracle.com Mon Sep 10 16:16:51 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 10 Sep 2018 09:16:51 -0700 Subject: RFR: JDK-8202384: Introduce alternate jvm variant with speculative execution disabled In-Reply-To: <5150e5a0-42b1-940d-6606-1c8041670ff9@oracle.com> References: <970b43b8-e2fb-1ae7-b6a4-535f2844f3c4@redhat.com> <4FDD968D-4793-42B2-8A17-52BB75F66B28@oracle.com> <88a9fc61-cbde-a7f0-78b7-5f26ff66fcff@oracle.com> <80471236-7511-45fa-86d4-05a2500c5752@oracle.com> <2A71CDF2-A6F5-4985-9005-4886D1047F6C@oracle.com> <2e2ace1c-22ad-e6e3-5b05-e2688b5b1b5c@oracle.com> <965cfb76-1d06-14b5-7f1e-44481ef2c54d@oracle.com> <53309106-f59d-f086-e20a-a3d6eb544dda@oracle.com> <94c29910-6008-cf65-43f0-3c63b0843a32@oracle.com> <5150e5a0-42b1-940d-6606-1c8041670ff9@oracle.com> Message-ID: <4725d151-d75b-e0c3-b945-05b70af681f7@oracle.com> Hello, On 2018-09-10 01:27, Magnus Ihse Bursie wrote: > > On 2018-09-07 19:30, Erik Joelsson wrote: >> Hello again, >> >> Resurrecting this review. It is now part of proposed JEP and some >> details have changed. The alternate jvm variant is now called >> "nonspeculative", and so is activated with the command line flag >> "-nonspeculative". This is all in line with the proposed JEP. >> >> Differences from last webrev are: >> >> * The name of the new JVM variant >> * Removed an unused AC_SUBST >> >> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.07/index.html > Looks good to me. But what about the change in GensrcJfr.gmk? (I might > have asked about this before...) > It's a leftover but still needed IMO. This patch initially contained the fix for separating output dirs for the jfr java gensrc tool. That fix was then applied separately, but as I see it incompletely. If we compile the tool in the GensrcX.gmk file, then we must also filter the classes being compiled so we don't recompile every tool in every GensrcX.gmk file. Right now, there are no other tools in that src root, but there may well be in the future, especially if we start moving all build tools into a common dir. /Erik > /Magnus >> >> /Erik >> >> >> On 2018-06-11 23:29, Magnus Ihse Bursie wrote: >>> >>> >>> On 2018-06-11 22:42, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Based on the discussion here, I have reverted back to something >>>> more similar to webrev.02, but with a few changes. Mainly fixing a >>>> bug that caused JVM_FEATURES_hardened to not actually be the same >>>> as for server (if you have custom additions in configure). I also >>>> added a check so that configure fails if you try to enable either >>>> variant hardened or feature no-speculative-cti and the flags aren't >>>> available. >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.05/index.html >>> ?Looks good to me. Thanks for all the effort! >>> >>> /Magnus >>> >>>> >>>> /Erik >>>> >>>> On 2018-06-11 00:10, Magnus Ihse Bursie wrote: >>>>> On 2018-06-08 23:50, Erik Joelsson wrote: >>>>>> On 2018-06-07 17:30, David Holmes wrote: >>>>>>> On 8/06/2018 6:11 AM, Erik Joelsson wrote: >>>>>>>> I just don't think the extra work is warranted or should be >>>>>>>> prioritized at this point. I also cannot think of a combination >>>>>>>> of options required for what you are suggesting that wouldn't >>>>>>>> be confusing to the user. If someone truly feels like these >>>>>>>> flags are forced on them and can't live with them, we or >>>>>>>> preferably that person can fix it then. I don't think that's >>>>>>>> dictatorship. OpenJDK is still open source and anyone can >>>>>>>> contribute. >>>>>>> >>>>>>> I don't see why --enable-hardened-jdk and >>>>>>> --enable-hardened-hotspot to add to the right flags would be >>>>>>> either complicated or confusing. >>>>>>> >>>>>> For me the confusion surrounds the difference between >>>>>> --enable-hardened-hotspot and --with-jvm-variants=server, >>>>>> hardened and making the user understand it. But sure, it is >>>>>> doable. Here is a new webrev with those two options as I >>>>>> interpret them. Here is the help text: >>>>>> >>>>>> ?--enable-hardened-jdk?? enable hardenening compiler flags for >>>>>> all jdk >>>>>> ????????????????????????? libraries (except the JVM), typically >>>>>> disabling >>>>>> ????????????????????????? speculative cti. [disabled] >>>>>> ?--enable-hardened-hotspot >>>>>> ????????????????????????? enable hardenening compiler flags for >>>>>> hotspot (all >>>>>> ????????????????????????? jvm variants), typically disabling >>>>>> speculative cti. >>>>>> ????????????????????????? To make hardening of hotspot a runtime >>>>>> choice, >>>>>> ????????????????????????? consider the "hardened" jvm variant >>>>>> instead of this >>>>>> ????????????????????????? option. [disabled] >>>>>> >>>>>> Note that this changes the default for jdk libraries to not >>>>>> enable hardening unless the user requests it. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8202384/webrev.04/ >>>>> >>>>> Hold it, hold it! I'm not sure how we ended up here, but I don't >>>>> like it at all. :-( >>>>> >>>>> I think Eriks initial patch is much better than this. Some >>>>> arguments in random order to defend this position: >>>>> >>>>> 1) Why should we have a configure option to disable security >>>>> relevant flags for the JDK, if there has been no measured negative >>>>> effect? We don't do this for any other compiler flags, especially >>>>> not security relevant ones! >>>>> >>>>> I've re-read the entire thread to see if I could understand what >>>>> could possibly motivate this, but the only thing I can find is >>>>> David Holmes vague fear that these flags would not be well-tested >>>>> enough. Let me counter with my own vague guesses: I believe the >>>>> spectre mitigation methods to have been fully and properly tested, >>>>> since they are rolled-out massively on all products. And let me >>>>> complement with my own fear: the PR catastrophe if OpenJDK were >>>>> *not* built with spectre mitigations, and someone were to exploit >>>>> that! >>>>> >>>>> In fact, I could even argue that "server" should be hardened *by >>>>> default*, and that we should instead introduce a non-hardened JVM >>>>> named something akin to "quick-but-dangerous-server" instead. But >>>>> I realize that a 25% performance hit is hard to swallow, so I >>>>> won't push this agenda. >>>>> >>>>> 2) It is by no means clear that "--enable-hardened-jdk" does not >>>>> harden all aspects of the JDK! If we should keep the option (which >>>>> I definitely do not think we should!) it should be renamed to >>>>> "--enable-hardened-libraries", or something like that. And it >>>>> should be on by default, so it should be a >>>>> "--disabled-hardened-jdk-libraries". >>>>> >>>>> Also, the general-sounding name "hardened" sounds like it might >>>>> encompass more things than it does. What if I disabled a hardened >>>>> jdk build, should I still get stack banging protection? If so, you >>>>> need to move a lot more security-related flags to this option. >>>>> (And, just to be absolutely clear: I don't think you should do that.) >>>>> >>>>> 3) Having two completely different ways of turning on Spectre >>>>> protection for hotspot is just utterly confusing! This was a >>>>> perfect example of how to use the JVM features, just as in the >>>>> original patch. >>>>> >>>>> If you want to have spectre mitigation enabled for both server and >>>>> client, by default, you would just need to run "configure >>>>> --with-jvm-variants=server,client >>>>> --with-jvm-features=no-speculative-cti", which will enable that >>>>> feature for all variants. That's not really hard *at all* for >>>>> anyone building OpenJDK. And it's way clearer what will happen, >>>>> than a --enable-hardened-hotspot. >>>>> >>>>> 4) If you are a downstream provider building OpenJDK and you are >>>>> dead set on not including Spectre mitigations in the JDK >>>>> libraries, despite being shown to have no negative effects, then >>>>> you can do just as any other downstream user with highly >>>>> specialized requirements, and patch the source. I have no >>>>> sympathies for this; I can't stop it but I don't think there's any >>>>> reason for us to complicate the code to support this unlikely case. >>>>> >>>>> So, to recap, I think the webrev as published in >>>>> http://cr.openjdk.java.net/~erikj/8202384/webrev.02/ (with >>>>> "altserver" renamed to "hardened") is the way to go. >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> >>>>>> >>>>>> /Erik >>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Mon Sep 10 17:57:17 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 10 Sep 2018 10:57:17 -0700 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: References: Message-ID: I finally have time to look on it and I agree with your changes. The only comment I have is to add check for SubI on other branch (not only on True branch). Negation may occur on either branch since you accept all conditions for negation. Thanks, Vladimir On 9/9/18 9:24 PM, Pengfei Li (Arm Technology China) wrote: > Hi Dean / Vladimir / JDK experts, > > Do you have any further questions or comments on this patch? Or should I make some modifications on it, such as adding some limitations to the matching condition? > I appreciate your help. > > -- > Thanks, > Pengfei > > >> -----Original Message----- >> From: Pengfei Li (Arm Technology China) >> Sent: Monday, September 3, 2018 13:50 >> To: 'dean.long at oracle.com' ; 'Vladimir Kozlov' >> ; hotspot-compiler-dev at openjdk.java.net; >> hotspot-dev at openjdk.java.net >> Cc: nd >> Subject: RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check >> >> Hi Vladimir, Dean, >> >> Thanks for your review. >> >>> I don't see where negation is coming from for 'X % 2 == 0' expression. >>> It should be only 2 instructions: 'cmp (X and 1), 0' >> The 'cmp (X and 1), 0' is just what we expected. But there's redundant >> conditional negation coming from the possibly negative X handling in "X % 2". >> For instance, X = -5, "X % 2" should be -1. So only "(X and 1)" operation is not >> enough. We have to negate the result. >> >>> I will look on it next week. But it would be nice if you can provide small test >> to show this issue. >> I've already provided a case of "if (a%2 == 0) { ... }" in JBS description. What >> code generated and what can be optimized are listed there. >> You could see https://bugs.openjdk.java.net/browse/JDK-8210152 for details. >> You could also see the test case for this optimization I attached below. >> >>> It looks like your matching may allow more patterns than expected. I was >> expecting it to look for < 0 or >= 0 for the conditional negation, but I don't see >> it. >> Yes. I didn't limit the if condition to <0 or >= 0 so it will match more patterns. >> But nothing is going wrong if this ideal transformation applies on more cases. >> In pseudo code, if someone writes: >> if ( some_condition ) { x = -x; } >> if ( x == 0 ) { do_something(); } >> The negation in 1st if-clause could always be eliminated whatever the >> condition is. >> >> -- >> Thanks, >> Pengfei >> >> >> -- my test case attached below -- >> public class Foo { >> >> public static void main(String[] args) { >> int[] dividends = { 0, 17, 1553, -90, -35789, 0x80000000 }; >> for (int i = 0; i < dividends.length; i++) { >> int x = dividends[i]; >> System.out.println(testDivisible(x)); >> System.out.println(testModulo(x)); >> testCondNeg(x); >> } >> return; >> } >> >> public static int testDivisible(int x) { >> // Modulo result is only for zero check >> if (x % 4 == 0) { >> return 444; >> } >> return 555; >> } >> >> public static int testModulo(int x) { >> int y = x % 4; >> if (y == 0) { >> return 222; >> } >> // Modulo result is used elsewhere >> System.out.println(y); >> return 333; >> } >> >> public static void testCondNeg(int x) { >> // Pure conditional negation >> if (printAndIfNeg(x)) { >> x = -x; >> } >> if (x == 0) { >> System.out.println("zero!"); >> } >> } >> >> static boolean printAndIfNeg(int x) { >> System.out.println(x); >> return x <= 0; >> } >> } From vladimir.x.ivanov at oracle.com Mon Sep 10 19:37:58 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 10 Sep 2018 22:37:58 +0300 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: References: Message-ID: On a side note: the transformation doesn't look specific to int. How hard would it be to extend it to cover long? Best regards, Vladimir Ivanov On 10/09/2018 07:24, Pengfei Li (Arm Technology China) wrote: > Hi Dean / Vladimir / JDK experts, > > Do you have any further questions or comments on this patch? Or should I make some modifications on it, such as adding some limitations to the matching condition? > I appreciate your help. > > -- > Thanks, > Pengfei > > >> -----Original Message----- >> From: Pengfei Li (Arm Technology China) >> Sent: Monday, September 3, 2018 13:50 >> To: 'dean.long at oracle.com' ; 'Vladimir Kozlov' >> ; hotspot-compiler-dev at openjdk.java.net; >> hotspot-dev at openjdk.java.net >> Cc: nd >> Subject: RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check >> >> Hi Vladimir, Dean, >> >> Thanks for your review. >> >>> I don't see where negation is coming from for 'X % 2 == 0' expression. >>> It should be only 2 instructions: 'cmp (X and 1), 0' >> The 'cmp (X and 1), 0' is just what we expected. But there's redundant >> conditional negation coming from the possibly negative X handling in "X % 2". >> For instance, X = -5, "X % 2" should be -1. So only "(X and 1)" operation is not >> enough. We have to negate the result. >> >>> I will look on it next week. But it would be nice if you can provide small test >> to show this issue. >> I've already provided a case of "if (a%2 == 0) { ... }" in JBS description. What >> code generated and what can be optimized are listed there. >> You could see https://bugs.openjdk.java.net/browse/JDK-8210152 for details. >> You could also see the test case for this optimization I attached below. >> >>> It looks like your matching may allow more patterns than expected. I was >> expecting it to look for < 0 or >= 0 for the conditional negation, but I don't see >> it. >> Yes. I didn't limit the if condition to <0 or >= 0 so it will match more patterns. >> But nothing is going wrong if this ideal transformation applies on more cases. >> In pseudo code, if someone writes: >> if ( some_condition ) { x = -x; } >> if ( x == 0 ) { do_something(); } >> The negation in 1st if-clause could always be eliminated whatever the >> condition is. >> >> -- >> Thanks, >> Pengfei >> >> >> -- my test case attached below -- >> public class Foo { >> >> public static void main(String[] args) { >> int[] dividends = { 0, 17, 1553, -90, -35789, 0x80000000 }; >> for (int i = 0; i < dividends.length; i++) { >> int x = dividends[i]; >> System.out.println(testDivisible(x)); >> System.out.println(testModulo(x)); >> testCondNeg(x); >> } >> return; >> } >> >> public static int testDivisible(int x) { >> // Modulo result is only for zero check >> if (x % 4 == 0) { >> return 444; >> } >> return 555; >> } >> >> public static int testModulo(int x) { >> int y = x % 4; >> if (y == 0) { >> return 222; >> } >> // Modulo result is used elsewhere >> System.out.println(y); >> return 333; >> } >> >> public static void testCondNeg(int x) { >> // Pure conditional negation >> if (printAndIfNeg(x)) { >> x = -x; >> } >> if (x == 0) { >> System.out.println("zero!"); >> } >> } >> >> static boolean printAndIfNeg(int x) { >> System.out.println(x); >> return x <= 0; >> } >> } From rwestrel at redhat.com Tue Sep 11 08:23:40 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 11 Sep 2018 10:23:40 +0200 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: References: Message-ID: > The only comment I have is to add check for SubI on other branch (not > only on True branch). Negation may occur on either branch since you > accept all conditions for negation. Can't we make this more general and support a phi with any number of inputs (not only 2 data inputs) as long as it's a mix of X and -X? Roland. From lutz.schmidt at sap.com Wed Sep 12 07:16:17 2018 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 12 Sep 2018 07:16:17 +0000 Subject: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization Message-ID: <7D5F0258-F6DE-402A-AB32-907A2D6E45DF@sap.com> I totally agree with Andrew's statement. FP calculations should be evaluated as the programmer wrote them down. All fiddling around with sequence or rounding is evil. You lose reproducibility of results. Regards, Lutz ?On 08.09.18, 11:26, "hotspot-dev on behalf of Andrew Haley" wrote: On 09/06/2018 03:32 PM, Severin Gehwolf wrote: > Right. I should note that ppc64, s390x and aarch64 ports don't have > this optimization turned off as those overrides are in a x86 specific > block. It appears it hasn't caused issues for these ports so far. That's just dumb luck. We really should turn off the merging of FP operations on all platforms. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Pengfei.Li at arm.com Wed Sep 12 09:25:30 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Wed, 12 Sep 2018 09:25:30 +0000 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: References: Message-ID: Hi Vladimir Ivanov, Thanks for your suggestion. I've investigated the effort to extend it to long. But unfortunately, different graph nodes are created for _irem and _lrem by 2. In bytecode parsing for _irem, a conditional negation with Phi node inside is created when the divisor is power-of-2 (see http://hg.openjdk.java.net/jdk/jdk/file/8c7198cac800/src/hotspot/share/opto/parse2.cpp#l1170 ). But C2 parser does not do in the similar way for _lrem. A "ModLNode" is created whatever the divisor equals (see http://hg.openjdk.java.net/jdk/jdk/file/8c7198cac800/src/hotspot/share/opto/parse2.cpp#l2539 ). So the "x % 2L == 0L" could not get benefit even this is extended to long. Maybe the long integer pattern can be optimized in other techniques. So I just wanted to do on 32bit integer at this time. -- Thanks again, Pengfei > -----Original Message----- > From: Vladimir Ivanov > Sent: Tuesday, September 11, 2018 03:38 > To: Pengfei Li (Arm Technology China) ; hotspot- > dev at openjdk.java.net > Cc: nd > Subject: Re: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power- > of-2 check > > > On a side note: the transformation doesn't look specific to int. How hard > would it be to extend it to cover long? > > Best regards, > Vladimir Ivanov > > On 10/09/2018 07:24, Pengfei Li (Arm Technology China) wrote: > > Hi Dean / Vladimir / JDK experts, > > > > Do you have any further questions or comments on this patch? Or should I > make some modifications on it, such as adding some limitations to the > matching condition? > > I appreciate your help. > > > > -- > > Thanks, > > Pengfei > > > > > >> -----Original Message----- > >> From: Pengfei Li (Arm Technology China) > >> Sent: Monday, September 3, 2018 13:50 > >> To: 'dean.long at oracle.com' ; 'Vladimir Kozlov' > >> ; hotspot-compiler-dev at openjdk.java.net; > >> hotspot-dev at openjdk.java.net > >> Cc: nd > >> Subject: RE: RFR(S): 8210152: Optimize integer divisible by > >> power-of-2 check > >> > >> Hi Vladimir, Dean, > >> > >> Thanks for your review. > >> > >>> I don't see where negation is coming from for 'X % 2 == 0' expression. > >>> It should be only 2 instructions: 'cmp (X and 1), 0' > >> The 'cmp (X and 1), 0' is just what we expected. But there's > >> redundant conditional negation coming from the possibly negative X > handling in "X % 2". > >> For instance, X = -5, "X % 2" should be -1. So only "(X and 1)" > >> operation is not enough. We have to negate the result. > >> > >>> I will look on it next week. But it would be nice if you can provide > >>> small test > >> to show this issue. > >> I've already provided a case of "if (a%2 == 0) { ... }" in JBS > >> description. What code generated and what can be optimized are listed > there. > >> You could see https://bugs.openjdk.java.net/browse/JDK-8210152 for > details. > >> You could also see the test case for this optimization I attached below. > >> > >>> It looks like your matching may allow more patterns than expected. I > >>> was > >> expecting it to look for < 0 or >= 0 for the conditional negation, > >> but I don't see it. > >> Yes. I didn't limit the if condition to <0 or >= 0 so it will match more > patterns. > >> But nothing is going wrong if this ideal transformation applies on more > cases. > >> In pseudo code, if someone writes: > >> if ( some_condition ) { x = -x; } > >> if ( x == 0 ) { do_something(); } > >> The negation in 1st if-clause could always be eliminated whatever the > >> condition is. > >> > >> -- > >> Thanks, > >> Pengfei > >> > >> > >> -- my test case attached below -- > >> public class Foo { > >> > >> public static void main(String[] args) { > >> int[] dividends = { 0, 17, 1553, -90, -35789, 0x80000000 }; > >> for (int i = 0; i < dividends.length; i++) { > >> int x = dividends[i]; > >> System.out.println(testDivisible(x)); > >> System.out.println(testModulo(x)); > >> testCondNeg(x); > >> } > >> return; > >> } > >> > >> public static int testDivisible(int x) { > >> // Modulo result is only for zero check > >> if (x % 4 == 0) { > >> return 444; > >> } > >> return 555; > >> } > >> > >> public static int testModulo(int x) { > >> int y = x % 4; > >> if (y == 0) { > >> return 222; > >> } > >> // Modulo result is used elsewhere > >> System.out.println(y); > >> return 333; > >> } > >> > >> public static void testCondNeg(int x) { > >> // Pure conditional negation > >> if (printAndIfNeg(x)) { > >> x = -x; > >> } > >> if (x == 0) { > >> System.out.println("zero!"); > >> } > >> } > >> > >> static boolean printAndIfNeg(int x) { > >> System.out.println(x); > >> return x <= 0; > >> } > >> } From Pengfei.Li at arm.com Wed Sep 12 09:50:44 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Wed, 12 Sep 2018 09:50:44 +0000 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: References: Message-ID: Hi, I've updated the patch based on Vladimir's comment. I added checks for SubI on both branches of the diamond phi. Also thanks Roland for the suggestion that supporting a Phi with 3 or more inputs. But I think the matching rule will be much more complex if we add this. And I'm not sure if there are any real case scenario which can benefit from this support. So I didn't add it in. New webrev: http://cr.openjdk.java.net/~njian/8210152/webrev.01/ I've run jtreg full test with the new patch and no new issues found. Please let me know if you have other comments or suggestions. If no further issues, I need your help to sponsor and push the patch. -- Thanks, Pengfei > -----Original Message----- > From: Roland Westrelin > Sent: Tuesday, September 11, 2018 16:24 > To: Vladimir Kozlov ; Pengfei Li (Arm > Technology China) ; dean.long at oracle.com; hotspot- > compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Cc: nd > Subject: Re: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power- > of-2 check > > > > The only comment I have is to add check for SubI on other branch (not > > only on True branch). Negation may occur on either branch since you > > accept all conditions for negation. > > Can't we make this more general and support a phi with any number of > inputs (not only 2 data inputs) as long as it's a mix of X and -X? > > Roland. From magnus.ihse.bursie at oracle.com Wed Sep 12 11:01:31 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 12 Sep 2018 13:01:31 +0200 Subject: Linux + Clang + execstack In-Reply-To: References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> <3193b432-0068-8e2b-9ad4-f5a6467568a1@oracle.com> Message-ID: <6b05bebc-4b06-1071-7dc3-a338ba91c8b0@oracle.com> On 2018-09-05 20:59, Martin Buchholz wrote: > So ... Magnus, are you happy with the current state of the proposed patch? I'm sorry Martin, but I can't figure out what the current state is. I tried backtracking the discussion but failed. :( Can you please repost the currently proposed patch? > > On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie > > > wrote: > > > For the gcc toolchain this can not be the case: > # Minimum supported linker versions, empty means unspecified > TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18" > > We make sure we have an ld that supports the basic flags we assume. > > > feature tests are better than version tests. I've heard that argument many times, and I've never agreed with it. In some cases, feature tests work. They typically work if someone has designed a clear API and included a feature test in it. A lot of additional POSIX functionality works that way. This means that you can rest assure that if the feature is present, then you know what you are going to get. In most of the rest of the world, functionality does not raise to that golden standard. Gcc adds a flag in one version, but it's buggy. A later version fixes the bugs. A later version still changes the behavior of the flag. Functionality that we depend on works or does not works depending on the intersection of things like our code, compiler version, operating system, and so on. In my experience, it's a rare thing for a feature test to actually work. Version tests, on the other hand, tests against a specific setup, that can be tested and proven to work. The downside of version tests is that they are often open-ended; we say that "anything above this version is supposed to work", even though we have not tested with gcc 8 or 9. The alternative is to say that "we've tested this between gcc 4.7 and 7.3 and will only support it for this version span", but that is in most cases more likely to break when gcc 8 comes along. > Because there are various linkers in play (old GNU ld, gold, lld, > macosx ld, BSD ld) and we'd like our compilers to work the same way on > various platforms, I'm vaguely unhappy with > TOOLCHAIN_MINIMUM_LD_VERSION_gcc. It looks > like?TOOLCHAIN_EXTRACT_LD_VERSION is another place where we conflate > toolchains and operating systems. The linker is often in a situation where it's conflated between toolchain and operating system. :-) I think it's more due to how the linker is positioned/perceived, than due to a fault of ours. On Windows, for instance, the linker is clearly a part of the toolchain. On solaris, there's a system linker and the solstudio does not distribute any linker on their own. On linux, the gcc toolchain actually allows you to select linker (gold, etc), but arguably they belong to the gcc toolchain rather than the OS. > We can add a similar check for the clang toolchain, if you want. > > Mixing and matching compilers and linkers willy-nilly is not a > supported build option > > > As always, I am for portability and for toolchain competition.? I'd > like to be able to build with Intel's icc toolchain. That might be a noble goal, but it's not realistic. There's a huge cost involved with supporting different combinations; the combinatorial matrix blows up quickly, and if these different combinations are not regularly tested, they *will* break. That being said, I'm too in general in favor of supporting more rather than less. But only as long as there's no high price to pay for the common/reasonable combinations. /Magnus From sgehwolf at redhat.com Wed Sep 12 12:44:48 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 12 Sep 2018 14:44:48 +0200 Subject: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: <7D5F0258-F6DE-402A-AB32-907A2D6E45DF@sap.com> References: <7D5F0258-F6DE-402A-AB32-907A2D6E45DF@sap.com> Message-ID: Hi, Updated webrev since fdlibm build change seems to have settled: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.02/ Optimization is being done at level -O2 (CXX_O_FLAG_NORM) with -ffp-contract=off when the toolchain (gcc/clang at this point) supports it. Otherwise no optimization will be done. Those overrides are no longer in an x86 specific block. Thus, ppc64, aarch64, s390x will get correct settings too. How does this look? Thanks, Severin On Wed, 2018-09-12 at 07:16 +0000, Schmidt, Lutz wrote: > I totally agree with Andrew's statement. FP calculations should be > evaluated as the programmer wrote them down. All fiddling around with > sequence or rounding is evil. You lose reproducibility of results. > Regards, > Lutz > > ?On 08.09.18, 11:26, "hotspot-dev on behalf of Andrew Haley" wrote: > > On 09/06/2018 03:32 PM, Severin Gehwolf wrote: > > Right. I should note that ppc64, s390x and aarch64 ports don't have > > this optimization turned off as those overrides are in a x86 specific > > block. It appears it hasn't caused issues for these ports so far. > > That's just dumb luck. We really should turn off the merging of FP > operations on all platforms. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From sgehwolf at redhat.com Wed Sep 12 16:13:33 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 12 Sep 2018 18:13:33 +0200 Subject: Why is vmStructs.cpp compiled with -O0? Message-ID: <0c608e27c025dfe332a8694494ba31c3bd7dafa4.camel@redhat.com> Hi, Does anybody know why vmStructs.cpp gets an override in JvmOverrideFiles.gmk: $ grep -C3 -n vmStructs.cpp make/hotspot/lib/JvmOverrideFiles.gmk 30-# status for individual files on specific platforms. 31- 32-ifeq ($(TOOLCHAIN_TYPE), gcc) 33: BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0 34- BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments 35- BUILD_LIBJVM_jvmciCompilerToVMInit.cpp_CXXFLAGS := -fno-var-tracking-assignments 36- BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized It seems to have been introduced with the new build system. JDK 8 doesn't seem to have it. Thoughts? Thanks, Severin From martinrb at google.com Wed Sep 12 16:35:29 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 12 Sep 2018 09:35:29 -0700 Subject: Linux + Clang + execstack In-Reply-To: <6b05bebc-4b06-1071-7dc3-a338ba91c8b0@oracle.com> References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> <3193b432-0068-8e2b-9ad4-f5a6467568a1@oracle.com> <6b05bebc-4b06-1071-7dc3-a338ba91c8b0@oracle.com> Message-ID: On Wed, Sep 12, 2018 at 4:01 AM, Magnus Ihse Bursie wrote: > On 2018-09-05 20:59, Martin Buchholz wrote: > > So ... Magnus, are you happy with the current state of the proposed patch? > > I'm sorry Martin, but I can't figure out what the current state is. I tried > backtracking the discussion but failed. :( Can you please repost the > currently proposed patch? http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/noexecstack.patch > On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie > wrote: >> >> >> For the gcc toolchain this can not be the case: >> # Minimum supported linker versions, empty means unspecified >> TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18" >> >> We make sure we have an ld that supports the basic flags we assume. > > > feature tests are better than version tests. > > I've heard that argument many times, and I've never agreed with it. In some > cases, feature tests work. They typically work if someone has designed a > clear API and included a feature test in it. A lot of additional POSIX > functionality works that way. This means that you can rest assure that if > the feature is present, then you know what you are going to get. > > In most of the rest of the world, functionality does not raise to that > golden standard. Gcc adds a flag in one version, but it's buggy. A later > version fixes the bugs. A later version still changes the behavior of the > flag. Functionality that we depend on works or does not works depending on > the intersection of things like our code, compiler version, operating > system, and so on. > > In my experience, it's a rare thing for a feature test to actually work. > Version tests, on the other hand, tests against a specific setup, that can > be tested and proven to work. The downside of version tests is that they are > often open-ended; we say that "anything above this version is supposed to > work", even though we have not tested with gcc 8 or 9. The alternative is to > say that "we've tested this between gcc 4.7 and 7.3 and will only support it > for this version span", but that is in most cases more likely to break when > gcc 8 comes along. Specific version tests are in principle more accurate, but they require a level of testing and maintenance that is unlikely to be seen in the real world. The received wisdom is that one should prefer feature tests whenever possible and I agree with that as well, based on decades of experience. Sometimes you need something in between, e.g. replacing a configure-time check with a run-time check. From erik.joelsson at oracle.com Wed Sep 12 17:02:06 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 12 Sep 2018 10:02:06 -0700 Subject: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: References: <7D5F0258-F6DE-402A-AB32-907A2D6E45DF@sap.com> Message-ID: <4cc34e60-be08-4e4a-c08c-fdcde0ba4646@oracle.com> Hello Severin, In configure, we now set FDLIBM_CFLAGS based on toolchain type and capabilities. In JvmOverrideFiles.gmk, the use of it is still conditional on Linux. I don't think it should be. We already have the conditionals we need. /Erik On 2018-09-12 05:44, Severin Gehwolf wrote: > Hi, > > Updated webrev since fdlibm build change seems to have settled: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.02/ > > Optimization is being done at level -O2 (CXX_O_FLAG_NORM) with > -ffp-contract=off when the toolchain (gcc/clang at this point) > supports it. Otherwise no optimization will be done. Those overrides > are no longer in an x86 specific block. Thus, ppc64, aarch64, s390x > will get correct settings too. > > How does this look? > > Thanks, > Severin > > On Wed, 2018-09-12 at 07:16 +0000, Schmidt, Lutz wrote: >> I totally agree with Andrew's statement. FP calculations should be >> evaluated as the programmer wrote them down. All fiddling around with >> sequence or rounding is evil. You lose reproducibility of results. >> Regards, >> Lutz >> >> ?On 08.09.18, 11:26, "hotspot-dev on behalf of Andrew Haley" wrote: >> >> On 09/06/2018 03:32 PM, Severin Gehwolf wrote: >> > Right. I should note that ppc64, s390x and aarch64 ports don't have >> > this optimization turned off as those overrides are in a x86 specific >> > block. It appears it hasn't caused issues for these ports so far. >> >> That's just dumb luck. We really should turn off the merging of FP >> operations on all platforms. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> >> From erik.joelsson at oracle.com Wed Sep 12 17:25:06 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 12 Sep 2018 10:25:06 -0700 Subject: Why is vmStructs.cpp compiled with -O0? In-Reply-To: <0c608e27c025dfe332a8694494ba31c3bd7dafa4.camel@redhat.com> References: <0c608e27c025dfe332a8694494ba31c3bd7dafa4.camel@redhat.com> Message-ID: <97b1aa06-5827-8872-a26d-f4300c2d1274@oracle.com> Hello, I very much doubt it was included with the new build system. We were extremely careful to use the exact same flags then, and did binary comparisons of all object files to verify equal builds. Tracing back, it was caused (probably unintentionally) by this change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e796d52ca85b In the old build, setting OPT_CFLAGS/ overrides the common OPT_CFLAGS. In the new build, we have a more general way of adding flags for specific files that does not directly override any other flags. To get the same behavior for vmStructs.cpp in the new build as in the old at the time of the switch, we had to add -O0 explicitly in the new build. /Erik On 2018-09-12 09:13, Severin Gehwolf wrote: > Hi, > > Does anybody know why vmStructs.cpp gets an override in > JvmOverrideFiles.gmk: > > $ grep -C3 -n vmStructs.cpp make/hotspot/lib/JvmOverrideFiles.gmk > 30-# status for individual files on specific platforms. > 31- > 32-ifeq ($(TOOLCHAIN_TYPE), gcc) > 33: BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0 > 34- BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments > 35- BUILD_LIBJVM_jvmciCompilerToVMInit.cpp_CXXFLAGS := -fno-var-tracking-assignments > 36- BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized > > It seems to have been introduced with the new build system. JDK 8 > doesn't seem to have it. Thoughts? > > Thanks, > Severin > From vladimir.kozlov at oracle.com Wed Sep 12 21:15:42 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 12 Sep 2018 14:15:42 -0700 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: References: Message-ID: <91d1bf82-eb60-c0a1-449d-8bb9246ddedd@oracle.com> Looks good. Thanks, Vladimir On 9/12/18 2:50 AM, Pengfei Li (Arm Technology China) wrote: > Hi, > > I've updated the patch based on Vladimir's comment. I added checks for SubI on both branches of the diamond phi. > Also thanks Roland for the suggestion that supporting a Phi with 3 or more inputs. But I think the matching rule will be much more complex if we add this. And I'm not sure if there are any real case scenario which can benefit from this support. So I didn't add it in. > > New webrev: http://cr.openjdk.java.net/~njian/8210152/webrev.01/ > I've run jtreg full test with the new patch and no new issues found. > > Please let me know if you have other comments or suggestions. If no further issues, I need your help to sponsor and push the patch. > > -- > Thanks, > Pengfei > > >> -----Original Message----- >> From: Roland Westrelin >> Sent: Tuesday, September 11, 2018 16:24 >> To: Vladimir Kozlov ; Pengfei Li (Arm >> Technology China) ; dean.long at oracle.com; hotspot- >> compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Cc: nd >> Subject: Re: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power- >> of-2 check >> >> >>> The only comment I have is to add check for SubI on other branch (not >>> only on True branch). Negation may occur on either branch since you >>> accept all conditions for negation. >> >> Can't we make this more general and support a phi with any number of >> inputs (not only 2 data inputs) as long as it's a mix of X and -X? >> >> Roland. From Pengfei.Li at arm.com Thu Sep 13 08:31:01 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 13 Sep 2018 08:31:01 +0000 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: <91d1bf82-eb60-c0a1-449d-8bb9246ddedd@oracle.com> References: <91d1bf82-eb60-c0a1-449d-8bb9246ddedd@oracle.com> Message-ID: Thanks Vladimir. So I still need another reviewer's feedback. -- Thanks, Pengfei > -----Original Message----- > > Looks good. > > Thanks, > Vladimir > > On 9/12/18 2:50 AM, Pengfei Li (Arm Technology China) wrote: > > Hi, > > > > I've updated the patch based on Vladimir's comment. I added checks for > SubI on both branches of the diamond phi. > > Also thanks Roland for the suggestion that supporting a Phi with 3 or more > inputs. But I think the matching rule will be much more complex if we add > this. And I'm not sure if there are any real case scenario which can benefit > from this support. So I didn't add it in. > > > > New webrev: http://cr.openjdk.java.net/~njian/8210152/webrev.01/ > > I've run jtreg full test with the new patch and no new issues found. > > > > Please let me know if you have other comments or suggestions. If no > further issues, I need your help to sponsor and push the patch. > > > > -- > > Thanks, > > Pengfei > > > > > >> -----Original Message----- > >> From: Roland Westrelin > >> Sent: Tuesday, September 11, 2018 16:24 > >> To: Vladimir Kozlov ; Pengfei Li (Arm > >> Technology China) ; dean.long at oracle.com; > >> hotspot- compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > >> Cc: nd > >> Subject: Re: [PING] RE: RFR(S): 8210152: Optimize integer divisible > >> by power- > >> of-2 check > >> > >> > >>> The only comment I have is to add check for SubI on other branch > >>> (not only on True branch). Negation may occur on either branch since > >>> you accept all conditions for negation. > >> > >> Can't we make this more general and support a phi with any number of > >> inputs (not only 2 data inputs) as long as it's a mix of X and -X? > >> > >> Roland. From sgehwolf at redhat.com Thu Sep 13 08:43:40 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 13 Sep 2018 10:43:40 +0200 Subject: RFR: 8210703: vmStructs.cpp compiled with -O0 (was: Why is vmStructs.cpp compiled with -O0? In-Reply-To: <97b1aa06-5827-8872-a26d-f4300c2d1274@oracle.com> References: <0c608e27c025dfe332a8694494ba31c3bd7dafa4.camel@redhat.com> <97b1aa06-5827-8872-a26d-f4300c2d1274@oracle.com> Message-ID: <9ab2dbb35adb318c164bf4f7d543dc8005444d90.camel@redhat.com> Hi Erik, On Wed, 2018-09-12 at 10:25 -0700, Erik Joelsson wrote: > Hello, > > I very much doubt it was included with the new build system. We were > extremely careful to use the exact same flags then, and did binary > comparisons of all object files to verify equal builds. > > Tracing back, it was caused (probably unintentionally) by this change: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e796d52ca85b Thanks for the detective work! This looks very much unintentional to me as JDK-8114853 is about silencing a note. > In the old build, setting OPT_CFLAGS/ overrides the common > OPT_CFLAGS. In the new build, we have a more general way of adding flags > for specific files that does not directly override any other flags. To > get the same behavior for vmStructs.cpp in the new build as in the old > at the time of the switch, we had to add -O0 explicitly in the new build. I've filed JDK-8210703 and posting this patch as review for the bug. Note I've changed the subject. Does this look OK? diff --git a/make/hotspot/lib/JvmOverrideFiles.gmk b/make/hotspot/lib/JvmOverrideFiles.gmk --- a/make/hotspot/lib/JvmOverrideFiles.gmk +++ b/make/hotspot/lib/JvmOverrideFiles.gmk @@ -30,7 +30,7 @@ # status for individual files on specific platforms. ifeq ($(TOOLCHAIN_TYPE), gcc) - BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0 + BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments BUILD_LIBJVM_jvmciCompilerToVMInit.cpp_CXXFLAGS := -fno-var-tracking-assignments BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized Thanks, Severin On 2018-09-12 09:13, Severin Gehwolf wrote: > > Hi, > > > > Does anybody know why vmStructs.cpp gets an override in > > JvmOverrideFiles.gmk: > > > > $ grep -C3 -n vmStructs.cpp make/hotspot/lib/JvmOverrideFiles.gmk > > 30-# status for individual files on specific platforms. > > 31- > > 32-ifeq ($(TOOLCHAIN_TYPE), gcc) > > 33: BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0 > > 34- BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments > > 35- BUILD_LIBJVM_jvmciCompilerToVMInit.cpp_CXXFLAGS := -fno-var-tracking-assignments > > 36- BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized > > > > It seems to have been introduced with the new build system. JDK 8 > > doesn't seem to have it. Thoughts? > > > > Thanks, > > Severin > > > > From rednaxelafx at gmail.com Thu Sep 13 08:57:02 2018 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 13 Sep 2018 01:57:02 -0700 Subject: VM deadlock between VM shutdown and G1 Message-ID: Hi HotSpot devs, I'd like to report a VM deadlock situation we've experienced in production a few weeks ago on JDK8. I checked the latest jdk/jdk code and the same race condition is still there. I can file a JBS ticket if this looks like a valid problem. tl;dr: there's a race condition between the VM shutdown and G1, in that the VM shutdown sequence may have just terminated all the concurrent GC threads, and at the same time G1 has just started an incremental collection cycle and is waiting for the concurrent marker to finish. Since there's no concurrent GC thread alive to update the status anymore, G1 waits indefinitely while holding a safepoint, causing the VM to deadlock. Details: 3 threads are involved in the actual deadlock. Detailed stack traces are at the end of this email. 1. A Java application thread at an allocation site triggering a G1 incremental collection 2. A thread that called System.exit(), initiating the VM shutdown sequence. It's in VM's native code so it doesn't block a safepoint. 3. VM thread, already inside of a safepoint and started running G1's incremental collection. (4. "the world" is at a safepoint so all other Java threads are just waiting) The problem is, Thread 2 has already run half way into before_exit(), and one of the steps in there is: hotspot/src/share/vm/runtime/java.cpp 503 // Stop concurrent GC threads 504 Universe::heap()->stop(); But G1 is waiting for the concurrent marker to finish scanning the root regions: hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp 506 bool CMRootRegions::wait_until_scan_finished() { 507 if (!scan_in_progress()) return false; 508 509 { 510 MutexLockerEx x(RootRegionScan_lock, Mutex::_no_safepoint_check_flag); 511 while (scan_in_progress()) { 512 RootRegionScan_lock->wait(Mutex::_no_safepoint_check_flag); 513 } 514 } 515 return true; 516 } But scan_in_process is only updated in a few places: hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp 449 void CMRootRegions::prepare_for_scan() { 450 assert(!scan_in_progress(), "pre-condition"); 451 452 // Currently, only survivors can be root regions. 453 assert(_next_survivor == NULL, "pre-condition"); 454 _next_survivor = _young_list->first_survivor_region(); 455 _scan_in_progress = (_next_survivor != NULL); 456 _should_abort = false; 457 } 490 void CMRootRegions::scan_finished() { 491 assert(scan_in_progress(), "pre-condition"); 492 493 // Currently, only survivors can be root regions. 494 if (!_should_abort) { 495 assert(_next_survivor == NULL, "we should have claimed all survivors"); 496 } 497 _next_survivor = NULL; 498 499 { 500 MutexLockerEx x(RootRegionScan_lock, Mutex::_no_safepoint_check_flag); 501 _scan_in_progress = false; 502 RootRegionScan_lock->notify_all(); 503 } 504 } And with the current GC threads gone, nobody ever gets to set scan_in_process back to false, which leads to an infinite wait. One way I'd imagine fixing this is by adding a check in G1's CMRootRegions::wait_until_scan_finished() to see if the concurrent marker thread is still there, and if it isn't, there's no point in waiting anymore. Obviously similar fixes would have to be done separately for other concurrent GCs in HotSpot. What do you think? Thanks, Kris Detail thread stacks for in the example: 1. A Java application thread at an allocation site triggering a G1 incremental collection: Thread 2164 (Thread 0x7fcfc4e11700 (LWP 25218)): #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007fd2931e9a1b in os::PlatformEvent::park() (this=this at entry=0x7fd05c029c00) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 #2 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, ev=0x7fd05c029c00) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 #3 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (this=this at entry=0x7fd28c012800, Self=Self at entry=0x7fd1ac0f2000, timo=timo at entry=0) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 #4 0x00007fd2931a382e in Monitor::wait(bool, long, bool) (this=0x7fd28c012800, no_safepoint_check=, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1126 #5 0x00007fd29339d5fc in VMThread::execute(VM_Operation*) (op=op at entry=0x7fcfc4e0c430) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:642 #6 0x00007fd292e99fec in G1CollectedHeap::attempt_allocation_slow(unsigned long, unsigned char, unsigned int*, unsigned int*) (gc_cause=GCCause::_g1_inc_collection_pause, succeeded=, gc_count_before=, word_size=1026, this=0x7fd28c033c40) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:3628 #7 0x00007fd292e99fec in G1CollectedHeap::attempt_allocation_slow(unsigned long, unsigned char, unsigned int*, unsigned int*) (this=this at entry=0x7fd28c033c40, word_size=word_size at entry=1026, context=context at entry=0 '\000', gc_count_before_ret=gc_count_before_ret at entry=0x7fcfc4e0c50c, gclocker_retry_count_ret=gclocker_retry_count_ret at entry=0x7fcfc4e0c508) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:956 #8 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned long, bool*) (gclocker_retry_count_ret=0x7fcfc4e0c508, gc_count_before_ret=0x7fcfc4e0c50c, word_size=1026, this=0x7fd28c033c40) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp:147 #9 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned long, bool*) (this=0x7fd28c033c40, word_size=1026, gc_overhead_limit_was_exceeded=) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:846 #10 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:135 #11 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:175 #12 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, Thread*) (__the_thread__=0x7fd1ac0f2000, length=8192, size=1026, klass=...) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:216 #13 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, Thread*) (this=0x7c0000768, length=length at entry=8192, do_zero=do_zero at entry=true, __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/oops/typeArrayKlass.cpp:107 #14 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, Thread*) (__the_thread__=__the_thread__ at entry=0x7fd1ac0f2000, length=length at entry=8192, this=) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/oops/typeArrayKlass.hpp:67 #15 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, Thread*) (type=, length=length at entry=8192, __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/memory/oopFactory.cpp:56 #16 0x00007fd293283457 in OptoRuntime::new_array_C(Klass*, int, JavaThread*) (array_type=, len=8192, thread=0x7fd1ac0f2000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/opto/runtime.cpp:279 #17 0x00007fd27d0871c7 in () 2. A thread that called System.exit(), initiating the VM shutdown sequence. It's in native code so it doesn't block a safepoint: Thread 563 (Thread 0x7fd017980700 (LWP 7959)): #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007fd2931e9a1b in os::PlatformEvent::park() (this=0x7fd0f4015000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 #2 0x00007fd293064485 in JvmtiRawMonitor::SimpleWait(Thread*, long) (this=this at entry=0x7fd28f22f020, Self=Self at entry=0x7fd28f0c9800, millis=millis at entry=-1) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:194 #3 0x00007fd293064c75 in JvmtiRawMonitor::raw_wait(long, bool, Thread*) (this=this at entry=0x7fd28f22f020, millis=millis at entry=-1, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x7fd28f0c9800) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:383 #4 0x00007fd293040c09 in JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*, long) (this=, rmonitor=0x7fd28f22f020, millis=-1) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiEnv.cpp:3144 #5 0x00007fd291620af8 in debugMonitorWait (monitor=) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/util.c:1075 #6 0x00007fd29160e86c in cbVMDeath (jvmti_env=, env=0x7fd28f0c99e0) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:1273 #7 0x00007fd29304f4b0 in JvmtiExport::post_vm_death() () at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiExport.cpp:490 #8 0x00007fd292f896dd in before_exit(JavaThread*) (thread=) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/java.cpp:532 #9 0x00007fd292fd005b in JVM_Halt(jint) (code=1) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvm.cpp:441 #10 0x00007fd27d020868 in [native] java.lang.Shutdown.halt0(int) () at java/lang/Shutdown.java:0 #11 0x00007fd27d00809d in [interpreted: bc = 7] java.lang.Shutdown.halt(int) () at java/lang/Shutdown.java:140 #12 0x00007fd27d00809d in [interpreted: bc = 99] java.lang.Shutdown.exit(int) () at java/lang/Shutdown.java:214 #13 0x00007fd27d00809d in [interpreted: bc = 14] java.lang.Runtime.exit(int) () at java/lang/Runtime.java:110 #14 0x00007fd27d00809d in [interpreted: bc = 4] java.lang.System.exit(int) () at java/lang/System.java:972 #15 0x00007fd27d00809d in [interpreted: bc = 1] scala.sys.package$.exit(int) () at scala/sys/package.java:41 3. VM thread, already inside of a safepoint and started running G1's incremental collection: Thread 19 (Thread 0x7fd1d70ab700 (LWP 47)): #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007fd2931e9a1b in os::PlatformEvent::park() (this=this at entry=0x7fd28c498200) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 #2 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, ev=0x7fd28c498200) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 #3 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (this=this at entry=0x7fd28c011700, Self=Self at entry=0x7fd28c497800, timo=timo at entry=0) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 #4 0x00007fd2931a37fa in Monitor::wait(bool, long, bool) (this=0x7fd28c011700, no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1111 #5 0x00007fd292db1fe2 in CMRootRegions::wait_until_scan_finished() (this=0x7fd28c0826b8) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:512 #6 0x00007fd292ea59a4 in G1CollectedHeap::do_collection_pause_at_safepoint(double) (this=this at entry=0x7fd28c033c40, target_pause_time_ms=200) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:4095 #7 0x00007fd29339f002 in VM_G1IncCollectionPause::doit() (this=0x7fcfc4e0c430) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/vm_operations_g1.cpp:148 #8 0x00007fd29339dfd7 in VM_Operation::evaluate() (this=this at entry=0x7fcfc4e0c430) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vm_operations.cpp:62 #9 0x00007fd29339b6d7 in VMThread::evaluate_operation(VM_Operation*) (op=0x7fcfc4e0c430, this=) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:377 #10 0x00007fd29339cb5f in VMThread::loop() (this=this at entry=0x7fd28c497800) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:502 #11 0x00007fd29339d051 in VMThread::run() (this=0x7fd28c497800) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:276 #12 0x00007fd2931e1222 in java_start(Thread*) (thread=0x7fd28c497800) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:790 From thomas.schatzl at oracle.com Thu Sep 13 09:24:58 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 13 Sep 2018 11:24:58 +0200 Subject: VM deadlock between VM shutdown and G1 In-Reply-To: References: Message-ID: Hi Kris, On Thu, 2018-09-13 at 01:57 -0700, Krystal Mok wrote: > Hi HotSpot devs, > > I'd like to report a VM deadlock situation we've experienced in > production a few weeks ago on JDK8. I checked the latest jdk/jdk code > and the same race condition is still there. > > I can file a JBS ticket if this looks like a valid problem. I filed https://bugs.openjdk.java.net/browse/JDK-8210706 . At first glance the suggested fix seems reasonable. Thanks, Thomas > > tl;dr: there's a race condition between the VM shutdown and G1, in > that the VM shutdown sequence may have just terminated all the > concurrent GC threads, and at the same time G1 has just started an > incremental collection cycle and is waiting for the concurrent marker > to finish. Since there's no concurrent GC thread alive to update the > status anymore, G1 waits indefinitely while holding a safepoint, > causing the VM to deadlock. > > Details: > > 3 threads are involved in the actual deadlock. Detailed stack traces > are at the end of this email. > > 1. A Java application thread at an allocation site triggering a G1 > incremental collection > 2. A thread that called System.exit(), initiating the VM shutdown > sequence. > It's in VM's native code so it doesn't block a safepoint. > 3. VM thread, already inside of a safepoint and started running G1's > incremental collection. > (4. "the world" is at a safepoint so all other Java threads are just > waiting) > > The problem is, Thread 2 has already run half way into before_exit(), > and one of the steps in there is: > > hotspot/src/share/vm/runtime/java.cpp > > 503 // Stop concurrent GC threads > 504 Universe::heap()->stop(); > > But G1 is waiting for the concurrent marker to finish scanning the > root regions: > > hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp > > 506 bool CMRootRegions::wait_until_scan_finished() { > 507 if (!scan_in_progress()) return false; > 508 > 509 { > 510 MutexLockerEx x(RootRegionScan_lock, > Mutex::_no_safepoint_check_flag); > 511 while (scan_in_progress()) { > 512 RootRegionScan_lock- > >wait(Mutex::_no_safepoint_check_flag); > 513 } > 514 } > 515 return true; > 516 } > > But scan_in_process is only updated in a few places: > > hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp > > 449 void CMRootRegions::prepare_for_scan() { > 450 assert(!scan_in_progress(), "pre-condition"); > 451 > 452 // Currently, only survivors can be root regions. > 453 assert(_next_survivor == NULL, "pre-condition"); > 454 _next_survivor = _young_list->first_survivor_region(); > 455 _scan_in_progress = (_next_survivor != NULL); > 456 _should_abort = false; > 457 } > > 490 void CMRootRegions::scan_finished() { > 491 assert(scan_in_progress(), "pre-condition"); > 492 > 493 // Currently, only survivors can be root regions. > 494 if (!_should_abort) { > 495 assert(_next_survivor == NULL, "we should have claimed all > survivors"); > 496 } > 497 _next_survivor = NULL; > 498 > 499 { > 500 MutexLockerEx x(RootRegionScan_lock, > Mutex::_no_safepoint_check_flag); > 501 _scan_in_progress = false; > 502 RootRegionScan_lock->notify_all(); > 503 } > 504 } > > And with the current GC threads gone, nobody ever gets to set > scan_in_process back to false, which leads to an infinite wait. > > One way I'd imagine fixing this is by adding a check in G1's > CMRootRegions::wait_until_scan_finished() to see if the concurrent > marker thread is still there, and if it isn't, there's no point in > waiting anymore. > Obviously similar fixes would have to be done separately for other > concurrent GCs in HotSpot. > > What do you think? > > Thanks, > Kris > > Detail thread stacks for in the example: > > 1. A Java application thread at an allocation site triggering a G1 > incremental collection: > > Thread 2164 (Thread 0x7fcfc4e11700 (LWP 25218)): > #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > #1 0x00007fd2931e9a1b in os::PlatformEvent::park() > (this=this at entry=0x7fd05c029c00) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > #2 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, > ev=0x7fd05c029c00) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 > #3 0x00007fd2931a256f in Monitor::IWait(Thread*, long) > (this=this at entry=0x7fd28c012800, > Self=Self at entry=0x7fd1ac0f2000, timo=timo at entry=0) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 > #4 0x00007fd2931a382e in Monitor::wait(bool, long, bool) > (this=0x7fd28c012800, no_safepoint_check=, > timeout=timeout at entry=0, > as_suspend_equivalent=as_suspend_equivalent at entry=false) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1126 > #5 0x00007fd29339d5fc in VMThread::execute(VM_Operation*) > (op=op at entry=0x7fcfc4e0c430) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:642 > #6 0x00007fd292e99fec in > G1CollectedHeap::attempt_allocation_slow(unsigned > long, unsigned char, unsigned int*, unsigned int*) > (gc_cause=GCCause::_g1_inc_collection_pause, succeeded= pointer>, > gc_count_before=, word_size=1026, this=0x7fd28c033c40) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > :3628 > #7 0x00007fd292e99fec in > G1CollectedHeap::attempt_allocation_slow(unsigned > long, unsigned char, unsigned int*, unsigned int*) > (this=this at entry=0x7fd28c033c40, > word_size=word_size at entry=1026, context=context at entry=0 '\000', > gc_count_before_ret=gc_count_before_ret at entry=0x7fcfc4e0c50c, > gclocker_retry_count_ret=gclocker_retry_count_ret at entry=0x7fcfc4e0c50 > 8) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > :956 > #8 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned > long, > bool*) (gclocker_retry_count_ret=0x7fcfc4e0c508, > gc_count_before_ret=0x7fcfc4e0c50c, word_size=1026, > this=0x7fd28c033c40) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.inl > ine.hpp:147 > #9 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned > long, > bool*) (this=0x7fd28c033c40, word_size=1026, > gc_overhead_limit_was_exceeded=) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > :846 > #10 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:13 > 5 > #11 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:17 > 5 > #12 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > Thread*) (__the_thread__=0x7fd1ac0f2000, length=8192, size=1026, > klass=...) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:21 > 6 > #13 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > Thread*) (this=0x7c0000768, length=length at entry=8192, > do_zero=do_zero at entry=true, > __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/oops/typeArrayKlass.cpp:107 > #14 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, > Thread*) (__the_thread__=__the_thread__ at entry=0x7fd1ac0f2000, > length=length at entry=8192, this=) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/oops/typeArrayKlass.hpp:67 > #15 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, > Thread*) (type=, length=length at entry=8192, > __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/memory/oopFactory.cpp:56 > #16 0x00007fd293283457 in OptoRuntime::new_array_C(Klass*, int, > JavaThread*) (array_type=, len=8192, > thread=0x7fd1ac0f2000) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/opto/runtime.cpp:279 > #17 0x00007fd27d0871c7 in () > > 2. A thread that called System.exit(), initiating the VM shutdown > sequence. > It's in native code so it doesn't block a safepoint: > > Thread 563 (Thread 0x7fd017980700 (LWP 7959)): > #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > #1 0x00007fd2931e9a1b in os::PlatformEvent::park() > (this=0x7fd0f4015000) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > #2 0x00007fd293064485 in JvmtiRawMonitor::SimpleWait(Thread*, long) > (this=this at entry=0x7fd28f22f020, Self=Self at entry=0x7fd28f0c9800, > millis=millis at entry=-1) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:194 > #3 0x00007fd293064c75 in JvmtiRawMonitor::raw_wait(long, bool, > Thread*) > (this=this at entry=0x7fd28f22f020, millis=millis at entry=-1, > interruptible=interruptible at entry=true, > __the_thread__=__the_thread__ at entry=0x7fd28f0c9800) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:383 > #4 0x00007fd293040c09 in JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*, > long) > (this=, rmonitor=0x7fd28f22f020, millis=-1) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/prims/jvmtiEnv.cpp:3144 > #5 0x00007fd291620af8 in debugMonitorWait (monitor=) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/jdk/src/share/back/util.c:1075 > #6 0x00007fd29160e86c in cbVMDeath (jvmti_env=, > env=0x7fd28f0c99e0) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/jdk/src/share/back/eventHandler.c:1273 > #7 0x00007fd29304f4b0 in JvmtiExport::post_vm_death() () at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/prims/jvmtiExport.cpp:490 > #8 0x00007fd292f896dd in before_exit(JavaThread*) (thread= out>) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/runtime/java.cpp:532 > #9 0x00007fd292fd005b in JVM_Halt(jint) (code=1) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/prims/jvm.cpp:441 > #10 0x00007fd27d020868 in [native] java.lang.Shutdown.halt0(int) () > at > java/lang/Shutdown.java:0 > #11 0x00007fd27d00809d in [interpreted: bc = 7] > java.lang.Shutdown.halt(int) () at java/lang/Shutdown.java:140 > #12 0x00007fd27d00809d in [interpreted: bc = 99] > java.lang.Shutdown.exit(int) () at java/lang/Shutdown.java:214 > #13 0x00007fd27d00809d in [interpreted: bc = 14] > java.lang.Runtime.exit(int) () at java/lang/Runtime.java:110 > #14 0x00007fd27d00809d in [interpreted: bc = 4] > java.lang.System.exit(int) > () at java/lang/System.java:972 > #15 0x00007fd27d00809d in [interpreted: bc = 1] > scala.sys.package$.exit(int) () at scala/sys/package.java:41 > > 3. VM thread, already inside of a safepoint and started running G1's > incremental collection: > > Thread 19 (Thread 0x7fd1d70ab700 (LWP 47)): > #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > #1 0x00007fd2931e9a1b in os::PlatformEvent::park() > (this=this at entry=0x7fd28c498200) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > #2 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, > ev=0x7fd28c498200) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 > #3 0x00007fd2931a256f in Monitor::IWait(Thread*, long) > (this=this at entry=0x7fd28c011700, > Self=Self at entry=0x7fd28c497800, timo=timo at entry=0) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 > #4 0x00007fd2931a37fa in Monitor::wait(bool, long, bool) > (this=0x7fd28c011700, no_safepoint_check=no_safepoint_check at entry=tru > e, > timeout=timeout at entry=0, > as_suspend_equivalent=as_suspend_equivalent at entry=false) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1111 > #5 0x00007fd292db1fe2 in CMRootRegions::wait_until_scan_finished() > (this=0x7fd28c0826b8) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp: > 512 > #6 0x00007fd292ea59a4 in > G1CollectedHeap::do_collection_pause_at_safepoint(double) > (this=this at entry=0x7fd28c033c40, > target_pause_time_ms=200) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp > :4095 > #7 0x00007fd29339f002 in VM_G1IncCollectionPause::doit() > (this=0x7fcfc4e0c430) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/gc_implementation/g1/vm_operations_g1.cp > p:148 > #8 0x00007fd29339dfd7 in VM_Operation::evaluate() > (this=this at entry=0x7fcfc4e0c430) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/runtime/vm_operations.cpp:62 > #9 0x00007fd29339b6d7 in VMThread::evaluate_operation(VM_Operation*) > (op=0x7fcfc4e0c430, this=) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:377 > #10 0x00007fd29339cb5f in VMThread::loop() (this=this at entry=0x7fd28c4 > 97800) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:502 > #11 0x00007fd29339d051 in VMThread::run() (this=0x7fd28c497800) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:276 > #12 0x00007fd2931e1222 in java_start(Thread*) (thread=0x7fd28c497800) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162- > b12/src/hotspot/src/os/linux/vm/os_linux.cpp:790 From david.holmes at oracle.com Thu Sep 13 09:51:03 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Sep 2018 19:51:03 +1000 Subject: VM deadlock between VM shutdown and G1 In-Reply-To: References: Message-ID: Hi Kris, I didn't quite follow the analysis (see below) On 13/09/2018 6:57 PM, Krystal Mok wrote: > Hi HotSpot devs, > > I'd like to report a VM deadlock situation we've experienced in production > a few weeks ago on JDK8. I checked the latest jdk/jdk code and the same > race condition is still there. > > I can file a JBS ticket if this looks like a valid problem. > > tl;dr: there's a race condition between the VM shutdown and G1, in that the > VM shutdown sequence may have just terminated all the concurrent GC > threads, and at the same time G1 has just started an incremental collection > cycle and is waiting for the concurrent marker to finish. Since there's no > concurrent GC thread alive to update the status anymore, G1 waits > indefinitely while holding a safepoint, causing the VM to deadlock. > > Details: > > 3 threads are involved in the actual deadlock. Detailed stack traces are at > the end of this email. > > 1. A Java application thread at an allocation site triggering a G1 > incremental collection > 2. A thread that called System.exit(), initiating the VM shutdown sequence. > It's in VM's native code so it doesn't block a safepoint. VM code is not "native" in the sense of being safepoint-safe. If it's still in the System.c code trying to call the VM then it is native but as soon as it tries to enter the VM it will block if a safepoint is in progress. In addition the exit requires that the VM go to a safepoint before terminating. > 3. VM thread, already inside of a safepoint and started running G1's > incremental collection. > (4. "the world" is at a safepoint so all other Java threads are just > waiting) > > The problem is, Thread 2 has already run half way into before_exit(), and The problem seems to be an event callback, cbVMDeath, which seems to have take the thread from _thread_in_vm (which is not a safepoint-safe state) to presumably _thread_in_native, which is safepoint-safe. The callback then blocks on a RawMonitorWait for something and that would seem to be where the problem arises. What is the callback trying to do? Cheers, David ----- > one of the steps in there is: > > hotspot/src/share/vm/runtime/java.cpp > > 503 // Stop concurrent GC threads > 504 Universe::heap()->stop(); > > But G1 is waiting for the concurrent marker to finish scanning the root > regions: > > hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp > > 506 bool CMRootRegions::wait_until_scan_finished() { > 507 if (!scan_in_progress()) return false; > 508 > 509 { > 510 MutexLockerEx x(RootRegionScan_lock, > Mutex::_no_safepoint_check_flag); > 511 while (scan_in_progress()) { > 512 RootRegionScan_lock->wait(Mutex::_no_safepoint_check_flag); > 513 } > 514 } > 515 return true; > 516 } > > But scan_in_process is only updated in a few places: > > hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp > > 449 void CMRootRegions::prepare_for_scan() { > 450 assert(!scan_in_progress(), "pre-condition"); > 451 > 452 // Currently, only survivors can be root regions. > 453 assert(_next_survivor == NULL, "pre-condition"); > 454 _next_survivor = _young_list->first_survivor_region(); > 455 _scan_in_progress = (_next_survivor != NULL); > 456 _should_abort = false; > 457 } > > 490 void CMRootRegions::scan_finished() { > 491 assert(scan_in_progress(), "pre-condition"); > 492 > 493 // Currently, only survivors can be root regions. > 494 if (!_should_abort) { > 495 assert(_next_survivor == NULL, "we should have claimed all > survivors"); > 496 } > 497 _next_survivor = NULL; > 498 > 499 { > 500 MutexLockerEx x(RootRegionScan_lock, > Mutex::_no_safepoint_check_flag); > 501 _scan_in_progress = false; > 502 RootRegionScan_lock->notify_all(); > 503 } > 504 } > > And with the current GC threads gone, nobody ever gets to set > scan_in_process back to false, which leads to an infinite wait. > > One way I'd imagine fixing this is by adding a check in G1's > CMRootRegions::wait_until_scan_finished() to see if the concurrent marker > thread is still there, and if it isn't, there's no point in waiting anymore. > Obviously similar fixes would have to be done separately for other > concurrent GCs in HotSpot. > > What do you think? > > Thanks, > Kris > > Detail thread stacks for in the example: > > 1. A Java application thread at an allocation site triggering a G1 > incremental collection: > > Thread 2164 (Thread 0x7fcfc4e11700 (LWP 25218)): > #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > #1 0x00007fd2931e9a1b in os::PlatformEvent::park() > (this=this at entry=0x7fd05c029c00) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > #2 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, > ev=0x7fd05c029c00) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 > #3 0x00007fd2931a256f in Monitor::IWait(Thread*, long) > (this=this at entry=0x7fd28c012800, > Self=Self at entry=0x7fd1ac0f2000, timo=timo at entry=0) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 > #4 0x00007fd2931a382e in Monitor::wait(bool, long, bool) > (this=0x7fd28c012800, no_safepoint_check=, > timeout=timeout at entry=0, > as_suspend_equivalent=as_suspend_equivalent at entry=false) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1126 > #5 0x00007fd29339d5fc in VMThread::execute(VM_Operation*) > (op=op at entry=0x7fcfc4e0c430) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:642 > #6 0x00007fd292e99fec in G1CollectedHeap::attempt_allocation_slow(unsigned > long, unsigned char, unsigned int*, unsigned int*) > (gc_cause=GCCause::_g1_inc_collection_pause, succeeded=, > gc_count_before=, word_size=1026, this=0x7fd28c033c40) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:3628 > #7 0x00007fd292e99fec in G1CollectedHeap::attempt_allocation_slow(unsigned > long, unsigned char, unsigned int*, unsigned int*) > (this=this at entry=0x7fd28c033c40, > word_size=word_size at entry=1026, context=context at entry=0 '\000', > gc_count_before_ret=gc_count_before_ret at entry=0x7fcfc4e0c50c, > gclocker_retry_count_ret=gclocker_retry_count_ret at entry=0x7fcfc4e0c508) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:956 > #8 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned long, > bool*) (gclocker_retry_count_ret=0x7fcfc4e0c508, > gc_count_before_ret=0x7fcfc4e0c50c, word_size=1026, this=0x7fd28c033c40) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp:147 > #9 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned long, > bool*) (this=0x7fd28c033c40, word_size=1026, > gc_overhead_limit_was_exceeded=) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:846 > #10 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:135 > #11 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:175 > #12 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > Thread*) (__the_thread__=0x7fd1ac0f2000, length=8192, size=1026, klass=...) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:216 > #13 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > Thread*) (this=0x7c0000768, length=length at entry=8192, > do_zero=do_zero at entry=true, > __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/oops/typeArrayKlass.cpp:107 > #14 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, > Thread*) (__the_thread__=__the_thread__ at entry=0x7fd1ac0f2000, > length=length at entry=8192, this=) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/oops/typeArrayKlass.hpp:67 > #15 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, > Thread*) (type=, length=length at entry=8192, > __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/memory/oopFactory.cpp:56 > #16 0x00007fd293283457 in OptoRuntime::new_array_C(Klass*, int, > JavaThread*) (array_type=, len=8192, thread=0x7fd1ac0f2000) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/opto/runtime.cpp:279 > #17 0x00007fd27d0871c7 in () > > 2. A thread that called System.exit(), initiating the VM shutdown sequence. > It's in native code so it doesn't block a safepoint: > > Thread 563 (Thread 0x7fd017980700 (LWP 7959)): > #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > #1 0x00007fd2931e9a1b in os::PlatformEvent::park() (this=0x7fd0f4015000) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > #2 0x00007fd293064485 in JvmtiRawMonitor::SimpleWait(Thread*, long) > (this=this at entry=0x7fd28f22f020, Self=Self at entry=0x7fd28f0c9800, > millis=millis at entry=-1) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:194 > #3 0x00007fd293064c75 in JvmtiRawMonitor::raw_wait(long, bool, Thread*) > (this=this at entry=0x7fd28f22f020, millis=millis at entry=-1, > interruptible=interruptible at entry=true, > __the_thread__=__the_thread__ at entry=0x7fd28f0c9800) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:383 > #4 0x00007fd293040c09 in JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*, long) > (this=, rmonitor=0x7fd28f22f020, millis=-1) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiEnv.cpp:3144 > #5 0x00007fd291620af8 in debugMonitorWait (monitor=) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/util.c:1075 > #6 0x00007fd29160e86c in cbVMDeath (jvmti_env=, > env=0x7fd28f0c99e0) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:1273 > #7 0x00007fd29304f4b0 in JvmtiExport::post_vm_death() () at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiExport.cpp:490 > #8 0x00007fd292f896dd in before_exit(JavaThread*) (thread=) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/java.cpp:532 > #9 0x00007fd292fd005b in JVM_Halt(jint) (code=1) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvm.cpp:441 > #10 0x00007fd27d020868 in [native] java.lang.Shutdown.halt0(int) () at > java/lang/Shutdown.java:0 > #11 0x00007fd27d00809d in [interpreted: bc = 7] > java.lang.Shutdown.halt(int) () at java/lang/Shutdown.java:140 > #12 0x00007fd27d00809d in [interpreted: bc = 99] > java.lang.Shutdown.exit(int) () at java/lang/Shutdown.java:214 > #13 0x00007fd27d00809d in [interpreted: bc = 14] > java.lang.Runtime.exit(int) () at java/lang/Runtime.java:110 > #14 0x00007fd27d00809d in [interpreted: bc = 4] java.lang.System.exit(int) > () at java/lang/System.java:972 > #15 0x00007fd27d00809d in [interpreted: bc = 1] > scala.sys.package$.exit(int) () at scala/sys/package.java:41 > > 3. VM thread, already inside of a safepoint and started running G1's > incremental collection: > > Thread 19 (Thread 0x7fd1d70ab700 (LWP 47)): > #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > #1 0x00007fd2931e9a1b in os::PlatformEvent::park() > (this=this at entry=0x7fd28c498200) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > #2 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, > ev=0x7fd28c498200) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 > #3 0x00007fd2931a256f in Monitor::IWait(Thread*, long) > (this=this at entry=0x7fd28c011700, > Self=Self at entry=0x7fd28c497800, timo=timo at entry=0) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 > #4 0x00007fd2931a37fa in Monitor::wait(bool, long, bool) > (this=0x7fd28c011700, no_safepoint_check=no_safepoint_check at entry=true, > timeout=timeout at entry=0, > as_suspend_equivalent=as_suspend_equivalent at entry=false) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1111 > #5 0x00007fd292db1fe2 in CMRootRegions::wait_until_scan_finished() > (this=0x7fd28c0826b8) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:512 > #6 0x00007fd292ea59a4 in > G1CollectedHeap::do_collection_pause_at_safepoint(double) > (this=this at entry=0x7fd28c033c40, > target_pause_time_ms=200) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:4095 > #7 0x00007fd29339f002 in VM_G1IncCollectionPause::doit() > (this=0x7fcfc4e0c430) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/vm_operations_g1.cpp:148 > #8 0x00007fd29339dfd7 in VM_Operation::evaluate() > (this=this at entry=0x7fcfc4e0c430) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vm_operations.cpp:62 > #9 0x00007fd29339b6d7 in VMThread::evaluate_operation(VM_Operation*) > (op=0x7fcfc4e0c430, this=) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:377 > #10 0x00007fd29339cb5f in VMThread::loop() (this=this at entry=0x7fd28c497800) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:502 > #11 0x00007fd29339d051 in VMThread::run() (this=0x7fd28c497800) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:276 > #12 0x00007fd2931e1222 in java_start(Thread*) (thread=0x7fd28c497800) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:790 > From david.holmes at oracle.com Thu Sep 13 09:57:28 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Sep 2018 19:57:28 +1000 Subject: VM deadlock between VM shutdown and G1 In-Reply-To: References: Message-ID: <86d405c7-f27e-6869-62a6-0ef5d8a60d0d@oracle.com> Actually this seems to have some similarities with 4953323 And if cbVMDeath is anything like what is depicted here: http://www.oracle.com/technetwork/articles/javase/index-140680.html then deadlock seems quite likely. I'll try to look into this deeper tomorrow. Cheers, David On 13/09/2018 7:51 PM, David Holmes wrote: > Hi Kris, > > I didn't quite follow the analysis (see below) > > On 13/09/2018 6:57 PM, Krystal Mok wrote: >> Hi HotSpot devs, >> >> I'd like to report a VM deadlock situation we've experienced in >> production >> a few weeks ago on JDK8. I checked the latest jdk/jdk code and the same >> race condition is still there. >> >> I can file a JBS ticket if this looks like a valid problem. >> >> tl;dr: there's a race condition between the VM shutdown and G1, in >> that the >> VM shutdown sequence may have just terminated all the concurrent GC >> threads, and at the same time G1 has just started an incremental >> collection >> cycle and is waiting for the concurrent marker to finish. Since >> there's no >> concurrent GC thread alive to update the status anymore, G1 waits >> indefinitely while holding a safepoint, causing the VM to deadlock. >> >> Details: >> >> 3 threads are involved in the actual deadlock. Detailed stack traces >> are at >> the end of this email. >> >> 1. A Java application thread at an allocation site triggering a G1 >> incremental collection >> 2. A thread that called System.exit(), initiating the VM shutdown >> sequence. >> It's in VM's native code so it doesn't block a safepoint. > > VM code is not "native" in the sense of being safepoint-safe. If it's > still in the System.c code trying to call the VM then it is native but > as soon as it tries to enter the VM it will block if a safepoint is in > progress. In addition the exit requires that the VM go to a safepoint > before terminating. > >> 3. VM thread, already inside of a safepoint and started running G1's >> incremental collection. >> (4. "the world" is at a safepoint so all other Java threads are just >> waiting) >> >> The problem is, Thread 2 has already run half way into before_exit(), and > > The problem seems to be an event callback, cbVMDeath, which seems to > have take the thread from _thread_in_vm (which is not a safepoint-safe > state) to presumably _thread_in_native, which is safepoint-safe. The > callback then blocks on a RawMonitorWait for something and that would > seem to be where the problem arises. What is the callback trying to do? > > Cheers, > David > ----- > > >> one of the steps in there is: >> >> hotspot/src/share/vm/runtime/java.cpp >> >> 503?? // Stop concurrent GC threads >> 504?? Universe::heap()->stop(); >> >> But G1 is waiting for the concurrent marker to finish scanning the root >> regions: >> >> hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp >> >> ? 506 bool CMRootRegions::wait_until_scan_finished() { >> ? 507?? if (!scan_in_progress()) return false; >> ? 508 >> ? 509?? { >> ? 510???? MutexLockerEx x(RootRegionScan_lock, >> Mutex::_no_safepoint_check_flag); >> ? 511???? while (scan_in_progress()) { >> ? 512?????? RootRegionScan_lock->wait(Mutex::_no_safepoint_check_flag); >> ? 513???? } >> ? 514?? } >> ? 515?? return true; >> ? 516 } >> >> But scan_in_process is only updated in a few places: >> >> hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp >> >> ? 449 void CMRootRegions::prepare_for_scan() { >> ? 450?? assert(!scan_in_progress(), "pre-condition"); >> ? 451 >> ? 452?? // Currently, only survivors can be root regions. >> ? 453?? assert(_next_survivor == NULL, "pre-condition"); >> ? 454?? _next_survivor = _young_list->first_survivor_region(); >> ? 455?? _scan_in_progress = (_next_survivor != NULL); >> ? 456?? _should_abort = false; >> ? 457 } >> >> ? 490 void CMRootRegions::scan_finished() { >> ? 491?? assert(scan_in_progress(), "pre-condition"); >> ? 492 >> ? 493?? // Currently, only survivors can be root regions. >> ? 494?? if (!_should_abort) { >> ? 495???? assert(_next_survivor == NULL, "we should have claimed all >> survivors"); >> ? 496?? } >> ? 497?? _next_survivor = NULL; >> ? 498 >> ? 499?? { >> ? 500???? MutexLockerEx x(RootRegionScan_lock, >> Mutex::_no_safepoint_check_flag); >> ? 501???? _scan_in_progress = false; >> ? 502???? RootRegionScan_lock->notify_all(); >> ? 503?? } >> ? 504 } >> >> And with the current GC threads gone, nobody ever gets to set >> scan_in_process back to false, which leads to an infinite wait. >> >> One way I'd imagine fixing this is by adding a check in G1's >> CMRootRegions::wait_until_scan_finished() to see if the concurrent marker >> thread is still there, and if it isn't, there's no point in waiting >> anymore. >> Obviously similar fixes would have to be done separately for other >> concurrent GCs in HotSpot. >> >> What do you think? >> >> Thanks, >> Kris >> >> Detail thread stacks for in the example: >> >> 1. A Java application thread at an allocation site triggering a G1 >> incremental collection: >> >> Thread 2164 (Thread 0x7fcfc4e11700 (LWP 25218)): >> #0? 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> #1? 0x00007fd2931e9a1b in os::PlatformEvent::park() >> (this=this at entry=0x7fd05c029c00) >> at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 >> >> #2? 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, >> ev=0x7fd05c029c00) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 >> >> #3? 0x00007fd2931a256f in Monitor::IWait(Thread*, long) >> (this=this at entry=0x7fd28c012800, >> Self=Self at entry=0x7fd1ac0f2000, timo=timo at entry=0) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 >> >> #4? 0x00007fd2931a382e in Monitor::wait(bool, long, bool) >> (this=0x7fd28c012800, no_safepoint_check=, >> timeout=timeout at entry=0, >> as_suspend_equivalent=as_suspend_equivalent at entry=false) >> at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1126 >> >> #5? 0x00007fd29339d5fc in VMThread::execute(VM_Operation*) >> (op=op at entry=0x7fcfc4e0c430) >> at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:642 >> >> #6? 0x00007fd292e99fec in >> G1CollectedHeap::attempt_allocation_slow(unsigned >> long, unsigned char, unsigned int*, unsigned int*) >> (gc_cause=GCCause::_g1_inc_collection_pause, succeeded=> pointer>, >> gc_count_before=, word_size=1026, this=0x7fd28c033c40) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:3628 >> >> #7? 0x00007fd292e99fec in >> G1CollectedHeap::attempt_allocation_slow(unsigned >> long, unsigned char, unsigned int*, unsigned int*) >> (this=this at entry=0x7fd28c033c40, >> word_size=word_size at entry=1026, context=context at entry=0 '\000', >> gc_count_before_ret=gc_count_before_ret at entry=0x7fcfc4e0c50c, >> gclocker_retry_count_ret=gclocker_retry_count_ret at entry=0x7fcfc4e0c508) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:956 >> >> #8? 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned long, >> bool*) (gclocker_retry_count_ret=0x7fcfc4e0c508, >> gc_count_before_ret=0x7fcfc4e0c50c, word_size=1026, >> this=0x7fd28c033c40) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp:147 >> >> #9? 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned long, >> bool*) (this=0x7fd28c033c40, word_size=1026, >> gc_overhead_limit_was_exceeded=) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:846 >> >> #10 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, >> Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:135 >> >> #11 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, >> Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:175 >> >> #12 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, >> Thread*) (__the_thread__=0x7fd1ac0f2000, length=8192, size=1026, >> klass=...) >> at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:216 >> >> #13 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, >> Thread*) (this=0x7c0000768, length=length at entry=8192, >> do_zero=do_zero at entry=true, >> __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/oops/typeArrayKlass.cpp:107 >> >> #14 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, >> Thread*) (__the_thread__=__the_thread__ at entry=0x7fd1ac0f2000, >> length=length at entry=8192, this=) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/oops/typeArrayKlass.hpp:67 >> >> #15 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, >> Thread*) (type=, length=length at entry=8192, >> __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/memory/oopFactory.cpp:56 >> >> #16 0x00007fd293283457 in OptoRuntime::new_array_C(Klass*, int, >> JavaThread*) (array_type=, len=8192, >> thread=0x7fd1ac0f2000) >> at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/opto/runtime.cpp:279 >> >> #17 0x00007fd27d0871c7 in? () >> >> 2. A thread that called System.exit(), initiating the VM shutdown >> sequence. >> It's in native code so it doesn't block a safepoint: >> >> Thread 563 (Thread 0x7fd017980700 (LWP 7959)): >> #0? 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> #1? 0x00007fd2931e9a1b in os::PlatformEvent::park() (this=0x7fd0f4015000) >> at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 >> >> #2? 0x00007fd293064485 in JvmtiRawMonitor::SimpleWait(Thread*, long) >> (this=this at entry=0x7fd28f22f020, Self=Self at entry=0x7fd28f0c9800, >> millis=millis at entry=-1) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:194 >> >> #3? 0x00007fd293064c75 in JvmtiRawMonitor::raw_wait(long, bool, Thread*) >> (this=this at entry=0x7fd28f22f020, millis=millis at entry=-1, >> interruptible=interruptible at entry=true, >> __the_thread__=__the_thread__ at entry=0x7fd28f0c9800) >> at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:383 >> >> #4? 0x00007fd293040c09 in JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*, >> long) >> (this=, rmonitor=0x7fd28f22f020, millis=-1) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiEnv.cpp:3144 >> >> #5? 0x00007fd291620af8 in debugMonitorWait (monitor=) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/util.c:1075 >> >> #6? 0x00007fd29160e86c in cbVMDeath (jvmti_env=, >> env=0x7fd28f0c99e0) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:1273 >> >> #7? 0x00007fd29304f4b0 in JvmtiExport::post_vm_death() () at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiExport.cpp:490 >> >> #8? 0x00007fd292f896dd in before_exit(JavaThread*) (thread=> out>) >> at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/java.cpp:532 >> >> #9? 0x00007fd292fd005b in JVM_Halt(jint) (code=1) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvm.cpp:441 >> >> #10 0x00007fd27d020868 in [native] java.lang.Shutdown.halt0(int) () at >> java/lang/Shutdown.java:0 >> #11 0x00007fd27d00809d in [interpreted: bc = 7] >> java.lang.Shutdown.halt(int) () at java/lang/Shutdown.java:140 >> #12 0x00007fd27d00809d in [interpreted: bc = 99] >> java.lang.Shutdown.exit(int) () at java/lang/Shutdown.java:214 >> #13 0x00007fd27d00809d in [interpreted: bc = 14] >> java.lang.Runtime.exit(int) () at java/lang/Runtime.java:110 >> #14 0x00007fd27d00809d in [interpreted: bc = 4] >> java.lang.System.exit(int) >> () at java/lang/System.java:972 >> #15 0x00007fd27d00809d in [interpreted: bc = 1] >> scala.sys.package$.exit(int) () at scala/sys/package.java:41 >> >> 3. VM thread, already inside of a safepoint and started running G1's >> incremental collection: >> >> Thread 19 (Thread 0x7fd1d70ab700 (LWP 47)): >> #0? 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> #1? 0x00007fd2931e9a1b in os::PlatformEvent::park() >> (this=this at entry=0x7fd28c498200) >> at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 >> >> #2? 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, >> ev=0x7fd28c498200) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 >> >> #3? 0x00007fd2931a256f in Monitor::IWait(Thread*, long) >> (this=this at entry=0x7fd28c011700, >> Self=Self at entry=0x7fd28c497800, timo=timo at entry=0) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 >> >> #4? 0x00007fd2931a37fa in Monitor::wait(bool, long, bool) >> (this=0x7fd28c011700, no_safepoint_check=no_safepoint_check at entry=true, >> timeout=timeout at entry=0, >> as_suspend_equivalent=as_suspend_equivalent at entry=false) >> at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1111 >> >> #5? 0x00007fd292db1fe2 in CMRootRegions::wait_until_scan_finished() >> (this=0x7fd28c0826b8) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:512 >> >> #6? 0x00007fd292ea59a4 in >> G1CollectedHeap::do_collection_pause_at_safepoint(double) >> (this=this at entry=0x7fd28c033c40, >> target_pause_time_ms=200) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:4095 >> >> #7? 0x00007fd29339f002 in VM_G1IncCollectionPause::doit() >> (this=0x7fcfc4e0c430) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/vm_operations_g1.cpp:148 >> >> #8? 0x00007fd29339dfd7 in VM_Operation::evaluate() >> (this=this at entry=0x7fcfc4e0c430) >> at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vm_operations.cpp:62 >> >> #9? 0x00007fd29339b6d7 in VMThread::evaluate_operation(VM_Operation*) >> (op=0x7fcfc4e0c430, this=) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:377 >> >> #10 0x00007fd29339cb5f in VMThread::loop() >> (this=this at entry=0x7fd28c497800) >> at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:502 >> >> #11 0x00007fd29339d051 in VMThread::run() (this=0x7fd28c497800) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:276 >> >> #12 0x00007fd2931e1222 in java_start(Thread*) (thread=0x7fd28c497800) at >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:790 >> >> From rednaxelafx at gmail.com Thu Sep 13 10:14:15 2018 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 13 Sep 2018 03:14:15 -0700 Subject: VM deadlock between VM shutdown and G1 In-Reply-To: References: Message-ID: Hi David, Comments inline: On Thu, Sep 13, 2018 at 2:51 AM, David Holmes wrote: > Hi Kris, > > I didn't quite follow the analysis (see below) > > On 13/09/2018 6:57 PM, Krystal Mok wrote: >> >> 1. A Java application thread at an allocation site triggering a G1 >> incremental collection >> 2. A thread that called System.exit(), initiating the VM shutdown >> sequence. >> It's in VM's native code so it doesn't block a safepoint. >> > > VM code is not "native" in the sense of being safepoint-safe. If it's > still in the System.c code trying to call the VM then it is native but as > soon as it tries to enter the VM it will block if a safepoint is in > progress. In addition the exit requires that the VM go to a safepoint > before terminating. > > The time window was extremely narrow but it did happen in practice. The Java application thread called System.exit() -> JVM_Halt(), where the safepoint was probably not-yet active so it went past the safepoint check upon entry and gets into _thread_in_vm state, and then when it tries to post the VM death event it transitions to _thread_in_native state (through JvmtiJavaThreadEventTransition, which is then safepoint safe), and probably at around this time the safepoint synchronization started and then stopped the world. There's nothing really special about what the cbVMDeath otherwise. This process has enabled the JDWP agent and that's a part of the story how this thread got into a _thread_in_native state. > 3. VM thread, already inside of a safepoint and started running G1's >> incremental collection. >> (4. "the world" is at a safepoint so all other Java threads are just >> waiting) >> >> The problem is, Thread 2 has already run half way into before_exit(), and >> > > The problem seems to be an event callback, cbVMDeath, which seems to have > take the thread from _thread_in_vm (which is not a safepoint-safe state) to > presumably _thread_in_native, which is safepoint-safe. The callback then > blocks on a RawMonitorWait for something and that would seem to be where > the problem arises. What is the callback trying to do? > > The cbVMDeath callback is just waiting for other active callbacks to check in (line 1273): jdk/src/share/back/eventHandler.c 1267 debugMonitorEnter(callbackBlock); { 1268 debugMonitorEnter(callbackLock); { 1269 vm_death_callback_active = JNI_TRUE; 1270 (void)threadControl_resumeAll(); 1271 while (active_callbacks > 0) { 1272 /* wait for active CALLBACKs to check in (and block) */ 1273 debugMonitorWait(callbackLock); 1274 } 1275 } debugMonitorExit(callbackLock); The real deadlock in this case should still be the fact that VM has reached a safepoint at this point in time, but G1's waiting for the concurrent marker to check in, yet it's already gone. > Cheers, > David > Thanks, Kris From sgehwolf at redhat.com Thu Sep 13 10:02:36 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 13 Sep 2018 12:02:36 +0200 Subject: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: <4cc34e60-be08-4e4a-c08c-fdcde0ba4646@oracle.com> References: <7D5F0258-F6DE-402A-AB32-907A2D6E45DF@sap.com> <4cc34e60-be08-4e4a-c08c-fdcde0ba4646@oracle.com> Message-ID: Hi Erik, On Wed, 2018-09-12 at 10:02 -0700, Erik Joelsson wrote: > Hello Severin, > > In configure, we now set FDLIBM_CFLAGS based on toolchain type and > capabilities. In JvmOverrideFiles.gmk, the use of it is still > conditional on Linux. I don't think it should be. We already have the > conditionals we need. Thanks for the review. Updated webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.03/ I wasn't sure whether the precompiled headers handling for gcc/clang is right and was reluctant to move it out of the linux conditional. The assumption on my end is that if headers are compiled with -O3, we can't used them for any other opt level. It should still all work. Thoughts? Thanks, Severin > On 2018-09-12 05:44, Severin Gehwolf wrote: > > Hi, > > > > Updated webrev since fdlibm build change seems to have settled: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.02/ > > > > Optimization is being done at level -O2 (CXX_O_FLAG_NORM) with > > -ffp-contract=off when the toolchain (gcc/clang at this point) > > supports it. Otherwise no optimization will be done. Those overrides > > are no longer in an x86 specific block. Thus, ppc64, aarch64, s390x > > will get correct settings too. > > > > How does this look? > > > > Thanks, > > Severin > > > > On Wed, 2018-09-12 at 07:16 +0000, Schmidt, Lutz wrote: > > > I totally agree with Andrew's statement. FP calculations should be > > > evaluated as the programmer wrote them down. All fiddling around with > > > sequence or rounding is evil. You lose reproducibility of results. > > > Regards, > > > Lutz > > > > > > ?On 08.09.18, 11:26, "hotspot-dev on behalf of Andrew Haley" wrote: > > > > > > On 09/06/2018 03:32 PM, Severin Gehwolf wrote: > > > > Right. I should note that ppc64, s390x and aarch64 ports don't have > > > > this optimization turned off as those overrides are in a x86 specific > > > > block. It appears it hasn't caused issues for these ports so far. > > > > > > That's just dumb luck. We really should turn off the merging of FP > > > operations on all platforms. > > > > > > -- > > > Andrew Haley > > > Java Platform Lead Engineer > > > Red Hat UK Ltd. > > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > > > > > > From magnus.ihse.bursie at oracle.com Thu Sep 13 11:52:25 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Sep 2018 13:52:25 +0200 Subject: RFR: 8210703: vmStructs.cpp compiled with -O0 (was: Why is vmStructs.cpp compiled with -O0? In-Reply-To: <9ab2dbb35adb318c164bf4f7d543dc8005444d90.camel@redhat.com> References: <0c608e27c025dfe332a8694494ba31c3bd7dafa4.camel@redhat.com> <97b1aa06-5827-8872-a26d-f4300c2d1274@oracle.com> <9ab2dbb35adb318c164bf4f7d543dc8005444d90.camel@redhat.com> Message-ID: Severin, Your patch looks good to me. I'm assuming you have tested that nothing breaks. /Magnus > 13 sep. 2018 kl. 10:43 skrev Severin Gehwolf : > > Hi Erik, > >> On Wed, 2018-09-12 at 10:25 -0700, Erik Joelsson wrote: >> Hello, >> >> I very much doubt it was included with the new build system. We were >> extremely careful to use the exact same flags then, and did binary >> comparisons of all object files to verify equal builds. >> >> Tracing back, it was caused (probably unintentionally) by this change: >> >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e796d52ca85b > > Thanks for the detective work! This looks very much unintentional to me > as JDK-8114853 is about silencing a note. > >> In the old build, setting OPT_CFLAGS/ overrides the common >> OPT_CFLAGS. In the new build, we have a more general way of adding flags >> for specific files that does not directly override any other flags. To >> get the same behavior for vmStructs.cpp in the new build as in the old >> at the time of the switch, we had to add -O0 explicitly in the new build. > > I've filed JDK-8210703 and posting this patch as review for the bug. > Note I've changed the subject. Does this look OK? > > diff --git a/make/hotspot/lib/JvmOverrideFiles.gmk b/make/hotspot/lib/JvmOverrideFiles.gmk > --- a/make/hotspot/lib/JvmOverrideFiles.gmk > +++ b/make/hotspot/lib/JvmOverrideFiles.gmk > @@ -30,7 +30,7 @@ > # status for individual files on specific platforms. > > ifeq ($(TOOLCHAIN_TYPE), gcc) > - BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0 > + BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments > BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments > BUILD_LIBJVM_jvmciCompilerToVMInit.cpp_CXXFLAGS := -fno-var-tracking-assignments > BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized > > Thanks, > Severin > > On 2018-09-12 09:13, Severin Gehwolf wrote: >>> Hi, >>> >>> Does anybody know why vmStructs.cpp gets an override in >>> JvmOverrideFiles.gmk: >>> >>> $ grep -C3 -n vmStructs.cpp make/hotspot/lib/JvmOverrideFiles.gmk >>> 30-# status for individual files on specific platforms. >>> 31- >>> 32-ifeq ($(TOOLCHAIN_TYPE), gcc) >>> 33: BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0 >>> 34- BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments >>> 35- BUILD_LIBJVM_jvmciCompilerToVMInit.cpp_CXXFLAGS := -fno-var-tracking-assignments >>> 36- BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized >>> >>> It seems to have been introduced with the new build system. JDK 8 >>> doesn't seem to have it. Thoughts? >>> >>> Thanks, >>> Severin > From david.holmes at oracle.com Thu Sep 13 12:00:16 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 13 Sep 2018 22:00:16 +1000 Subject: VM deadlock between VM shutdown and G1 In-Reply-To: References: Message-ID: <7c01eb84-7100-1fd3-ff10-5449b36dcf6b@oracle.com> Hi Kris, Okay got it now. So basically: Universe::heap()->stop(); has to be written in such a way that it can safely be called even if there's a GC related VMop in execution. Cheers, David On 13/09/2018 8:14 PM, Krystal Mok wrote: > Hi David, > > Comments inline: > > On Thu, Sep 13, 2018 at 2:51 AM, David Holmes > wrote: > > Hi Kris, > > I didn't quite follow the analysis (see below) > > On 13/09/2018 6:57 PM, Krystal Mok wrote: > > 1. A Java application thread at an allocation site triggering a G1 > incremental collection > 2. A thread that called System.exit(), initiating the VM > shutdown sequence. > It's in VM's native code so it doesn't block a safepoint. > > > VM code is not "native" in the sense of being safepoint-safe. If > it's still in the System.c code trying to call the VM then it is > native but as soon as it tries to enter the VM it will block if a > safepoint is in progress. In addition the exit requires that the VM > go to a safepoint before terminating. > > The time window was extremely narrow but it did happen in practice. > The Java application thread called System.exit() -> JVM_Halt(), where > the safepoint was probably not-yet active so it went past the safepoint > check upon entry and gets into _thread_in_vm state, and then when it > tries to post the VM death event it transitions to _thread_in_native > state (through JvmtiJavaThreadEventTransition, which is then safepoint > safe), and probably at around this time the safepoint synchronization > started and then stopped the world. > > There's nothing really special about what the cbVMDeath otherwise. This > process has enabled the JDWP agent and that's a part of the story how > this thread got into a _thread_in_native state. > > 3. VM thread, already inside of a safepoint and started running G1's > incremental collection. > (4. "the world" is at a safepoint so all other Java threads are just > waiting) > > The problem is, Thread 2 has already run half way into > before_exit(), and > > > The problem seems to be an event callback, cbVMDeath, which seems to > have take the thread from _thread_in_vm (which is not a > safepoint-safe state) to presumably _thread_in_native, which is > safepoint-safe. The callback then blocks on a RawMonitorWait for > something and that would seem to be where the problem arises. What > is the callback trying to do? > > > The cbVMDeath callback is just waiting for other active callbacks to > check in (line 1273): > > jdk/src/share/back/eventHandler.c > > 1267? ? ?debugMonitorEnter(callbackBlock); { > 1268? ? ? ? ?debugMonitorEnter(callbackLock); { > 1269? ? ? ? ? ? ?vm_death_callback_active = JNI_TRUE; > 1270? ? ? ? ? ? ?(void)threadControl_resumeAll(); > 1271? ? ? ? ? ? ?while (active_callbacks > 0) { > 1272? ? ? ? ? ? ? ? ?/* wait for active CALLBACKs to check in (and block) */ > 1273? ? ? ? ? ? ? ? ?debugMonitorWait(callbackLock); > 1274? ? ? ? ? ? ?} > 1275? ? ? ? ?} debugMonitorExit(callbackLock); > > The real deadlock in this case should still be the fact that VM has > reached a safepoint at this point in time, but G1's waiting for the > concurrent marker to check in, yet it's already gone. > > Cheers, > David > > > Thanks, > Kris From rednaxelafx at gmail.com Thu Sep 13 14:06:31 2018 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 13 Sep 2018 07:06:31 -0700 Subject: VM deadlock between VM shutdown and G1 In-Reply-To: <7c01eb84-7100-1fd3-ff10-5449b36dcf6b@oracle.com> References: <7c01eb84-7100-1fd3-ff10-5449b36dcf6b@oracle.com> Message-ID: On Thu, Sep 13, 2018 at 5:00 AM, David Holmes wrote: > Hi Kris, > > Okay got it now. > > So basically: > > Universe::heap()->stop(); > > has to be written in such a way that it can safely be called even if > there's a GC related VMop in execution. > > Cheers, > David Yes exactly. It's a deadlock and you need two hands to make a clap, so either Universe::heap()->stop() needs to do more signaling (perhaps setting a global flag to indicate the concurrent GC threads are gone, and let the GCs pick it up), or the concurrent GCs themselves have to be more careful to check for VM exiting conditions when in a wait loop. - Kris From sgehwolf at redhat.com Thu Sep 13 15:06:51 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 13 Sep 2018 17:06:51 +0200 Subject: RFR: 8210703: vmStructs.cpp compiled with -O0 (was: Why is vmStructs.cpp compiled with -O0? In-Reply-To: References: <0c608e27c025dfe332a8694494ba31c3bd7dafa4.camel@redhat.com> <97b1aa06-5827-8872-a26d-f4300c2d1274@oracle.com> <9ab2dbb35adb318c164bf4f7d543dc8005444d90.camel@redhat.com> Message-ID: <4ea922ba67306b944d2de88327ded1d2068e744a.camel@redhat.com> Hi Magnus, On Thu, 2018-09-13 at 13:52 +0200, Magnus Ihse Bursie wrote: > Severin, > > Your patch looks good to me. I'm assuming you have tested that nothing breaks. Thanks for the review! Yes, I've tested with run-test-tier1 which seems OK. It includes serviceability/sa/ClhsdbVmStructsDump. I've also run VMStructs gtest. I'm currently running this through jdk-submit. Thanks, Severin > /Magnus > > > 13 sep. 2018 kl. 10:43 skrev Severin Gehwolf : > > > > Hi Erik, > > > > > On Wed, 2018-09-12 at 10:25 -0700, Erik Joelsson wrote: > > > Hello, > > > > > > I very much doubt it was included with the new build system. We were > > > extremely careful to use the exact same flags then, and did binary > > > comparisons of all object files to verify equal builds. > > > > > > Tracing back, it was caused (probably unintentionally) by this change: > > > > > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e796d52ca85b > > > > Thanks for the detective work! This looks very much unintentional to me > > as JDK-8114853 is about silencing a note. > > > > > In the old build, setting OPT_CFLAGS/ overrides the common > > > OPT_CFLAGS. In the new build, we have a more general way of adding flags > > > for specific files that does not directly override any other flags. To > > > get the same behavior for vmStructs.cpp in the new build as in the old > > > at the time of the switch, we had to add -O0 explicitly in the new build. > > > > I've filed JDK-8210703 and posting this patch as review for the bug. > > Note I've changed the subject. Does this look OK? > > > > diff --git a/make/hotspot/lib/JvmOverrideFiles.gmk b/make/hotspot/lib/JvmOverrideFiles.gmk > > --- a/make/hotspot/lib/JvmOverrideFiles.gmk > > +++ b/make/hotspot/lib/JvmOverrideFiles.gmk > > @@ -30,7 +30,7 @@ > > # status for individual files on specific platforms. > > > > ifeq ($(TOOLCHAIN_TYPE), gcc) > > - BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0 > > + BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments > > BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments > > BUILD_LIBJVM_jvmciCompilerToVMInit.cpp_CXXFLAGS := -fno-var-tracking-assignments > > BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized > > > > Thanks, > > Severin > > > > On 2018-09-12 09:13, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Does anybody know why vmStructs.cpp gets an override in > > > > JvmOverrideFiles.gmk: > > > > > > > > $ grep -C3 -n vmStructs.cpp make/hotspot/lib/JvmOverrideFiles.gmk > > > > 30-# status for individual files on specific platforms. > > > > 31- > > > > 32-ifeq ($(TOOLCHAIN_TYPE), gcc) > > > > 33: BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0 > > > > 34- BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments > > > > 35- BUILD_LIBJVM_jvmciCompilerToVMInit.cpp_CXXFLAGS := -fno-var-tracking-assignments > > > > 36- BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized > > > > > > > > It seems to have been introduced with the new build system. JDK 8 > > > > doesn't seem to have it. Thoughts? > > > > > > > > Thanks, > > > > Severin > > From erik.joelsson at oracle.com Thu Sep 13 16:16:21 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Sep 2018 09:16:21 -0700 Subject: RFR: 8210703: vmStructs.cpp compiled with -O0 In-Reply-To: <4ea922ba67306b944d2de88327ded1d2068e744a.camel@redhat.com> References: <0c608e27c025dfe332a8694494ba31c3bd7dafa4.camel@redhat.com> <97b1aa06-5827-8872-a26d-f4300c2d1274@oracle.com> <9ab2dbb35adb318c164bf4f7d543dc8005444d90.camel@redhat.com> <4ea922ba67306b944d2de88327ded1d2068e744a.camel@redhat.com> Message-ID: <6af758c4-e5a4-3a50-a679-9e93014cae6d@oracle.com> Looks good to me. Thanks for cleaning this up! /Erik On 2018-09-13 08:06, Severin Gehwolf wrote: > Hi Magnus, > > On Thu, 2018-09-13 at 13:52 +0200, Magnus Ihse Bursie wrote: >> Severin, >> >> Your patch looks good to me. I'm assuming you have tested that nothing breaks. > Thanks for the review! > > Yes, I've tested with run-test-tier1 which seems OK. It includes > serviceability/sa/ClhsdbVmStructsDump. I've also run VMStructs gtest. > I'm currently running this through jdk-submit. > > Thanks, > Severin > >> /Magnus >> >>> 13 sep. 2018 kl. 10:43 skrev Severin Gehwolf : >>> >>> Hi Erik, >>> >>>> On Wed, 2018-09-12 at 10:25 -0700, Erik Joelsson wrote: >>>> Hello, >>>> >>>> I very much doubt it was included with the new build system. We were >>>> extremely careful to use the exact same flags then, and did binary >>>> comparisons of all object files to verify equal builds. >>>> >>>> Tracing back, it was caused (probably unintentionally) by this change: >>>> >>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/e796d52ca85b >>> Thanks for the detective work! This looks very much unintentional to me >>> as JDK-8114853 is about silencing a note. >>> >>>> In the old build, setting OPT_CFLAGS/ overrides the common >>>> OPT_CFLAGS. In the new build, we have a more general way of adding flags >>>> for specific files that does not directly override any other flags. To >>>> get the same behavior for vmStructs.cpp in the new build as in the old >>>> at the time of the switch, we had to add -O0 explicitly in the new build. >>> I've filed JDK-8210703 and posting this patch as review for the bug. >>> Note I've changed the subject. Does this look OK? >>> >>> diff --git a/make/hotspot/lib/JvmOverrideFiles.gmk b/make/hotspot/lib/JvmOverrideFiles.gmk >>> --- a/make/hotspot/lib/JvmOverrideFiles.gmk >>> +++ b/make/hotspot/lib/JvmOverrideFiles.gmk >>> @@ -30,7 +30,7 @@ >>> # status for individual files on specific platforms. >>> >>> ifeq ($(TOOLCHAIN_TYPE), gcc) >>> - BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0 >>> + BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments >>> BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments >>> BUILD_LIBJVM_jvmciCompilerToVMInit.cpp_CXXFLAGS := -fno-var-tracking-assignments >>> BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized >>> >>> Thanks, >>> Severin >>> >>> On 2018-09-12 09:13, Severin Gehwolf wrote: >>>>> Hi, >>>>> >>>>> Does anybody know why vmStructs.cpp gets an override in >>>>> JvmOverrideFiles.gmk: >>>>> >>>>> $ grep -C3 -n vmStructs.cpp make/hotspot/lib/JvmOverrideFiles.gmk >>>>> 30-# status for individual files on specific platforms. >>>>> 31- >>>>> 32-ifeq ($(TOOLCHAIN_TYPE), gcc) >>>>> 33: BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := -fno-var-tracking-assignments -O0 >>>>> 34- BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := -fno-var-tracking-assignments >>>>> 35- BUILD_LIBJVM_jvmciCompilerToVMInit.cpp_CXXFLAGS := -fno-var-tracking-assignments >>>>> 36- BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized >>>>> >>>>> It seems to have been introduced with the new build system. JDK 8 >>>>> doesn't seem to have it. Thoughts? >>>>> >>>>> Thanks, >>>>> Severin >> From erik.joelsson at oracle.com Thu Sep 13 17:39:50 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 13 Sep 2018 10:39:50 -0700 Subject: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: References: <7D5F0258-F6DE-402A-AB32-907A2D6E45DF@sap.com> <4cc34e60-be08-4e4a-c08c-fdcde0ba4646@oracle.com> Message-ID: On 2018-09-13 03:02, Severin Gehwolf wrote: > Hi Erik, > > On Wed, 2018-09-12 at 10:02 -0700, Erik Joelsson wrote: >> Hello Severin, >> >> In configure, we now set FDLIBM_CFLAGS based on toolchain type and >> capabilities. In JvmOverrideFiles.gmk, the use of it is still >> conditional on Linux. I don't think it should be. We already have the >> conditionals we need. > Thanks for the review. Updated webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.03/ > > I wasn't sure whether the precompiled headers handling for gcc/clang is > right and was reluctant to move it out of the linux conditional. The > assumption on my end is that if headers are compiled with -O3, we can't > used them for any other opt level. It should still all work. Thoughts? Looking at this again, I now realize the whole file has the treatment for these files repeated for each OS, with slight variations. This becomes a clash with the change we are now attempting which is toolchain oriented. I think the easiest way here would be to keep it OS separated for now by reverting to your previous patch. You could consider putting the FDLIBM_CFLAGS conditional block outside the linux block however and apply the "$(FDLIBM_CFLAGS) $(LIBJVM_FDLIBM_COPY_OPT_FLAG)" flags on the lines in the macosx block further down as well. The changes for fdlibm as they are now will apply on macosx since we use clang there, so the jvm change should too. /Erik > Thanks, > Severin > >> On 2018-09-12 05:44, Severin Gehwolf wrote: >>> Hi, >>> >>> Updated webrev since fdlibm build change seems to have settled: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.02/ >>> >>> Optimization is being done at level -O2 (CXX_O_FLAG_NORM) with >>> -ffp-contract=off when the toolchain (gcc/clang at this point) >>> supports it. Otherwise no optimization will be done. Those overrides >>> are no longer in an x86 specific block. Thus, ppc64, aarch64, s390x >>> will get correct settings too. >>> >>> How does this look? >>> >>> Thanks, >>> Severin >>> >>> On Wed, 2018-09-12 at 07:16 +0000, Schmidt, Lutz wrote: >>>> I totally agree with Andrew's statement. FP calculations should be >>>> evaluated as the programmer wrote them down. All fiddling around with >>>> sequence or rounding is evil. You lose reproducibility of results. >>>> Regards, >>>> Lutz >>>> >>>> ?On 08.09.18, 11:26, "hotspot-dev on behalf of Andrew Haley" wrote: >>>> >>>> On 09/06/2018 03:32 PM, Severin Gehwolf wrote: >>>> > Right. I should note that ppc64, s390x and aarch64 ports don't have >>>> > this optimization turned off as those overrides are in a x86 specific >>>> > block. It appears it hasn't caused issues for these ports so far. >>>> >>>> That's just dumb luck. We really should turn off the merging of FP >>>> operations on all platforms. >>>> >>>> -- >>>> Andrew Haley >>>> Java Platform Lead Engineer >>>> Red Hat UK Ltd. >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>>> >>>> >> From magnus.ihse.bursie at oracle.com Thu Sep 13 19:48:37 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Sep 2018 21:48:37 +0200 Subject: Linux + Clang + execstack In-Reply-To: References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> <3193b432-0068-8e2b-9ad4-f5a6467568a1@oracle.com> <6b05bebc-4b06-1071-7dc3-a338ba91c8b0@oracle.com> Message-ID: <7002cda6-ab66-3ff9-083b-cfc024e0c927@oracle.com> On 2018-09-12 18:35, Martin Buchholz wrote: > On Wed, Sep 12, 2018 at 4:01 AM, Magnus Ihse Bursie > wrote: >> On 2018-09-05 20:59, Martin Buchholz wrote: >> >> So ... Magnus, are you happy with the current state of the proposed patch? >> >> I'm sorry Martin, but I can't figure out what the current state is. I tried >> backtracking the discussion but failed. :( Can you please repost the >> currently proposed patch? > http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/noexecstack.patch I'm not entirely happy, but it'll have to do. The problem here is that the underlying structure of the flags handling is still not good so this probably cannot be expressed better than this. Do you have a JBS issue? /Magnus > >> On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie >> wrote: >>> >>> For the gcc toolchain this can not be the case: >>> # Minimum supported linker versions, empty means unspecified >>> TOOLCHAIN_MINIMUM_LD_VERSION_gcc="2.18" >>> >>> We make sure we have an ld that supports the basic flags we assume. >> >> feature tests are better than version tests. >> >> I've heard that argument many times, and I've never agreed with it. In some >> cases, feature tests work. They typically work if someone has designed a >> clear API and included a feature test in it. A lot of additional POSIX >> functionality works that way. This means that you can rest assure that if >> the feature is present, then you know what you are going to get. >> >> In most of the rest of the world, functionality does not raise to that >> golden standard. Gcc adds a flag in one version, but it's buggy. A later >> version fixes the bugs. A later version still changes the behavior of the >> flag. Functionality that we depend on works or does not works depending on >> the intersection of things like our code, compiler version, operating >> system, and so on. >> >> In my experience, it's a rare thing for a feature test to actually work. >> Version tests, on the other hand, tests against a specific setup, that can >> be tested and proven to work. The downside of version tests is that they are >> often open-ended; we say that "anything above this version is supposed to >> work", even though we have not tested with gcc 8 or 9. The alternative is to >> say that "we've tested this between gcc 4.7 and 7.3 and will only support it >> for this version span", but that is in most cases more likely to break when >> gcc 8 comes along. > Specific version tests are in principle more accurate, but they > require a level of testing and maintenance that is unlikely to be seen > in the real world. The received wisdom is that one should prefer > feature tests whenever possible and I agree with that as well, based > on decades of experience. > > Sometimes you need something in between, e.g. replacing a > configure-time check with a run-time check. From martinrb at google.com Thu Sep 13 20:49:51 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 13 Sep 2018 13:49:51 -0700 Subject: Linux + Clang + execstack In-Reply-To: <7002cda6-ab66-3ff9-083b-cfc024e0c927@oracle.com> References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> <3193b432-0068-8e2b-9ad4-f5a6467568a1@oracle.com> <6b05bebc-4b06-1071-7dc3-a338ba91c8b0@oracle.com> <7002cda6-ab66-3ff9-083b-cfc024e0c927@oracle.com> Message-ID: On Thu, Sep 13, 2018 at 12:48 PM, Magnus Ihse Bursie wrote: >> >> http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/noexecstack.patch > > I'm not entirely happy, but it'll have to do. The problem here is that the > underlying structure of the flags handling is still not good so this > probably cannot be expressed better than this. We're not entirely happy either. A much higher interface might look like TRY_ADD_LINKER_FLAGS -z noexecstack which would add -Wl,-z,noexecstack to LDFLAGS when appropriate .... hmmm ... I only just noticed that both gcc and clang accept simply $CC -z noexecstack (it's even documented!) Should we switch to that instead? > Do you have a JBS issue? I have https://bugs.openjdk.java.net/browse/JDK-8205457 gcc and clang should use the same ld flags but the proposed patch only addresses part of that. I could create a sub-task (but I've never done that before) or a new bug or change the description of this bug. What do you think? From leelamohan.venati at gmail.com Thu Sep 13 20:54:54 2018 From: leelamohan.venati at gmail.com (Leela Mohan) Date: Thu, 13 Sep 2018 13:54:54 -0700 Subject: VM deadlock between VM shutdown and G1 In-Reply-To: <86d405c7-f27e-6869-62a6-0ef5d8a60d0d@oracle.com> References: <86d405c7-f27e-6869-62a6-0ef5d8a60d0d@oracle.com> Message-ID: Hi Kris, If i understand this deadlock correctly, There are two issues here. A) Inside "cbVMDeath" , "VM exiting" thread is waiting to be notified by active JVMTI callbacks to be completed. If we see "BEGIN_CALLBACK/END_CALLBACK" in jdk /src /share / back /eventHandler.c, Threads which does JVMTI Callbacks increment "active_callbacks" when entering and decrement "active_callbacks" when returning and also, when entering wait indefinitely if there is active VM_Death callback and when returning, notify all threads waiting on "callbackLock" if "active_callbacks" is zero. "VM exiting" thread is waiting on "callbackLock" indefinitely. We need to understand why is "active_callbacks" non-zero. And that is the *first *issue. Can you put backtraces for all the threads. And also, I think, indefinite waiting on "callbackLock" instead of "timed wait" is a bad idea since if "spuriously failing to notify" situation happens then thread wouldn't unblock. B) *Second* issue is the one you mentioned. If you look in JVM_Halt, we call vm_exit() after before_exit() call. vm_exit() call creates VM_Exit VM operation and pushes to vm queue to be executed. If VMThread deadlocks for the reason you mentioned, it can't progress to execute VM_Exit operation. Note that VM_Exit operation is expected to call eventual exit(). Stopping the GC threads when there is active VM GC operation seems to be bad idea. Instead, I think, we should move "Universe::heap()->stop()" to Vm_Exit:doit() can possibly solve these situations. Let me know if i missed anything. Thanks, Leela On Thu, Sep 13, 2018 at 7:58 AM David Holmes wrote: > Actually this seems to have some similarities with 4953323 > > And if cbVMDeath is anything like what is depicted here: > > http://www.oracle.com/technetwork/articles/javase/index-140680.html > > then deadlock seems quite likely. > > I'll try to look into this deeper tomorrow. > > Cheers, > David > > On 13/09/2018 7:51 PM, David Holmes wrote: > > Hi Kris, > > > > I didn't quite follow the analysis (see below) > > > > On 13/09/2018 6:57 PM, Krystal Mok wrote: > >> Hi HotSpot devs, > >> > >> I'd like to report a VM deadlock situation we've experienced in > >> production > >> a few weeks ago on JDK8. I checked the latest jdk/jdk code and the same > >> race condition is still there. > >> > >> I can file a JBS ticket if this looks like a valid problem. > >> > >> tl;dr: there's a race condition between the VM shutdown and G1, in > >> that the > >> VM shutdown sequence may have just terminated all the concurrent GC > >> threads, and at the same time G1 has just started an incremental > >> collection > >> cycle and is waiting for the concurrent marker to finish. Since > >> there's no > >> concurrent GC thread alive to update the status anymore, G1 waits > >> indefinitely while holding a safepoint, causing the VM to deadlock. > >> > >> Details: > >> > >> 3 threads are involved in the actual deadlock. Detailed stack traces > >> are at > >> the end of this email. > >> > >> 1. A Java application thread at an allocation site triggering a G1 > >> incremental collection > >> 2. A thread that called System.exit(), initiating the VM shutdown > >> sequence. > >> It's in VM's native code so it doesn't block a safepoint. > > > > VM code is not "native" in the sense of being safepoint-safe. If it's > > still in the System.c code trying to call the VM then it is native but > > as soon as it tries to enter the VM it will block if a safepoint is in > > progress. In addition the exit requires that the VM go to a safepoint > > before terminating. > > > >> 3. VM thread, already inside of a safepoint and started running G1's > >> incremental collection. > >> (4. "the world" is at a safepoint so all other Java threads are just > >> waiting) > >> > >> The problem is, Thread 2 has already run half way into before_exit(), > and > > > > The problem seems to be an event callback, cbVMDeath, which seems to > > have take the thread from _thread_in_vm (which is not a safepoint-safe > > state) to presumably _thread_in_native, which is safepoint-safe. The > > callback then blocks on a RawMonitorWait for something and that would > > seem to be where the problem arises. What is the callback trying to do? > > > > Cheers, > > David > > ----- > > > > > >> one of the steps in there is: > >> > >> hotspot/src/share/vm/runtime/java.cpp > >> > >> 503 // Stop concurrent GC threads > >> 504 Universe::heap()->stop(); > >> > >> But G1 is waiting for the concurrent marker to finish scanning the root > >> regions: > >> > >> hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp > >> > >> 506 bool CMRootRegions::wait_until_scan_finished() { > >> 507 if (!scan_in_progress()) return false; > >> 508 > >> 509 { > >> 510 MutexLockerEx x(RootRegionScan_lock, > >> Mutex::_no_safepoint_check_flag); > >> 511 while (scan_in_progress()) { > >> 512 RootRegionScan_lock->wait(Mutex::_no_safepoint_check_flag); > >> 513 } > >> 514 } > >> 515 return true; > >> 516 } > >> > >> But scan_in_process is only updated in a few places: > >> > >> hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp > >> > >> 449 void CMRootRegions::prepare_for_scan() { > >> 450 assert(!scan_in_progress(), "pre-condition"); > >> 451 > >> 452 // Currently, only survivors can be root regions. > >> 453 assert(_next_survivor == NULL, "pre-condition"); > >> 454 _next_survivor = _young_list->first_survivor_region(); > >> 455 _scan_in_progress = (_next_survivor != NULL); > >> 456 _should_abort = false; > >> 457 } > >> > >> 490 void CMRootRegions::scan_finished() { > >> 491 assert(scan_in_progress(), "pre-condition"); > >> 492 > >> 493 // Currently, only survivors can be root regions. > >> 494 if (!_should_abort) { > >> 495 assert(_next_survivor == NULL, "we should have claimed all > >> survivors"); > >> 496 } > >> 497 _next_survivor = NULL; > >> 498 > >> 499 { > >> 500 MutexLockerEx x(RootRegionScan_lock, > >> Mutex::_no_safepoint_check_flag); > >> 501 _scan_in_progress = false; > >> 502 RootRegionScan_lock->notify_all(); > >> 503 } > >> 504 } > >> > >> And with the current GC threads gone, nobody ever gets to set > >> scan_in_process back to false, which leads to an infinite wait. > >> > >> One way I'd imagine fixing this is by adding a check in G1's > >> CMRootRegions::wait_until_scan_finished() to see if the concurrent > marker > >> thread is still there, and if it isn't, there's no point in waiting > >> anymore. > >> Obviously similar fixes would have to be done separately for other > >> concurrent GCs in HotSpot. > >> > >> What do you think? > >> > >> Thanks, > >> Kris > >> > >> Detail thread stacks for in the example: > >> > >> 1. A Java application thread at an allocation site triggering a G1 > >> incremental collection: > >> > >> Thread 2164 (Thread 0x7fcfc4e11700 (LWP 25218)): > >> #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > >> #1 0x00007fd2931e9a1b in os::PlatformEvent::park() > >> (this=this at entry=0x7fd05c029c00) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > > >> > >> #2 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, > >> ev=0x7fd05c029c00) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 > > >> > >> #3 0x00007fd2931a256f in Monitor::IWait(Thread*, long) > >> (this=this at entry=0x7fd28c012800, > >> Self=Self at entry=0x7fd1ac0f2000, timo=timo at entry=0) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 > > >> > >> #4 0x00007fd2931a382e in Monitor::wait(bool, long, bool) > >> (this=0x7fd28c012800, no_safepoint_check=, > >> timeout=timeout at entry=0, > >> as_suspend_equivalent=as_suspend_equivalent at entry=false) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1126 > > >> > >> #5 0x00007fd29339d5fc in VMThread::execute(VM_Operation*) > >> (op=op at entry=0x7fcfc4e0c430) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:642 > > >> > >> #6 0x00007fd292e99fec in > >> G1CollectedHeap::attempt_allocation_slow(unsigned > >> long, unsigned char, unsigned int*, unsigned int*) > >> (gc_cause=GCCause::_g1_inc_collection_pause, succeeded= >> pointer>, > >> gc_count_before=, word_size=1026, this=0x7fd28c033c40) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:3628 > > >> > >> #7 0x00007fd292e99fec in > >> G1CollectedHeap::attempt_allocation_slow(unsigned > >> long, unsigned char, unsigned int*, unsigned int*) > >> (this=this at entry=0x7fd28c033c40, > >> word_size=word_size at entry=1026, context=context at entry=0 '\000', > >> gc_count_before_ret=gc_count_before_ret at entry=0x7fcfc4e0c50c, > >> gclocker_retry_count_ret=gclocker_retry_count_ret at entry=0x7fcfc4e0c508) > at > >> > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:956 > > >> > >> #8 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned long, > >> bool*) (gclocker_retry_count_ret=0x7fcfc4e0c508, > >> gc_count_before_ret=0x7fcfc4e0c50c, word_size=1026, > >> this=0x7fd28c033c40) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp:147 > > >> > >> #9 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned long, > >> bool*) (this=0x7fd28c033c40, word_size=1026, > >> gc_overhead_limit_was_exceeded=) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:846 > > >> > >> #10 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > >> Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:135 > > >> > >> #11 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > >> Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:175 > > >> > >> #12 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > >> Thread*) (__the_thread__=0x7fd1ac0f2000, length=8192, size=1026, > >> klass=...) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:216 > > >> > >> #13 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > >> Thread*) (this=0x7c0000768, length=length at entry=8192, > >> do_zero=do_zero at entry=true, > >> __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/oops/typeArrayKlass.cpp:107 > > >> > >> #14 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, > >> Thread*) (__the_thread__=__the_thread__ at entry=0x7fd1ac0f2000, > >> length=length at entry=8192, this=) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/oops/typeArrayKlass.hpp:67 > > >> > >> #15 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, > >> Thread*) (type=, length=length at entry=8192, > >> __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/memory/oopFactory.cpp:56 > > >> > >> #16 0x00007fd293283457 in OptoRuntime::new_array_C(Klass*, int, > >> JavaThread*) (array_type=, len=8192, > >> thread=0x7fd1ac0f2000) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/opto/runtime.cpp:279 > > >> > >> #17 0x00007fd27d0871c7 in () > >> > >> 2. A thread that called System.exit(), initiating the VM shutdown > >> sequence. > >> It's in native code so it doesn't block a safepoint: > >> > >> Thread 563 (Thread 0x7fd017980700 (LWP 7959)): > >> #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > >> #1 0x00007fd2931e9a1b in os::PlatformEvent::park() > (this=0x7fd0f4015000) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > > >> > >> #2 0x00007fd293064485 in JvmtiRawMonitor::SimpleWait(Thread*, long) > >> (this=this at entry=0x7fd28f22f020, Self=Self at entry=0x7fd28f0c9800, > >> millis=millis at entry=-1) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:194 > > >> > >> #3 0x00007fd293064c75 in JvmtiRawMonitor::raw_wait(long, bool, Thread*) > >> (this=this at entry=0x7fd28f22f020, millis=millis at entry=-1, > >> interruptible=interruptible at entry=true, > >> __the_thread__=__the_thread__ at entry=0x7fd28f0c9800) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:383 > > >> > >> #4 0x00007fd293040c09 in JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*, > >> long) > >> (this=, rmonitor=0x7fd28f22f020, millis=-1) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiEnv.cpp:3144 > > >> > >> #5 0x00007fd291620af8 in debugMonitorWait (monitor=) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/util.c:1075 > > >> > >> #6 0x00007fd29160e86c in cbVMDeath (jvmti_env=, > >> env=0x7fd28f0c99e0) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:1273 > > >> > >> #7 0x00007fd29304f4b0 in JvmtiExport::post_vm_death() () at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiExport.cpp:490 > > >> > >> #8 0x00007fd292f896dd in before_exit(JavaThread*) (thread= >> out>) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/java.cpp:532 > > >> > >> #9 0x00007fd292fd005b in JVM_Halt(jint) (code=1) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvm.cpp:441 > > >> > >> #10 0x00007fd27d020868 in [native] java.lang.Shutdown.halt0(int) () at > >> java/lang/Shutdown.java:0 > >> #11 0x00007fd27d00809d in [interpreted: bc = 7] > >> java.lang.Shutdown.halt(int) () at java/lang/Shutdown.java:140 > >> #12 0x00007fd27d00809d in [interpreted: bc = 99] > >> java.lang.Shutdown.exit(int) () at java/lang/Shutdown.java:214 > >> #13 0x00007fd27d00809d in [interpreted: bc = 14] > >> java.lang.Runtime.exit(int) () at java/lang/Runtime.java:110 > >> #14 0x00007fd27d00809d in [interpreted: bc = 4] > >> java.lang.System.exit(int) > >> () at java/lang/System.java:972 > >> #15 0x00007fd27d00809d in [interpreted: bc = 1] > >> scala.sys.package$.exit(int) () at scala/sys/package.java:41 > >> > >> 3. VM thread, already inside of a safepoint and started running G1's > >> incremental collection: > >> > >> Thread 19 (Thread 0x7fd1d70ab700 (LWP 47)): > >> #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > >> #1 0x00007fd2931e9a1b in os::PlatformEvent::park() > >> (this=this at entry=0x7fd28c498200) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > > >> > >> #2 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, > >> ev=0x7fd28c498200) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 > > >> > >> #3 0x00007fd2931a256f in Monitor::IWait(Thread*, long) > >> (this=this at entry=0x7fd28c011700, > >> Self=Self at entry=0x7fd28c497800, timo=timo at entry=0) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 > > >> > >> #4 0x00007fd2931a37fa in Monitor::wait(bool, long, bool) > >> (this=0x7fd28c011700, no_safepoint_check=no_safepoint_check at entry=true, > >> timeout=timeout at entry=0, > >> as_suspend_equivalent=as_suspend_equivalent at entry=false) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1111 > > >> > >> #5 0x00007fd292db1fe2 in CMRootRegions::wait_until_scan_finished() > >> (this=0x7fd28c0826b8) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:512 > > >> > >> #6 0x00007fd292ea59a4 in > >> G1CollectedHeap::do_collection_pause_at_safepoint(double) > >> (this=this at entry=0x7fd28c033c40, > >> target_pause_time_ms=200) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:4095 > > >> > >> #7 0x00007fd29339f002 in VM_G1IncCollectionPause::doit() > >> (this=0x7fcfc4e0c430) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/vm_operations_g1.cpp:148 > > >> > >> #8 0x00007fd29339dfd7 in VM_Operation::evaluate() > >> (this=this at entry=0x7fcfc4e0c430) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vm_operations.cpp:62 > > >> > >> #9 0x00007fd29339b6d7 in VMThread::evaluate_operation(VM_Operation*) > >> (op=0x7fcfc4e0c430, this=) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:377 > > >> > >> #10 0x00007fd29339cb5f in VMThread::loop() > >> (this=this at entry=0x7fd28c497800) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:502 > > >> > >> #11 0x00007fd29339d051 in VMThread::run() (this=0x7fd28c497800) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:276 > > >> > >> #12 0x00007fd2931e1222 in java_start(Thread*) (thread=0x7fd28c497800) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:790 > > >> > >> > From rednaxelafx at gmail.com Thu Sep 13 21:09:31 2018 From: rednaxelafx at gmail.com (Krystal Mok) Date: Thu, 13 Sep 2018 14:09:31 -0700 Subject: VM deadlock between VM shutdown and G1 In-Reply-To: References: <86d405c7-f27e-6869-62a6-0ef5d8a60d0d@oracle.com> Message-ID: Hi Leela, Thanks for your question! I do have more visibility into the full stack trace but unfortunately because it contains our production code traces I can't share the whole thing. I wanted to just highlight the part of stack traces that show the deadlock, so I only posted out the stacks for 3 threads. I can answer your question though: > We need to understand why is "active_callbacks" non-zero. And that is the first issue. Can you put backtraces for all the threads. I know the reason and it's not a part of the deadlock situation here. Rather, it's the consequence and not the cause. Here's another thread in a JVMTI callback that's blocked by safepoint. There's a really narrow time window that this combination could happen between these threads, but it did happen in our production environment: Thread 2824 (Thread 0x7fcf9531b700 (LWP 73531)): #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007fd2931e9a1b in os::PlatformEvent::park() (this=this at entry=0x7fd0d806ce00) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 #2 0x00007fd2931a1eec in Monitor::ILock(Thread*) (timo=0, ev=0x7fd0d806ce00) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 #3 0x00007fd2931a1eec in Monitor::ILock(Thread*) (this=this at entry=0x7fd28c012700, Self=Self at entry=0x7fd1242c5000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:491 #4 0x00007fd2931a322b in Monitor::lock_without_safepoint_check() (Self=0x7fd1242c5000, this=0x7fd28c012700) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/os.hpp:225 #5 0x00007fd2931a322b in Monitor::lock_without_safepoint_check() (Self=, this=0x7fd28c012700) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:959 #6 0x00007fd2931a322b in Monitor::lock_without_safepoint_check() (this=0x7fd28c012700) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:965 #7 0x00007fd293286dbd in SafepointSynchronize::block(JavaThread*) (thread=0x7fd1242c5000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/safepoint.cpp:703 #8 0x00007fd292f9bf43 in ThreadStateTransition::transition_and_fence(JavaThread*, JavaThreadState, JavaThreadState) (thread=thread at entry=0x7fd1242c5000, to=_thread_in_native, from=_thread_in_vm) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/interfaceSupport.hpp:184 #9 0x00007fd292f9c9aa in jni_IsSameObject(JNIEnv*, jobject, jobject) (to=_thread_in_native, from=_thread_in_vm, this=) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/interfaceSupport.hpp:232 #10 0x00007fd292f9c9aa in jni_IsSameObject(JNIEnv*, jobject, jobject) (this=, __in_chrg=) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/interfaceSupport.hpp:281 #11 0x00007fd292f9c9aa in jni_IsSameObject(JNIEnv*, jobject, jobject) (env=0x7fd1242c51e0, r1=0x7fd1b806b940, r2=) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jni.cpp:987 #12 0x00007fd2916060ab in classTrack_processUnloads (newTable=0x7fd1b80709b0, klass=0x7fd1b806b940, env=0x7fd1242c51e0) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/classTrack.c:87 #13 0x00007fd2916060ab in classTrack_processUnloads (env=env at entry=0x7fd1242c51e0) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/classTrack.c:190 #14 0x00007fd29160e58b in event_callback (env=env at entry=0x7fd1242c51e0, evinfo=evinfo at entry=0x7fcf9531ace0) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:586 #15 0x00007fd29160f835 in cbThreadStart (jvmti_env=, env=0x7fd1242c51e0, thread=0x7fd1ac1adf40) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:857 #16 0x00007fd29305146d in JvmtiExport::post_thread_start(JavaThread*) (thread=thread at entry=0x7fd1242c5000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiExport.cpp:1042 #17 0x00007fd29333bd18 in JavaThread::run() (this=0x7fd1242c5000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/thread.cpp:1668 #18 0x00007fd2931e1222 in java_start(Thread*) (thread=0x7fd1242c5000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:790 This thread is holding on to the "handlerLock", and a lot of other Java threads that are calling into JVMTI callbacks are waiting to get the handlerLock, e.g. Thread 2517 (Thread 0x7fcf9652d700 (LWP 57785)): #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007fd2931e9a1b in os::PlatformEvent::park() (this=0x7fd0c4060b00) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 #2 0x00007fd2930640bc in JvmtiRawMonitor::SimpleEnter(Thread*) (this=this at entry=0x7fd28f22f1c0, Self=Self at entry=0x7fd124294000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:148 #3 0x00007fd2930647b2 in JvmtiRawMonitor::raw_enter(Thread*) (this=this at entry=0x7fd28f22f1c0, __the_thread__=__the_thread__ at entry=0x7fd124294000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:309 #4 0x00007fd29304086d in JvmtiEnv::RawMonitorEnter(JvmtiRawMonitor*) (this=, rmonitor=0x7fd28f22f1c0) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiEnv.cpp:3048 #5 0x00007fd29162096d in debugMonitorEnter (monitor=0x7fd28f22f1c0) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/util.c:1044 #6 0x00007fd29160e376 in event_callback (env=env at entry=0x7fd1242941e0, evinfo=evinfo at entry=0x7fcf9652cae0) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:638 #7 0x00007fd29160f635 in cbThreadEnd (jvmti_env=, env=0x7fd1242941e0, thread=0x7fd17c01e4e0) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:875 #8 0x00007fd2930518a4 in JvmtiExport::post_thread_end(JavaThread*) (thread=thread at entry=0x7fd124294000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiExport.cpp:1074 #9 0x00007fd29333b128 in JavaThread::exit(bool, JavaThread::ExitType) (this=this at entry=0x7fd124294000, destroy_vm=destroy_vm at entry=false, exit_type=exit_type at entry=JavaThread::normal_exit) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/thread.cpp:1833 #10 0x00007fd29333b704 in JavaThread::thread_main_inner() (this=this at entry=0x7fd124294000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/thread.cpp:1704 #11 0x00007fd29333bcbc in JavaThread::run() (this=0x7fd124294000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/thread.cpp:1679 #12 0x00007fd2931e1222 in java_start(Thread*) (thread=0x7fd124294000) at /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:790 #13 0x00007fd2938756ba in start_thread (arg=0x7fcf9652d700) at pthread_create.c:333 #14 0x00007fd293fb041d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thanks, Kris On Thu, Sep 13, 2018 at 1:54 PM, Leela Mohan wrote: > Hi Kris, > > If i understand this deadlock correctly, There are two issues here. > > A) Inside "cbVMDeath" , "VM exiting" thread is waiting to be notified by > active JVMTI callbacks to be completed. If we see > "BEGIN_CALLBACK/END_CALLBACK" in jdk > /src > /share > > /back > > /eventHandler.c, Threads which does JVMTI Callbacks increment > "active_callbacks" when entering and decrement "active_callbacks" when > returning and also, when entering wait indefinitely if there is active > VM_Death callback and when returning, notify all threads waiting on > "callbackLock" if "active_callbacks" is zero. "VM exiting" thread is > waiting on "callbackLock" indefinitely. We need to understand why is > "active_callbacks" non-zero. And that is the *first *issue. Can you put > backtraces for all the threads. And also, I think, indefinite waiting on > "callbackLock" instead of "timed wait" is a bad idea since if "spuriously > failing to notify" situation happens then thread wouldn't unblock. > > B) *Second* issue is the one you mentioned. If you look in JVM_Halt, we > call vm_exit() after before_exit() call. vm_exit() call creates VM_Exit VM > operation and pushes to vm queue to be executed. If VMThread deadlocks for > the reason you mentioned, it can't progress to execute VM_Exit operation. > Note that VM_Exit operation is expected to call eventual exit(). Stopping > the GC threads when there is active VM GC operation seems to be bad idea. > Instead, I think, we should move "Universe::heap()->stop()" to > Vm_Exit:doit() can possibly solve these situations. > > Let me know if i missed anything. > > Thanks, > Leela > > On Thu, Sep 13, 2018 at 7:58 AM David Holmes > wrote: > >> Actually this seems to have some similarities with 4953323 >> >> And if cbVMDeath is anything like what is depicted here: >> >> http://www.oracle.com/technetwork/articles/javase/index-140680.html >> >> then deadlock seems quite likely. >> >> I'll try to look into this deeper tomorrow. >> >> Cheers, >> David >> >> On 13/09/2018 7:51 PM, David Holmes wrote: >> > Hi Kris, >> > >> > I didn't quite follow the analysis (see below) >> > >> > On 13/09/2018 6:57 PM, Krystal Mok wrote: >> >> Hi HotSpot devs, >> >> >> >> I'd like to report a VM deadlock situation we've experienced in >> >> production >> >> a few weeks ago on JDK8. I checked the latest jdk/jdk code and the same >> >> race condition is still there. >> >> >> >> I can file a JBS ticket if this looks like a valid problem. >> >> >> >> tl;dr: there's a race condition between the VM shutdown and G1, in >> >> that the >> >> VM shutdown sequence may have just terminated all the concurrent GC >> >> threads, and at the same time G1 has just started an incremental >> >> collection >> >> cycle and is waiting for the concurrent marker to finish. Since >> >> there's no >> >> concurrent GC thread alive to update the status anymore, G1 waits >> >> indefinitely while holding a safepoint, causing the VM to deadlock. >> >> >> >> Details: >> >> >> >> 3 threads are involved in the actual deadlock. Detailed stack traces >> >> are at >> >> the end of this email. >> >> >> >> 1. A Java application thread at an allocation site triggering a G1 >> >> incremental collection >> >> 2. A thread that called System.exit(), initiating the VM shutdown >> >> sequence. >> >> It's in VM's native code so it doesn't block a safepoint. >> > >> > VM code is not "native" in the sense of being safepoint-safe. If it's >> > still in the System.c code trying to call the VM then it is native but >> > as soon as it tries to enter the VM it will block if a safepoint is in >> > progress. In addition the exit requires that the VM go to a safepoint >> > before terminating. >> > >> >> 3. VM thread, already inside of a safepoint and started running G1's >> >> incremental collection. >> >> (4. "the world" is at a safepoint so all other Java threads are just >> >> waiting) >> >> >> >> The problem is, Thread 2 has already run half way into before_exit(), >> and >> > >> > The problem seems to be an event callback, cbVMDeath, which seems to >> > have take the thread from _thread_in_vm (which is not a safepoint-safe >> > state) to presumably _thread_in_native, which is safepoint-safe. The >> > callback then blocks on a RawMonitorWait for something and that would >> > seem to be where the problem arises. What is the callback trying to do? >> > >> > Cheers, >> > David >> > ----- >> > >> > >> >> one of the steps in there is: >> >> >> >> hotspot/src/share/vm/runtime/java.cpp >> >> >> >> 503 // Stop concurrent GC threads >> >> 504 Universe::heap()->stop(); >> >> >> >> But G1 is waiting for the concurrent marker to finish scanning the root >> >> regions: >> >> >> >> hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp >> >> >> >> 506 bool CMRootRegions::wait_until_scan_finished() { >> >> 507 if (!scan_in_progress()) return false; >> >> 508 >> >> 509 { >> >> 510 MutexLockerEx x(RootRegionScan_lock, >> >> Mutex::_no_safepoint_check_flag); >> >> 511 while (scan_in_progress()) { >> >> 512 RootRegionScan_lock->wait(Mutex::_no_safepoint_check_ >> flag); >> >> 513 } >> >> 514 } >> >> 515 return true; >> >> 516 } >> >> >> >> But scan_in_process is only updated in a few places: >> >> >> >> hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp >> >> >> >> 449 void CMRootRegions::prepare_for_scan() { >> >> 450 assert(!scan_in_progress(), "pre-condition"); >> >> 451 >> >> 452 // Currently, only survivors can be root regions. >> >> 453 assert(_next_survivor == NULL, "pre-condition"); >> >> 454 _next_survivor = _young_list->first_survivor_region(); >> >> 455 _scan_in_progress = (_next_survivor != NULL); >> >> 456 _should_abort = false; >> >> 457 } >> >> >> >> 490 void CMRootRegions::scan_finished() { >> >> 491 assert(scan_in_progress(), "pre-condition"); >> >> 492 >> >> 493 // Currently, only survivors can be root regions. >> >> 494 if (!_should_abort) { >> >> 495 assert(_next_survivor == NULL, "we should have claimed all >> >> survivors"); >> >> 496 } >> >> 497 _next_survivor = NULL; >> >> 498 >> >> 499 { >> >> 500 MutexLockerEx x(RootRegionScan_lock, >> >> Mutex::_no_safepoint_check_flag); >> >> 501 _scan_in_progress = false; >> >> 502 RootRegionScan_lock->notify_all(); >> >> 503 } >> >> 504 } >> >> >> >> And with the current GC threads gone, nobody ever gets to set >> >> scan_in_process back to false, which leads to an infinite wait. >> >> >> >> One way I'd imagine fixing this is by adding a check in G1's >> >> CMRootRegions::wait_until_scan_finished() to see if the concurrent >> marker >> >> thread is still there, and if it isn't, there's no point in waiting >> >> anymore. >> >> Obviously similar fixes would have to be done separately for other >> >> concurrent GCs in HotSpot. >> >> >> >> What do you think? >> >> >> >> Thanks, >> >> Kris >> >> >> >> Detail thread stacks for in the example: >> >> >> >> 1. A Java application thread at an allocation site triggering a G1 >> >> incremental collection: >> >> >> >> Thread 2164 (Thread 0x7fcfc4e11700 (LWP 25218)): >> >> #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at >> >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> >> #1 0x00007fd2931e9a1b in os::PlatformEvent::park() >> >> (this=this at entry=0x7fd05c029c00) >> >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/os/linux/vm/os_linux.cpp:5842 >> >> >> >> #2 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, >> >> ev=0x7fd05c029c00) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/runtime/mutex.cpp:424 >> >> >> >> #3 0x00007fd2931a256f in Monitor::IWait(Thread*, long) >> >> (this=this at entry=0x7fd28c012800, >> >> Self=Self at entry=0x7fd1ac0f2000, timo=timo at entry=0) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/runtime/mutex.cpp:802 >> >> >> >> #4 0x00007fd2931a382e in Monitor::wait(bool, long, bool) >> >> (this=0x7fd28c012800, no_safepoint_check=, >> >> timeout=timeout at entry=0, >> >> as_suspend_equivalent=as_suspend_equivalent at entry=false) >> >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/runtime/mutex.cpp:1126 >> >> >> >> #5 0x00007fd29339d5fc in VMThread::execute(VM_Operation*) >> >> (op=op at entry=0x7fcfc4e0c430) >> >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/runtime/vmThread.cpp:642 >> >> >> >> #6 0x00007fd292e99fec in >> >> G1CollectedHeap::attempt_allocation_slow(unsigned >> >> long, unsigned char, unsigned int*, unsigned int*) >> >> (gc_cause=GCCause::_g1_inc_collection_pause, succeeded=> >> pointer>, >> >> gc_count_before=, word_size=1026, this=0x7fd28c033c40) >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:3628 >> >> >> >> #7 0x00007fd292e99fec in >> >> G1CollectedHeap::attempt_allocation_slow(unsigned >> >> long, unsigned char, unsigned int*, unsigned int*) >> >> (this=this at entry=0x7fd28c033c40, >> >> word_size=word_size at entry=1026, context=context at entry=0 '\000', >> >> gc_count_before_ret=gc_count_before_ret at entry=0x7fcfc4e0c50c, >> >> gclocker_retry_count_ret=gclocker_retry_count_ret at entry=0x7fcfc4e0c508) >> at >> >> >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:956 >> >> >> >> #8 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned long, >> >> bool*) (gclocker_retry_count_ret=0x7fcfc4e0c508, >> >> gc_count_before_ret=0x7fcfc4e0c50c, word_size=1026, >> >> this=0x7fd28c033c40) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp:147 >> >> >> >> #9 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned long, >> >> bool*) (this=0x7fd28c033c40, word_size=1026, >> >> gc_overhead_limit_was_exceeded=) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:846 >> >> >> >> #10 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, >> >> Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:135 >> >> >> >> #11 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, >> >> Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:175 >> >> >> >> #12 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, >> >> Thread*) (__the_thread__=0x7fd1ac0f2000, length=8192, size=1026, >> >> klass=...) >> >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:216 >> >> >> >> #13 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, >> >> Thread*) (this=0x7c0000768, length=length at entry=8192, >> >> do_zero=do_zero at entry=true, >> >> __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/oops/typeArrayKlass.cpp:107 >> >> >> >> #14 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, >> >> Thread*) (__the_thread__=__the_thread__ at entry=0x7fd1ac0f2000, >> >> length=length at entry=8192, this=) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/oops/typeArrayKlass.hpp:67 >> >> >> >> #15 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, >> >> Thread*) (type=, length=length at entry=8192, >> >> __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/memory/oopFactory.cpp:56 >> >> >> >> #16 0x00007fd293283457 in OptoRuntime::new_array_C(Klass*, int, >> >> JavaThread*) (array_type=, len=8192, >> >> thread=0x7fd1ac0f2000) >> >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/opto/runtime.cpp:279 >> >> >> >> #17 0x00007fd27d0871c7 in () >> >> >> >> 2. A thread that called System.exit(), initiating the VM shutdown >> >> sequence. >> >> It's in native code so it doesn't block a safepoint: >> >> >> >> Thread 563 (Thread 0x7fd017980700 (LWP 7959)): >> >> #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at >> >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> >> #1 0x00007fd2931e9a1b in os::PlatformEvent::park() >> (this=0x7fd0f4015000) >> >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/os/linux/vm/os_linux.cpp:5842 >> >> >> >> #2 0x00007fd293064485 in JvmtiRawMonitor::SimpleWait(Thread*, long) >> >> (this=this at entry=0x7fd28f22f020, Self=Self at entry=0x7fd28f0c9800, >> >> millis=millis at entry=-1) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:194 >> >> >> >> #3 0x00007fd293064c75 in JvmtiRawMonitor::raw_wait(long, bool, >> Thread*) >> >> (this=this at entry=0x7fd28f22f020, millis=millis at entry=-1, >> >> interruptible=interruptible at entry=true, >> >> __the_thread__=__the_thread__ at entry=0x7fd28f0c9800) >> >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:383 >> >> >> >> #4 0x00007fd293040c09 in JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*, >> >> long) >> >> (this=, rmonitor=0x7fd28f22f020, millis=-1) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/prims/jvmtiEnv.cpp:3144 >> >> >> >> #5 0x00007fd291620af8 in debugMonitorWait (monitor=) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/util.c:1075 >> >> >> >> >> #6 0x00007fd29160e86c in cbVMDeath (jvmti_env=, >> >> env=0x7fd28f0c99e0) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/ >> src/share/back/eventHandler.c:1273 >> >> >> >> #7 0x00007fd29304f4b0 in JvmtiExport::post_vm_death() () at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/prims/jvmtiExport.cpp:490 >> >> >> >> #8 0x00007fd292f896dd in before_exit(JavaThread*) (thread=> >> out>) >> >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/runtime/java.cpp:532 >> >> >> >> #9 0x00007fd292fd005b in JVM_Halt(jint) (code=1) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/prims/jvm.cpp:441 >> >> >> >> #10 0x00007fd27d020868 in [native] java.lang.Shutdown.halt0(int) () at >> >> java/lang/Shutdown.java:0 >> >> #11 0x00007fd27d00809d in [interpreted: bc = 7] >> >> java.lang.Shutdown.halt(int) () at java/lang/Shutdown.java:140 >> >> #12 0x00007fd27d00809d in [interpreted: bc = 99] >> >> java.lang.Shutdown.exit(int) () at java/lang/Shutdown.java:214 >> >> #13 0x00007fd27d00809d in [interpreted: bc = 14] >> >> java.lang.Runtime.exit(int) () at java/lang/Runtime.java:110 >> >> #14 0x00007fd27d00809d in [interpreted: bc = 4] >> >> java.lang.System.exit(int) >> >> () at java/lang/System.java:972 >> >> #15 0x00007fd27d00809d in [interpreted: bc = 1] >> >> scala.sys.package$.exit(int) () at scala/sys/package.java:41 >> >> >> >> 3. VM thread, already inside of a safepoint and started running G1's >> >> incremental collection: >> >> >> >> Thread 19 (Thread 0x7fd1d70ab700 (LWP 47)): >> >> #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at >> >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >> >> #1 0x00007fd2931e9a1b in os::PlatformEvent::park() >> >> (this=this at entry=0x7fd28c498200) >> >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/os/linux/vm/os_linux.cpp:5842 >> >> >> >> #2 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, >> >> ev=0x7fd28c498200) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/runtime/mutex.cpp:424 >> >> >> >> #3 0x00007fd2931a256f in Monitor::IWait(Thread*, long) >> >> (this=this at entry=0x7fd28c011700, >> >> Self=Self at entry=0x7fd28c497800, timo=timo at entry=0) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/runtime/mutex.cpp:802 >> >> >> >> #4 0x00007fd2931a37fa in Monitor::wait(bool, long, bool) >> >> (this=0x7fd28c011700, no_safepoint_check=no_safepoint_check at entry >> =true, >> >> timeout=timeout at entry=0, >> >> as_suspend_equivalent=as_suspend_equivalent at entry=false) >> >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/runtime/mutex.cpp:1111 >> >> >> >> #5 0x00007fd292db1fe2 in CMRootRegions::wait_until_scan_finished() >> >> (this=0x7fd28c0826b8) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:512 >> >> >> >> #6 0x00007fd292ea59a4 in >> >> G1CollectedHeap::do_collection_pause_at_safepoint(double) >> >> (this=this at entry=0x7fd28c033c40, >> >> target_pause_time_ms=200) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:4095 >> >> >> >> #7 0x00007fd29339f002 in VM_G1IncCollectionPause::doit() >> >> (this=0x7fcfc4e0c430) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/gc_implementation/g1/vm_operations_g1.cpp:148 >> >> >> >> #8 0x00007fd29339dfd7 in VM_Operation::evaluate() >> >> (this=this at entry=0x7fcfc4e0c430) >> >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/runtime/vm_operations.cpp:62 >> >> >> >> #9 0x00007fd29339b6d7 in VMThread::evaluate_operation(VM_Operation*) >> >> (op=0x7fcfc4e0c430, this=) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/runtime/vmThread.cpp:377 >> >> >> >> #10 0x00007fd29339cb5f in VMThread::loop() >> >> (this=this at entry=0x7fd28c497800) >> >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/runtime/vmThread.cpp:502 >> >> >> >> #11 0x00007fd29339d051 in VMThread::run() (this=0x7fd28c497800) at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/share/vm/runtime/vmThread.cpp:276 >> >> >> >> #12 0x00007fd2931e1222 in java_start(Thread*) (thread=0x7fd28c497800) >> at >> >> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/ >> hotspot/src/os/linux/vm/os_linux.cpp:790 >> >> >> >> >> > From magnus.ihse.bursie at oracle.com Thu Sep 13 21:10:32 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Sep 2018 23:10:32 +0200 Subject: Linux + Clang + execstack In-Reply-To: References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> <3193b432-0068-8e2b-9ad4-f5a6467568a1@oracle.com> <6b05bebc-4b06-1071-7dc3-a338ba91c8b0@oracle.com> <7002cda6-ab66-3ff9-083b-cfc024e0c927@oracle.com> Message-ID: > We're not entirely happy either. > > A much higher interface might look like > > TRY_ADD_LINKER_FLAGS -z noexecstack Agreed. I'm working towards a solution like that. > which would add -Wl,-z,noexecstack to LDFLAGS when appropriate > .... hmmm ... > I only just noticed that both gcc and clang accept simply > $CC -z noexecstack > (it's even documented!) > Should we switch to that instead? No, I think it's better to keep -Wl,-z for consistency for all linker flags. Otherwise it just looks confusing. /Magnus > > >> Do you have a JBS issue? > I have > https://bugs.openjdk.java.net/browse/JDK-8205457 gcc and clang should > use the same ld flags > but the proposed patch only addresses part of that. I could create a > sub-task (but I've never done that before) or a new bug or change the > description of this bug. What do you think? From leelamohan.venati at gmail.com Thu Sep 13 22:23:40 2018 From: leelamohan.venati at gmail.com (Leela Mohan) Date: Thu, 13 Sep 2018 15:23:40 -0700 Subject: VM deadlock between VM shutdown and G1 In-Reply-To: References: <86d405c7-f27e-6869-62a6-0ef5d8a60d0d@oracle.com> Message-ID: Hi Kris, Thanks for clarifying. That explains the first question. Coming to your original deadlock situation, Moving "Universe::heap()->stop()" to VM_Exit::do_it() should solve this issue . Essentially, we should move any "stopping threads" logic to VM_Exit if those threads are required for any VM operation to complete. And also, we need to call "Universe::heap()->stop()" in Threads::destroy_vm() after VMThread::wait_for_vm_thread_exit() call (we can also do "Universe::heap()->stop()" in the end of VMThread::run()) Thanks, Leela On Thu, Sep 13, 2018 at 2:09 PM Krystal Mok wrote: > Hi Leela, > > Thanks for your question! I do have more visibility into the full stack > trace but unfortunately because it contains our production code traces I > can't share the whole thing. I wanted to just highlight the part of stack > traces that show the deadlock, so I only posted out the stacks for 3 > threads. > > I can answer your question though: > > > We need to understand why is "active_callbacks" non-zero. And that is > the first issue. Can you put backtraces for all the threads. > > I know the reason and it's not a part of the deadlock situation here. > Rather, it's the consequence and not the cause. > > Here's another thread in a JVMTI callback that's blocked by safepoint. > There's a really narrow time window that this combination could happen > between these threads, but it did happen in our production environment: > > Thread 2824 (Thread 0x7fcf9531b700 (LWP 73531)): > #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > #1 0x00007fd2931e9a1b in os::PlatformEvent::park() (this=this at entry=0x7fd0d806ce00) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > #2 0x00007fd2931a1eec in Monitor::ILock(Thread*) (timo=0, > ev=0x7fd0d806ce00) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 > #3 0x00007fd2931a1eec in Monitor::ILock(Thread*) (this=this at entry=0x7fd28c012700, > Self=Self at entry=0x7fd1242c5000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:491 > #4 0x00007fd2931a322b in Monitor::lock_without_safepoint_check() > (Self=0x7fd1242c5000, this=0x7fd28c012700) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/os.hpp:225 > #5 0x00007fd2931a322b in Monitor::lock_without_safepoint_check() > (Self=, this=0x7fd28c012700) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:959 > #6 0x00007fd2931a322b in Monitor::lock_without_safepoint_check() > (this=0x7fd28c012700) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:965 > #7 0x00007fd293286dbd in SafepointSynchronize::block(JavaThread*) > (thread=0x7fd1242c5000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/safepoint.cpp:703 > #8 0x00007fd292f9bf43 in > ThreadStateTransition::transition_and_fence(JavaThread*, JavaThreadState, > JavaThreadState) (thread=thread at entry=0x7fd1242c5000, > to=_thread_in_native, from=_thread_in_vm) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/interfaceSupport.hpp:184 > #9 0x00007fd292f9c9aa in jni_IsSameObject(JNIEnv*, jobject, jobject) > (to=_thread_in_native, from=_thread_in_vm, this=) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/interfaceSupport.hpp:232 > #10 0x00007fd292f9c9aa in jni_IsSameObject(JNIEnv*, jobject, jobject) > (this=, __in_chrg=) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/interfaceSupport.hpp:281 > #11 0x00007fd292f9c9aa in jni_IsSameObject(JNIEnv*, jobject, jobject) > (env=0x7fd1242c51e0, r1=0x7fd1b806b940, r2=) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jni.cpp:987 > #12 0x00007fd2916060ab in classTrack_processUnloads > (newTable=0x7fd1b80709b0, klass=0x7fd1b806b940, env=0x7fd1242c51e0) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/classTrack.c:87 > #13 0x00007fd2916060ab in classTrack_processUnloads (env=env at entry=0x7fd1242c51e0) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/classTrack.c:190 > #14 0x00007fd29160e58b in event_callback (env=env at entry=0x7fd1242c51e0, > evinfo=evinfo at entry=0x7fcf9531ace0) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:586 > #15 0x00007fd29160f835 in cbThreadStart (jvmti_env=, > env=0x7fd1242c51e0, thread=0x7fd1ac1adf40) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:857 > #16 0x00007fd29305146d in JvmtiExport::post_thread_start(JavaThread*) > (thread=thread at entry=0x7fd1242c5000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiExport.cpp:1042 > #17 0x00007fd29333bd18 in JavaThread::run() (this=0x7fd1242c5000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/thread.cpp:1668 > #18 0x00007fd2931e1222 in java_start(Thread*) (thread=0x7fd1242c5000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:790 > > This thread is holding on to the "handlerLock", and a lot of other Java > threads that are calling into JVMTI callbacks are waiting to get the > handlerLock, e.g. > > Thread 2517 (Thread 0x7fcf9652d700 (LWP 57785)): > #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > #1 0x00007fd2931e9a1b in os::PlatformEvent::park() (this=0x7fd0c4060b00) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > #2 0x00007fd2930640bc in JvmtiRawMonitor::SimpleEnter(Thread*) > (this=this at entry=0x7fd28f22f1c0, Self=Self at entry=0x7fd124294000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:148 > #3 0x00007fd2930647b2 in JvmtiRawMonitor::raw_enter(Thread*) > (this=this at entry=0x7fd28f22f1c0, __the_thread__=__the_thread__ at entry=0x7fd124294000) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:309 > #4 0x00007fd29304086d in JvmtiEnv::RawMonitorEnter(JvmtiRawMonitor*) > (this=, rmonitor=0x7fd28f22f1c0) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiEnv.cpp:3048 > #5 0x00007fd29162096d in debugMonitorEnter (monitor=0x7fd28f22f1c0) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/util.c:1044 > #6 0x00007fd29160e376 in event_callback (env=env at entry=0x7fd1242941e0, > evinfo=evinfo at entry=0x7fcf9652cae0) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:638 > #7 0x00007fd29160f635 in cbThreadEnd (jvmti_env=, > env=0x7fd1242941e0, thread=0x7fd17c01e4e0) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:875 > #8 0x00007fd2930518a4 in JvmtiExport::post_thread_end(JavaThread*) > (thread=thread at entry=0x7fd124294000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiExport.cpp:1074 > #9 0x00007fd29333b128 in JavaThread::exit(bool, JavaThread::ExitType) > (this=this at entry=0x7fd124294000, destroy_vm=destroy_vm at entry=false, > exit_type=exit_type at entry=JavaThread::normal_exit) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/thread.cpp:1833 > #10 0x00007fd29333b704 in JavaThread::thread_main_inner() (this=this at entry=0x7fd124294000) > at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/thread.cpp:1704 > #11 0x00007fd29333bcbc in JavaThread::run() (this=0x7fd124294000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/thread.cpp:1679 > #12 0x00007fd2931e1222 in java_start(Thread*) (thread=0x7fd124294000) at > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:790 > #13 0x00007fd2938756ba in start_thread (arg=0x7fcf9652d700) at > pthread_create.c:333 > #14 0x00007fd293fb041d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 > > Thanks, > Kris > > On Thu, Sep 13, 2018 at 1:54 PM, Leela Mohan > wrote: > >> Hi Kris, >> >> If i understand this deadlock correctly, There are two issues here. >> >> A) Inside "cbVMDeath" , "VM exiting" thread is waiting to be notified by >> active JVMTI callbacks to be completed. If we see >> "BEGIN_CALLBACK/END_CALLBACK" in jdk >> /src >> / >> share >> >> /back >> >> /eventHandler.c, Threads which does JVMTI Callbacks increment >> "active_callbacks" when entering and decrement "active_callbacks" when >> returning and also, when entering wait indefinitely if there is active >> VM_Death callback and when returning, notify all threads waiting on >> "callbackLock" if "active_callbacks" is zero. "VM exiting" thread is >> waiting on "callbackLock" indefinitely. We need to understand why is >> "active_callbacks" non-zero. And that is the *first *issue. Can you put >> backtraces for all the threads. And also, I think, indefinite waiting on >> "callbackLock" instead of "timed wait" is a bad idea since if "spuriously >> failing to notify" situation happens then thread wouldn't unblock. >> >> B) *Second* issue is the one you mentioned. If you look in JVM_Halt, we >> call vm_exit() after before_exit() call. vm_exit() call creates VM_Exit VM >> operation and pushes to vm queue to be executed. If VMThread deadlocks for >> the reason you mentioned, it can't progress to execute VM_Exit operation. >> Note that VM_Exit operation is expected to call eventual exit(). Stopping >> the GC threads when there is active VM GC operation seems to be bad idea. >> Instead, I think, we should move "Universe::heap()->stop()" to >> Vm_Exit:doit() can possibly solve these situations. >> >> Let me know if i missed anything. >> >> Thanks, >> Leela >> >> On Thu, Sep 13, 2018 at 7:58 AM David Holmes >> wrote: >> >>> Actually this seems to have some similarities with 4953323 >>> >>> And if cbVMDeath is anything like what is depicted here: >>> >>> http://www.oracle.com/technetwork/articles/javase/index-140680.html >>> >>> then deadlock seems quite likely. >>> >>> I'll try to look into this deeper tomorrow. >>> >>> Cheers, >>> David >>> >>> On 13/09/2018 7:51 PM, David Holmes wrote: >>> > Hi Kris, >>> > >>> > I didn't quite follow the analysis (see below) >>> > >>> > On 13/09/2018 6:57 PM, Krystal Mok wrote: >>> >> Hi HotSpot devs, >>> >> >>> >> I'd like to report a VM deadlock situation we've experienced in >>> >> production >>> >> a few weeks ago on JDK8. I checked the latest jdk/jdk code and the >>> same >>> >> race condition is still there. >>> >> >>> >> I can file a JBS ticket if this looks like a valid problem. >>> >> >>> >> tl;dr: there's a race condition between the VM shutdown and G1, in >>> >> that the >>> >> VM shutdown sequence may have just terminated all the concurrent GC >>> >> threads, and at the same time G1 has just started an incremental >>> >> collection >>> >> cycle and is waiting for the concurrent marker to finish. Since >>> >> there's no >>> >> concurrent GC thread alive to update the status anymore, G1 waits >>> >> indefinitely while holding a safepoint, causing the VM to deadlock. >>> >> >>> >> Details: >>> >> >>> >> 3 threads are involved in the actual deadlock. Detailed stack traces >>> >> are at >>> >> the end of this email. >>> >> >>> >> 1. A Java application thread at an allocation site triggering a G1 >>> >> incremental collection >>> >> 2. A thread that called System.exit(), initiating the VM shutdown >>> >> sequence. >>> >> It's in VM's native code so it doesn't block a safepoint. >>> > >>> > VM code is not "native" in the sense of being safepoint-safe. If it's >>> > still in the System.c code trying to call the VM then it is native but >>> > as soon as it tries to enter the VM it will block if a safepoint is in >>> > progress. In addition the exit requires that the VM go to a safepoint >>> > before terminating. >>> > >>> >> 3. VM thread, already inside of a safepoint and started running G1's >>> >> incremental collection. >>> >> (4. "the world" is at a safepoint so all other Java threads are just >>> >> waiting) >>> >> >>> >> The problem is, Thread 2 has already run half way into before_exit(), >>> and >>> > >>> > The problem seems to be an event callback, cbVMDeath, which seems to >>> > have take the thread from _thread_in_vm (which is not a safepoint-safe >>> > state) to presumably _thread_in_native, which is safepoint-safe. The >>> > callback then blocks on a RawMonitorWait for something and that would >>> > seem to be where the problem arises. What is the callback trying to do? >>> > >>> > Cheers, >>> > David >>> > ----- >>> > >>> > >>> >> one of the steps in there is: >>> >> >>> >> hotspot/src/share/vm/runtime/java.cpp >>> >> >>> >> 503 // Stop concurrent GC threads >>> >> 504 Universe::heap()->stop(); >>> >> >>> >> But G1 is waiting for the concurrent marker to finish scanning the >>> root >>> >> regions: >>> >> >>> >> hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp >>> >> >>> >> 506 bool CMRootRegions::wait_until_scan_finished() { >>> >> 507 if (!scan_in_progress()) return false; >>> >> 508 >>> >> 509 { >>> >> 510 MutexLockerEx x(RootRegionScan_lock, >>> >> Mutex::_no_safepoint_check_flag); >>> >> 511 while (scan_in_progress()) { >>> >> 512 >>> RootRegionScan_lock->wait(Mutex::_no_safepoint_check_flag); >>> >> 513 } >>> >> 514 } >>> >> 515 return true; >>> >> 516 } >>> >> >>> >> But scan_in_process is only updated in a few places: >>> >> >>> >> hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp >>> >> >>> >> 449 void CMRootRegions::prepare_for_scan() { >>> >> 450 assert(!scan_in_progress(), "pre-condition"); >>> >> 451 >>> >> 452 // Currently, only survivors can be root regions. >>> >> 453 assert(_next_survivor == NULL, "pre-condition"); >>> >> 454 _next_survivor = _young_list->first_survivor_region(); >>> >> 455 _scan_in_progress = (_next_survivor != NULL); >>> >> 456 _should_abort = false; >>> >> 457 } >>> >> >>> >> 490 void CMRootRegions::scan_finished() { >>> >> 491 assert(scan_in_progress(), "pre-condition"); >>> >> 492 >>> >> 493 // Currently, only survivors can be root regions. >>> >> 494 if (!_should_abort) { >>> >> 495 assert(_next_survivor == NULL, "we should have claimed all >>> >> survivors"); >>> >> 496 } >>> >> 497 _next_survivor = NULL; >>> >> 498 >>> >> 499 { >>> >> 500 MutexLockerEx x(RootRegionScan_lock, >>> >> Mutex::_no_safepoint_check_flag); >>> >> 501 _scan_in_progress = false; >>> >> 502 RootRegionScan_lock->notify_all(); >>> >> 503 } >>> >> 504 } >>> >> >>> >> And with the current GC threads gone, nobody ever gets to set >>> >> scan_in_process back to false, which leads to an infinite wait. >>> >> >>> >> One way I'd imagine fixing this is by adding a check in G1's >>> >> CMRootRegions::wait_until_scan_finished() to see if the concurrent >>> marker >>> >> thread is still there, and if it isn't, there's no point in waiting >>> >> anymore. >>> >> Obviously similar fixes would have to be done separately for other >>> >> concurrent GCs in HotSpot. >>> >> >>> >> What do you think? >>> >> >>> >> Thanks, >>> >> Kris >>> >> >>> >> Detail thread stacks for in the example: >>> >> >>> >> 1. A Java application thread at an allocation site triggering a G1 >>> >> incremental collection: >>> >> >>> >> Thread 2164 (Thread 0x7fcfc4e11700 (LWP 25218)): >>> >> #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at >>> >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >>> >> #1 0x00007fd2931e9a1b in os::PlatformEvent::park() >>> >> (this=this at entry=0x7fd05c029c00) >>> >> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 >>> >>> >> >>> >> #2 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, >>> >> ev=0x7fd05c029c00) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 >>> >>> >> >>> >> #3 0x00007fd2931a256f in Monitor::IWait(Thread*, long) >>> >> (this=this at entry=0x7fd28c012800, >>> >> Self=Self at entry=0x7fd1ac0f2000, timo=timo at entry=0) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 >>> >>> >> >>> >> #4 0x00007fd2931a382e in Monitor::wait(bool, long, bool) >>> >> (this=0x7fd28c012800, no_safepoint_check=, >>> >> timeout=timeout at entry=0, >>> >> as_suspend_equivalent=as_suspend_equivalent at entry=false) >>> >> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1126 >>> >>> >> >>> >> #5 0x00007fd29339d5fc in VMThread::execute(VM_Operation*) >>> >> (op=op at entry=0x7fcfc4e0c430) >>> >> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:642 >>> >>> >> >>> >> #6 0x00007fd292e99fec in >>> >> G1CollectedHeap::attempt_allocation_slow(unsigned >>> >> long, unsigned char, unsigned int*, unsigned int*) >>> >> (gc_cause=GCCause::_g1_inc_collection_pause, succeeded=>> >> pointer>, >>> >> gc_count_before=, word_size=1026, this=0x7fd28c033c40) >>> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:3628 >>> >>> >> >>> >> #7 0x00007fd292e99fec in >>> >> G1CollectedHeap::attempt_allocation_slow(unsigned >>> >> long, unsigned char, unsigned int*, unsigned int*) >>> >> (this=this at entry=0x7fd28c033c40, >>> >> word_size=word_size at entry=1026, context=context at entry=0 '\000', >>> >> gc_count_before_ret=gc_count_before_ret at entry=0x7fcfc4e0c50c, >>> >> gclocker_retry_count_ret=gclocker_retry_count_ret at entry=0x7fcfc4e0c508) >>> at >>> >> >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:956 >>> >>> >> >>> >> #8 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned long, >>> >> bool*) (gclocker_retry_count_ret=0x7fcfc4e0c508, >>> >> gc_count_before_ret=0x7fcfc4e0c50c, word_size=1026, >>> >> this=0x7fd28c033c40) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp:147 >>> >>> >> >>> >> #9 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned long, >>> >> bool*) (this=0x7fd28c033c40, word_size=1026, >>> >> gc_overhead_limit_was_exceeded=) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:846 >>> >>> >> >>> >> #10 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, >>> >> Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:135 >>> >>> >> >>> >> #11 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, >>> >> Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:175 >>> >>> >> >>> >> #12 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, >>> >> Thread*) (__the_thread__=0x7fd1ac0f2000, length=8192, size=1026, >>> >> klass=...) >>> >> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:216 >>> >>> >> >>> >> #13 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, >>> >> Thread*) (this=0x7c0000768, length=length at entry=8192, >>> >> do_zero=do_zero at entry=true, >>> >> __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/oops/typeArrayKlass.cpp:107 >>> >>> >> >>> >> #14 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, >>> >> Thread*) (__the_thread__=__the_thread__ at entry=0x7fd1ac0f2000, >>> >> length=length at entry=8192, this=) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/oops/typeArrayKlass.hpp:67 >>> >>> >> >>> >> #15 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, >>> >> Thread*) (type=, length=length at entry=8192, >>> >> __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/memory/oopFactory.cpp:56 >>> >>> >> >>> >> #16 0x00007fd293283457 in OptoRuntime::new_array_C(Klass*, int, >>> >> JavaThread*) (array_type=, len=8192, >>> >> thread=0x7fd1ac0f2000) >>> >> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/opto/runtime.cpp:279 >>> >>> >> >>> >> #17 0x00007fd27d0871c7 in () >>> >> >>> >> 2. A thread that called System.exit(), initiating the VM shutdown >>> >> sequence. >>> >> It's in native code so it doesn't block a safepoint: >>> >> >>> >> Thread 563 (Thread 0x7fd017980700 (LWP 7959)): >>> >> #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at >>> >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >>> >> #1 0x00007fd2931e9a1b in os::PlatformEvent::park() >>> (this=0x7fd0f4015000) >>> >> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 >>> >>> >> >>> >> #2 0x00007fd293064485 in JvmtiRawMonitor::SimpleWait(Thread*, long) >>> >> (this=this at entry=0x7fd28f22f020, Self=Self at entry=0x7fd28f0c9800, >>> >> millis=millis at entry=-1) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:194 >>> >>> >> >>> >> #3 0x00007fd293064c75 in JvmtiRawMonitor::raw_wait(long, bool, >>> Thread*) >>> >> (this=this at entry=0x7fd28f22f020, millis=millis at entry=-1, >>> >> interruptible=interruptible at entry=true, >>> >> __the_thread__=__the_thread__ at entry=0x7fd28f0c9800) >>> >> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:383 >>> >>> >> >>> >> #4 0x00007fd293040c09 in JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*, >>> >> long) >>> >> (this=, rmonitor=0x7fd28f22f020, millis=-1) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiEnv.cpp:3144 >>> >>> >> >>> >> #5 0x00007fd291620af8 in debugMonitorWait (monitor=) >>> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/util.c:1075 >>> >>> >> >>> >> #6 0x00007fd29160e86c in cbVMDeath (jvmti_env=, >>> >> env=0x7fd28f0c99e0) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:1273 >>> >>> >> >>> >> #7 0x00007fd29304f4b0 in JvmtiExport::post_vm_death() () at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiExport.cpp:490 >>> >>> >> >>> >> #8 0x00007fd292f896dd in before_exit(JavaThread*) (thread=>> >> out>) >>> >> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/java.cpp:532 >>> >>> >> >>> >> #9 0x00007fd292fd005b in JVM_Halt(jint) (code=1) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvm.cpp:441 >>> >>> >> >>> >> #10 0x00007fd27d020868 in [native] java.lang.Shutdown.halt0(int) () at >>> >> java/lang/Shutdown.java:0 >>> >> #11 0x00007fd27d00809d in [interpreted: bc = 7] >>> >> java.lang.Shutdown.halt(int) () at java/lang/Shutdown.java:140 >>> >> #12 0x00007fd27d00809d in [interpreted: bc = 99] >>> >> java.lang.Shutdown.exit(int) () at java/lang/Shutdown.java:214 >>> >> #13 0x00007fd27d00809d in [interpreted: bc = 14] >>> >> java.lang.Runtime.exit(int) () at java/lang/Runtime.java:110 >>> >> #14 0x00007fd27d00809d in [interpreted: bc = 4] >>> >> java.lang.System.exit(int) >>> >> () at java/lang/System.java:972 >>> >> #15 0x00007fd27d00809d in [interpreted: bc = 1] >>> >> scala.sys.package$.exit(int) () at scala/sys/package.java:41 >>> >> >>> >> 3. VM thread, already inside of a safepoint and started running G1's >>> >> incremental collection: >>> >> >>> >> Thread 19 (Thread 0x7fd1d70ab700 (LWP 47)): >>> >> #0 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at >>> >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 >>> >> #1 0x00007fd2931e9a1b in os::PlatformEvent::park() >>> >> (this=this at entry=0x7fd28c498200) >>> >> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 >>> >>> >> >>> >> #2 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, >>> >> ev=0x7fd28c498200) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 >>> >>> >> >>> >> #3 0x00007fd2931a256f in Monitor::IWait(Thread*, long) >>> >> (this=this at entry=0x7fd28c011700, >>> >> Self=Self at entry=0x7fd28c497800, timo=timo at entry=0) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 >>> >>> >> >>> >> #4 0x00007fd2931a37fa in Monitor::wait(bool, long, bool) >>> >> (this=0x7fd28c011700, no_safepoint_check=no_safepoint_check at entry >>> =true, >>> >> timeout=timeout at entry=0, >>> >> as_suspend_equivalent=as_suspend_equivalent at entry=false) >>> >> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1111 >>> >>> >> >>> >> #5 0x00007fd292db1fe2 in CMRootRegions::wait_until_scan_finished() >>> >> (this=0x7fd28c0826b8) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:512 >>> >>> >> >>> >> #6 0x00007fd292ea59a4 in >>> >> G1CollectedHeap::do_collection_pause_at_safepoint(double) >>> >> (this=this at entry=0x7fd28c033c40, >>> >> target_pause_time_ms=200) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:4095 >>> >>> >> >>> >> #7 0x00007fd29339f002 in VM_G1IncCollectionPause::doit() >>> >> (this=0x7fcfc4e0c430) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/vm_operations_g1.cpp:148 >>> >>> >> >>> >> #8 0x00007fd29339dfd7 in VM_Operation::evaluate() >>> >> (this=this at entry=0x7fcfc4e0c430) >>> >> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vm_operations.cpp:62 >>> >>> >> >>> >> #9 0x00007fd29339b6d7 in VMThread::evaluate_operation(VM_Operation*) >>> >> (op=0x7fcfc4e0c430, this=) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:377 >>> >>> >> >>> >> #10 0x00007fd29339cb5f in VMThread::loop() >>> >> (this=this at entry=0x7fd28c497800) >>> >> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:502 >>> >>> >> >>> >> #11 0x00007fd29339d051 in VMThread::run() (this=0x7fd28c497800) at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:276 >>> >>> >> >>> >> #12 0x00007fd2931e1222 in java_start(Thread*) (thread=0x7fd28c497800) >>> at >>> >> >>> /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:790 >>> >>> >> >>> >> >>> >> > From david.holmes at oracle.com Thu Sep 13 22:30:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Sep 2018 08:30:15 +1000 Subject: VM deadlock between VM shutdown and G1 In-Reply-To: References: <86d405c7-f27e-6869-62a6-0ef5d8a60d0d@oracle.com> Message-ID: <34190509-3f60-129a-594b-164983924c69@oracle.com> My 2c ... On 14/09/2018 6:54 AM, Leela Mohan wrote: > Hi Kris, > > If i understand this deadlock correctly, ?There are two issues here. > > A) Inside "cbVMDeath" ,?"VM exiting" thread is waiting to be notified by > active JVMTI callbacks to be completed.? If we see > "BEGIN_CALLBACK/END_CALLBACK" in jdk > /src > /share > /back > /eventHandler.c, > Threads which does JVMTI Callbacks increment "active_callbacks" when > entering and decrement "active_callbacks" when returning and also, when > entering wait indefinitely if there is active VM_Death callback and when > returning, notify all threads waiting on "callbackLock" ?if > "active_callbacks" is zero. "VM exiting" thread is waiting on > "callbackLock" indefinitely. We need to understand why is > "active_callbacks" non-zero. And that is the *first *issue. Can you put > backtraces for all the threads. And also, I think, indefinite waiting on > "callbackLock" instead of "timed wait" is a bad idea since if > ?"spuriously failing to notify" situation happens then thread wouldn't > unblock. > > B) *Second* issue is the one you mentioned. If you look in JVM_Halt, we > call vm_exit() after before_exit() call. vm_exit() call creates ?VM_Exit > VM operation and pushes to vm queue to be executed. If VMThread > deadlocks for the reason you mentioned, it can't progress to execute > VM_Exit operation. Note that VM_Exit operation is expected to call > eventual exit(). These are really just further consequences of the original GC safepoint not being able to complete. If the terminating thread did get its callback notification the shutdown process would still stall due to the in-progress safepoint. > Stopping the GC threads when there is active VM GC > operation seems to be bad idea. Instead, I think, we should move > "Universe::heap()->stop()" to Vm_Exit:doit() can possibly solve these > situations. Perhaps. But the shutdown process, like the initialization process, is very fragile. Any changes have to be examined in great detail to see how they may interact with other things. Bringing the VM to a safepoint for termination was a rather late addition to the process and arguably now that we do that, there could be things we do before that which are perhaps better done during it. But moving them would possibly introduce problems that regular testing would not expose - pretty much all the bugs in this area are exposed by real application code. Making the GC aware of the possibility of concurrent termination seems like the most isolated solution to me. Cheers, David > Let me know if i missed anything. > > Thanks, > Leela > > On Thu, Sep 13, 2018 at 7:58 AM David Holmes > wrote: > > Actually this seems to have some similarities with 4953323 > > And if cbVMDeath is anything like what is depicted here: > > http://www.oracle.com/technetwork/articles/javase/index-140680.html > > then deadlock seems quite likely. > > I'll try to look into this deeper tomorrow. > > Cheers, > David > > On 13/09/2018 7:51 PM, David Holmes wrote: > > Hi Kris, > > > > I didn't quite follow the analysis (see below) > > > > On 13/09/2018 6:57 PM, Krystal Mok wrote: > >> Hi HotSpot devs, > >> > >> I'd like to report a VM deadlock situation we've experienced in > >> production > >> a few weeks ago on JDK8. I checked the latest jdk/jdk code and > the same > >> race condition is still there. > >> > >> I can file a JBS ticket if this looks like a valid problem. > >> > >> tl;dr: there's a race condition between the VM shutdown and G1, in > >> that the > >> VM shutdown sequence may have just terminated all the concurrent GC > >> threads, and at the same time G1 has just started an incremental > >> collection > >> cycle and is waiting for the concurrent marker to finish. Since > >> there's no > >> concurrent GC thread alive to update the status anymore, G1 waits > >> indefinitely while holding a safepoint, causing the VM to deadlock. > >> > >> Details: > >> > >> 3 threads are involved in the actual deadlock. Detailed stack > traces > >> are at > >> the end of this email. > >> > >> 1. A Java application thread at an allocation site triggering a G1 > >> incremental collection > >> 2. A thread that called System.exit(), initiating the VM shutdown > >> sequence. > >> It's in VM's native code so it doesn't block a safepoint. > > > > VM code is not "native" in the sense of being safepoint-safe. If > it's > > still in the System.c code trying to call the VM then it is > native but > > as soon as it tries to enter the VM it will block if a safepoint > is in > > progress. In addition the exit requires that the VM go to a > safepoint > > before terminating. > > > >> 3. VM thread, already inside of a safepoint and started running G1's > >> incremental collection. > >> (4. "the world" is at a safepoint so all other Java threads are just > >> waiting) > >> > >> The problem is, Thread 2 has already run half way into > before_exit(), and > > > > The problem seems to be an event callback, cbVMDeath, which seems to > > have take the thread from _thread_in_vm (which is not a > safepoint-safe > > state) to presumably _thread_in_native, which is safepoint-safe. The > > callback then blocks on a RawMonitorWait for something and that > would > > seem to be where the problem arises. What is the callback trying > to do? > > > > Cheers, > > David > > ----- > > > > > >> one of the steps in there is: > >> > >> hotspot/src/share/vm/runtime/java.cpp > >> > >> 503?? // Stop concurrent GC threads > >> 504?? Universe::heap()->stop(); > >> > >> But G1 is waiting for the concurrent marker to finish scanning > the root > >> regions: > >> > >> hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp > >> > >> ? 506 bool CMRootRegions::wait_until_scan_finished() { > >> ? 507?? if (!scan_in_progress()) return false; > >> ? 508 > >> ? 509?? { > >> ? 510???? MutexLockerEx x(RootRegionScan_lock, > >> Mutex::_no_safepoint_check_flag); > >> ? 511???? while (scan_in_progress()) { > >> ? 512 > RootRegionScan_lock->wait(Mutex::_no_safepoint_check_flag); > >> ? 513???? } > >> ? 514?? } > >> ? 515?? return true; > >> ? 516 } > >> > >> But scan_in_process is only updated in a few places: > >> > >> hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp > >> > >> ? 449 void CMRootRegions::prepare_for_scan() { > >> ? 450?? assert(!scan_in_progress(), "pre-condition"); > >> ? 451 > >> ? 452?? // Currently, only survivors can be root regions. > >> ? 453?? assert(_next_survivor == NULL, "pre-condition"); > >> ? 454?? _next_survivor = _young_list->first_survivor_region(); > >> ? 455?? _scan_in_progress = (_next_survivor != NULL); > >> ? 456?? _should_abort = false; > >> ? 457 } > >> > >> ? 490 void CMRootRegions::scan_finished() { > >> ? 491?? assert(scan_in_progress(), "pre-condition"); > >> ? 492 > >> ? 493?? // Currently, only survivors can be root regions. > >> ? 494?? if (!_should_abort) { > >> ? 495???? assert(_next_survivor == NULL, "we should have claimed all > >> survivors"); > >> ? 496?? } > >> ? 497?? _next_survivor = NULL; > >> ? 498 > >> ? 499?? { > >> ? 500???? MutexLockerEx x(RootRegionScan_lock, > >> Mutex::_no_safepoint_check_flag); > >> ? 501???? _scan_in_progress = false; > >> ? 502???? RootRegionScan_lock->notify_all(); > >> ? 503?? } > >> ? 504 } > >> > >> And with the current GC threads gone, nobody ever gets to set > >> scan_in_process back to false, which leads to an infinite wait. > >> > >> One way I'd imagine fixing this is by adding a check in G1's > >> CMRootRegions::wait_until_scan_finished() to see if the > concurrent marker > >> thread is still there, and if it isn't, there's no point in waiting > >> anymore. > >> Obviously similar fixes would have to be done separately for other > >> concurrent GCs in HotSpot. > >> > >> What do you think? > >> > >> Thanks, > >> Kris > >> > >> Detail thread stacks for in the example: > >> > >> 1. A Java application thread at an allocation site triggering a G1 > >> incremental collection: > >> > >> Thread 2164 (Thread 0x7fcfc4e11700 (LWP 25218)): > >> #0? 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > >> #1? 0x00007fd2931e9a1b in os::PlatformEvent::park() > >> (this=this at entry=0x7fd05c029c00) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > > >> > >> #2? 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, > >> ev=0x7fd05c029c00) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 > > >> > >> #3? 0x00007fd2931a256f in Monitor::IWait(Thread*, long) > >> (this=this at entry=0x7fd28c012800, > >> Self=Self at entry=0x7fd1ac0f2000, timo=timo at entry=0) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 > > >> > >> #4? 0x00007fd2931a382e in Monitor::wait(bool, long, bool) > >> (this=0x7fd28c012800, no_safepoint_check=, > >> timeout=timeout at entry=0, > >> as_suspend_equivalent=as_suspend_equivalent at entry=false) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1126 > > >> > >> #5? 0x00007fd29339d5fc in VMThread::execute(VM_Operation*) > >> (op=op at entry=0x7fcfc4e0c430) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:642 > > >> > >> #6? 0x00007fd292e99fec in > >> G1CollectedHeap::attempt_allocation_slow(unsigned > >> long, unsigned char, unsigned int*, unsigned int*) > >> (gc_cause=GCCause::_g1_inc_collection_pause, succeeded= >> pointer>, > >> gc_count_before=, word_size=1026, > this=0x7fd28c033c40) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:3628 > > >> > >> #7? 0x00007fd292e99fec in > >> G1CollectedHeap::attempt_allocation_slow(unsigned > >> long, unsigned char, unsigned int*, unsigned int*) > >> (this=this at entry=0x7fd28c033c40, > >> word_size=word_size at entry=1026, context=context at entry=0 '\000', > >> gc_count_before_ret=gc_count_before_ret at entry=0x7fcfc4e0c50c, > >> > gclocker_retry_count_ret=gclocker_retry_count_ret at entry=0x7fcfc4e0c508) > at > >> > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:956 > > >> > >> #8? 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned > long, > >> bool*) (gclocker_retry_count_ret=0x7fcfc4e0c508, > >> gc_count_before_ret=0x7fcfc4e0c50c, word_size=1026, > >> this=0x7fd28c033c40) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp:147 > > >> > >> #9? 0x00007fd292e9b03b in G1CollectedHeap::mem_allocate(unsigned > long, > >> bool*) (this=0x7fd28c033c40, word_size=1026, > >> gc_overhead_limit_was_exceeded=) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:846 > > >> > >> #10 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > >> Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:135 > > >> > >> #11 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > >> Thread*) (__the_thread__=0x7fd1ac0f2000, size=1026, klass=...) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:175 > > >> > >> #12 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > >> Thread*) (__the_thread__=0x7fd1ac0f2000, length=8192, size=1026, > >> klass=...) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_interface/collectedHeap.inline.hpp:216 > > >> > >> #13 0x00007fd293356080 in TypeArrayKlass::allocate_common(int, bool, > >> Thread*) (this=0x7c0000768, length=length at entry=8192, > >> do_zero=do_zero at entry=true, > >> __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/oops/typeArrayKlass.cpp:107 > > >> > >> #14 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, > >> Thread*) (__the_thread__=__the_thread__ at entry=0x7fd1ac0f2000, > >> length=length at entry=8192, this=) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/oops/typeArrayKlass.hpp:67 > > >> > >> #15 0x00007fd2931d3550 in oopFactory::new_typeArray(BasicType, int, > >> Thread*) (type=, length=length at entry=8192, > >> __the_thread__=__the_thread__ at entry=0x7fd1ac0f2000) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/memory/oopFactory.cpp:56 > > >> > >> #16 0x00007fd293283457 in OptoRuntime::new_array_C(Klass*, int, > >> JavaThread*) (array_type=, len=8192, > >> thread=0x7fd1ac0f2000) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/opto/runtime.cpp:279 > > >> > >> #17 0x00007fd27d0871c7 in? () > >> > >> 2. A thread that called System.exit(), initiating the VM shutdown > >> sequence. > >> It's in native code so it doesn't block a safepoint: > >> > >> Thread 563 (Thread 0x7fd017980700 (LWP 7959)): > >> #0? 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > >> #1? 0x00007fd2931e9a1b in os::PlatformEvent::park() > (this=0x7fd0f4015000) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > > >> > >> #2? 0x00007fd293064485 in JvmtiRawMonitor::SimpleWait(Thread*, long) > >> (this=this at entry=0x7fd28f22f020, Self=Self at entry=0x7fd28f0c9800, > >> millis=millis at entry=-1) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:194 > > >> > >> #3? 0x00007fd293064c75 in JvmtiRawMonitor::raw_wait(long, bool, > Thread*) > >> (this=this at entry=0x7fd28f22f020, millis=millis at entry=-1, > >> interruptible=interruptible at entry=true, > >> __the_thread__=__the_thread__ at entry=0x7fd28f0c9800) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiRawMonitor.cpp:383 > > >> > >> #4? 0x00007fd293040c09 in > JvmtiEnv::RawMonitorWait(JvmtiRawMonitor*, > >> long) > >> (this=, rmonitor=0x7fd28f22f020, millis=-1) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiEnv.cpp:3144 > > >> > >> #5? 0x00007fd291620af8 in debugMonitorWait (monitor= out>) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/util.c:1075 > > >> > >> #6? 0x00007fd29160e86c in cbVMDeath (jvmti_env=, > >> env=0x7fd28f0c99e0) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/jdk/src/share/back/eventHandler.c:1273 > > >> > >> #7? 0x00007fd29304f4b0 in JvmtiExport::post_vm_death() () at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvmtiExport.cpp:490 > > >> > >> #8? 0x00007fd292f896dd in before_exit(JavaThread*) > (thread= >> out>) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/java.cpp:532 > > >> > >> #9? 0x00007fd292fd005b in JVM_Halt(jint) (code=1) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/prims/jvm.cpp:441 > > >> > >> #10 0x00007fd27d020868 in [native] java.lang.Shutdown.halt0(int) > () at > >> java/lang/Shutdown.java:0 > >> #11 0x00007fd27d00809d in [interpreted: bc = 7] > >> java.lang.Shutdown.halt(int) () at java/lang/Shutdown.java:140 > >> #12 0x00007fd27d00809d in [interpreted: bc = 99] > >> java.lang.Shutdown.exit(int) () at java/lang/Shutdown.java:214 > >> #13 0x00007fd27d00809d in [interpreted: bc = 14] > >> java.lang.Runtime.exit(int) () at java/lang/Runtime.java:110 > >> #14 0x00007fd27d00809d in [interpreted: bc = 4] > >> java.lang.System.exit(int) > >> () at java/lang/System.java:972 > >> #15 0x00007fd27d00809d in [interpreted: bc = 1] > >> scala.sys.package$.exit(int) () at scala/sys/package.java:41 > >> > >> 3. VM thread, already inside of a safepoint and started running G1's > >> incremental collection: > >> > >> Thread 19 (Thread 0x7fd1d70ab700 (LWP 47)): > >> #0? 0x00007fd29387b360 in pthread_cond_wait@@GLIBC_2.3.2 () at > >> ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 > >> #1? 0x00007fd2931e9a1b in os::PlatformEvent::park() > >> (this=this at entry=0x7fd28c498200) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:5842 > > >> > >> #2? 0x00007fd2931a256f in Monitor::IWait(Thread*, long) (timo=0, > >> ev=0x7fd28c498200) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:424 > > >> > >> #3? 0x00007fd2931a256f in Monitor::IWait(Thread*, long) > >> (this=this at entry=0x7fd28c011700, > >> Self=Self at entry=0x7fd28c497800, timo=timo at entry=0) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:802 > > >> > >> #4? 0x00007fd2931a37fa in Monitor::wait(bool, long, bool) > >> (this=0x7fd28c011700, > no_safepoint_check=no_safepoint_check at entry=true, > >> timeout=timeout at entry=0, > >> as_suspend_equivalent=as_suspend_equivalent at entry=false) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/mutex.cpp:1111 > > >> > >> #5? 0x00007fd292db1fe2 in CMRootRegions::wait_until_scan_finished() > >> (this=0x7fd28c0826b8) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:512 > > >> > >> #6? 0x00007fd292ea59a4 in > >> G1CollectedHeap::do_collection_pause_at_safepoint(double) > >> (this=this at entry=0x7fd28c033c40, > >> target_pause_time_ms=200) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp:4095 > > >> > >> #7? 0x00007fd29339f002 in VM_G1IncCollectionPause::doit() > >> (this=0x7fcfc4e0c430) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/gc_implementation/g1/vm_operations_g1.cpp:148 > > >> > >> #8? 0x00007fd29339dfd7 in VM_Operation::evaluate() > >> (this=this at entry=0x7fcfc4e0c430) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vm_operations.cpp:62 > > >> > >> #9? 0x00007fd29339b6d7 in > VMThread::evaluate_operation(VM_Operation*) > >> (op=0x7fcfc4e0c430, this=) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:377 > > >> > >> #10 0x00007fd29339cb5f in VMThread::loop() > >> (this=this at entry=0x7fd28c497800) > >> at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:502 > > >> > >> #11 0x00007fd29339d051 in VMThread::run() (this=0x7fd28c497800) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/share/vm/runtime/vmThread.cpp:276 > > >> > >> #12 0x00007fd2931e1222 in java_start(Thread*) > (thread=0x7fd28c497800) at > >> > /build/openjdk-8-OdO8jS/openjdk-8-8u162-b12/src/hotspot/src/os/linux/vm/os_linux.cpp:790 > > >> > >> > From mikael.vidstedt at oracle.com Thu Sep 13 23:03:15 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 13 Sep 2018 16:03:15 -0700 Subject: RFR(S): 8210676: Remove some unused Label variables Message-ID: Please review this change which removes a bunch of unused Label variables. Would appreciate some help from aarch64/ppc/s390x folks to verify it! bug: https://bugs.openjdk.java.net/browse/JDK-8210676 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ * Background (from bug) [~dholmes] noticed during the code review of JDK-8210381 that the "Label Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused labels like it should be removed. * About the change I have *not* tried to find and remove *all* unused Label variables, because that turns out to be much harder than it might seem. I may or may not follow up on this work to remove additional unused Label variables later, but before that I?m investigating removal of other unused variables in general. Meanwhile I like to think that this is a reasonable cleanup anyway. * Testing tier1 build&test passes. Cheers, Mikael From vladimir.kozlov at oracle.com Thu Sep 13 23:16:25 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Sep 2018 16:16:25 -0700 Subject: RFR(S): 8210676: Remove some unused Label variables In-Reply-To: References: Message-ID: Looks good to me. Thanks, Vladimir On 9/13/18 4:03 PM, Mikael Vidstedt wrote: > > Please review this change which removes a bunch of unused Label variables. Would appreciate some help from aarch64/ppc/s390x folks to verify it! > > bug: https://bugs.openjdk.java.net/browse/JDK-8210676 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ > > * Background (from bug) > > [~dholmes] noticed during the code review of JDK-8210381 that the "Label Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused labels like it should be removed. > > * About the change > > I have *not* tried to find and remove *all* unused Label variables, because that turns out to be much harder than it might seem. I may or may not follow up on this work to remove additional unused Label variables later, but before that I?m investigating removal of other unused variables in general. Meanwhile I like to think that this is a reasonable cleanup anyway. > > * Testing > > tier1 build&test passes. > > Cheers, > Mikael > From david.holmes at oracle.com Fri Sep 14 00:10:30 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Sep 2018 10:10:30 +1000 Subject: RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <0a663580-17ab-413c-416d-c3af4773d8e4@oracle.com> References: <6775CB01-428C-4214-B722-FD21FCEF93F5@oracle.com> <0a663580-17ab-413c-416d-c3af4773d8e4@oracle.com> Message-ID: <7475c0ef-4b75-6130-f43f-63c2e3806ddb@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 Further to the discussion on this under "8185062: os::is_MP() sometimes returns false": http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-August/027720.html then: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-March/031038.html I've recommenced working on this for JDK 12. John identifies 4 different uses of os::is_MP in the bug report which I plan to address as follows: 1. to gate the introduction of MP-specific features, notably memory barriers The is_MP check will be removed and we will always issue memory barriers or pre-pend lock prefix etc. 2. to align certain patchable code sequences (method entry, call sites) The is_MP is currently retained. This is because I have no idea what this alignment logic is or how it relates to uniprocessor or multiprocessor implementations. Can anyone shed some light? 3. to gate certain optimizations which are questionable on uniprocessors (see quicken_jni_functions) These are psuedo-memory-barriers where we manufacture a data-dependency instead of inserting mfence/lfence (x86 example). These are treated as #1 and is_MP is removed. 4. to gate optimizations which are desirable on uniprocessors (mutex/monitor short circuits) These are spin controls and so is_MP remains. There's an initial partial webrev (mainly x86): http://cr.openjdk.java.net/~dholmes/8188764/webrev/ Comments welcome. Thanks, David From david.holmes at oracle.com Fri Sep 14 01:17:21 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Sep 2018 11:17:21 +1000 Subject: RFR(S): 8210676: Remove some unused Label variables In-Reply-To: References: Message-ID: Looks good - though the proof is in the building of course. The debug-only use of notDouble in src/hotspot/cpu/x86/templateTable_x86.cpp seems somewhat odd. Thanks, David On 14/09/2018 9:03 AM, Mikael Vidstedt wrote: > > Please review this change which removes a bunch of unused Label variables. Would appreciate some help from aarch64/ppc/s390x folks to verify it! > > bug: https://bugs.openjdk.java.net/browse/JDK-8210676 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ > > * Background (from bug) > > [~dholmes] noticed during the code review of JDK-8210381 that the "Label Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused labels like it should be removed. > > * About the change > > I have *not* tried to find and remove *all* unused Label variables, because that turns out to be much harder than it might seem. I may or may not follow up on this work to remove additional unused Label variables later, but before that I?m investigating removal of other unused variables in general. Meanwhile I like to think that this is a reasonable cleanup anyway. > > * Testing > > tier1 build&test passes. > > Cheers, > Mikael > From john.r.rose at oracle.com Fri Sep 14 01:17:44 2018 From: john.r.rose at oracle.com (John Rose) Date: Thu, 13 Sep 2018 20:17:44 -0500 Subject: RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <7475c0ef-4b75-6130-f43f-63c2e3806ddb@oracle.com> References: <6775CB01-428C-4214-B722-FD21FCEF93F5@oracle.com> <0a663580-17ab-413c-416d-c3af4773d8e4@oracle.com> <7475c0ef-4b75-6130-f43f-63c2e3806ddb@oracle.com> Message-ID: On Sep 13, 2018, at 7:10 PM, David Holmes wrote: > > 2. to align certain patchable code sequences (method entry, call sites) > > The is_MP is currently retained. This is because I have no idea what this alignment logic is or how it relates to uniprocessor or multiprocessor implementations. Can anyone shed some light? Patchable instruction sequences inherently exhibit race conditions, where thread A is patching an instruction at the same time thread B is executing it. The algorithms we use ensure that any observation that B can make on any intermediate states during A's patching will always end up with a correct outcome. This is easiest if there are few or no intermediate states. (Some inline caches have two related instructions that must be patched in tandem. For those, intermediate states seem to be unavoidable, but we will get the right answer from all possible observation orders.) When patching the entry instruction at the head of a method, or a linkable call instruction inside of a method, we try very hard to use a patch sequence which executes as a single memory transaction. This means, in practice, that when thread A patches an instruction, it should patch a 32-bit or 64-bit word that somehow overlaps the instruction or is contained in it. We believe that memory hardware will never break up such an word write, if it is naturally aligned for the word being written. We also know that some CPUs work very hard to create atomic updates even of naturally unaligned words, but we don't want to bet the farm on this always working. Therefore, if there is any chance of a race condition, we try to patch only naturally aligned words, as single, full-word writes. The is_MP query is asking, "do we have to worry about races?" Just set it to constant-true. It's not worth trying to maintain the alternative algorithm. In fact, pre-emptive single-processor systems have race conditions too, although they are rarer and more constrained than in modern systems. ? John From mikael.vidstedt at oracle.com Fri Sep 14 01:22:20 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 13 Sep 2018 18:22:20 -0700 Subject: RFR(S): 8210676: Remove some unused Label variables In-Reply-To: References: Message-ID: <6D50BF19-4A15-432F-A0EF-FC777113F88E@oracle.com> > On Sep 13, 2018, at 6:17 PM, David Holmes wrote: > > Looks good - though the proof is in the building of course. > > The debug-only use of notDouble in src/hotspot/cpu/x86/templateTable_x86.cpp seems somewhat odd. Would you prefer to see it declared next to the other labels, but guarded with ASSERT? Cheers, Mikael > > Thanks, > David > > On 14/09/2018 9:03 AM, Mikael Vidstedt wrote: >> Please review this change which removes a bunch of unused Label variables. Would appreciate some help from aarch64/ppc/s390x folks to verify it! >> bug: https://bugs.openjdk.java.net/browse/JDK-8210676 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ >> * Background (from bug) >> [~dholmes] noticed during the code review of JDK-8210381 that the "Label Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused labels like it should be removed. >> * About the change >> I have *not* tried to find and remove *all* unused Label variables, because that turns out to be much harder than it might seem. I may or may not follow up on this work to remove additional unused Label variables later, but before that I?m investigating removal of other unused variables in general. Meanwhile I like to think that this is a reasonable cleanup anyway. >> * Testing >> tier1 build&test passes. >> Cheers, >> Mikael From david.holmes at oracle.com Fri Sep 14 01:37:53 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Sep 2018 11:37:53 +1000 Subject: RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: <6775CB01-428C-4214-B722-FD21FCEF93F5@oracle.com> <0a663580-17ab-413c-416d-c3af4773d8e4@oracle.com> <7475c0ef-4b75-6130-f43f-63c2e3806ddb@oracle.com> Message-ID: Thanks for the explanation John! To summarise for my own benefit. Patching an unaligned address may not be atomic at the hardware level, but for a uniprocessor it is effectively atomic as nothing else can concurrently examine the address (we "can't" field interrupts that might trigger a context switch in the middle of an instruction executing). For MP concurrent access is possible so we always force alignment. I will assume is_MP is true and always use the aligning code. Though I already noticed this would have some non-trivial flow on where we check for un-aligned patching and assert !is_MP. That will reduce to adding a guarantee that the patching location is aligned and only use the code for the aligned case. Thanks, David On 14/09/2018 11:17 AM, John Rose wrote: > On Sep 13, 2018, at 7:10 PM, David Holmes > wrote: >> >> 2. to align certain patchable code sequences (method entry, call sites) >> >> The is_MP is currently retained. This is because I have no idea what >> this alignment logic is or how it relates to uniprocessor or >> multiprocessor implementations. Can anyone shed some light? > > Patchable instruction sequences inherently exhibit race conditions, > where thread A is patching an instruction at the same time thread B > is executing it. ?The algorithms we use ensure that any observation > that B can make on any intermediate states during A's patching will > always end up with a correct outcome. ?This is easiest if there are > few or no intermediate states. ?(Some inline caches have two related > instructions that must be patched in tandem. ?For those, intermediate > states seem to be unavoidable, but we will get the right answer from > all possible observation orders.) > > When patching the entry instruction at the head of a method, or a > linkable call instruction inside of a method, we try very hard to use > a patch sequence which executes as a single memory transaction. > This means, in practice, that when thread A patches an instruction, > it should patch a 32-bit or 64-bit word that somehow overlaps the > instruction or is contained in it. ?We believe that memory hardware > will never break up such an word write, if it is naturally aligned > for the word being written. ?We also know that some CPUs work > very hard to create atomic updates even of naturally unaligned > words, but we don't want to bet the farm on this always working. > > Therefore, if there is any chance of a race condition, we try to > patch only naturally aligned words, as single, full-word writes. > > The is_MP query is asking, "do we have to worry about races?" > Just set it to constant-true. ?It's not worth trying to maintain the > alternative algorithm. ?In fact, pre-emptive single-processor > systems have race conditions too, although they are rarer and > more constrained than in modern systems. > > ? John From david.holmes at oracle.com Fri Sep 14 01:38:57 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Sep 2018 11:38:57 +1000 Subject: RFR(S): 8210676: Remove some unused Label variables In-Reply-To: <6D50BF19-4A15-432F-A0EF-FC777113F88E@oracle.com> References: <6D50BF19-4A15-432F-A0EF-FC777113F88E@oracle.com> Message-ID: <4e46fa33-188f-999b-1711-faed4b137f8b@oracle.com> On 14/09/2018 11:22 AM, Mikael Vidstedt wrote: > >> On Sep 13, 2018, at 6:17 PM, David Holmes wrote: >> >> Looks good - though the proof is in the building of course. >> >> The debug-only use of notDouble in src/hotspot/cpu/x86/templateTable_x86.cpp seems somewhat odd. > > Would you prefer to see it declared next to the other labels, but guarded with ASSERT? No what you have is fine. I'm just curious about why the double case is only examined in a non-product build ?? David > Cheers, > Mikael > >> >> Thanks, >> David >> >> On 14/09/2018 9:03 AM, Mikael Vidstedt wrote: >>> Please review this change which removes a bunch of unused Label variables. Would appreciate some help from aarch64/ppc/s390x folks to verify it! >>> bug: https://bugs.openjdk.java.net/browse/JDK-8210676 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ >>> * Background (from bug) >>> [~dholmes] noticed during the code review of JDK-8210381 that the "Label Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused labels like it should be removed. >>> * About the change >>> I have *not* tried to find and remove *all* unused Label variables, because that turns out to be much harder than it might seem. I may or may not follow up on this work to remove additional unused Label variables later, but before that I?m investigating removal of other unused variables in general. Meanwhile I like to think that this is a reasonable cleanup anyway. >>> * Testing >>> tier1 build&test passes. >>> Cheers, >>> Mikael > From Ningsheng.Jian at arm.com Fri Sep 14 04:19:10 2018 From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China)) Date: Fri, 14 Sep 2018 04:19:10 +0000 Subject: [aarch64-port-dev ] RFR(S): 8210676: Remove some unused Label variables In-Reply-To: References: Message-ID: Hi Mikael, AArch64 and Arm parts looks good and I have also verified the build. Thanks, Ningsheng > -----Original Message----- > From: aarch64-port-dev On > Behalf Of Mikael Vidstedt > Sent: Friday, September 14, 2018 7:03 AM > To: HotSpot Open Source Developers > Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; > aarch64-port-dev at openjdk.java.net > Subject: [aarch64-port-dev ] RFR(S): 8210676: Remove some unused Label > variables > > > Please review this change which removes a bunch of unused Label variables. > Would appreciate some help from aarch64/ppc/s390x folks to verify it! > > bug: https://bugs.openjdk.java.net/browse/JDK-8210676 > webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ > > * Background (from bug) > > [~dholmes] noticed during the code review of JDK-8210381 that the "Label > Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused > labels like it should be removed. > > * About the change > > I have *not* tried to find and remove *all* unused Label variables, because that > turns out to be much harder than it might seem. I may or may not follow up on > this work to remove additional unused Label variables later, but before that I?m > investigating removal of other unused variables in general. Meanwhile I like to > think that this is a reasonable cleanup anyway. > > * Testing > > tier1 build&test passes. > > Cheers, > Mikael From magnus.ihse.bursie at oracle.com Fri Sep 14 08:37:20 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Sep 2018 10:37:20 +0200 Subject: Compile error in codeBlob.cpp when building JDK-11 for Windows-32 In-Reply-To: <5044cb6a-8c28-752d-5fbd-5e4f73a937d8@synedra.com> References: <5044cb6a-8c28-752d-5fbd-5e4f73a937d8@synedra.com> Message-ID: <5233640d-ff34-a591-2e6c-a4f50ee4baa6@oracle.com> On 2018-09-14 10:03, Robert Lichtenberger wrote: > I have tried to build a Windows 32-bit JDK-11. While I was successful in > building a 64-bit Windows JDK, the attempt for 32-bit failed: > > Here's what I did: > > $ bash configure --with-boot-jdk=/cygdrive/c/jdk-10.0.2 > --disable-warnings-as-errors --with-target-bits=32 > ... > > ==================================================== > The existing configuration has been successfully updated in > /cygdrive/c/jdk/jdk11/build/windows-x86-normal-server-release > using configure arguments '--with-boot-jdk=/cygdrive/c/jdk-10.0.2 > --disable-warnings-as-errors --with-target-bits=32'. > > Configuration summary: > * Debug level:??? release > * HS debug level: product > * JVM variants:?? server > * JVM features:?? server: 'cds cmsgc compiler1 compiler2 epsilongc g1gc > jfr jni-check jvmti management nmt parallelgc serialgc services vm-structs' > * OpenJDK target: OS: windows, CPU architecture: x86, address length: 32 > * Version string: 11-internal+0-adhoc.synedra.jdk11 (11-internal) > > Tools summary: > * Environment:??? cygwin version 2.10.0(0.325/5/3) (root at > /cygdrive/c/cygwin64) > * Boot JDK:?????? openjdk version "10.0.2" 2018-07-17? OpenJDK Runtime > Environment 18.3 (build 10.0.2+13)? OpenJDK 64-Bit Server VM 18.3 (build > 10.0.2+13, mixed mode)?? (at /cygdrive/c/jdk-10.0.2) > * Toolchain:????? microsoft (Microsoft Visual Studio 2017) > * C Compiler:???? Version 19.15.26729 (at > /cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl) > * C++ Compiler:?? Version 19.15.26729 (at > /cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl) > > Build performance summary: > * Cores to use:?? 2 > * Memory limit:?? 16383 MB > ... > > $ time make CONF=windows-x86-normal-server-release all > Building target 'all' in configuration 'windows-x86-normal-server-release' > c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(229): error C2956: > sized deallocation function 'operator delete(void*, size_t)' would be > chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(250): error C2956: > sized deallocation function 'operator delete(void*, size_t)' would be > chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(289): error C2956: > sized deallocation function 'operator delete(void*, size_t)' would be > chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(312): error C2956: > sized deallocation function 'operator delete(void*, size_t)' would be > chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(333): error C2956: > sized deallocation function 'operator delete(void*, size_t)' would be > chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(372): error C2956: > sized deallocation function 'operator delete(void*, size_t)' would be > chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(437): error C2956: > sized deallocation function 'operator delete(void*, size_t)' would be > chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(470): error C2956: > sized deallocation function 'operator delete(void*, size_t)' would be > chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(506): error C2956: > sized deallocation function 'operator delete(void*, size_t)' would be > chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(541): error C2956: > sized deallocation function 'operator delete(void*, size_t)' would be > chosen as placement deallocation function. > predefined C++ types (compiler internal)(44): note: see declaration of > 'operator delete' > make[3]: *** [lib/CompileJvm.gmk:151: > /cygdrive/c/jdk/jdk11/build/windows-x86-normal-server-release/hotspot/variant-server/libjvm/objs/codeBlob.obj] > Error 1 > make[2]: *** [make/Main.gmk:257: hotspot-server-libs] Error 2 > make[2]: *** Waiting for unfinished jobs.... > > ERROR: Build failed for target 'all' in configuration > 'windows-x86-normal-server-release' (exit code 2) This is most likely due to some issue on new/delete operators works, which are undergoing changes in the language. That is, a code issue on hotspot. I don't know why you are seeing this on windows-x86 though. https://msdn.microsoft.com/en-us/library/mt723604.aspx suggests that you can disable this check by -Zc:sizedDealloc-. Do this by "configure --with-extra-cxxflags=Zc:sizedDealloc-". > On a meta-level: Is a JDK for Windows 32-bit just built no longer or is > it completely abandoned as a platform? Oracle is not building 32-bit Windows regularly, and I don't think anyone else is doing that. (Perhaps AdoptOpenJDK?) In such a scenario, the code quickly bit rots. There has been no decision as of yet to remove the code from the code base, but unless someone steps up to maintain the code base, it's unlikely to survive in the long term. /Magnus From sgehwolf at redhat.com Fri Sep 14 08:37:39 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 14 Sep 2018 10:37:39 +0200 Subject: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: References: <7D5F0258-F6DE-402A-AB32-907A2D6E45DF@sap.com> <4cc34e60-be08-4e4a-c08c-fdcde0ba4646@oracle.com> Message-ID: On Thu, 2018-09-13 at 10:39 -0700, Erik Joelsson wrote: > On 2018-09-13 03:02, Severin Gehwolf wrote: > > Hi Erik, > > > > On Wed, 2018-09-12 at 10:02 -0700, Erik Joelsson wrote: > > > Hello Severin, > > > > > > In configure, we now set FDLIBM_CFLAGS based on toolchain type and > > > capabilities. In JvmOverrideFiles.gmk, the use of it is still > > > conditional on Linux. I don't think it should be. We already have the > > > conditionals we need. > > > > Thanks for the review. Updated webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.03/ > > > > I wasn't sure whether the precompiled headers handling for gcc/clang is > > right and was reluctant to move it out of the linux conditional. The > > assumption on my end is that if headers are compiled with -O3, we can't > > used them for any other opt level. It should still all work. Thoughts? > > Looking at this again, I now realize the whole file has the treatment > for these files repeated for each OS, with slight variations. This > becomes a clash with the change we are now attempting which is toolchain > oriented. I think the easiest way here would be to keep it OS separated > for now by reverting to your previous patch. > > You could consider putting the FDLIBM_CFLAGS conditional block outside > the linux block however and apply the "$(FDLIBM_CFLAGS) > $(LIBJVM_FDLIBM_COPY_OPT_FLAG)" flags on the lines in the macosx block > further down as well. The changes for fdlibm as they are now will apply > on macosx since we use clang there, so the jvm change should too. OK, done: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.04/ More thoughts? Thanks, Severin From aph at redhat.com Fri Sep 14 08:59:35 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 14 Sep 2018 09:59:35 +0100 Subject: [aarch64-port-dev ] RFR(S): 8210676: Remove some unused Label variables In-Reply-To: References: Message-ID: <45d6dcb7-d1df-62c5-0662-a921350b21de@redhat.com> On 09/14/2018 05:19 AM, Ningsheng Jian (Arm Technology China) wrote: > AArch64 and Arm parts looks good and I have also verified the build. Yep. That's a nice cleanup. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From magnus.ihse.bursie at oracle.com Fri Sep 14 09:04:50 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Sep 2018 11:04:50 +0200 Subject: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: References: <7D5F0258-F6DE-402A-AB32-907A2D6E45DF@sap.com> <4cc34e60-be08-4e4a-c08c-fdcde0ba4646@oracle.com> Message-ID: <9b9eccd8-6f3c-dfe2-3683-d8f2c16ee05e@oracle.com> On 2018-09-14 10:37, Severin Gehwolf wrote: > On Thu, 2018-09-13 at 10:39 -0700, Erik Joelsson wrote: >> On 2018-09-13 03:02, Severin Gehwolf wrote: >>> Hi Erik, >>> >>> On Wed, 2018-09-12 at 10:02 -0700, Erik Joelsson wrote: >>>> Hello Severin, >>>> >>>> In configure, we now set FDLIBM_CFLAGS based on toolchain type and >>>> capabilities. In JvmOverrideFiles.gmk, the use of it is still >>>> conditional on Linux. I don't think it should be. We already have the >>>> conditionals we need. >>> Thanks for the review. Updated webrev: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.03/ >>> >>> I wasn't sure whether the precompiled headers handling for gcc/clang is >>> right and was reluctant to move it out of the linux conditional. The >>> assumption on my end is that if headers are compiled with -O3, we can't >>> used them for any other opt level. It should still all work. Thoughts? >> Looking at this again, I now realize the whole file has the treatment >> for these files repeated for each OS, with slight variations. This >> becomes a clash with the change we are now attempting which is toolchain >> oriented. I think the easiest way here would be to keep it OS separated >> for now by reverting to your previous patch. >> >> You could consider putting the FDLIBM_CFLAGS conditional block outside >> the linux block however and apply the "$(FDLIBM_CFLAGS) >> $(LIBJVM_FDLIBM_COPY_OPT_FLAG)" flags on the lines in the macosx block >> further down as well. The changes for fdlibm as they are now will apply >> on macosx since we use clang there, so the jvm change should too. > OK, done: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.04/ I think this looks reasonable, but let's hear what Erik has to say about it also. /Magnus > > More thoughts? > > Thanks, > Severin > From aph at redhat.com Fri Sep 14 09:05:12 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 14 Sep 2018 10:05:12 +0100 Subject: RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <7475c0ef-4b75-6130-f43f-63c2e3806ddb@oracle.com> References: <6775CB01-428C-4214-B722-FD21FCEF93F5@oracle.com> <0a663580-17ab-413c-416d-c3af4773d8e4@oracle.com> <7475c0ef-4b75-6130-f43f-63c2e3806ddb@oracle.com> Message-ID: <5c39129b-94cd-ba43-5784-88ae6ad67ff9@redhat.com> On 09/14/2018 01:10 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 > > There's an initial partial webrev (mainly x86): > > http://cr.openjdk.java.net/~dholmes/8188764/webrev/ AArch64 part looks good. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aleksei.voitylov at bell-sw.com Fri Sep 14 11:54:47 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 14 Sep 2018 14:54:47 +0300 Subject: [12] RFR (S): 8210465: ARM: Object equals abstraction for BarrierSetAssembler Message-ID: <44a15a18-04b6-f0d1-97a6-5c4552c9af3a@bell-sw.com> Hi, please review this patch which follows the changes on x86 and AARCH64: Enhancement: https://bugs.openjdk.java.net/browse/JDK-8210465 Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210465.01/ Tested by HotSpot regression tests. Original issue for x86 and AARCH64: https://bugs.openjdk.java.net/browse/JDK-8203157 Thanks, -Aleksei From aleksei.voitylov at bell-sw.com Fri Sep 14 11:54:51 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 14 Sep 2018 14:54:51 +0300 Subject: [12] RFR (S): 8210466: ARM: Modularize allocations in assembler Message-ID: Hi, please review this patch which follows the changes on x86 and AARCH64: Enhancement: https://bugs.openjdk.java.net/browse/JDK-8210466 Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210466.01/ This patch is incremental to 8210465. Tested by HotSpot regression tests. Original issue for x86 and AARCH64: https://bugs.openjdk.java.net/browse/JDK-8205336 Thanks, -Aleksei From rkennke at redhat.com Fri Sep 14 12:39:02 2018 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 14 Sep 2018 14:39:02 +0200 Subject: [12] RFR (S): 8210465: ARM: Object equals abstraction for BarrierSetAssembler In-Reply-To: <44a15a18-04b6-f0d1-97a6-5c4552c9af3a@bell-sw.com> References: <44a15a18-04b6-f0d1-97a6-5c4552c9af3a@bell-sw.com> Message-ID: This looks good to me, from GC interface perspective. Don't know ARM32 very well, but looks ok from far away too. Thanks, Roman > Hi, > > please review this patch which follows the changes on x86 and AARCH64: > > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8210465 > Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210465.01/ > > Tested by HotSpot regression tests. > > Original issue for x86 and AARCH64: > https://bugs.openjdk.java.net/browse/JDK-8203157 > > Thanks, > > -Aleksei > From coleen.phillimore at oracle.com Fri Sep 14 12:44:15 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 14 Sep 2018 08:44:15 -0400 Subject: RFR(S): 8210676: Remove some unused Label variables In-Reply-To: <4e46fa33-188f-999b-1711-faed4b137f8b@oracle.com> References: <6D50BF19-4A15-432F-A0EF-FC777113F88E@oracle.com> <4e46fa33-188f-999b-1711-faed4b137f8b@oracle.com> Message-ID: On 9/13/18 9:38 PM, David Holmes wrote: > On 14/09/2018 11:22 AM, Mikael Vidstedt wrote: >> >>> On Sep 13, 2018, at 6:17 PM, David Holmes >>> wrote: >>> >>> Looks good - though the proof is in the building of course. >>> >>> The debug-only use of notDouble in >>> src/hotspot/cpu/x86/templateTable_x86.cpp seems somewhat odd. >> >> Would you prefer to see it declared next to the other labels, but >> guarded with ASSERT? > > No what you have is fine. I'm just curious about why the double case > is only examined in a non-product build ?? The notDouble label is sort of a switch default label, which we only care about in debug.? Otherwise it falls off into code below. thanks, Coleen > > David > >> Cheers, >> Mikael >> >>> >>> Thanks, >>> David >>> >>> On 14/09/2018 9:03 AM, Mikael Vidstedt wrote: >>>> Please review this change which removes a bunch of unused Label >>>> variables. Would appreciate some help from aarch64/ppc/s390x folks >>>> to verify it! >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8210676 >>>> webrev: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ >>>> * Background (from bug) >>>> [~dholmes] noticed during the code review of JDK-8210381 that the >>>> "Label Egress" variable in macroAssembler_sparc.cpp was unused. It >>>> and other unused labels like it should be removed. >>>> * About the change >>>> I have *not* tried to find and remove *all* unused Label variables, >>>> because that turns out to be much harder than it might seem. I may >>>> or may not follow up on this work to remove additional unused Label >>>> variables later, but before that I?m investigating removal of other >>>> unused variables in general. Meanwhile I like to think that this is >>>> a reasonable cleanup anyway. >>>> * Testing >>>> tier1 build&test passes. >>>> Cheers, >>>> Mikael >> From rkennke at redhat.com Fri Sep 14 12:58:51 2018 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 14 Sep 2018 14:58:51 +0200 Subject: [12] RFR (S): 8210466: ARM: Modularize allocations in assembler In-Reply-To: References: Message-ID: <344bb3c5-c570-bf2f-36db-96d189f009e1@redhat.com> Hi Aleksei, This looks good from GC interface perspective. Thanks, Roman > Hi, > > please review this patch which follows the changes on x86 and AARCH64: > > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8210466 > Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210466.01/ > > This patch is incremental to 8210465. Tested by HotSpot regression tests. > > Original issue for x86 and AARCH64: > https://bugs.openjdk.java.net/browse/JDK-8205336 > > Thanks, > > -Aleksei > > > From erik.joelsson at oracle.com Fri Sep 14 17:08:43 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 14 Sep 2018 10:08:43 -0700 Subject: 8210425: [x86] sharedRuntimeTrig/sharedRuntimeTrans compiled without optimization In-Reply-To: <9b9eccd8-6f3c-dfe2-3683-d8f2c16ee05e@oracle.com> References: <7D5F0258-F6DE-402A-AB32-907A2D6E45DF@sap.com> <4cc34e60-be08-4e4a-c08c-fdcde0ba4646@oracle.com> <9b9eccd8-6f3c-dfe2-3683-d8f2c16ee05e@oracle.com> Message-ID: <2320e224-7578-b608-8dca-d42188c8bef3@oracle.com> Yes, this looks good, thanks for hanging in there! /Erik On 2018-09-14 02:04, Magnus Ihse Bursie wrote: > > > On 2018-09-14 10:37, Severin Gehwolf wrote: >> On Thu, 2018-09-13 at 10:39 -0700, Erik Joelsson wrote: >>> On 2018-09-13 03:02, Severin Gehwolf wrote: >>>> Hi Erik, >>>> >>>> On Wed, 2018-09-12 at 10:02 -0700, Erik Joelsson wrote: >>>>> Hello Severin, >>>>> >>>>> In configure, we now set FDLIBM_CFLAGS based on toolchain type and >>>>> capabilities. In JvmOverrideFiles.gmk, the use of it is still >>>>> conditional on Linux. I don't think it should be. We already have the >>>>> conditionals we need. >>>> Thanks for the review. Updated webrev: >>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.03/ >>>> >>>> I wasn't sure whether the precompiled headers handling for >>>> gcc/clang is >>>> right and was reluctant to move it out of the linux conditional. The >>>> assumption on my end is that if headers are compiled with -O3, we >>>> can't >>>> used them for any other opt level. It should still all work. Thoughts? >>> Looking at this again, I now realize the whole file has the treatment >>> for these files repeated for each OS, with slight variations. This >>> becomes a clash with the change we are now attempting which is >>> toolchain >>> oriented. I think the easiest way here would be to keep it OS separated >>> for now by reverting to your previous patch. >>> >>> You could consider putting the FDLIBM_CFLAGS conditional block outside >>> the linux block however and apply the "$(FDLIBM_CFLAGS) >>> $(LIBJVM_FDLIBM_COPY_OPT_FLAG)" flags on the lines in the macosx block >>> further down as well. The changes for fdlibm as they are now will apply >>> on macosx since we use clang there, so the jvm change should too. >> OK, done: >> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210425/webrev.04/ > I think this looks reasonable, but let's hear what Erik has to say > about it also. > > /Magnus >> >> More thoughts? >> >> Thanks, >> Severin >> > From igor.ignatyev at oracle.com Fri Sep 14 17:48:33 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 14 Sep 2018 10:48:33 -0700 Subject: RFR (L) 8210481: Remove #ifdef cplusplus from vmTestbase In-Reply-To: References: Message-ID: <5301110A-52D0-4EAD-B18D-CC86866539C7@oracle.com> Hi JC, looks good to me. (cc'ing hotspot-dev alias as it affects other teams' tests) -- Igor > On Sep 14, 2018, at 9:50 AM, JC Beyler wrote: > > Hi all, > > Could I get a review for the following webrev: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8210481 > > @Alex: I know we had said generally 50 files max but this one is really straight forward; if you still prefer 50 files, let me know and I'll cut it up into chunks. > > @all: A big webrev this time, to which I apologize but it is the last macro removal webrev from me in a while (there still is https://bugs.openjdk.java.net/browse/JDK-8210728 but I'm giving everyone a rest on macro removal and will work on a few code refactoring I promised to do ;-)). > > To perhaps help reviewing it: > This webrev removes two #ifdef per file touched: > > -#ifdef __cplusplus > extern "C" { > -#endif > > and > > -#ifdef __cplusplus > } > -#endif > > -> The patch only has deletions (4 per file), no insertions > -> I double checked that all files only have exactly those removals and no other removals EXCEPT: > http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h.udiff.html > which is still defining the NSK_STUB macros but was doing it for C/C++ styles. > -> Last easier check for reviewers: > - Look for deletions but that are not exactly "-#endif" or "-#ifdef __cplusplus" > grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v "^-#ifdef __cplusplus$" > > That command provides only the lines from the nsk_tools.h file: > $ grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v "^-#ifdef __cplusplus$" > -#define NSK_CPP_STUB1(Func,env) (*env)->Func(env) > -#define NSK_CPP_STUB2(Func,env,a) (*env)->Func(env,a) > -#define NSK_CPP_STUB3(Func,env,a,b) (*env)->Func(env,a,b) > -#define NSK_CPP_STUB4(Func,env,a,b,c) (*env)->Func(env,a,b,c) > -#define NSK_CPP_STUB5(Func,env,a,b,c,d) (*env)->Func(env,a,b,c,d) > -#define NSK_CPP_STUB6(Func,env,a,b,c,d,e) (*env)->Func(env,a,b,c,d,e) > -#define NSK_CPP_STUB7(Func,env,a,b,c,d,e,f) (*env)->Func(env,a,b,c,d,e,f) > -#define NSK_CPP_STUB8(Func,env,a,b,c,d,e,f,g) (*env)->Func(env,a,b,c,d,e,f,g) > -#define NSK_CPP_STUB9(Func,env,a,b,c,d,e,f,g,h) (*env)->Func(env,a,b,c,d,e,f,g,h) > -#ifndef NSK_CPP_STUBS_ENFORCE_C > -#undef NSK_CPP_STUB1 > -#undef NSK_CPP_STUB2 > -#undef NSK_CPP_STUB3 > -#undef NSK_CPP_STUB4 > -#undef NSK_CPP_STUB5 > -#undef NSK_CPP_STUB6 > -#undef NSK_CPP_STUB7 > -#undef NSK_CPP_STUB8 > -#undef NSK_CPP_STUB9 > > Thanks for the reviews, > Jc From coleen.phillimore at oracle.com Fri Sep 14 18:32:54 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 14 Sep 2018 14:32:54 -0400 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) Message-ID: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> Summary: Save windows 64 callee saved registers rsi, rdi to Thread, save r15, also callee saved to r9 This is done for generated stubs that do arraycopy that need GC barrier code because GC assumes that r10 is scratch, since it's defined as rscratch1.? See bug for more details.? Thanks Erik for your help and the diagnosis. Tested with mach5 hs-tier1-7.? We don't have a reproduceable test case. open webrev at http://cr.openjdk.java.net/~coleenp/8203466.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8203466 Thanks, Coleen From dean.long at oracle.com Fri Sep 14 20:01:02 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 14 Sep 2018 13:01:02 -0700 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> Message-ID: Hi Coleen.? In the bug you asked: > Why can't we just push rdi and rsi to the stack and restore them? This code appears to be leaf code so shouldn't care about stack format Did that ever get answered?? If there is concern about the pushes and pops canceling out at the end, you could always reserve the stack space at the beginning, after __ enter(); and then setup_arg_regs/restore_arg_regs would not need to adjust the stack pointer. dl On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote: > Summary: Save windows 64 callee saved registers rsi, rdi to Thread, > save r15, also callee saved to r9 > > This is done for generated stubs that do arraycopy that need GC > barrier code because GC assumes that r10 is scratch, since it's > defined as rscratch1.? See bug for more details.? Thanks Erik for your > help and the diagnosis. > > Tested with mach5 hs-tier1-7.? We don't have a reproduceable test case. > > open webrev at http://cr.openjdk.java.net/~coleenp/8203466.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8203466 > > Thanks, > Coleen > From aph at redhat.com Sat Sep 15 08:32:08 2018 From: aph at redhat.com (Andrew Haley) Date: Sat, 15 Sep 2018 09:32:08 +0100 Subject: RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: <6775CB01-428C-4214-B722-FD21FCEF93F5@oracle.com> <0a663580-17ab-413c-416d-c3af4773d8e4@oracle.com> <7475c0ef-4b75-6130-f43f-63c2e3806ddb@oracle.com> Message-ID: <7fc85a74-9309-556a-3fc6-eb4c7236f921@redhat.com> On 09/14/2018 02:17 AM, John Rose wrote: > Therefore, if there is any chance of a race condition, we try to > patch only naturally aligned words, as single, full-word writes. Thanks for that. It was very difficult to understand what the code was doing when I ported it to AArch64. It would be very nice to have this commentary in the source code. May I submit this as a comment-only patch? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dms at samersoff.net Sun Sep 16 12:11:14 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 16 Sep 2018 15:11:14 +0300 Subject: [12] RFR (S): 8210465: ARM: Object equals abstraction for BarrierSetAssembler In-Reply-To: <44a15a18-04b6-f0d1-97a6-5c4552c9af3a@bell-sw.com> References: <44a15a18-04b6-f0d1-97a6-5c4552c9af3a@bell-sw.com> Message-ID: Aleksei, Looks good to me. PS: BarrierSetAssembler* bs = BarrierSet::barrier_set()->barrier_set_assembler(); bs->obj_equals(this, obj1, obj2); Just to emit cmp reg, reg looks a bit overkilling for me. On 09/14/2018 02:54 PM, Aleksei Voitylov wrote: > Hi, > > please review this patch which follows the changes on x86 and AARCH64: > > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8210465 > Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210465.01/ > > Tested by HotSpot regression tests. > > Original issue for x86 and AARCH64: > https://bugs.openjdk.java.net/browse/JDK-8203157 > > Thanks, > > -Aleksei > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From dms at samersoff.net Sun Sep 16 12:17:27 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 16 Sep 2018 15:17:27 +0300 Subject: [12] RFR (S): 8210466: ARM: Modularize allocations in assembler In-Reply-To: References: Message-ID: <5e1b8aa0-c283-0eeb-d073-9fb2f4a13e4e@samersoff.net> Hello Aleksei, Looks good to me. -Dmitry On 09/14/2018 02:54 PM, Aleksei Voitylov wrote: > Hi, > > please review this patch which follows the changes on x86 and AARCH64: > > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8210466 > Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210466.01/ > > This patch is incremental to 8210465. Tested by HotSpot regression tests. > > Original issue for x86 and AARCH64: > https://bugs.openjdk.java.net/browse/JDK-8205336 > > Thanks, > > -Aleksei > > > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From dms at samersoff.net Sun Sep 16 12:19:15 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 16 Sep 2018 15:19:15 +0300 Subject: [12] RFR(S): 8209695: ARM: Explicit barriers for interpreter In-Reply-To: <3075f116-73cd-deb1-bb75-287101a3e5eb@bell-sw.com> References: <3075f116-73cd-deb1-bb75-287101a3e5eb@bell-sw.com> Message-ID: <34a658d5-00c2-9b0e-9a2a-8232053128e1@samersoff.net> Hello Aleksei, Looks good to me. -Dmitry On 08/23/2018 05:30 PM, Aleksei Voitylov wrote: > Hi, > > please review this patch which adds explicit barriers for interpreter on > ARM similar to how it was done on x86 and Aarch64: > > webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8209695.01/ > issue: https://bugs.openjdk.java.net/browse/JDK-8209695 > > here is the issue where this functionality was added on x86 and Aarch64: > https://bugs.openjdk.java.net/browse/JDK-8205523 > > Tested by running hotspot tests. > > Thanks, > > -Aleksei > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From dms at samersoff.net Sun Sep 16 12:21:06 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Sun, 16 Sep 2018 15:21:06 +0300 Subject: [12] RFR(S): 8209697: ARM: Explicit barriers for C1/assembler In-Reply-To: <0654c3fc-213c-a06f-d28e-7be1d1fcbe0b@bell-sw.com> References: <0654c3fc-213c-a06f-d28e-7be1d1fcbe0b@bell-sw.com> Message-ID: <1bdb5d7f-b92c-bee1-22f0-63762936f22d@samersoff.net> Hello Aleksei, Looks good to me. -Dmitry On 08/23/2018 05:30 PM, Aleksei Voitylov wrote: > Hi, > > please review this patch which adds explicit barriers for C1/assembler > on ARM similar to how it was done on x86 and Aarch64: > > webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8209697.01/ > issue: https://bugs.openjdk.java.net/browse/JDK-8209697 > > here is the issue where this functionality was added on x86 and Aarch64: > https://bugs.openjdk.java.net/browse/JDK-8209668 > > Tested by running hotspot tests. > > Thanks, > > -Aleksei > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From david.holmes at oracle.com Mon Sep 17 03:32:57 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Sep 2018 13:32:57 +1000 Subject: Compile error in codeBlob.cpp when building JDK-11 for Windows-32 In-Reply-To: <5233640d-ff34-a591-2e6c-a4f50ee4baa6@oracle.com> References: <5044cb6a-8c28-752d-5fbd-5e4f73a937d8@synedra.com> <5233640d-ff34-a591-2e6c-a4f50ee4baa6@oracle.com> Message-ID: <8ea3b1c0-4d3e-7321-e94f-c0e8141c9730@oracle.com> We've seen this problem before: https://bugs.openjdk.java.net/browse/JDK-8196880 As Magnus noted Oracle doesn't support 32-bit builds any more, and as far as I can see no-one does. AdoptOpenJDK doesn't. But as long as the code remains we can fix issues if they are raised. I've filed: https://bugs.openjdk.java.net/browse/JDK-8210803 Cheers, David On 14/09/2018 6:37 PM, Magnus Ihse Bursie wrote: > > On 2018-09-14 10:03, Robert Lichtenberger wrote: >> I have tried to build a Windows 32-bit JDK-11. While I was successful in >> building a 64-bit Windows JDK, the attempt for 32-bit failed: >> >> Here's what I did: >> >> $ bash configure --with-boot-jdk=/cygdrive/c/jdk-10.0.2 >> --disable-warnings-as-errors --with-target-bits=32 >> ... >> >> ==================================================== >> The existing configuration has been successfully updated in >> /cygdrive/c/jdk/jdk11/build/windows-x86-normal-server-release >> using configure arguments '--with-boot-jdk=/cygdrive/c/jdk-10.0.2 >> --disable-warnings-as-errors --with-target-bits=32'. >> >> Configuration summary: >> * Debug level:??? release >> * HS debug level: product >> * JVM variants:?? server >> * JVM features:?? server: 'cds cmsgc compiler1 compiler2 epsilongc g1gc >> jfr jni-check jvmti management nmt parallelgc serialgc services >> vm-structs' >> * OpenJDK target: OS: windows, CPU architecture: x86, address length: 32 >> * Version string: 11-internal+0-adhoc.synedra.jdk11 (11-internal) >> >> Tools summary: >> * Environment:??? cygwin version 2.10.0(0.325/5/3) (root at >> /cygdrive/c/cygwin64) >> * Boot JDK:?????? openjdk version "10.0.2" 2018-07-17? OpenJDK Runtime >> Environment 18.3 (build 10.0.2+13)? OpenJDK 64-Bit Server VM 18.3 (build >> 10.0.2+13, mixed mode)?? (at /cygdrive/c/jdk-10.0.2) >> * Toolchain:????? microsoft (Microsoft Visual Studio 2017) >> * C Compiler:???? Version 19.15.26729 (at >> /cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl) >> >> * C++ Compiler:?? Version 19.15.26729 (at >> /cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl) >> >> >> Build performance summary: >> * Cores to use:?? 2 >> * Memory limit:?? 16383 MB >> ... >> >> $ time make CONF=windows-x86-normal-server-release all >> Building target 'all' in configuration >> 'windows-x86-normal-server-release' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(229): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(250): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(289): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(312): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(333): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(372): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(437): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(470): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(506): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(541): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> make[3]: *** [lib/CompileJvm.gmk:151: >> /cygdrive/c/jdk/jdk11/build/windows-x86-normal-server-release/hotspot/variant-server/libjvm/objs/codeBlob.obj] >> >> Error 1 >> make[2]: *** [make/Main.gmk:257: hotspot-server-libs] Error 2 >> make[2]: *** Waiting for unfinished jobs.... >> >> ERROR: Build failed for target 'all' in configuration >> 'windows-x86-normal-server-release' (exit code 2) > > This is most likely due to some issue on new/delete operators works, > which are undergoing changes in the language. That is, a code issue on > hotspot. > > I don't know why you are seeing this on windows-x86 though. > https://msdn.microsoft.com/en-us/library/mt723604.aspx suggests that you > can disable this check by -Zc:sizedDealloc-. Do this by "configure > --with-extra-cxxflags=Zc:sizedDealloc-". > >> On a meta-level: Is a JDK for Windows 32-bit just built no longer or is >> it completely abandoned as a platform? > > Oracle is not building 32-bit Windows regularly, and I don't think > anyone else is doing that. (Perhaps AdoptOpenJDK?) In such a scenario, > the code quickly bit rots. There has been no decision as of yet to > remove the code from the code base, but unless someone steps up to > maintain the code base, it's unlikely to survive in the long term. > > /Magnus From david.holmes at oracle.com Mon Sep 17 03:40:59 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Sep 2018 13:40:59 +1000 Subject: RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <5c39129b-94cd-ba43-5784-88ae6ad67ff9@redhat.com> References: <6775CB01-428C-4214-B722-FD21FCEF93F5@oracle.com> <0a663580-17ab-413c-416d-c3af4773d8e4@oracle.com> <7475c0ef-4b75-6130-f43f-63c2e3806ddb@oracle.com> <5c39129b-94cd-ba43-5784-88ae6ad67ff9@redhat.com> Message-ID: On 14/09/2018 7:05 PM, Andrew Haley wrote: > On 09/14/2018 01:10 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >> >> There's an initial partial webrev (mainly x86): >> >> http://cr.openjdk.java.net/~dholmes/8188764/webrev/ > > AArch64 part looks good. Thanks Andrew. I'll send out actually RFR shortly. David From david.holmes at oracle.com Mon Sep 17 03:55:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Sep 2018 13:55:32 +1000 Subject: RFR (L) 8210481: Remove #ifdef cplusplus from vmTestbase In-Reply-To: <5301110A-52D0-4EAD-B18D-CC86866539C7@oracle.com> References: <5301110A-52D0-4EAD-B18D-CC86866539C7@oracle.com> Message-ID: +1 from me. Thanks, David On 15/09/2018 3:48 AM, Igor Ignatyev wrote: > Hi JC, > > looks good to me. > > (cc'ing hotspot-dev alias as it affects other teams' tests) > > -- Igor > >> On Sep 14, 2018, at 9:50 AM, JC Beyler wrote: >> >> Hi all, >> >> Could I get a review for the following webrev: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210481 >> >> @Alex: I know we had said generally 50 files max but this one is really straight forward; if you still prefer 50 files, let me know and I'll cut it up into chunks. >> >> @all: A big webrev this time, to which I apologize but it is the last macro removal webrev from me in a while (there still is https://bugs.openjdk.java.net/browse/JDK-8210728 but I'm giving everyone a rest on macro removal and will work on a few code refactoring I promised to do ;-)). >> >> To perhaps help reviewing it: >> This webrev removes two #ifdef per file touched: >> >> -#ifdef __cplusplus >> extern "C" { >> -#endif >> >> and >> >> -#ifdef __cplusplus >> } >> -#endif >> >> -> The patch only has deletions (4 per file), no insertions >> -> I double checked that all files only have exactly those removals and no other removals EXCEPT: >> http://cr.openjdk.java.net/~jcbeyler/8210481/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h.udiff.html >> which is still defining the NSK_STUB macros but was doing it for C/C++ styles. >> -> Last easier check for reviewers: >> - Look for deletions but that are not exactly "-#endif" or "-#ifdef __cplusplus" >> grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v "^-#ifdef __cplusplus$" >> >> That command provides only the lines from the nsk_tools.h file: >> $ grep "^-[^-]" jdk12-jvmti12.patch | grep -v "^-#endif$" | grep -v "^-#ifdef __cplusplus$" >> -#define NSK_CPP_STUB1(Func,env) (*env)->Func(env) >> -#define NSK_CPP_STUB2(Func,env,a) (*env)->Func(env,a) >> -#define NSK_CPP_STUB3(Func,env,a,b) (*env)->Func(env,a,b) >> -#define NSK_CPP_STUB4(Func,env,a,b,c) (*env)->Func(env,a,b,c) >> -#define NSK_CPP_STUB5(Func,env,a,b,c,d) (*env)->Func(env,a,b,c,d) >> -#define NSK_CPP_STUB6(Func,env,a,b,c,d,e) (*env)->Func(env,a,b,c,d,e) >> -#define NSK_CPP_STUB7(Func,env,a,b,c,d,e,f) (*env)->Func(env,a,b,c,d,e,f) >> -#define NSK_CPP_STUB8(Func,env,a,b,c,d,e,f,g) (*env)->Func(env,a,b,c,d,e,f,g) >> -#define NSK_CPP_STUB9(Func,env,a,b,c,d,e,f,g,h) (*env)->Func(env,a,b,c,d,e,f,g,h) >> -#ifndef NSK_CPP_STUBS_ENFORCE_C >> -#undef NSK_CPP_STUB1 >> -#undef NSK_CPP_STUB2 >> -#undef NSK_CPP_STUB3 >> -#undef NSK_CPP_STUB4 >> -#undef NSK_CPP_STUB5 >> -#undef NSK_CPP_STUB6 >> -#undef NSK_CPP_STUB7 >> -#undef NSK_CPP_STUB8 >> -#undef NSK_CPP_STUB9 >> >> Thanks for the reviews, >> Jc > From martin.doerr at sap.com Mon Sep 17 04:56:29 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 17 Sep 2018 04:56:29 +0000 Subject: Compile error in codeBlob.cpp when building JDK-11 for Windows-32 In-Reply-To: <8ea3b1c0-4d3e-7321-e94f-c0e8141c9730@oracle.com> References: <5044cb6a-8c28-752d-5fbd-5e4f73a937d8@synedra.com> <5233640d-ff34-a591-2e6c-a4f50ee4baa6@oracle.com> <8ea3b1c0-4d3e-7321-e94f-c0e8141c9730@oracle.com> Message-ID: <8ba113f30554458ba66d3d43c978e7f9@sap.com> Hi Robert, we have successfully built jdk11 with Visual Studio 2013 (with --disable-warnings-as-errors): "configure: Using microsoft C compiler version 18.00.40629 [Microsoft (R) C/C++ Optimizing Compiler Version 18.00.40629 for x86]" Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of David Holmes Sent: Montag, 17. September 2018 05:33 To: Magnus Ihse Bursie ; Robert Lichtenberger Cc: hotspot-dev developers Subject: Re: Compile error in codeBlob.cpp when building JDK-11 for Windows-32 We've seen this problem before: https://bugs.openjdk.java.net/browse/JDK-8196880 As Magnus noted Oracle doesn't support 32-bit builds any more, and as far as I can see no-one does. AdoptOpenJDK doesn't. But as long as the code remains we can fix issues if they are raised. I've filed: https://bugs.openjdk.java.net/browse/JDK-8210803 Cheers, David On 14/09/2018 6:37 PM, Magnus Ihse Bursie wrote: > > On 2018-09-14 10:03, Robert Lichtenberger wrote: >> I have tried to build a Windows 32-bit JDK-11. While I was successful in >> building a 64-bit Windows JDK, the attempt for 32-bit failed: >> >> Here's what I did: >> >> $ bash configure --with-boot-jdk=/cygdrive/c/jdk-10.0.2 >> --disable-warnings-as-errors --with-target-bits=32 >> ... >> >> ==================================================== >> The existing configuration has been successfully updated in >> /cygdrive/c/jdk/jdk11/build/windows-x86-normal-server-release >> using configure arguments '--with-boot-jdk=/cygdrive/c/jdk-10.0.2 >> --disable-warnings-as-errors --with-target-bits=32'. >> >> Configuration summary: >> * Debug level:??? release >> * HS debug level: product >> * JVM variants:?? server >> * JVM features:?? server: 'cds cmsgc compiler1 compiler2 epsilongc g1gc >> jfr jni-check jvmti management nmt parallelgc serialgc services >> vm-structs' >> * OpenJDK target: OS: windows, CPU architecture: x86, address length: 32 >> * Version string: 11-internal+0-adhoc.synedra.jdk11 (11-internal) >> >> Tools summary: >> * Environment:??? cygwin version 2.10.0(0.325/5/3) (root at >> /cygdrive/c/cygwin64) >> * Boot JDK:?????? openjdk version "10.0.2" 2018-07-17? OpenJDK Runtime >> Environment 18.3 (build 10.0.2+13)? OpenJDK 64-Bit Server VM 18.3 (build >> 10.0.2+13, mixed mode)?? (at /cygdrive/c/jdk-10.0.2) >> * Toolchain:????? microsoft (Microsoft Visual Studio 2017) >> * C Compiler:???? Version 19.15.26729 (at >> /cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl) >> >> * C++ Compiler:?? Version 19.15.26729 (at >> /cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl) >> >> >> Build performance summary: >> * Cores to use:?? 2 >> * Memory limit:?? 16383 MB >> ... >> >> $ time make CONF=windows-x86-normal-server-release all >> Building target 'all' in configuration >> 'windows-x86-normal-server-release' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(229): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(250): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(289): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(312): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(333): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(372): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(437): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(470): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(506): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(541): error C2956: >> sized deallocation function 'operator delete(void*, size_t)' would be >> chosen as placement deallocation function. >> predefined C++ types (compiler internal)(44): note: see declaration of >> 'operator delete' >> make[3]: *** [lib/CompileJvm.gmk:151: >> /cygdrive/c/jdk/jdk11/build/windows-x86-normal-server-release/hotspot/variant-server/libjvm/objs/codeBlob.obj] >> >> Error 1 >> make[2]: *** [make/Main.gmk:257: hotspot-server-libs] Error 2 >> make[2]: *** Waiting for unfinished jobs.... >> >> ERROR: Build failed for target 'all' in configuration >> 'windows-x86-normal-server-release' (exit code 2) > > This is most likely due to some issue on new/delete operators works, > which are undergoing changes in the language. That is, a code issue on > hotspot. > > I don't know why you are seeing this on windows-x86 though. > https://msdn.microsoft.com/en-us/library/mt723604.aspx suggests that you > can disable this check by -Zc:sizedDealloc-. Do this by "configure > --with-extra-cxxflags=Zc:sizedDealloc-". > >> On a meta-level: Is a JDK for Windows 32-bit just built no longer or is >> it completely abandoned as a platform? > > Oracle is not building 32-bit Windows regularly, and I don't think > anyone else is doing that. (Perhaps AdoptOpenJDK?) In such a scenario, > the code quickly bit rots. There has been no decision as of yet to > remove the code from the code base, but unless someone steps up to > maintain the code base, it's unlikely to survive in the long term. > > /Magnus From david.holmes at oracle.com Mon Sep 17 05:08:51 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Sep 2018 15:08:51 +1000 Subject: RFR(S): 8210676: Remove some unused Label variables In-Reply-To: References: <6D50BF19-4A15-432F-A0EF-FC777113F88E@oracle.com> <4e46fa33-188f-999b-1711-faed4b137f8b@oracle.com> Message-ID: <2dd4b098-223e-68d0-87d2-300ec87d7aff@oracle.com> On 14/09/2018 10:44 PM, coleen.phillimore at oracle.com wrote: > On 9/13/18 9:38 PM, David Holmes wrote: >> On 14/09/2018 11:22 AM, Mikael Vidstedt wrote: >>> >>>> On Sep 13, 2018, at 6:17 PM, David Holmes >>>> wrote: >>>> >>>> Looks good - though the proof is in the building of course. >>>> >>>> The debug-only use of notDouble in >>>> src/hotspot/cpu/x86/templateTable_x86.cpp seems somewhat odd. >>> >>> Would you prefer to see it declared next to the other labels, but >>> guarded with ASSERT? >> >> No what you have is fine. I'm just curious about why the double case >> is only examined in a non-product build ?? > > The notDouble label is sort of a switch default label, which we only > care about in debug.? Otherwise it falls off into code below. Okay - thanks Coleen. David > thanks, > Coleen >> >> David >> >>> Cheers, >>> Mikael >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 14/09/2018 9:03 AM, Mikael Vidstedt wrote: >>>>> Please review this change which removes a bunch of unused Label >>>>> variables. Would appreciate some help from aarch64/ppc/s390x folks >>>>> to verify it! >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8210676 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ >>>>> >>>>> * Background (from bug) >>>>> [~dholmes] noticed during the code review of JDK-8210381 that the >>>>> "Label Egress" variable in macroAssembler_sparc.cpp was unused. It >>>>> and other unused labels like it should be removed. >>>>> * About the change >>>>> I have *not* tried to find and remove *all* unused Label variables, >>>>> because that turns out to be much harder than it might seem. I may >>>>> or may not follow up on this work to remove additional unused Label >>>>> variables later, but before that I?m investigating removal of other >>>>> unused variables in general. Meanwhile I like to think that this is >>>>> a reasonable cleanup anyway. >>>>> * Testing >>>>> tier1 build&test passes. >>>>> Cheers, >>>>> Mikael >>> > From martin.doerr at sap.com Mon Sep 17 06:59:12 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 17 Sep 2018 06:59:12 +0000 Subject: RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: <6775CB01-428C-4214-B722-FD21FCEF93F5@oracle.com> <0a663580-17ab-413c-416d-c3af4773d8e4@oracle.com> <7475c0ef-4b75-6130-f43f-63c2e3806ddb@oracle.com> <5c39129b-94cd-ba43-5784-88ae6ad67ff9@redhat.com> Message-ID: <0fec282d755e4afd8eb68c0cc73cdc98@sap.com> PPC and s390 parts look good, too. Thanks, Martin -----Original Message----- From: hotspot-dev On Behalf Of David Holmes Sent: Montag, 17. September 2018 05:41 To: Andrew Haley ; hotspot-dev developers Subject: Re: RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds On 14/09/2018 7:05 PM, Andrew Haley wrote: > On 09/14/2018 01:10 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >> >> There's an initial partial webrev (mainly x86): >> >> http://cr.openjdk.java.net/~dholmes/8188764/webrev/ > > AArch64 part looks good. Thanks Andrew. I'll send out actually RFR shortly. David From david.holmes at oracle.com Mon Sep 17 07:16:07 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Sep 2018 17:16:07 +1000 Subject: RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <0fec282d755e4afd8eb68c0cc73cdc98@sap.com> References: <6775CB01-428C-4214-B722-FD21FCEF93F5@oracle.com> <0a663580-17ab-413c-416d-c3af4773d8e4@oracle.com> <7475c0ef-4b75-6130-f43f-63c2e3806ddb@oracle.com> <5c39129b-94cd-ba43-5784-88ae6ad67ff9@redhat.com> <0fec282d755e4afd8eb68c0cc73cdc98@sap.com> Message-ID: <98c0a7e7-c9a5-a3e0-b5ee-7d6cafd4d871@oracle.com> Thanks Martin. RFR coming soon. David On 17/09/2018 4:59 PM, Doerr, Martin wrote: > PPC and s390 parts look good, too. > > Thanks, > Martin > > -----Original Message----- > From: hotspot-dev On Behalf Of David Holmes > Sent: Montag, 17. September 2018 05:41 > To: Andrew Haley ; hotspot-dev developers > Subject: Re: RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds > > On 14/09/2018 7:05 PM, Andrew Haley wrote: >> On 09/14/2018 01:10 AM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >>> >>> There's an initial partial webrev (mainly x86): >>> >>> http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >> >> AArch64 part looks good. > > Thanks Andrew. I'll send out actually RFR shortly. > > David > From rkennke at redhat.com Mon Sep 17 08:28:13 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 17 Sep 2018 10:28:13 +0200 Subject: [12] RFR (S): 8210465: ARM: Object equals abstraction for BarrierSetAssembler In-Reply-To: References: <44a15a18-04b6-f0d1-97a6-5c4552c9af3a@bell-sw.com> Message-ID: > PS: > > BarrierSetAssembler* bs = > BarrierSet::barrier_set()->barrier_set_assembler(); > bs->obj_equals(this, obj1, obj2); > > Just to emit cmp reg, reg looks a bit overkilling for me. This is intentional. GCs might want to override what they do for comparing objects. For example, Shenandoah does that. Thanks, Roman > On 09/14/2018 02:54 PM, Aleksei Voitylov wrote: >> Hi, >> >> please review this patch which follows the changes on x86 and AARCH64: >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8210465 >> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210465.01/ >> >> Tested by HotSpot regression tests. >> >> Original issue for x86 and AARCH64: >> https://bugs.openjdk.java.net/browse/JDK-8203157 >> >> Thanks, >> >> -Aleksei >> > > From martijnverburg at gmail.com Mon Sep 17 09:14:38 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 17 Sep 2018 10:14:38 +0100 Subject: Compile error in codeBlob.cpp when building JDK-11 for Windows-32 In-Reply-To: <8ea3b1c0-4d3e-7321-e94f-c0e8141c9730@oracle.com> References: <5044cb6a-8c28-752d-5fbd-5e4f73a937d8@synedra.com> <5233640d-ff34-a591-2e6c-a4f50ee4baa6@oracle.com> <8ea3b1c0-4d3e-7321-e94f-c0e8141c9730@oracle.com> Message-ID: Hi all, Quik note inline. On Mon, 17 Sep 2018 at 04:33, David Holmes wrote: > > > We've seen this problem before: > > https://bugs.openjdk.java.net/browse/JDK-8196880 > > As Magnus noted Oracle doesn't support 32-bit builds any more, and as > far as I can see no-one does. AdoptOpenJDK doesn't. > Adopt does now produce win32 builds and we have someone willing to put in the work to try and maintain that port, but Adopt doesn't provide commercial support no. We're currently producing 8 builds but will start walking up versions this week. Cheers, Martijn > But as long as the code remains we can fix issues if they are raised. > I've filed: > > https://bugs.openjdk.java.net/browse/JDK-8210803 > > Cheers, > David > > On 14/09/2018 6:37 PM, Magnus Ihse Bursie wrote: > > > > On 2018-09-14 10:03, Robert Lichtenberger wrote: > >> I have tried to build a Windows 32-bit JDK-11. While I was successful in > >> building a 64-bit Windows JDK, the attempt for 32-bit failed: > >> > >> Here's what I did: > >> > >> $ bash configure --with-boot-jdk=/cygdrive/c/jdk-10.0.2 > >> --disable-warnings-as-errors --with-target-bits=32 > >> ... > >> > >> ==================================================== > >> The existing configuration has been successfully updated in > >> /cygdrive/c/jdk/jdk11/build/windows-x86-normal-server-release > >> using configure arguments '--with-boot-jdk=/cygdrive/c/jdk-10.0.2 > >> --disable-warnings-as-errors --with-target-bits=32'. > >> > >> Configuration summary: > >> * Debug level: release > >> * HS debug level: product > >> * JVM variants: server > >> * JVM features: server: 'cds cmsgc compiler1 compiler2 epsilongc g1gc > >> jfr jni-check jvmti management nmt parallelgc serialgc services > >> vm-structs' > >> * OpenJDK target: OS: windows, CPU architecture: x86, address length: 32 > >> * Version string: 11-internal+0-adhoc.synedra.jdk11 (11-internal) > >> > >> Tools summary: > >> * Environment: cygwin version 2.10.0(0.325/5/3) (root at > >> /cygdrive/c/cygwin64) > >> * Boot JDK: openjdk version "10.0.2" 2018-07-17 OpenJDK Runtime > >> Environment 18.3 (build 10.0.2+13) OpenJDK 64-Bit Server VM 18.3 (build > >> 10.0.2+13, mixed mode) (at /cygdrive/c/jdk-10.0.2) > >> * Toolchain: microsoft (Microsoft Visual Studio 2017) > >> * C Compiler: Version 19.15.26729 (at > >> > /cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl) > > >> > >> * C++ Compiler: Version 19.15.26729 (at > >> > /cygdrive/c/progra~2/micros~1/2017/commun~1/vc/tools/msvc/1415~1.267/bin/hostx86/x86/cl) > > >> > >> > >> Build performance summary: > >> * Cores to use: 2 > >> * Memory limit: 16383 MB > >> ... > >> > >> $ time make CONF=windows-x86-normal-server-release all > >> Building target 'all' in configuration > >> 'windows-x86-normal-server-release' > >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(229): error C2956: > >> sized deallocation function 'operator delete(void*, size_t)' would be > >> chosen as placement deallocation function. > >> predefined C++ types (compiler internal)(44): note: see declaration of > >> 'operator delete' > >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(250): error C2956: > >> sized deallocation function 'operator delete(void*, size_t)' would be > >> chosen as placement deallocation function. > >> predefined C++ types (compiler internal)(44): note: see declaration of > >> 'operator delete' > >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(289): error C2956: > >> sized deallocation function 'operator delete(void*, size_t)' would be > >> chosen as placement deallocation function. > >> predefined C++ types (compiler internal)(44): note: see declaration of > >> 'operator delete' > >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(312): error C2956: > >> sized deallocation function 'operator delete(void*, size_t)' would be > >> chosen as placement deallocation function. > >> predefined C++ types (compiler internal)(44): note: see declaration of > >> 'operator delete' > >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(333): error C2956: > >> sized deallocation function 'operator delete(void*, size_t)' would be > >> chosen as placement deallocation function. > >> predefined C++ types (compiler internal)(44): note: see declaration of > >> 'operator delete' > >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(372): error C2956: > >> sized deallocation function 'operator delete(void*, size_t)' would be > >> chosen as placement deallocation function. > >> predefined C++ types (compiler internal)(44): note: see declaration of > >> 'operator delete' > >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(437): error C2956: > >> sized deallocation function 'operator delete(void*, size_t)' would be > >> chosen as placement deallocation function. > >> predefined C++ types (compiler internal)(44): note: see declaration of > >> 'operator delete' > >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(470): error C2956: > >> sized deallocation function 'operator delete(void*, size_t)' would be > >> chosen as placement deallocation function. > >> predefined C++ types (compiler internal)(44): note: see declaration of > >> 'operator delete' > >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(506): error C2956: > >> sized deallocation function 'operator delete(void*, size_t)' would be > >> chosen as placement deallocation function. > >> predefined C++ types (compiler internal)(44): note: see declaration of > >> 'operator delete' > >> c:/jdk/jdk11/src/hotspot/share/code/codeBlob.cpp(541): error C2956: > >> sized deallocation function 'operator delete(void*, size_t)' would be > >> chosen as placement deallocation function. > >> predefined C++ types (compiler internal)(44): note: see declaration of > >> 'operator delete' > >> make[3]: *** [lib/CompileJvm.gmk:151: > >> > /cygdrive/c/jdk/jdk11/build/windows-x86-normal-server-release/hotspot/variant-server/libjvm/objs/codeBlob.obj] > > >> > >> Error 1 > >> make[2]: *** [make/Main.gmk:257: hotspot-server-libs] Error 2 > >> make[2]: *** Waiting for unfinished jobs.... > >> > >> ERROR: Build failed for target 'all' in configuration > >> 'windows-x86-normal-server-release' (exit code 2) > > > > This is most likely due to some issue on new/delete operators works, > > which are undergoing changes in the language. That is, a code issue on > > hotspot. > > > > I don't know why you are seeing this on windows-x86 though. > > https://msdn.microsoft.com/en-us/library/mt723604.aspx suggests that > you > > can disable this check by -Zc:sizedDealloc-. Do this by "configure > > --with-extra-cxxflags=Zc:sizedDealloc-". > > > >> On a meta-level: Is a JDK for Windows 32-bit just built no longer or is > >> it completely abandoned as a platform? > > > > Oracle is not building 32-bit Windows regularly, and I don't think > > anyone else is doing that. (Perhaps AdoptOpenJDK?) In such a scenario, > > the code quickly bit rots. There has been no decision as of yet to > > remove the code from the code base, but unless someone steps up to > > maintain the code base, it's unlikely to survive in the long term. > > > > /Magnus > From aleksei.voitylov at bell-sw.com Mon Sep 17 09:51:12 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 17 Sep 2018 12:51:12 +0300 Subject: [12] RFR (S): 8210465: ARM: Object equals abstraction for BarrierSetAssembler In-Reply-To: References: <44a15a18-04b6-f0d1-97a6-5c4552c9af3a@bell-sw.com> Message-ID: <0bcd903f-9eaa-3c13-177b-444d2ccd6d29@bell-sw.com> Roman, Dmitry, thank you for review! -Aleksei On 17/09/2018 11:28, Roman Kennke wrote: >> PS: >> >> BarrierSetAssembler* bs = >> BarrierSet::barrier_set()->barrier_set_assembler(); >> bs->obj_equals(this, obj1, obj2); >> >> Just to emit cmp reg, reg looks a bit overkilling for me. > This is intentional. GCs might want to override what they do for > comparing objects. For example, Shenandoah does that. > > Thanks, > Roman > > >> On 09/14/2018 02:54 PM, Aleksei Voitylov wrote: >>> Hi, >>> >>> please review this patch which follows the changes on x86 and AARCH64: >>> >>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8210465 >>> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210465.01/ >>> >>> Tested by HotSpot regression tests. >>> >>> Original issue for x86 and AARCH64: >>> https://bugs.openjdk.java.net/browse/JDK-8203157 >>> >>> Thanks, >>> >>> -Aleksei >>> >> > From coleen.phillimore at oracle.com Mon Sep 17 12:05:52 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 17 Sep 2018 08:05:52 -0400 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> Message-ID: <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> On 9/14/18 4:01 PM, dean.long at oracle.com wrote: > Hi Coleen.? In the bug you asked: > > > Why can't we just push rdi and rsi to the stack and restore them? > This code appears to be leaf code so shouldn't care about stack format > > Did that ever get answered?? If there is concern about the pushes and > pops canceling out at the end, you could always reserve the stack > space at the beginning, after > > __ enter(); > > and then setup_arg_regs/restore_arg_regs would not need to adjust the > stack pointer. The reason I didn't do this is that I couldn't get it to work for all the various call sites.? Also, the barrier code is going to need the thread register sometimes which wasn't available.? So I went with this.? I'm somewhat unclear with how this is called from the c2 code.? If you want to try this solution, I should probably give up and reassign it to compiler. thanks, coleen > > dl > > On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote: >> Summary: Save windows 64 callee saved registers rsi, rdi to Thread, >> save r15, also callee saved to r9 >> >> This is done for generated stubs that do arraycopy that need GC >> barrier code because GC assumes that r10 is scratch, since it's >> defined as rscratch1.? See bug for more details.? Thanks Erik for >> your help and the diagnosis. >> >> Tested with mach5 hs-tier1-7.? We don't have a reproduceable test case. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8203466.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8203466 >> >> Thanks, >> Coleen >> > From sgehwolf at redhat.com Mon Sep 17 13:48:54 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 17 Sep 2018 15:48:54 +0200 Subject: [8u] RFR: 8207057: No debug info for assembler files Message-ID: <8b0187049cd0b83b4ed69f45dc002dcd47cb16f9.camel@redhat.com> Hi, Please review this 8u backport of JDK-8207057 which adds debug info when assembling assembler files. The build system changed between 9+ and 8u, so it's an independent patch from JDK 12's version. Bug: https://bugs.openjdk.java.net/browse/JDK-8207057 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8207057/jdk8/01/ Testing: Debugging of assembler files in gdb. Eyeballing compile logs. Thoughts? Thanks, Severin From bob.vandette at oracle.com Mon Sep 17 16:20:00 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 17 Sep 2018 12:20:00 -0400 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two Message-ID: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Please review the changes related to JEP 340 which remove the second 64-bit ARM port from the JDK. http://cr.openjdk.java.net/~bobv/8209093/webrev.01 I?ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. I?ve run specJVM98 on the three 32-bit ARM VMs. I also verified that Linux x64 builds. Bob. From erik.joelsson at oracle.com Mon Sep 17 16:22:39 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 17 Sep 2018 09:22:39 -0700 Subject: [8u] RFR: 8207057: No debug info for assembler files In-Reply-To: <8b0187049cd0b83b4ed69f45dc002dcd47cb16f9.camel@redhat.com> References: <8b0187049cd0b83b4ed69f45dc002dcd47cb16f9.camel@redhat.com> Message-ID: <2949c856-fa8b-287e-2fd4-1232aa3a4506@oracle.com> Looks ok to me. /Erik On 2018-09-17 06:48, Severin Gehwolf wrote: > Hi, > > Please review this 8u backport of JDK-8207057 which adds debug info > when assembling assembler files. The build system changed between 9+ > and 8u, so it's an independent patch from JDK 12's version. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8207057 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8207057/jdk8/01/ > > Testing: Debugging of assembler files in gdb. Eyeballing compile logs. > > Thoughts? > > Thanks, > Severin > From vladimir.kozlov at oracle.com Mon Sep 17 17:00:45 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Sep 2018 10:00:45 -0700 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: CCing to build-dev and aarch64-port. I looked through changes and they seem fine. Thanks, Vladimir On 9/17/18 9:20 AM, Bob Vandette wrote: > Please review the changes related to JEP 340 which remove the second 64-bit ARM port > from the JDK. > > http://cr.openjdk.java.net/~bobv/8209093/webrev.01 > > I?ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. > I?ve run specJVM98 on the three 32-bit ARM VMs. > > I also verified that Linux x64 builds. > > Bob. > > From erik.joelsson at oracle.com Mon Sep 17 17:25:59 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 17 Sep 2018 10:25:59 -0700 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: <1c9699c5-ca62-2637-fe8e-2d9f1413047f@oracle.com> Build changes look ok. /Erik On 2018-09-17 10:00, Vladimir Kozlov wrote: > CCing to build-dev and aarch64-port. > > I looked through changes and they seem fine. > > Thanks, > Vladimir > > On 9/17/18 9:20 AM, Bob Vandette wrote: >> Please review the changes related to JEP 340 which remove the second >> 64-bit ARM port >> from the JDK. >> >> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >> >> I?ve testing building the remaining 32 and 64 bit ARM ports including >> the minimal, client and server VMs. >> I?ve run specJVM98 on the three 32-bit ARM VMs. >> >> I also verified that Linux x64 builds. >> >> Bob. >> >> From shade at redhat.com Mon Sep 17 17:49:52 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Sep 2018 19:49:52 +0200 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: On 09/17/2018 07:00 PM, Vladimir Kozlov wrote: > On 9/17/18 9:20 AM, Bob Vandette wrote: >> Please review the changes related to JEP 340 which remove the second >> 64-bit ARM port from the JDK.>> >> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 I read through the webrev, and it seems to be the clean removal. It also feels very satisfying to drop 15 KLOC of ifdef-ed code. Minor nits: *) In src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp and src/hotspot/cpu/arm/interp_masm_arm.cpp we have "#if defined(ASSERT)", which cab be just "#ifdef ASSERT" now *) Ditto in src/hotspot/cpu/arm/jniFastGetField_arm.cpp we have "#if defined(__ABI_HARD__)" *) In src/hotspot/cpu/arm/macroAssembler_arm.hpp, the comment below seems to apply to AArch64 only. Yet, only the first line of the comment is removed. I think we should instead convert that comment into "TODO:" mentioning this might be revised after AArch64 removal? 992 void branch_if_negative_32(Register r, Label& L) { 993 // Note about branch_if_negative_32() / branch_if_any_negative_32() implementation for AArch64: 994 // tbnz is not used instead of tst & b.mi because destination may be out of tbnz range (+-32KB) 995 // since these methods are used in LIR_Assembler::emit_arraycopy() to jump to stub entry. 996 tst_32(r, r); 997 b(L, mi); 998 } *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, lines L1204..1205, L1435..1436 can be merged together: 1203 // Generate the inner loop for shifted forward array copy (unaligned copy). 1204 // It can be used when bytes_per_count < wordSize, i.e. 1205 // byte/short copy 1434 // Generate the inner loop for shifted backward array copy (unaligned copy). 1435 // It can be used when bytes_per_count < wordSize, i.e. 1436 // byte/short copy *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, the comment changed incorrectly around L3363? - // R4 (AArch64) / SP[0] (32-bit ARM) - element count (32-bit int) + // R4 - element count (32-bit int) *) In src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp, "R4"/"R5" comments are missing: - const Register Rsig_handler = AARCH64_ONLY(R21) NOT_AARCH64(Rtmp_save0 /* R4 */); - const Register Rnative_code = AARCH64_ONLY(R22) NOT_AARCH64(Rtmp_save1 /* R5 */); + const Register Rsig_handler = Rtmp_save0; + const Register Rnative_code = Rtmp_save1; Thanks, -Aleksey From bob.vandette at oracle.com Mon Sep 17 18:15:10 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 17 Sep 2018 14:15:10 -0400 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: <1C1771D3-07BF-45A5-AE5A-578BE9392CAE@oracle.com> Thanks for the detailed review Aleksey. I took care of these. Bob. > On Sep 17, 2018, at 1:49 PM, Aleksey Shipilev wrote: > > On 09/17/2018 07:00 PM, Vladimir Kozlov wrote: >> On 9/17/18 9:20 AM, Bob Vandette wrote: >>> Please review the changes related to JEP 340 which remove the second >>> 64-bit ARM port from the JDK.>> >>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 > > I read through the webrev, and it seems to be the clean removal. It also feels > very satisfying to drop 15 KLOC of ifdef-ed code. > > Minor nits: > > *) In src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp and > src/hotspot/cpu/arm/interp_masm_arm.cpp we have "#if defined(ASSERT)", which cab > be just "#ifdef ASSERT" now > > *) Ditto in src/hotspot/cpu/arm/jniFastGetField_arm.cpp we have "#if > defined(__ABI_HARD__)" > > *) In src/hotspot/cpu/arm/macroAssembler_arm.hpp, the comment below seems to > apply to AArch64 only. Yet, only the first line of the comment is removed. I > think we should instead convert that comment into "TODO:" mentioning this might > be revised after AArch64 removal? > > 992 void branch_if_negative_32(Register r, Label& L) { > 993 // Note about branch_if_negative_32() / branch_if_any_negative_32() > implementation for AArch64: > 994 // tbnz is not used instead of tst & b.mi because destination may be > out of tbnz range (+-32KB) > 995 // since these methods are used in LIR_Assembler::emit_arraycopy() to > jump to stub entry. > 996 tst_32(r, r); > 997 b(L, mi); > 998 } > > *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, lines L1204..1205, L1435..1436 > can be merged together: > > 1203 // Generate the inner loop for shifted forward array copy (unaligned copy). > 1204 // It can be used when bytes_per_count < wordSize, i.e. > 1205 // byte/short copy > > 1434 // Generate the inner loop for shifted backward array copy (unaligned copy). > 1435 // It can be used when bytes_per_count < wordSize, i.e. > 1436 // byte/short copy > > > *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, the comment changed > incorrectly around L3363? > > - // R4 (AArch64) / SP[0] (32-bit ARM) - element count (32-bit int) > + // R4 - element count (32-bit int) > > > *) In src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp, "R4"/"R5" > comments are missing: > > - const Register Rsig_handler = AARCH64_ONLY(R21) NOT_AARCH64(Rtmp_save0 /* > R4 */); > - const Register Rnative_code = AARCH64_ONLY(R22) NOT_AARCH64(Rtmp_save1 /* > R5 */); > + const Register Rsig_handler = Rtmp_save0; > + const Register Rnative_code = Rtmp_save1; > > Thanks, > -Aleksey > From dean.long at oracle.com Mon Sep 17 18:25:47 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 17 Sep 2018 11:25:47 -0700 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> Message-ID: Sure, go ahead :-) On 9/17/18 5:05 AM, coleen.phillimore at oracle.com wrote: > If you want to try this solution, I should probably give up and > reassign it to compiler. From dean.long at oracle.com Mon Sep 17 21:17:23 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 17 Sep 2018 14:17:23 -0700 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> Message-ID: <8154d8b1-f6f3-0f39-9f42-daebc628cf02@oracle.com> Can you move the JavaThread _WIN64 changes to thread_windows_x86.hpp? dl On 9/17/18 5:05 AM, coleen.phillimore at oracle.com wrote: > > > On 9/14/18 4:01 PM, dean.long at oracle.com wrote: >> Hi Coleen.? In the bug you asked: >> >> > Why can't we just push rdi and rsi to the stack and restore them? >> This code appears to be leaf code so shouldn't care about stack format >> >> Did that ever get answered?? If there is concern about the pushes and >> pops canceling out at the end, you could always reserve the stack >> space at the beginning, after >> >> __ enter(); >> >> and then setup_arg_regs/restore_arg_regs would not need to adjust the >> stack pointer. > > The reason I didn't do this is that I couldn't get it to work for all > the various call sites.? Also, the barrier code is going to need the > thread register sometimes which wasn't available.? So I went with > this.? I'm somewhat unclear with how this is called from the c2 code.? > If you want to try this solution, I should probably give up and > reassign it to compiler. > > thanks, > coleen > >> >> dl >> >> On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote: >>> Summary: Save windows 64 callee saved registers rsi, rdi to Thread, >>> save r15, also callee saved to r9 >>> >>> This is done for generated stubs that do arraycopy that need GC >>> barrier code because GC assumes that r10 is scratch, since it's >>> defined as rscratch1.? See bug for more details.? Thanks Erik for >>> your help and the diagnosis. >>> >>> Tested with mach5 hs-tier1-7.? We don't have a reproduceable test case. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8203466.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8203466 >>> >>> Thanks, >>> Coleen >>> >> > From mikael.vidstedt at oracle.com Mon Sep 17 22:42:32 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 17 Sep 2018 15:42:32 -0700 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: <6AD7825D-22D7-4C8E-9DE3-A3A395AA99EB@oracle.com> Looks good. Thanks for doing this! Cheers, Mikael > On Sep 17, 2018, at 9:20 AM, Bob Vandette wrote: > > Please review the changes related to JEP 340 which remove the second 64-bit ARM port > from the JDK. > > http://cr.openjdk.java.net/~bobv/8209093/webrev.01 > > I?ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. > I?ve run specJVM98 on the three 32-bit ARM VMs. > > I also verified that Linux x64 builds. > > Bob. > > From coleen.phillimore at oracle.com Mon Sep 17 23:47:43 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 17 Sep 2018 19:47:43 -0400 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: <8154d8b1-f6f3-0f39-9f42-daebc628cf02@oracle.com> References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> <8154d8b1-f6f3-0f39-9f42-daebc628cf02@oracle.com> Message-ID: <8680ff8e-dee6-dec1-060b-472278072652@oracle.com> On 9/17/18 5:17 PM, dean.long at oracle.com wrote: > Can you move the JavaThread _WIN64 changes to thread_windows_x86.hpp? Thanks for looking at this.? I moved it to the better place: http://cr.openjdk.java.net/~coleenp/8203466.02/webrev/index.html Retested with build and ran one test 100 times that failed once. Thanks, Coleen > > dl > > On 9/17/18 5:05 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 9/14/18 4:01 PM, dean.long at oracle.com wrote: >>> Hi Coleen.? In the bug you asked: >>> >>> > Why can't we just push rdi and rsi to the stack and restore them? >>> This code appears to be leaf code so shouldn't care about stack format >>> >>> Did that ever get answered?? If there is concern about the pushes >>> and pops canceling out at the end, you could always reserve the >>> stack space at the beginning, after >>> >>> __ enter(); >>> >>> and then setup_arg_regs/restore_arg_regs would not need to adjust >>> the stack pointer. >> >> The reason I didn't do this is that I couldn't get it to work for all >> the various call sites.? Also, the barrier code is going to need the >> thread register sometimes which wasn't available. So I went with >> this.? I'm somewhat unclear with how this is called from the c2 >> code.? If you want to try this solution, I should probably give up >> and reassign it to compiler. >> >> thanks, >> coleen >> >>> >>> dl >>> >>> On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Save windows 64 callee saved registers rsi, rdi to Thread, >>>> save r15, also callee saved to r9 >>>> >>>> This is done for generated stubs that do arraycopy that need GC >>>> barrier code because GC assumes that r10 is scratch, since it's >>>> defined as rscratch1.? See bug for more details. Thanks Erik for >>>> your help and the diagnosis. >>>> >>>> Tested with mach5 hs-tier1-7.? We don't have a reproduceable test >>>> case. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8203466.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8203466 >>>> >>>> Thanks, >>>> Coleen >>>> >>> >> > From dean.long at oracle.com Tue Sep 18 00:45:07 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 17 Sep 2018 17:45:07 -0700 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: <8680ff8e-dee6-dec1-060b-472278072652@oracle.com> References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> <8154d8b1-f6f3-0f39-9f42-daebc628cf02@oracle.com> <8680ff8e-dee6-dec1-060b-472278072652@oracle.com> Message-ID: <697ad3d3-3abc-3340-e150-b748d669ec00@oracle.com> Looks good. dl On 9/17/18 4:47 PM, coleen.phillimore at oracle.com wrote: > > > On 9/17/18 5:17 PM, dean.long at oracle.com wrote: >> Can you move the JavaThread _WIN64 changes to thread_windows_x86.hpp? > > Thanks for looking at this.? I moved it to the better place: > > http://cr.openjdk.java.net/~coleenp/8203466.02/webrev/index.html > > Retested with build and ran one test 100 times that failed once. > > Thanks, > Coleen > >> >> dl >> >> On 9/17/18 5:05 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 9/14/18 4:01 PM, dean.long at oracle.com wrote: >>>> Hi Coleen.? In the bug you asked: >>>> >>>> > Why can't we just push rdi and rsi to the stack and restore them? >>>> This code appears to be leaf code so shouldn't care about stack format >>>> >>>> Did that ever get answered?? If there is concern about the pushes >>>> and pops canceling out at the end, you could always reserve the >>>> stack space at the beginning, after >>>> >>>> __ enter(); >>>> >>>> and then setup_arg_regs/restore_arg_regs would not need to adjust >>>> the stack pointer. >>> >>> The reason I didn't do this is that I couldn't get it to work for >>> all the various call sites.? Also, the barrier code is going to need >>> the thread register sometimes which wasn't available. So I went with >>> this.? I'm somewhat unclear with how this is called from the c2 >>> code.? If you want to try this solution, I should probably give up >>> and reassign it to compiler. >>> >>> thanks, >>> coleen >>> >>>> >>>> dl >>>> >>>> On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Save windows 64 callee saved registers rsi, rdi to >>>>> Thread, save r15, also callee saved to r9 >>>>> >>>>> This is done for generated stubs that do arraycopy that need GC >>>>> barrier code because GC assumes that r10 is scratch, since it's >>>>> defined as rscratch1.? See bug for more details. Thanks Erik for >>>>> your help and the diagnosis. >>>>> >>>>> Tested with mach5 hs-tier1-7.? We don't have a reproduceable test >>>>> case. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8203466.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8203466 >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Tue Sep 18 01:02:02 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 17 Sep 2018 21:02:02 -0400 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: <697ad3d3-3abc-3340-e150-b748d669ec00@oracle.com> References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> <8154d8b1-f6f3-0f39-9f42-daebc628cf02@oracle.com> <8680ff8e-dee6-dec1-060b-472278072652@oracle.com> <697ad3d3-3abc-3340-e150-b748d669ec00@oracle.com> Message-ID: Thanks, Dean. Coleen On 9/17/18 8:45 PM, dean.long at oracle.com wrote: > Looks good. > > dl > > On 9/17/18 4:47 PM, coleen.phillimore at oracle.com wrote: >> >> >> On 9/17/18 5:17 PM, dean.long at oracle.com wrote: >>> Can you move the JavaThread _WIN64 changes to thread_windows_x86.hpp? >> >> Thanks for looking at this.? I moved it to the better place: >> >> http://cr.openjdk.java.net/~coleenp/8203466.02/webrev/index.html >> >> Retested with build and ran one test 100 times that failed once. >> >> Thanks, >> Coleen >> >>> >>> dl >>> >>> On 9/17/18 5:05 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 9/14/18 4:01 PM, dean.long at oracle.com wrote: >>>>> Hi Coleen.? In the bug you asked: >>>>> >>>>> > Why can't we just push rdi and rsi to the stack and restore >>>>> them? This code appears to be leaf code so shouldn't care about >>>>> stack format >>>>> >>>>> Did that ever get answered?? If there is concern about the pushes >>>>> and pops canceling out at the end, you could always reserve the >>>>> stack space at the beginning, after >>>>> >>>>> __ enter(); >>>>> >>>>> and then setup_arg_regs/restore_arg_regs would not need to adjust >>>>> the stack pointer. >>>> >>>> The reason I didn't do this is that I couldn't get it to work for >>>> all the various call sites.? Also, the barrier code is going to >>>> need the thread register sometimes which wasn't available. So I >>>> went with this.? I'm somewhat unclear with how this is called from >>>> the c2 code.? If you want to try this solution, I should probably >>>> give up and reassign it to compiler. >>>> >>>> thanks, >>>> coleen >>>> >>>>> >>>>> dl >>>>> >>>>> On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Save windows 64 callee saved registers rsi, rdi to >>>>>> Thread, save r15, also callee saved to r9 >>>>>> >>>>>> This is done for generated stubs that do arraycopy that need GC >>>>>> barrier code because GC assumes that r10 is scratch, since it's >>>>>> defined as rscratch1.? See bug for more details. Thanks Erik for >>>>>> your help and the diagnosis. >>>>>> >>>>>> Tested with mach5 hs-tier1-7.? We don't have a reproduceable test >>>>>> case. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8203466.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8203466 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>> >>>> >>> >> > From david.holmes at oracle.com Tue Sep 18 02:53:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Sep 2018 12:53:19 +1000 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: Hi Bob, On 18/09/2018 2:20 AM, Bob Vandette wrote: > Please review the changes related to JEP 340 which remove the second 64-bit ARM port > from the JDK. > > http://cr.openjdk.java.net/~bobv/8209093/webrev.01 > > I?ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. > I?ve run specJVM98 on the three 32-bit ARM VMs. Did you test all the ARM related abi-profiles? It seems to me they were only for Oracle's ARM32 port and may have never been used otherwise. I would have expected all that stuff to be removed. Cheers, David > I also verified that Linux x64 builds. > > Bob. > > From david.holmes at oracle.com Tue Sep 18 05:32:20 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Sep 2018 15:32:20 +1000 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ As previously discussed in the RFC thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html this change obsoletes the AssumeMP flag and removes the bulk of the logic that is conditional on os::is_MP() as follows: 1. to gate the introduction of MP-specific features, notably memory barriers The is_MP check is removed and we will always issue memory barriers or pre-pend lock prefix etc. 2. to align certain patchable code sequences (method entry, call sites) The is_MP is removed and we always align patchable locations. 3. to gate certain optimizations which are questionable on uniprocessors (see quicken_jni_functions) These are psuedo-memory-barriers where we manufacture a data-dependency instead of inserting mfence/lfence (x86 example). These are treated as #1 and is_MP is removed. 4. to gate optimizations which are desirable on uniprocessors (mutex/monitor short circuits) These are spin controls and so is_MP remains. I have not updated the about-to-be-removed Oracle ARM port code. Testing: - Tiers 1 -3 (mach5) Performance run TBD. Thanks, David From mikael.vidstedt at oracle.com Tue Sep 18 06:06:32 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 17 Sep 2018 23:06:32 -0700 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: Message-ID: <67A64B3B-FA66-4BFB-9A6E-FC6BD41F4869@oracle.com> Nice cleanup, looks good! Minor nit: sharedRuntime_x86_32.cpp: two right brackets on the same line (2102). Cheers, Mikael > On Sep 17, 2018, at 10:32 PM, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 > Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ > > As previously discussed in the RFC thread: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html > > this change obsoletes the AssumeMP flag and removes the bulk of the logic that is conditional on os::is_MP() as follows: > > 1. to gate the introduction of MP-specific features, notably memory barriers > > The is_MP check is removed and we will always issue memory barriers > or pre-pend lock prefix etc. > > 2. to align certain patchable code sequences (method entry, call sites) > > The is_MP is removed and we always align patchable locations. > > 3. to gate certain optimizations which are questionable on uniprocessors > (see quicken_jni_functions) > > These are psuedo-memory-barriers where we manufacture a data-dependency > instead of inserting mfence/lfence (x86 example). These are treated as > #1 and is_MP is removed. > > 4. to gate optimizations which are desirable on uniprocessors > (mutex/monitor short circuits) > > These are spin controls and so is_MP remains. > > I have not updated the about-to-be-removed Oracle ARM port code. > > Testing: > - Tiers 1 -3 (mach5) > > Performance run TBD. > > Thanks, > David From martin.doerr at sap.com Tue Sep 18 06:11:44 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 18 Sep 2018 06:11:44 +0000 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <67A64B3B-FA66-4BFB-9A6E-FC6BD41F4869@oracle.com> References: <67A64B3B-FA66-4BFB-9A6E-FC6BD41F4869@oracle.com> Message-ID: <006cdf9376ec4ebaa17af689c332662b@sap.com> Hi David, thanks for doing this change. As written before, PPC and s390 parts look good. Seems like os::is_MP() is unused with this change. But we're keeping it for any future use? I'm ok with it, just asking. Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of Mikael Vidstedt Sent: Dienstag, 18. September 2018 08:07 To: David Holmes Cc: hotspot-dev developers Subject: Re: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds Nice cleanup, looks good! Minor nit: sharedRuntime_x86_32.cpp: two right brackets on the same line (2102). Cheers, Mikael > On Sep 17, 2018, at 10:32 PM, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 > Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ > > As previously discussed in the RFC thread: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html > > this change obsoletes the AssumeMP flag and removes the bulk of the logic that is conditional on os::is_MP() as follows: > > 1. to gate the introduction of MP-specific features, notably memory barriers > > The is_MP check is removed and we will always issue memory barriers > or pre-pend lock prefix etc. > > 2. to align certain patchable code sequences (method entry, call sites) > > The is_MP is removed and we always align patchable locations. > > 3. to gate certain optimizations which are questionable on uniprocessors > (see quicken_jni_functions) > > These are psuedo-memory-barriers where we manufacture a data-dependency > instead of inserting mfence/lfence (x86 example). These are treated as > #1 and is_MP is removed. > > 4. to gate optimizations which are desirable on uniprocessors > (mutex/monitor short circuits) > > These are spin controls and so is_MP remains. > > I have not updated the about-to-be-removed Oracle ARM port code. > > Testing: > - Tiers 1 -3 (mach5) > > Performance run TBD. > > Thanks, > David From david.holmes at oracle.com Tue Sep 18 06:25:55 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Sep 2018 16:25:55 +1000 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <67A64B3B-FA66-4BFB-9A6E-FC6BD41F4869@oracle.com> References: <67A64B3B-FA66-4BFB-9A6E-FC6BD41F4869@oracle.com> Message-ID: On 18/09/2018 4:06 PM, Mikael Vidstedt wrote: > > Nice cleanup, looks good! Thanks for taking a look so quickly! > Minor nit: > > sharedRuntime_x86_32.cpp: two right brackets on the same line (2102). Well spotted. Fixed in place. David > Cheers, > Mikael > >> On Sep 17, 2018, at 10:32 PM, David Holmes wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >> >> As previously discussed in the RFC thread: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >> >> this change obsoletes the AssumeMP flag and removes the bulk of the logic that is conditional on os::is_MP() as follows: >> >> 1. to gate the introduction of MP-specific features, notably memory barriers >> >> The is_MP check is removed and we will always issue memory barriers >> or pre-pend lock prefix etc. >> >> 2. to align certain patchable code sequences (method entry, call sites) >> >> The is_MP is removed and we always align patchable locations. >> >> 3. to gate certain optimizations which are questionable on uniprocessors >> (see quicken_jni_functions) >> >> These are psuedo-memory-barriers where we manufacture a data-dependency >> instead of inserting mfence/lfence (x86 example). These are treated as >> #1 and is_MP is removed. >> >> 4. to gate optimizations which are desirable on uniprocessors >> (mutex/monitor short circuits) >> >> These are spin controls and so is_MP remains. >> >> I have not updated the about-to-be-removed Oracle ARM port code. >> >> Testing: >> - Tiers 1 -3 (mach5) >> >> Performance run TBD. >> >> Thanks, >> David > From david.holmes at oracle.com Tue Sep 18 06:30:28 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Sep 2018 16:30:28 +1000 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <006cdf9376ec4ebaa17af689c332662b@sap.com> References: <67A64B3B-FA66-4BFB-9A6E-FC6BD41F4869@oracle.com> <006cdf9376ec4ebaa17af689c332662b@sap.com> Message-ID: <4aad6f36-9f89-5150-cc33-6d377f8a8ecf@oracle.com> Hi Martin, On 18/09/2018 4:11 PM, Doerr, Martin wrote: > Hi David, > > thanks for doing this change. > As written before, PPC and s390 parts look good. Thanks for restating that here. > Seems like os::is_MP() is unused with this change. But we're keeping it for any future use? > I'm ok with it, just asking. It is still used for spin-loop and related optimisations. Badly tuned spinloops on uniprocessors could be a significant performance issue. Keeping the is_MP check on a MP system is no hindrance as its just part of the spin-loop. Thanks, David > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of Mikael Vidstedt > Sent: Dienstag, 18. September 2018 08:07 > To: David Holmes > Cc: hotspot-dev developers > Subject: Re: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds > > > Nice cleanup, looks good! > > Minor nit: > > sharedRuntime_x86_32.cpp: two right brackets on the same line (2102). > > Cheers, > Mikael > >> On Sep 17, 2018, at 10:32 PM, David Holmes wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >> >> As previously discussed in the RFC thread: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >> >> this change obsoletes the AssumeMP flag and removes the bulk of the logic that is conditional on os::is_MP() as follows: >> >> 1. to gate the introduction of MP-specific features, notably memory barriers >> >> The is_MP check is removed and we will always issue memory barriers >> or pre-pend lock prefix etc. >> >> 2. to align certain patchable code sequences (method entry, call sites) >> >> The is_MP is removed and we always align patchable locations. >> >> 3. to gate certain optimizations which are questionable on uniprocessors >> (see quicken_jni_functions) >> >> These are psuedo-memory-barriers where we manufacture a data-dependency >> instead of inserting mfence/lfence (x86 example). These are treated as >> #1 and is_MP is removed. >> >> 4. to gate optimizations which are desirable on uniprocessors >> (mutex/monitor short circuits) >> >> These are spin controls and so is_MP remains. >> >> I have not updated the about-to-be-removed Oracle ARM port code. >> >> Testing: >> - Tiers 1 -3 (mach5) >> >> Performance run TBD. >> >> Thanks, >> David > From martin.doerr at sap.com Tue Sep 18 06:37:39 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 18 Sep 2018 06:37:39 +0000 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <4aad6f36-9f89-5150-cc33-6d377f8a8ecf@oracle.com> References: <67A64B3B-FA66-4BFB-9A6E-FC6BD41F4869@oracle.com> <006cdf9376ec4ebaa17af689c332662b@sap.com> <4aad6f36-9f89-5150-cc33-6d377f8a8ecf@oracle.com> Message-ID: Hi David, > It is still used for spin-loop and related optimisations. Badly tuned > spinloops on uniprocessors could be a significant performance issue. > Keeping the is_MP check on a MP system is no hindrance as its just part > of the spin-loop. So this means you're actually fixing this. os::is_MP is always true in the current implementation (due to "AssumeMP ||"). Thanks for explaining. Shared code part looks fine. Thanks, Martin From mikael.vidstedt at oracle.com Tue Sep 18 07:03:17 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 18 Sep 2018 00:03:17 -0700 Subject: RFR(M): 8210848: Obsolete SyncKnobs Message-ID: Please review this change which obsoletes the SyncKnobs flag, and simplifies the code by removing the resulting unused code paths. Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ * Background (from the bug) The experimental SyncKnobs flag can in theory be used to tune the behavior of the synchronization primitives. The flag was convenient when the various algorithms were compared a long time ago. In practice the only algorithm used and tested today are the default one. The SyncKnobs flag no longer serves the purpose it used to, and is "Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. * About the change As mentioned above this change not only obsolete the SyncKnobs flag, but also removes the various sub-options/knobs and prunes the resulting dead code. Of course I?m happy to hear your thoughts on that. After having asked around it seems like the knobs have not been used the last decade or so, and I like to think that the synchronization code is complex enough without what is in that case effectively dead code. In order to make reviewing this slightly easier I have for your convenience (at least I hope it is) also created a bunch of smaller patches which stack, each removing one specific knob. Hopefully they?re more or less self-explanatory, but let me know if I can help clarify something: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ * Testing A slightly earlier version of this patch passed the standard tier1-3 testing. I will run additional testing after I get some feedback. Cheers, Mikael From david.holmes at oracle.com Tue Sep 18 07:04:39 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Sep 2018 17:04:39 +1000 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: <67A64B3B-FA66-4BFB-9A6E-FC6BD41F4869@oracle.com> <006cdf9376ec4ebaa17af689c332662b@sap.com> <4aad6f36-9f89-5150-cc33-6d377f8a8ecf@oracle.com> Message-ID: On 18/09/2018 4:37 PM, Doerr, Martin wrote: > Hi David, > >> It is still used for spin-loop and related optimisations. Badly tuned >> spinloops on uniprocessors could be a significant performance issue. >> Keeping the is_MP check on a MP system is no hindrance as its just part >> of the spin-loop. > > So this means you're actually fixing this. > os::is_MP is always true in the current implementation (due to "AssumeMP ||"). Out-of-the-box yes. I'm assuming anyone actually running on a uniprocessor would have set -XX:-AssumeMP. Thanks, David > Thanks for explaining. > > Shared code part looks fine. > > Thanks, > Martin > From Pengfei.Li at arm.com Tue Sep 18 07:13:00 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Tue, 18 Sep 2018 07:13:00 +0000 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: <91d1bf82-eb60-c0a1-449d-8bb9246ddedd@oracle.com> References: <91d1bf82-eb60-c0a1-449d-8bb9246ddedd@oracle.com> Message-ID: Hi Reviewers, Is there any other comments, objections or suggestions on the new webrev? If no problems, could anyone help to push this commit? I look forward to your response. -- Thanks, Pengfei > -----Original Message----- > > Looks good. > > Thanks, > Vladimir > > On 9/12/18 2:50 AM, Pengfei Li (Arm Technology China) wrote: > > Hi, > > > > I've updated the patch based on Vladimir's comment. I added checks for > SubI on both branches of the diamond phi. > > Also thanks Roland for the suggestion that supporting a Phi with 3 or more > inputs. But I think the matching rule will be much more complex if we add > this. And I'm not sure if there are any real case scenario which can benefit > from this support. So I didn't add it in. > > > > New webrev: http://cr.openjdk.java.net/~njian/8210152/webrev.01/ > > I've run jtreg full test with the new patch and no new issues found. > > > > Please let me know if you have other comments or suggestions. If no > further issues, I need your help to sponsor and push the patch. > > > > -- > > Thanks, > > Pengfei > > > > From erik.osterlund at oracle.com Tue Sep 18 09:45:05 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 18 Sep 2018 11:45:05 +0200 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: <8680ff8e-dee6-dec1-060b-472278072652@oracle.com> References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> <8154d8b1-f6f3-0f39-9f42-daebc628cf02@oracle.com> <8680ff8e-dee6-dec1-060b-472278072652@oracle.com> Message-ID: <5BA0C921.9080409@oracle.com> Hi Coleen, Looks good. I guess the whole thing looks horrible in a way, but the patch is good. Thanks for fixing this. /Erik On 2018-09-18 01:47, coleen.phillimore at oracle.com wrote: > > > On 9/17/18 5:17 PM, dean.long at oracle.com wrote: >> Can you move the JavaThread _WIN64 changes to thread_windows_x86.hpp? > > Thanks for looking at this. I moved it to the better place: > > http://cr.openjdk.java.net/~coleenp/8203466.02/webrev/index.html > > Retested with build and ran one test 100 times that failed once. > > Thanks, > Coleen > >> >> dl >> >> On 9/17/18 5:05 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 9/14/18 4:01 PM, dean.long at oracle.com wrote: >>>> Hi Coleen. In the bug you asked: >>>> >>>> > Why can't we just push rdi and rsi to the stack and restore them? >>>> This code appears to be leaf code so shouldn't care about stack format >>>> >>>> Did that ever get answered? If there is concern about the pushes >>>> and pops canceling out at the end, you could always reserve the >>>> stack space at the beginning, after >>>> >>>> __ enter(); >>>> >>>> and then setup_arg_regs/restore_arg_regs would not need to adjust >>>> the stack pointer. >>> >>> The reason I didn't do this is that I couldn't get it to work for >>> all the various call sites. Also, the barrier code is going to need >>> the thread register sometimes which wasn't available. So I went with >>> this. I'm somewhat unclear with how this is called from the c2 >>> code. If you want to try this solution, I should probably give up >>> and reassign it to compiler. >>> >>> thanks, >>> coleen >>> >>>> >>>> dl >>>> >>>> On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Save windows 64 callee saved registers rsi, rdi to >>>>> Thread, save r15, also callee saved to r9 >>>>> >>>>> This is done for generated stubs that do arraycopy that need GC >>>>> barrier code because GC assumes that r10 is scratch, since it's >>>>> defined as rscratch1. See bug for more details. Thanks Erik for >>>>> your help and the diagnosis. >>>>> >>>>> Tested with mach5 hs-tier1-7. We don't have a reproduceable test >>>>> case. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8203466.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8203466 >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>> >>> >> > From claes.redestad at oracle.com Tue Sep 18 11:07:58 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 18 Sep 2018 13:07:58 +0200 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: References: Message-ID: <85236ff7-a252-ac83-ad69-1c8208a60c25@oracle.com> Great cleanup! src/hotspot/share/runtime/objectMonitor.cpp: ? The DeferredInitialize method seems a bit silly now that it only guards the setting of three little Knobs using a CAS.. perhaps we would be better off wrapping these three in methods (spinLimit() { return os::is_MP() ? 5000 : 0; }), or perhaps we can guarantee that os::is_MP is initialized before, somehow? Either way I think we could profitably get rid of DeferredInitialize and InitDone. /Claes On 2018-09-18 09:03, Mikael Vidstedt wrote: > Please review this change which obsoletes the SyncKnobs flag, and simplifies the code by removing the resulting unused code paths. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ > > * Background (from the bug) > > The experimental SyncKnobs flag can in theory be used to tune the behavior of the synchronization primitives. The flag was convenient when the various algorithms were compared a long time ago. > > In practice the only algorithm used and tested today are the default one. The SyncKnobs flag no longer serves the purpose it used to, and is "Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. > > * About the change > > As mentioned above this change not only obsolete the SyncKnobs flag, but also removes the various sub-options/knobs and prunes the resulting dead code. Of course I?m happy to hear your thoughts on that. After having asked around it seems like the knobs have not been used the last decade or so, and I like to think that the synchronization code is complex enough without what is in that case effectively dead code. > > In order to make reviewing this slightly easier I have for your convenience (at least I hope it is) also created a bunch of smaller patches which stack, each removing one specific knob. Hopefully they?re more or less self-explanatory, but let me know if I can help clarify something: > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ > > * Testing > > A slightly earlier version of this patch passed the standard tier1-3 testing. I will run additional testing after I get some feedback. > > Cheers, > Mikael > From aleksei.voitylov at bell-sw.com Tue Sep 18 12:39:21 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Tue, 18 Sep 2018 15:39:21 +0300 Subject: [12] RFR(S): 8209697: ARM: Explicit barriers for C1/assembler In-Reply-To: <1bdb5d7f-b92c-bee1-22f0-63762936f22d@samersoff.net> References: <0654c3fc-213c-a06f-d28e-7be1d1fcbe0b@bell-sw.com> <1bdb5d7f-b92c-bee1-22f0-63762936f22d@samersoff.net> Message-ID: Thank you Dmitry for review! On 16/09/2018 15:21, Dmitry Samersoff wrote: > Hello Aleksei, > > Looks good to me. > > -Dmitry > > On 08/23/2018 05:30 PM, Aleksei Voitylov wrote: >> Hi, >> >> please review this patch which adds explicit barriers for C1/assembler >> on ARM similar to how it was done on x86 and Aarch64: >> >> webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8209697.01/ >> issue: https://bugs.openjdk.java.net/browse/JDK-8209697 >> >> here is the issue where this functionality was added on x86 and Aarch64: >> https://bugs.openjdk.java.net/browse/JDK-8209668 >> >> Tested by running hotspot tests. >> >> Thanks, >> >> -Aleksei >> > From aleksei.voitylov at bell-sw.com Tue Sep 18 12:39:28 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Tue, 18 Sep 2018 15:39:28 +0300 Subject: [12] RFR(S): 8209695: ARM: Explicit barriers for interpreter In-Reply-To: <34a658d5-00c2-9b0e-9a2a-8232053128e1@samersoff.net> References: <3075f116-73cd-deb1-bb75-287101a3e5eb@bell-sw.com> <34a658d5-00c2-9b0e-9a2a-8232053128e1@samersoff.net> Message-ID: Thank you Dmitry for review! On 16/09/2018 15:19, Dmitry Samersoff wrote: > Hello Aleksei, > > Looks good to me. > > -Dmitry > > On 08/23/2018 05:30 PM, Aleksei Voitylov wrote: >> Hi, >> >> please review this patch which adds explicit barriers for interpreter on >> ARM similar to how it was done on x86 and Aarch64: >> >> webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8209695.01/ >> issue: https://bugs.openjdk.java.net/browse/JDK-8209695 >> >> here is the issue where this functionality was added on x86 and Aarch64: >> https://bugs.openjdk.java.net/browse/JDK-8205523 >> >> Tested by running hotspot tests. >> >> Thanks, >> >> -Aleksei >> > From aleksei.voitylov at bell-sw.com Tue Sep 18 12:39:38 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Tue, 18 Sep 2018 15:39:38 +0300 Subject: [12] RFR (S): 8210466: ARM: Modularize allocations in assembler In-Reply-To: <5e1b8aa0-c283-0eeb-d073-9fb2f4a13e4e@samersoff.net> References: <5e1b8aa0-c283-0eeb-d073-9fb2f4a13e4e@samersoff.net> Message-ID: <32f96806-96fd-33bb-4e87-09eee4e8e3b1@bell-sw.com> Thank you Dmitry for review! On 16/09/2018 15:17, Dmitry Samersoff wrote: > Hello Aleksei, > > Looks good to me. > > -Dmitry > > On 09/14/2018 02:54 PM, Aleksei Voitylov wrote: >> Hi, >> >> please review this patch which follows the changes on x86 and AARCH64: >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8210466 >> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210466.01/ >> >> This patch is incremental to 8210465. Tested by HotSpot regression tests. >> >> Original issue for x86 and AARCH64: >> https://bugs.openjdk.java.net/browse/JDK-8205336 >> >> Thanks, >> >> -Aleksei >> >> >> > From coleen.phillimore at oracle.com Tue Sep 18 12:54:43 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 18 Sep 2018 08:54:43 -0400 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: <5BA0C921.9080409@oracle.com> References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> <8154d8b1-f6f3-0f39-9f42-daebc628cf02@oracle.com> <8680ff8e-dee6-dec1-060b-472278072652@oracle.com> <5BA0C921.9080409@oracle.com> Message-ID: <16098021-b330-448b-080a-465c8d4df3d0@oracle.com> Thanks Erik! Coleen On 9/18/18 5:45 AM, Erik ?sterlund wrote: > Hi Coleen, > > Looks good. I guess the whole thing looks horrible in a way, but the > patch is good. > Thanks for fixing this. > > /Erik > > On 2018-09-18 01:47, coleen.phillimore at oracle.com wrote: >> >> >> On 9/17/18 5:17 PM, dean.long at oracle.com wrote: >>> Can you move the JavaThread _WIN64 changes to thread_windows_x86.hpp? >> >> Thanks for looking at this.? I moved it to the better place: >> >> http://cr.openjdk.java.net/~coleenp/8203466.02/webrev/index.html >> >> Retested with build and ran one test 100 times that failed once. >> >> Thanks, >> Coleen >> >>> >>> dl >>> >>> On 9/17/18 5:05 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 9/14/18 4:01 PM, dean.long at oracle.com wrote: >>>>> Hi Coleen.? In the bug you asked: >>>>> >>>>> > Why can't we just push rdi and rsi to the stack and restore >>>>> them? This code appears to be leaf code so shouldn't care about >>>>> stack format >>>>> >>>>> Did that ever get answered?? If there is concern about the pushes >>>>> and pops canceling out at the end, you could always reserve the >>>>> stack space at the beginning, after >>>>> >>>>> __ enter(); >>>>> >>>>> and then setup_arg_regs/restore_arg_regs would not need to adjust >>>>> the stack pointer. >>>> >>>> The reason I didn't do this is that I couldn't get it to work for >>>> all the various call sites.? Also, the barrier code is going to >>>> need the thread register sometimes which wasn't available. So I >>>> went with this.? I'm somewhat unclear with how this is called from >>>> the c2 code.? If you want to try this solution, I should probably >>>> give up and reassign it to compiler. >>>> >>>> thanks, >>>> coleen >>>> >>>>> >>>>> dl >>>>> >>>>> On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Save windows 64 callee saved registers rsi, rdi to >>>>>> Thread, save r15, also callee saved to r9 >>>>>> >>>>>> This is done for generated stubs that do arraycopy that need GC >>>>>> barrier code because GC assumes that r10 is scratch, since it's >>>>>> defined as rscratch1.? See bug for more details. Thanks Erik for >>>>>> your help and the diagnosis. >>>>>> >>>>>> Tested with mach5 hs-tier1-7.? We don't have a reproduceable test >>>>>> case. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8203466.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8203466 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>> >>>> >>> >> > From bob.vandette at oracle.com Tue Sep 18 13:17:46 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 18 Sep 2018 09:17:46 -0400 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> I only did some basic testing of the hard-float abi. Bell SW has offered to do more extensive testing as part of this JEP. I have no way of knowing if any of the other profiles are being used but I would think it?s worth keeping them in the event that someone wants to try to build/test these other configurations. The goal of this JEP is to eliminate the arm64 port and not cause any other changes in behavior. Bob. > On Sep 17, 2018, at 10:53 PM, David Holmes wrote: > > Hi Bob, > > On 18/09/2018 2:20 AM, Bob Vandette wrote: >> Please review the changes related to JEP 340 which remove the second 64-bit ARM port >> from the JDK. >> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >> I?ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. >> I?ve run specJVM98 on the three 32-bit ARM VMs. > > Did you test all the ARM related abi-profiles? It seems to me they were only for Oracle's ARM32 port and may have never been used otherwise. I would have expected all that stuff to be removed. > > Cheers, > David > >> I also verified that Linux x64 builds. >> Bob. From martin.doerr at sap.com Tue Sep 18 13:55:03 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 18 Sep 2018 13:55:03 +0000 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: <16098021-b330-448b-080a-465c8d4df3d0@oracle.com> References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> <8154d8b1-f6f3-0f39-9f42-daebc628cf02@oracle.com> <8680ff8e-dee6-dec1-060b-472278072652@oracle.com> <5BA0C921.9080409@oracle.com> <16098021-b330-448b-080a-465c8d4df3d0@oracle.com> Message-ID: Hi Coleen, is it really safe to keep a value in R9 across the barrier's runtime call? It's specified as volatile in [1]. I think it'd be nice if we had a dedicated stub calling convention. Calling (almost) only cpu specific stubs via os+cpu specific C calling conventions is a mess. But thanks for fixing the issue. Best regards, Martin [1] https://docs.microsoft.com/en-us/cpp/build/register-usage?view=vs-2017 -----Original Message----- From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com Sent: Dienstag, 18. September 2018 14:55 To: Erik ?sterlund ; hotspot-dev at openjdk.java.net Subject: Re: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) Thanks Erik! Coleen On 9/18/18 5:45 AM, Erik ?sterlund wrote: > Hi Coleen, > > Looks good. I guess the whole thing looks horrible in a way, but the > patch is good. > Thanks for fixing this. > > /Erik > > On 2018-09-18 01:47, coleen.phillimore at oracle.com wrote: >> >> >> On 9/17/18 5:17 PM, dean.long at oracle.com wrote: >>> Can you move the JavaThread _WIN64 changes to thread_windows_x86.hpp? >> >> Thanks for looking at this.? I moved it to the better place: >> >> http://cr.openjdk.java.net/~coleenp/8203466.02/webrev/index.html >> >> Retested with build and ran one test 100 times that failed once. >> >> Thanks, >> Coleen >> >>> >>> dl >>> >>> On 9/17/18 5:05 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 9/14/18 4:01 PM, dean.long at oracle.com wrote: >>>>> Hi Coleen.? In the bug you asked: >>>>> >>>>> > Why can't we just push rdi and rsi to the stack and restore >>>>> them? This code appears to be leaf code so shouldn't care about >>>>> stack format >>>>> >>>>> Did that ever get answered?? If there is concern about the pushes >>>>> and pops canceling out at the end, you could always reserve the >>>>> stack space at the beginning, after >>>>> >>>>> __ enter(); >>>>> >>>>> and then setup_arg_regs/restore_arg_regs would not need to adjust >>>>> the stack pointer. >>>> >>>> The reason I didn't do this is that I couldn't get it to work for >>>> all the various call sites.? Also, the barrier code is going to >>>> need the thread register sometimes which wasn't available. So I >>>> went with this.? I'm somewhat unclear with how this is called from >>>> the c2 code.? If you want to try this solution, I should probably >>>> give up and reassign it to compiler. >>>> >>>> thanks, >>>> coleen >>>> >>>>> >>>>> dl >>>>> >>>>> On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Save windows 64 callee saved registers rsi, rdi to >>>>>> Thread, save r15, also callee saved to r9 >>>>>> >>>>>> This is done for generated stubs that do arraycopy that need GC >>>>>> barrier code because GC assumes that r10 is scratch, since it's >>>>>> defined as rscratch1.? See bug for more details. Thanks Erik for >>>>>> your help and the diagnosis. >>>>>> >>>>>> Tested with mach5 hs-tier1-7.? We don't have a reproduceable test >>>>>> case. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8203466.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8203466 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>> >>>> >>> >> > From coleen.phillimore at oracle.com Tue Sep 18 14:31:19 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 18 Sep 2018 10:31:19 -0400 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> <8154d8b1-f6f3-0f39-9f42-daebc628cf02@oracle.com> <8680ff8e-dee6-dec1-060b-472278072652@oracle.com> <5BA0C921.9080409@oracle.com> <16098021-b330-448b-080a-465c8d4df3d0@oracle.com> Message-ID: Hi, I just pushed this because I wasn't expecting more comments. On 9/18/18 9:55 AM, Doerr, Martin wrote: > Hi Coleen, > > is it really safe to keep a value in R9 across the barrier's runtime call? I was going to save r15 also to thread local, but since r9 wasn't the problem we observed and is not aliased to something like rscratch1, which invites reuse, I think it's safe for now.? I don't think this code is future-proof and hand coded assembly for performance is something I wish we could avoid. > It's specified as volatile in [1]. > > I think it'd be nice if we had a dedicated stub calling convention. Calling (almost) only cpu specific stubs via os+cpu specific C calling conventions is a mess. But thanks for fixing the issue. I would be nice if this was less of a mess.? Let me know if you find that this doesn't fix the issue.? This wasn't reproduceable. thanks, Coleen > > Best regards, > Martin > > [1] https://docs.microsoft.com/en-us/cpp/build/register-usage?view=vs-2017 > > > -----Original Message----- > From: hotspot-dev On Behalf Of coleen.phillimore at oracle.com > Sent: Dienstag, 18. September 2018 14:55 > To: Erik ?sterlund ; hotspot-dev at openjdk.java.net > Subject: Re: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) > > Thanks Erik! > Coleen > > On 9/18/18 5:45 AM, Erik ?sterlund wrote: >> Hi Coleen, >> >> Looks good. I guess the whole thing looks horrible in a way, but the >> patch is good. >> Thanks for fixing this. >> >> /Erik >> >> On 2018-09-18 01:47, coleen.phillimore at oracle.com wrote: >>> >>> On 9/17/18 5:17 PM, dean.long at oracle.com wrote: >>>> Can you move the JavaThread _WIN64 changes to thread_windows_x86.hpp? >>> Thanks for looking at this.? I moved it to the better place: >>> >>> http://cr.openjdk.java.net/~coleenp/8203466.02/webrev/index.html >>> >>> Retested with build and ran one test 100 times that failed once. >>> >>> Thanks, >>> Coleen >>> >>>> dl >>>> >>>> On 9/17/18 5:05 AM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> On 9/14/18 4:01 PM, dean.long at oracle.com wrote: >>>>>> Hi Coleen.? In the bug you asked: >>>>>> >>>>>>> Why can't we just push rdi and rsi to the stack and restore >>>>>> them? This code appears to be leaf code so shouldn't care about >>>>>> stack format >>>>>> >>>>>> Did that ever get answered?? If there is concern about the pushes >>>>>> and pops canceling out at the end, you could always reserve the >>>>>> stack space at the beginning, after >>>>>> >>>>>> __ enter(); >>>>>> >>>>>> and then setup_arg_regs/restore_arg_regs would not need to adjust >>>>>> the stack pointer. >>>>> The reason I didn't do this is that I couldn't get it to work for >>>>> all the various call sites.? Also, the barrier code is going to >>>>> need the thread register sometimes which wasn't available. So I >>>>> went with this.? I'm somewhat unclear with how this is called from >>>>> the c2 code.? If you want to try this solution, I should probably >>>>> give up and reassign it to compiler. >>>>> >>>>> thanks, >>>>> coleen >>>>> >>>>>> dl >>>>>> >>>>>> On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Save windows 64 callee saved registers rsi, rdi to >>>>>>> Thread, save r15, also callee saved to r9 >>>>>>> >>>>>>> This is done for generated stubs that do arraycopy that need GC >>>>>>> barrier code because GC assumes that r10 is scratch, since it's >>>>>>> defined as rscratch1.? See bug for more details. Thanks Erik for >>>>>>> your help and the diagnosis. >>>>>>> >>>>>>> Tested with mach5 hs-tier1-7.? We don't have a reproduceable test >>>>>>> case. >>>>>>> >>>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8203466.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8203466 >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> From dean.long at oracle.com Tue Sep 18 17:00:26 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 18 Sep 2018 10:00:26 -0700 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> <8154d8b1-f6f3-0f39-9f42-daebc628cf02@oracle.com> <8680ff8e-dee6-dec1-060b-472278072652@oracle.com> <5BA0C921.9080409@oracle.com> <16098021-b330-448b-080a-465c8d4df3d0@oracle.com> Message-ID: A lot of the barrier code is saving registers around calls: ?__ pusha();???????????? // push registers (overkill) ?/* call_vm */ ?__ popa(); however, the "overkill" comment now seems like it should be "necessary for now". If we wanted to stress test our stubs and make failures like this more reproducible, we could remove the pusha/popa and make call_VM in debug builds trash the volatile registers on return. dl On 9/18/18 7:31 AM, coleen.phillimore at oracle.com wrote: > > Hi, I just pushed this because I wasn't expecting more comments. > > On 9/18/18 9:55 AM, Doerr, Martin wrote: >> Hi Coleen, >> >> is it really safe to keep a value in R9 across the barrier's runtime >> call? > > I was going to save r15 also to thread local, but since r9 wasn't the > problem we observed and is not aliased to something like rscratch1, > which invites reuse, I think it's safe for now.? I don't think this > code is future-proof and hand coded assembly for performance is > something I wish we could avoid. > >> It's specified as volatile in [1]. >> >> I think it'd be nice if we had a dedicated stub calling convention. >> Calling (almost) only cpu specific stubs via os+cpu specific C >> calling conventions is a mess. But thanks for fixing the issue. > > I would be nice if this was less of a mess.? Let me know if you find > that this doesn't fix the issue.? This wasn't reproduceable. > thanks, > Coleen >> >> Best regards, >> Martin >> >> [1] >> https://docs.microsoft.com/en-us/cpp/build/register-usage?view=vs-2017 >> >> >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> coleen.phillimore at oracle.com >> Sent: Dienstag, 18. September 2018 14:55 >> To: Erik ?sterlund ; >> hotspot-dev at openjdk.java.net >> Subject: Re: RFR 8203466: intermittent crash at >> jdk.internal.misc.Unsafe::getObjectVolatile (native) >> >> Thanks Erik! >> Coleen >> >> On 9/18/18 5:45 AM, Erik ?sterlund wrote: >>> Hi Coleen, >>> >>> Looks good. I guess the whole thing looks horrible in a way, but the >>> patch is good. >>> Thanks for fixing this. >>> >>> /Erik >>> >>> On 2018-09-18 01:47, coleen.phillimore at oracle.com wrote: >>>> >>>> On 9/17/18 5:17 PM, dean.long at oracle.com wrote: >>>>> Can you move the JavaThread _WIN64 changes to thread_windows_x86.hpp? >>>> Thanks for looking at this.? I moved it to the better place: >>>> >>>> http://cr.openjdk.java.net/~coleenp/8203466.02/webrev/index.html >>>> >>>> Retested with build and ran one test 100 times that failed once. >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> dl >>>>> >>>>> On 9/17/18 5:05 AM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> On 9/14/18 4:01 PM, dean.long at oracle.com wrote: >>>>>>> Hi Coleen.? In the bug you asked: >>>>>>> >>>>>>>> Why can't we just push rdi and rsi to the stack and restore >>>>>>> them? This code appears to be leaf code so shouldn't care about >>>>>>> stack format >>>>>>> >>>>>>> Did that ever get answered?? If there is concern about the pushes >>>>>>> and pops canceling out at the end, you could always reserve the >>>>>>> stack space at the beginning, after >>>>>>> >>>>>>> __ enter(); >>>>>>> >>>>>>> and then setup_arg_regs/restore_arg_regs would not need to adjust >>>>>>> the stack pointer. >>>>>> The reason I didn't do this is that I couldn't get it to work for >>>>>> all the various call sites.? Also, the barrier code is going to >>>>>> need the thread register sometimes which wasn't available. So I >>>>>> went with this.? I'm somewhat unclear with how this is called from >>>>>> the c2 code.? If you want to try this solution, I should probably >>>>>> give up and reassign it to compiler. >>>>>> >>>>>> thanks, >>>>>> coleen >>>>>> >>>>>>> dl >>>>>>> >>>>>>> On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote: >>>>>>>> Summary: Save windows 64 callee saved registers rsi, rdi to >>>>>>>> Thread, save r15, also callee saved to r9 >>>>>>>> >>>>>>>> This is done for generated stubs that do arraycopy that need GC >>>>>>>> barrier code because GC assumes that r10 is scratch, since it's >>>>>>>> defined as rscratch1.? See bug for more details. Thanks Erik for >>>>>>>> your help and the diagnosis. >>>>>>>> >>>>>>>> Tested with mach5 hs-tier1-7.? We don't have a reproduceable test >>>>>>>> case. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/8203466.01/webrev >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8203466 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> > From simon at cjnash.com Tue Sep 18 17:14:20 2018 From: simon at cjnash.com (Simon Nash) Date: Tue, 18 Sep 2018 18:14:20 +0100 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> Message-ID: <5BA1326C.7040708@cjnash.com> On 18/09/2018 14:17, Bob Vandette wrote: > I only did some basic testing of the hard-float abi. Bell SW has offered to do more extensive testing > as part of this JEP. > > I have no way of knowing if any of the other profiles are being used but I would think it?s > worth keeping them in the event that someone wants to try to build/test these other configurations. > I am using the abi profiles arm-vfp-hflt and arm-sflt. So far I have only built jdk9u with these profiles. It would be a serious problem for me if these profiles don't continue to work on later JDK versions. Simon > The goal of this JEP is to eliminate the arm64 port and not cause any other changes in behavior. > > Bob. > > >> On Sep 17, 2018, at 10:53 PM, David Holmes wrote: >> >> Hi Bob, >> >> On 18/09/2018 2:20 AM, Bob Vandette wrote: >>> Please review the changes related to JEP 340 which remove the second 64-bit ARM port >>> from the JDK. >>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >>> I?ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. >>> I?ve run specJVM98 on the three 32-bit ARM VMs. >> Did you test all the ARM related abi-profiles? It seems to me they were only for Oracle's ARM32 port and may have never been used otherwise. I would have expected all that stuff to be removed. >> >> Cheers, >> David >> >>> I also verified that Linux x64 builds. >>> Bob. > > From coleen.phillimore at oracle.com Tue Sep 18 22:36:58 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 18 Sep 2018 18:36:58 -0400 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: References: Message-ID: This looks like a nice cleanup! http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/src/hotspot/share/runtime/synchronizer.cpp.frames.html verifyInUse can be removed also. Also, the verification removed at line 1830 seems like it could be useful.? Can you make it an assert instead?? Sorry this might invalidate your testing. http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/src/hotspot/share/runtime/objectMonitor.cpp.frames.html There are still some variables called Knob_Something that should probably be renamed to something meaningful, but could be done in a future RFE and not make this change larger. That's all I saw.? Looks good! Coleen On 9/18/18 3:03 AM, Mikael Vidstedt wrote: > Please review this change which obsoletes the SyncKnobs flag, and simplifies the code by removing the resulting unused code paths. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ > > * Background (from the bug) > > The experimental SyncKnobs flag can in theory be used to tune the behavior of the synchronization primitives. The flag was convenient when the various algorithms were compared a long time ago. > > In practice the only algorithm used and tested today are the default one. The SyncKnobs flag no longer serves the purpose it used to, and is "Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. > > * About the change > > As mentioned above this change not only obsolete the SyncKnobs flag, but also removes the various sub-options/knobs and prunes the resulting dead code. Of course I?m happy to hear your thoughts on that. After having asked around it seems like the knobs have not been used the last decade or so, and I like to think that the synchronization code is complex enough without what is in that case effectively dead code. > > In order to make reviewing this slightly easier I have for your convenience (at least I hope it is) also created a bunch of smaller patches which stack, each removing one specific knob. Hopefully they?re more or less self-explanatory, but let me know if I can help clarify something: > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ > > * Testing > > A slightly earlier version of this patch passed the standard tier1-3 testing. I will run additional testing after I get some feedback. > > Cheers, > Mikael > From coleen.phillimore at oracle.com Tue Sep 18 23:36:46 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 18 Sep 2018 19:36:46 -0400 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: References: Message-ID: <25e88114-46a2-fe08-084f-0bab06a33545@oracle.com> On 9/18/18 6:36 PM, coleen.phillimore at oracle.com wrote: > > This looks like a nice cleanup! > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/src/hotspot/share/runtime/synchronizer.cpp.frames.html > > > verifyInUse can be removed also. > > Also, the verification removed at line 1830 seems like it could be > useful.? Can you make it an assert instead?? Sorry this might > invalidate your testing. I read this too fast.? This doesn't verify anything.? I has a fatal error if you own any locks in this ReleaseJavaMonitorsClosure.? Not sure if that's a problem or not but we don't want to start giving fatal errors for it unconditionally like this. Coleen > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/src/hotspot/share/runtime/objectMonitor.cpp.frames.html > > > There are still some variables called Knob_Something that should > probably be renamed to something meaningful, but could be done in a > future RFE and not make this change larger. > > That's all I saw.? Looks good! > Coleen > > On 9/18/18 3:03 AM, Mikael Vidstedt wrote: >> Please review this change which obsoletes the SyncKnobs flag, and >> simplifies the code by removing the resulting unused code paths. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ >> >> >> >> * Background (from the bug) >> >> The experimental SyncKnobs flag can in theory be used to tune the >> behavior of the synchronization primitives. The flag was convenient >> when the various algorithms were compared a long time ago. >> >> In practice the only algorithm used and tested today are the default >> one. The SyncKnobs flag no longer serves the purpose it used to, and >> is "Unstable" (the documentation of the flag says so explicitly). It >> should be obsoleted and later removed. >> >> * About the change >> >> As mentioned above this change not only obsolete the SyncKnobs flag, >> but also removes the various sub-options/knobs and prunes the >> resulting dead code. Of course I?m happy to hear your thoughts on >> that. After having asked around it seems like the knobs have not been >> used the last decade or so, and I like to think that the >> synchronization code is complex enough without what is in that case >> effectively dead code. >> >> In order to make reviewing this slightly easier I have for your >> convenience (at least I hope it is) also created a bunch of smaller >> patches which stack, each removing one specific knob. Hopefully >> they?re more or less self-explanatory, but let me know if I can help >> clarify something: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ >> >> >> * Testing >> >> A slightly earlier version of this patch passed the standard tier1-3 >> testing. I will run additional testing after I get some feedback. >> >> Cheers, >> Mikael >> > From martinrb at google.com Wed Sep 19 00:01:03 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 18 Sep 2018 17:01:03 -0700 Subject: Linux + Clang + execstack In-Reply-To: References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> <3193b432-0068-8e2b-9ad4-f5a6467568a1@oracle.com> <6b05bebc-4b06-1071-7dc3-a338ba91c8b0@oracle.com> <7002cda6-ab66-3ff9-083b-cfc024e0c927@oracle.com> Message-ID: Unfortunately, my gmail marked Arthur's emails to this thread as spam, with ensuing confusion. I retargeted this fix to the new bug 8209817: stack is executable when building with Clang on Linux http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/ https://bugs.openjdk.java.net/browse/JDK-8209817 and it made it through the submit repo tests. Ready to submit this. On Thu, Sep 13, 2018 at 2:10 PM, Magnus Ihse Bursie wrote: > >> We're not entirely happy either. >> >> A much higher interface might look like >> >> TRY_ADD_LINKER_FLAGS -z noexecstack > > Agreed. I'm working towards a solution like that. >> >> which would add -Wl,-z,noexecstack to LDFLAGS when appropriate >> .... hmmm ... >> I only just noticed that both gcc and clang accept simply >> $CC -z noexecstack >> (it's even documented!) >> Should we switch to that instead? > > No, I think it's better to keep -Wl,-z for consistency for all linker flags. > Otherwise it just looks confusing. > > /Magnus > > >> >> >>> Do you have a JBS issue? >> >> I have >> https://bugs.openjdk.java.net/browse/JDK-8205457 gcc and clang should >> use the same ld flags >> but the proposed patch only addresses part of that. I could create a >> sub-task (but I've never done that before) or a new bug or change the >> description of this bug. What do you think? > > From mikael.vidstedt at oracle.com Wed Sep 19 03:01:16 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 18 Sep 2018 20:01:16 -0700 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: <85236ff7-a252-ac83-ad69-1c8208a60c25@oracle.com> References: <85236ff7-a252-ac83-ad69-1c8208a60c25@oracle.com> Message-ID: Thanks for the review, and very good point about DeferredInitialize. I have a patch ready which performs the initialization eagerly at startup, but I?ll do that as a follow up to avoid making this particular change and review more complex. Cheers, Mikael > On Sep 18, 2018, at 4:07 AM, Claes Redestad wrote: > > Great cleanup! > > src/hotspot/share/runtime/objectMonitor.cpp: > > The DeferredInitialize method seems a bit silly now that it only guards the setting of three little Knobs using a CAS.. perhaps we would be better off wrapping these three in methods (spinLimit() { return os::is_MP() ? 5000 : 0; }), or perhaps we can guarantee that os::is_MP is initialized before, somehow? Either way I think we could profitably get rid of DeferredInitialize and InitDone. > > /Claes > > On 2018-09-18 09:03, Mikael Vidstedt wrote: >> Please review this change which obsoletes the SyncKnobs flag, and simplifies the code by removing the resulting unused code paths. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ >> >> * Background (from the bug) >> >> The experimental SyncKnobs flag can in theory be used to tune the behavior of the synchronization primitives. The flag was convenient when the various algorithms were compared a long time ago. >> >> In practice the only algorithm used and tested today are the default one. The SyncKnobs flag no longer serves the purpose it used to, and is "Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. >> >> * About the change >> >> As mentioned above this change not only obsolete the SyncKnobs flag, but also removes the various sub-options/knobs and prunes the resulting dead code. Of course I?m happy to hear your thoughts on that. After having asked around it seems like the knobs have not been used the last decade or so, and I like to think that the synchronization code is complex enough without what is in that case effectively dead code. >> >> In order to make reviewing this slightly easier I have for your convenience (at least I hope it is) also created a bunch of smaller patches which stack, each removing one specific knob. Hopefully they?re more or less self-explanatory, but let me know if I can help clarify something: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ >> >> * Testing >> >> A slightly earlier version of this patch passed the standard tier1-3 testing. I will run additional testing after I get some feedback. >> >> Cheers, >> Mikael >> > From mikael.vidstedt at oracle.com Wed Sep 19 03:04:45 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 18 Sep 2018 20:04:45 -0700 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: <25e88114-46a2-fe08-084f-0bab06a33545@oracle.com> References: <25e88114-46a2-fe08-084f-0bab06a33545@oracle.com> Message-ID: <93967DE7-AB56-42DC-8498-5D18CC916CC3@oracle.com> Right, I think the verifyInUse can all go. New version: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.01/syncknobs-full/open/webrev/ Incremental webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.01/syncknobs-07.2-Knob_VerifyInUse/open/webrev/ I agree that some of the Knob variables can be renamed now. As a matter of fact in an earlier version of the patch I had done that rename, but I decided to roll that back to avoid making the change more complex. I?ll do that as an immediate follow up. Cheers, Mikael > On Sep 18, 2018, at 4:36 PM, coleen.phillimore at oracle.com wrote: > > > > On 9/18/18 6:36 PM, coleen.phillimore at oracle.com wrote: >> >> This looks like a nice cleanup! >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/src/hotspot/share/runtime/synchronizer.cpp.frames.html >> >> verifyInUse can be removed also. >> >> Also, the verification removed at line 1830 seems like it could be useful. Can you make it an assert instead? Sorry this might invalidate your testing. > > I read this too fast. This doesn't verify anything. I has a fatal error if you own any locks in this ReleaseJavaMonitorsClosure. Not sure if that's a problem or not but we don't want to start giving fatal errors for it unconditionally like this. > > Coleen >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/src/hotspot/share/runtime/objectMonitor.cpp.frames.html >> >> There are still some variables called Knob_Something that should probably be renamed to something meaningful, but could be done in a future RFE and not make this change larger. >> >> That's all I saw. Looks good! >> Coleen >> >> On 9/18/18 3:03 AM, Mikael Vidstedt wrote: >>> Please review this change which obsoletes the SyncKnobs flag, and simplifies the code by removing the resulting unused code paths. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 >>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ >>> >>> * Background (from the bug) >>> >>> The experimental SyncKnobs flag can in theory be used to tune the behavior of the synchronization primitives. The flag was convenient when the various algorithms were compared a long time ago. >>> >>> In practice the only algorithm used and tested today are the default one. The SyncKnobs flag no longer serves the purpose it used to, and is "Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. >>> >>> * About the change >>> >>> As mentioned above this change not only obsolete the SyncKnobs flag, but also removes the various sub-options/knobs and prunes the resulting dead code. Of course I?m happy to hear your thoughts on that. After having asked around it seems like the knobs have not been used the last decade or so, and I like to think that the synchronization code is complex enough without what is in that case effectively dead code. >>> >>> In order to make reviewing this slightly easier I have for your convenience (at least I hope it is) also created a bunch of smaller patches which stack, each removing one specific knob. Hopefully they?re more or less self-explanatory, but let me know if I can help clarify something: >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ >>> >>> * Testing >>> >>> A slightly earlier version of this patch passed the standard tier1-3 testing. I will run additional testing after I get some feedback. >>> >>> Cheers, >>> Mikael >>> >> > From magnus.ihse.bursie at oracle.com Wed Sep 19 07:56:55 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Sep 2018 09:56:55 +0200 Subject: Linux + Clang + execstack In-Reply-To: References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> <3193b432-0068-8e2b-9ad4-f5a6467568a1@oracle.com> <6b05bebc-4b06-1071-7dc3-a338ba91c8b0@oracle.com> <7002cda6-ab66-3ff9-083b-cfc024e0c927@oracle.com> Message-ID: <098aa3f1-9fdc-c669-203b-c33355d5a43f@oracle.com> On 2018-09-19 02:01, Martin Buchholz wrote: > Unfortunately, my gmail marked Arthur's emails to this thread as spam, > with ensuing confusion. > > I retargeted this fix to the new bug > > 8209817: stack is executable when building with Clang on Linux > http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/ > https://bugs.openjdk.java.net/browse/JDK-8209817 > > and it made it through the submit repo tests. > > Ready to submit this. Please do. /Magnus > > On Thu, Sep 13, 2018 at 2:10 PM, Magnus Ihse Bursie > wrote: >>> We're not entirely happy either. >>> >>> A much higher interface might look like >>> >>> TRY_ADD_LINKER_FLAGS -z noexecstack >> Agreed. I'm working towards a solution like that. >>> which would add -Wl,-z,noexecstack to LDFLAGS when appropriate >>> .... hmmm ... >>> I only just noticed that both gcc and clang accept simply >>> $CC -z noexecstack >>> (it's even documented!) >>> Should we switch to that instead? >> No, I think it's better to keep -Wl,-z for consistency for all linker flags. >> Otherwise it just looks confusing. >> >> /Magnus >> >> >>> >>>> Do you have a JBS issue? >>> I have >>> https://bugs.openjdk.java.net/browse/JDK-8205457 gcc and clang should >>> use the same ld flags >>> but the proposed patch only addresses part of that. I could create a >>> sub-task (but I've never done that before) or a new bug or change the >>> description of this bug. What do you think? >> From martin.doerr at sap.com Wed Sep 19 08:08:33 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 19 Sep 2018 08:08:33 +0000 Subject: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) In-Reply-To: References: <67da575e-e221-5fb3-21e9-35bd5507cdd3@oracle.com> <253ebada-cf09-6340-1580-f667c2eb3de6@oracle.com> <8154d8b1-f6f3-0f39-9f42-daebc628cf02@oracle.com> <8680ff8e-dee6-dec1-060b-472278072652@oracle.com> <5BA0C921.9080409@oracle.com> <16098021-b330-448b-080a-465c8d4df3d0@oracle.com> Message-ID: Hi Dean, ok. Thanks for checking. Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of dean.long at oracle.com Sent: Dienstag, 18. September 2018 19:00 To: hotspot-dev at openjdk.java.net Subject: Re: RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native) A lot of the barrier code is saving registers around calls: ?__ pusha();???????????? // push registers (overkill) ?/* call_vm */ ?__ popa(); however, the "overkill" comment now seems like it should be "necessary for now". If we wanted to stress test our stubs and make failures like this more reproducible, we could remove the pusha/popa and make call_VM in debug builds trash the volatile registers on return. dl On 9/18/18 7:31 AM, coleen.phillimore at oracle.com wrote: > > Hi, I just pushed this because I wasn't expecting more comments. > > On 9/18/18 9:55 AM, Doerr, Martin wrote: >> Hi Coleen, >> >> is it really safe to keep a value in R9 across the barrier's runtime >> call? > > I was going to save r15 also to thread local, but since r9 wasn't the > problem we observed and is not aliased to something like rscratch1, > which invites reuse, I think it's safe for now.? I don't think this > code is future-proof and hand coded assembly for performance is > something I wish we could avoid. > >> It's specified as volatile in [1]. >> >> I think it'd be nice if we had a dedicated stub calling convention. >> Calling (almost) only cpu specific stubs via os+cpu specific C >> calling conventions is a mess. But thanks for fixing the issue. > > I would be nice if this was less of a mess.? Let me know if you find > that this doesn't fix the issue.? This wasn't reproduceable. > thanks, > Coleen >> >> Best regards, >> Martin >> >> [1] >> https://docs.microsoft.com/en-us/cpp/build/register-usage?view=vs-2017 >> >> >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> coleen.phillimore at oracle.com >> Sent: Dienstag, 18. September 2018 14:55 >> To: Erik ?sterlund ; >> hotspot-dev at openjdk.java.net >> Subject: Re: RFR 8203466: intermittent crash at >> jdk.internal.misc.Unsafe::getObjectVolatile (native) >> >> Thanks Erik! >> Coleen >> >> On 9/18/18 5:45 AM, Erik ?sterlund wrote: >>> Hi Coleen, >>> >>> Looks good. I guess the whole thing looks horrible in a way, but the >>> patch is good. >>> Thanks for fixing this. >>> >>> /Erik >>> >>> On 2018-09-18 01:47, coleen.phillimore at oracle.com wrote: >>>> >>>> On 9/17/18 5:17 PM, dean.long at oracle.com wrote: >>>>> Can you move the JavaThread _WIN64 changes to thread_windows_x86.hpp? >>>> Thanks for looking at this.? I moved it to the better place: >>>> >>>> http://cr.openjdk.java.net/~coleenp/8203466.02/webrev/index.html >>>> >>>> Retested with build and ran one test 100 times that failed once. >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> dl >>>>> >>>>> On 9/17/18 5:05 AM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> On 9/14/18 4:01 PM, dean.long at oracle.com wrote: >>>>>>> Hi Coleen.? In the bug you asked: >>>>>>> >>>>>>>> Why can't we just push rdi and rsi to the stack and restore >>>>>>> them? This code appears to be leaf code so shouldn't care about >>>>>>> stack format >>>>>>> >>>>>>> Did that ever get answered?? If there is concern about the pushes >>>>>>> and pops canceling out at the end, you could always reserve the >>>>>>> stack space at the beginning, after >>>>>>> >>>>>>> __ enter(); >>>>>>> >>>>>>> and then setup_arg_regs/restore_arg_regs would not need to adjust >>>>>>> the stack pointer. >>>>>> The reason I didn't do this is that I couldn't get it to work for >>>>>> all the various call sites.? Also, the barrier code is going to >>>>>> need the thread register sometimes which wasn't available. So I >>>>>> went with this.? I'm somewhat unclear with how this is called from >>>>>> the c2 code.? If you want to try this solution, I should probably >>>>>> give up and reassign it to compiler. >>>>>> >>>>>> thanks, >>>>>> coleen >>>>>> >>>>>>> dl >>>>>>> >>>>>>> On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote: >>>>>>>> Summary: Save windows 64 callee saved registers rsi, rdi to >>>>>>>> Thread, save r15, also callee saved to r9 >>>>>>>> >>>>>>>> This is done for generated stubs that do arraycopy that need GC >>>>>>>> barrier code because GC assumes that r10 is scratch, since it's >>>>>>>> defined as rscratch1.? See bug for more details. Thanks Erik for >>>>>>>> your help and the diagnosis. >>>>>>>> >>>>>>>> Tested with mach5 hs-tier1-7.? We don't have a reproduceable test >>>>>>>> case. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/8203466.01/webrev >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8203466 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>>>> > From matthias.baesken at sap.com Wed Sep 19 09:12:42 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 19 Sep 2018 09:12:42 +0000 Subject: OOM counters Message-ID: Hello, Currently we have already counters in the Hotspot codebase counting Java heap, Metaspace and class metaspace related OOMs. See declarations: jdk/src/hotspot/share/utilities/exceptions.hpp 107 // Count out of memory errors that are interesting in error diagnosis 108 static volatile int _out_of_memory_error_java_heap_errors; 109 static volatile int _out_of_memory_error_metaspace_errors; 110 static volatile int _out_of_memory_error_class_metaspace_errors; output : jdk/src/hotspot/share/utilities/exceptions.cpp 460void Exceptions::print_exception_counts_on_error(outputStream* st) { 461 print_oom_count(st, "java_heap_errors", _out_of_memory_error_java_heap_errors); 462 print_oom_count(st, "metaspace_errors", _out_of_memory_error_metaspace_errors); 463 print_oom_count(st, "class_metaspace_errors", _out_of_memory_error_class_metaspace_errors); 464 if (_stack_overflow_errors > 0) { 465 st->print_cr("StackOverflowErrors=%d", _stack_overflow_errors); 466 } 467 if (_linkage_errors > 0) { 468 st->print_cr("LinkageErrors=%d", _linkage_errors); 469 } 470} But currently the output is only done from vmError.cpp , in case of a) error reporting b) jcmd vm.info (in case exceptions happened, otherwise the section is not printed) (see void VMError::print_vm_info(outputStream* st) { ... } ) It would be interesting for us to get the values of the existing counters via JDK coding. In our proprietary JVM we had a similar mechanism. Is there anything planned for this (or even already something present) ? There exists already a class java/lang/management/MemoryMXBean.java with a management interface for the memory system of the Java virtual machine. It contains some "getter" - methods like public int getObjectPendingFinalizationCount(); public MemoryUsage getHeapMemoryUsage(); Do you think we could add a method (or methods) for accessing the existing OOM counters ( for example, public OomCounters getOutOfMemoryCounters(); ) ? Best regards, Matthias From patric.hedlin at oracle.com Wed Sep 19 09:25:19 2018 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Wed, 19 Sep 2018 11:25:19 +0200 Subject: RFR(XS): 8210284: "assert((av & 0x00000001) == 0) failed: unsupported V8" on Solaris 11.4 Message-ID: Dear all, I would like to ask for help to review the following change/update: Issue:? https://bugs.openjdk.java.net/browse/JDK-8210284 Webrev: http://cr.openjdk.java.net/~phedlin/tr8210284 Testing:Verified that the JVM (in debug build) will not assert on ???? ??? start-up when running Solaris 11.4, after applying the update. Best regards, Patric From nils.eliasson at oracle.com Wed Sep 19 09:28:29 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 19 Sep 2018 11:28:29 +0200 Subject: RFR(XS): 8210284: "assert((av & 0x00000001) == 0) failed: unsupported V8" on Solaris 11.4 In-Reply-To: References: Message-ID: <0ab89031-f452-0de0-4e1f-1fdfd5a6b422@oracle.com> Looks good! // Nils On 2018-09-19 11:25, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8210284 > > Webrev: http://cr.openjdk.java.net/~phedlin/tr8210284 > > > > Testing:Verified that the JVM (in debug build) will not assert on > ???? ??? start-up when running Solaris 11.4, after applying the update. > > > Best regards, > Patric From boris.ulasevich at bell-sw.com Wed Sep 19 10:30:03 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 19 Sep 2018 13:30:03 +0300 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: <990eb025-8705-8633-abd7-0e87a3dc6d33@bell-sw.com> Hi Bob, Thank you for this job! I have started testing. Will come back with results next week :) The changes is Ok for me. Please see some minor comments below. regards, Boris On 17.09.2018 20:49, Aleksey Shipilev wrote: > On 09/17/2018 07:00 PM, Vladimir Kozlov wrote: >> On 9/17/18 9:20 AM, Bob Vandette wrote: >>> Please review the changes related to JEP 340 which remove the second >>> 64-bit ARM port from the JDK.>> >>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 > > I read through the webrev, and it seems to be the clean removal. It also feels > very satisfying to drop 15 KLOC of ifdef-ed code. > > Minor nits: > > *) In src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp and > src/hotspot/cpu/arm/interp_masm_arm.cpp we have "#if defined(ASSERT)", which cab > be just "#ifdef ASSERT" now > > *) Ditto in src/hotspot/cpu/arm/jniFastGetField_arm.cpp we have "#if > defined(__ABI_HARD__)" > > *) In src/hotspot/cpu/arm/macroAssembler_arm.hpp, the comment below seems to > apply to AArch64 only. Yes, the note looks like AArch64 specific comment, but I think it is valid for arm32 too. So the change is Ok for me. > Yet, only the first line of the comment is removed. I > think we should instead convert that comment into "TODO:" mentioning this might > be revised after AArch64 removal? > > 992 void branch_if_negative_32(Register r, Label& L) { > 993 // Note about branch_if_negative_32() / branch_if_any_negative_32() > implementation for AArch64: > 994 // tbnz is not used instead of tst & b.mi because destination may be > out of tbnz range (+-32KB) > 995 // since these methods are used in LIR_Assembler::emit_arraycopy() to > jump to stub entry. > 996 tst_32(r, r); > 997 b(L, mi); > 998 } > > *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, lines L1204..1205, L1435..1436 > can be merged together: > > 1203 // Generate the inner loop for shifted forward array copy (unaligned copy). > 1204 // It can be used when bytes_per_count < wordSize, i.e. > 1205 // byte/short copy > > 1434 // Generate the inner loop for shifted backward array copy (unaligned copy). > 1435 // It can be used when bytes_per_count < wordSize, i.e. > 1436 // byte/short copy > > > *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, the comment changed > incorrectly around L3363? I believe both (L3188 and L3363) comments should mention SP[0] (not R4) as an input parameter now. > - // R4 (AArch64) / SP[0] (32-bit ARM) - element count (32-bit int) > + // R4 - element count (32-bit int) > > > *) In src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp, "R4"/"R5" > comments are missing: > > - const Register Rsig_handler = AARCH64_ONLY(R21) NOT_AARCH64(Rtmp_save0 /* > R4 */); > - const Register Rnative_code = AARCH64_ONLY(R22) NOT_AARCH64(Rtmp_save1 /* > R5 */); > + const Register Rsig_handler = Rtmp_save0; > + const Register Rnative_code = Rtmp_save1; > > Thanks, > -Aleksey > From erik.osterlund at oracle.com Wed Sep 19 12:19:23 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 19 Sep 2018 14:19:23 +0200 Subject: RFR(XS): 8210284: "assert((av & 0x00000001) == 0) failed: unsupported V8" on Solaris 11.4 In-Reply-To: References: Message-ID: <18901554-24c4-64b0-3f06-9a1d029f8d85@oracle.com> Hi Patric, Looks good. Thanks, /Erik On 2018-09-19 11:25, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8210284 > > Webrev: http://cr.openjdk.java.net/~phedlin/tr8210284 > > > > Testing:Verified that the JVM (in debug build) will not assert on > ???? ??? start-up when running Solaris 11.4, after applying the update. > > > Best regards, > Patric From matthias.baesken at sap.com Wed Sep 19 16:01:03 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 19 Sep 2018 16:01:03 +0000 Subject: OOM counters In-Reply-To: References: Message-ID: Hi JC, yes it is good to have for monitoring. However another application we have is that people wanted to trigger actions on an OOM occurrence , like doing some restarts etc . For these kind of actions they had in our proprietary JVM some kind of queue containing the latest ?prominent? errors (OOMs , but also some others). So they periodically checked the queue and in case an OOM is found , they started the desired action . There is (to some extend) a replacement for this in the VM, the XX flags ExitOnOutOfMemoryError and OnOutOfMemoryError= . However, these flags are not very flexible (always exiting is not what all people want), and executing a command forks and execs a shell (see vmError) which is quite some overhead and also a bit problematic in some cases. Best regards, Matthias From: JC Beyler Sent: Mittwoch, 19. September 2018 16:49 To: Baesken, Matthias Cc: hotspot-dev Source Developers ; serviceability-dev at openjdk.java.net Subject: Re: OOM counters Hi Matthias, In the case of an OOM, what's the use-case here? Are there cases where you are recuperating often from OOMs that the counters have different values and it's interesting to monitor? Or is it to determine which of the three got incremented by the OOM that was thrown? Finally, when would you call the MemoryMXBean new call: if you are recuperating from OOMs, I could imagine that you might be able to get the counters periodically and monitor this; if you're not, you'd be doing this call during an OOM? Thanks, Jc On Wed, Sep 19, 2018 at 2:13 AM Baesken, Matthias > wrote: Hello, Currently we have already counters in the Hotspot codebase counting Java heap, Metaspace and class metaspace related OOMs. See declarations: jdk/src/hotspot/share/utilities/exceptions.hpp 107 // Count out of memory errors that are interesting in error diagnosis 108 static volatile int _out_of_memory_error_java_heap_errors; 109 static volatile int _out_of_memory_error_metaspace_errors; 110 static volatile int _out_of_memory_error_class_metaspace_errors; output : jdk/src/hotspot/share/utilities/exceptions.cpp 460void Exceptions::print_exception_counts_on_error(outputStream* st) { 461 print_oom_count(st, "java_heap_errors", _out_of_memory_error_java_heap_errors); 462 print_oom_count(st, "metaspace_errors", _out_of_memory_error_metaspace_errors); 463 print_oom_count(st, "class_metaspace_errors", _out_of_memory_error_class_metaspace_errors); 464 if (_stack_overflow_errors > 0) { 465 st->print_cr("StackOverflowErrors=%d", _stack_overflow_errors); 466 } 467 if (_linkage_errors > 0) { 468 st->print_cr("LinkageErrors=%d", _linkage_errors); 469 } 470} But currently the output is only done from vmError.cpp , in case of a) error reporting b) jcmd vm.info (in case exceptions happened, otherwise the section is not printed) (see void VMError::print_vm_info(outputStream* st) { ... } ) It would be interesting for us to get the values of the existing counters via JDK coding. In our proprietary JVM we had a similar mechanism. Is there anything planned for this (or even already something present) ? There exists already a class java/lang/management/MemoryMXBean.java with a management interface for the memory system of the Java virtual machine. It contains some "getter" - methods like public int getObjectPendingFinalizationCount(); public MemoryUsage getHeapMemoryUsage(); Do you think we could add a method (or methods) for accessing the existing OOM counters ( for example, public OomCounters getOutOfMemoryCounters(); ) ? Best regards, Matthias -- Thanks, Jc From vladimir.kozlov at oracle.com Wed Sep 19 16:22:56 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 19 Sep 2018 09:22:56 -0700 Subject: RFR(XS): 8210284: "assert((av & 0x00000001) == 0) failed: unsupported V8" on Solaris 11.4 In-Reply-To: References: Message-ID: <88e85a78-d9a9-9b05-a895-9e1349aaecba@oracle.com> Looks good. Thanks, Vladimir On 9/19/18 2:25 AM, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8210284 > > Webrev: http://cr.openjdk.java.net/~phedlin/tr8210284 > > > > Testing:Verified that the JVM (in debug build) will not assert on > ???? ??? start-up when running Solaris 11.4, after applying the update. > > > Best regards, > Patric From david.holmes at oracle.com Wed Sep 19 06:07:01 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Sep 2018 16:07:01 +1000 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: <85236ff7-a252-ac83-ad69-1c8208a60c25@oracle.com> References: <85236ff7-a252-ac83-ad69-1c8208a60c25@oracle.com> Message-ID: On 18/09/2018 9:07 PM, Claes Redestad wrote: > Great cleanup! > > src/hotspot/share/runtime/objectMonitor.cpp: > > ? The DeferredInitialize method seems a bit silly now that it only > guards the setting of three little Knobs using a CAS.. perhaps we would > be better off wrapping these three in methods (spinLimit() { return > os::is_MP() ? 5000 : 0; }), or perhaps we can guarantee that os::is_MP > is initialized before, somehow? Either way I think we could profitably > get rid of DeferredInitialize and InitDone. It had to be deferred to a point where os::is_MP() returned an accurate result (it returns true before the number of processors is initialized). As the comment says that could now be moved e.g. to os::init_2(). It also served to avoid calling os::is_MP() all the time in the spin code - though that no longer seems to be a concern. With my changes to always treat as MP everywhere except spin-loops, os::is_MP becomes trivial and could be inlined. Cheers, David > /Claes > > On 2018-09-18 09:03, Mikael Vidstedt wrote: >> Please review this change which obsoletes the SyncKnobs flag, and >> simplifies the code by removing the resulting unused code paths. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 >> Webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ >> >> >> >> * Background (from the bug) >> >> The experimental SyncKnobs flag can in theory be used to tune the >> behavior of the synchronization primitives. The flag was convenient >> when the various algorithms were compared a long time ago. >> >> In practice the only algorithm used and tested today are the default >> one. The SyncKnobs flag no longer serves the purpose it used to, and >> is "Unstable" (the documentation of the flag says so explicitly). It >> should be obsoleted and later removed. >> >> * About the change >> >> As mentioned above this change not only obsolete the SyncKnobs flag, >> but also removes the various sub-options/knobs and prunes the >> resulting dead code. Of course I?m happy to hear your thoughts on >> that. After having asked around it seems like the knobs have not been >> used the last decade or so, and I like to think that the >> synchronization code is complex enough without what is in that case >> effectively dead code. >> >> In order to make reviewing this slightly easier I have for your >> convenience (at least I hope it is) also created a bunch of smaller >> patches which stack, each removing one specific knob. Hopefully >> they?re more or less self-explanatory, but let me know if I can help >> clarify something: >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ >> >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ >> >> >> * Testing >> >> A slightly earlier version of this patch passed the standard tier1-3 >> testing. I will run additional testing after I get some feedback. >> >> Cheers, >> Mikael >> > From david.holmes at oracle.com Wed Sep 19 06:33:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Sep 2018 16:33:15 +1000 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: References: Message-ID: Hi Mikael, Code review from 34,000ft :) Generally looks good for the algorithmic selection knobs. Though I am sad to see some of this go - specifically the code for the different queuing policies after a notify(). I have vague recollections of applications encountering pathological behaviour with particular and excessive use of wait/notify, that was fixed by changing the queuing policy. But at least that code would be relative simple to add back if someone wanted to. I have some concerns about the handling of the spin related knobs. We have sophisticated spin logic to optimise performance** which involves a large number of tuning knobs. Many of those knobs are gone as their values could only change at build time. A few remain because they are affected by os::is_MP. So what we end up with is a partial simplification where the code is no longer readily tunable (if someone needed to do it), but nor is it that simple. ** What concerns me is that we have this sophisticated but unused code, not because it is stale/dead/un-needed, but because the collective "we" has lost the ability and/or motivation to actually try and tune this as hardware has evolved. We no longer know how optimal the remaining spin knobs actually are - and certainly not across the broader range of architectures that OpenJDK now supports. Maybe the better path for this "unused code" is to start using it? I have a few specific comments: Knob_Verbose: instead of outright deleting this now should we instead have a RFE to convert to UL where appropriate and feasible (and perhaps just use tty and TraceXXX if UL can not be used). In particular logging around ForceMonitorScavenge might be useful (unless we're going to obsolete that too :) ). --- thread.cpp: This comment block is no longer relevant: 1956 // Optionally release any monitors for regular JavaThread exits. This 1957 // is provided as a work around for any bugs in monitor enter-exit 1958 // matching. This can be expensive so it is not enabled by default. I wonder if we could just assert there are no held monitors in the regular JavaThread case ... ? --- synchronizer.cpp: is verifyInUse dead code now? (I have to wonder whether everything would be shown to be okay if we turned on these checks? More generally is this a sanity check we should actually be performing in debug builds, or was this really only useful during the development of the "in use" lists? I suspect the latter.) --- objectMonitor.cpp: Aside: This comment block is out of date and can be deleted. 904 // I'd like to write one of the following: 905 // A. OrderAccess::release() ; _owner = NULL 906 // B. OrderAccess::loadstore(); OrderAccess::storestore(); _owner = NULL; 907 // Unfortunately OrderAccess::release() and OrderAccess::loadstore() both 908 // store into a _dummy variable. That store is not needed, but can result 909 // in massive wasteful coherency traffic on classic SMP systems. 910 // Instead, I use release_store(), which is implemented as just a simple 911 // ST on x64, x86 and SPARC. Thanks, David On 18/09/2018 5:03 PM, Mikael Vidstedt wrote: > > Please review this change which obsoletes the SyncKnobs flag, and simplifies the code by removing the resulting unused code paths. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ > > * Background (from the bug) > > The experimental SyncKnobs flag can in theory be used to tune the behavior of the synchronization primitives. The flag was convenient when the various algorithms were compared a long time ago. > > In practice the only algorithm used and tested today are the default one. The SyncKnobs flag no longer serves the purpose it used to, and is "Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. > > * About the change > > As mentioned above this change not only obsolete the SyncKnobs flag, but also removes the various sub-options/knobs and prunes the resulting dead code. Of course I?m happy to hear your thoughts on that. After having asked around it seems like the knobs have not been used the last decade or so, and I like to think that the synchronization code is complex enough without what is in that case effectively dead code. > > In order to make reviewing this slightly easier I have for your convenience (at least I hope it is) also created a bunch of smaller patches which stack, each removing one specific knob. Hopefully they?re more or less self-explanatory, but let me know if I can help clarify something: > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ > > * Testing > > A slightly earlier version of this patch passed the standard tier1-3 testing. I will run additional testing after I get some feedback. > > Cheers, > Mikael > From david.holmes at oracle.com Wed Sep 19 06:47:28 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Sep 2018 16:47:28 +1000 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: Message-ID: <373625dc-8171-1112-c216-38d7e0de4aea@oracle.com> > I have not updated the about-to-be-removed Oracle ARM port code. It is only the 64-bit port that is being removed so I do need to look at the other ARM code. This may get more awkward given we only support MP ARM on v6 and v7, and that some v7 variants don't support MP. David On 18/09/2018 3:32 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 > Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ > > As previously discussed in the RFC thread: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html > > > this change obsoletes the AssumeMP flag and removes the bulk of the > logic that is conditional on os::is_MP() as follows: > > 1. to gate the introduction of MP-specific features, notably memory > barriers > > The is_MP check is removed and we will always issue memory barriers > or pre-pend lock prefix etc. > > 2. to align certain patchable code sequences (method entry, call sites) > > The is_MP is removed and we always align patchable locations. > > 3. to gate certain optimizations which are questionable on uniprocessors > (see quicken_jni_functions) > > These are psuedo-memory-barriers where we manufacture a data-dependency > instead of inserting mfence/lfence (x86 example). These are treated as > #1 and is_MP is removed. > > 4. to gate optimizations which are desirable on uniprocessors > (mutex/monitor short circuits) > > These are spin controls and so is_MP remains. > > I have not updated the about-to-be-removed Oracle ARM port code. > > Testing: > ? - Tiers 1 -3 (mach5) > > Performance run TBD. > > Thanks, > David From david.holmes at oracle.com Wed Sep 19 06:44:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Sep 2018 16:44:12 +1000 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> Message-ID: Hi Bob, On 18/09/2018 11:17 PM, Bob Vandette wrote: > I only did some basic testing of the hard-float abi. Bell SW has offered to do more extensive testing > as part of this JEP. > > I have no way of knowing if any of the other profiles are being used but I would think it?s > worth keeping them in the event that someone wants to try to build/test these other configurations. > > The goal of this JEP is to eliminate the arm64 port and not cause any other changes in behavior. Sorry I was under the mistaken impression that all of the Oracle ARM port was being removed, but it is only the 64-bit part. That said it would concern me greatly if people are still building for anything older than ARMv7 with MP support! The work I'm doing to always act as-if MP is not only potentially inefficient on a uniprocessor, but for ARM variants without MP support, potentially it won't even run if instructions don't exist. I need to look into this further. Thanks, David > Bob. > > >> On Sep 17, 2018, at 10:53 PM, David Holmes wrote: >> >> Hi Bob, >> >> On 18/09/2018 2:20 AM, Bob Vandette wrote: >>> Please review the changes related to JEP 340 which remove the second 64-bit ARM port >>> from the JDK. >>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >>> I?ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. >>> I?ve run specJVM98 on the three 32-bit ARM VMs. >> >> Did you test all the ARM related abi-profiles? It seems to me they were only for Oracle's ARM32 port and may have never been used otherwise. I would have expected all that stuff to be removed. >> >> Cheers, >> David >> >>> I also verified that Linux x64 builds. >>> Bob. > From david.holmes at oracle.com Thu Sep 20 01:12:38 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Sep 2018 11:12:38 +1000 Subject: OOM counters In-Reply-To: References: Message-ID: <0d49f4e2-99e5-b22a-1127-057d30c2147e@oracle.com> Hi Matthias, Those counters, as I recall, were added to the hs_err report purely to show if an application/test had been "playing too close to the edge" before it crashed. They were never intended as user-inspectable values. I have no opinion as to whether they should be. David On 19/09/2018 7:12 PM, Baesken, Matthias wrote: > Hello,? Currently we have already counters in the Hotspot codebase > counting Java heap, > > Metaspace and class metaspace related OOMs. > > See declarations: > > jdk/src/hotspot/share/utilities/exceptions.hpp > > 107? // Count out of memory errors that are interesting in error diagnosis > > 108? static volatile int _out_of_memory_error_java_heap_errors; > > 109? static volatile int _out_of_memory_error_metaspace_errors; > > 110? static volatile int _out_of_memory_error_class_metaspace_errors; > > output : > > jdk/src/hotspot/share/utilities/exceptions.cpp > > 460void Exceptions::print_exception_counts_on_error(outputStream* st) { > > 461? print_oom_count(st, "java_heap_errors", > _out_of_memory_error_java_heap_errors); > > 462? print_oom_count(st, "metaspace_errors", > _out_of_memory_error_metaspace_errors); > > 463? print_oom_count(st, "class_metaspace_errors", > _out_of_memory_error_class_metaspace_errors); > > 464? if (_stack_overflow_errors > 0) { > > 465??? st->print_cr("StackOverflowErrors=%d", _stack_overflow_errors); > > 466? } > > 467? if (_linkage_errors > 0) { > > 468??? st->print_cr("LinkageErrors=%d", _linkage_errors); > > 469? } > > 470} > > But currently? the output is? only done from vmError.cpp , in case of > > a)? error reporting > > b)? jcmd? vm.info? (in case exceptions happened, otherwise the section > is not printed) > > (see void VMError::print_vm_info(outputStream* st) { ... } ) > > It would be interesting for us to get the values of the existing > counters via JDK coding. > > In our proprietary JVM we had a similar mechanism. > > Is there anything planned for this (or even already something present) ? > > There exists already a class java/lang/management/MemoryMXBean.java > with a? management interface for the memory system of > > the Java virtual machine.? It contains some "getter" - methods like > > ??? public int getObjectPendingFinalizationCount(); > > ??? public MemoryUsage getHeapMemoryUsage(); > > Do you think we could add a method (or methods) for accessing the > existing OOM counters > > ( for example,? public OomCounters getOutOfMemoryCounters();? ) ? > > Best regards, Matthias > From mikael.vidstedt at oracle.com Thu Sep 20 05:12:38 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 19 Sep 2018 22:12:38 -0700 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: References: Message-ID: <1D612813-2ABB-4226-8ED4-5F541C22B4E6@oracle.com> > On Sep 18, 2018, at 11:33 PM, David Holmes wrote: > > Hi Mikael, > > Code review from 34,000ft :) Ha! :) > Generally looks good for the algorithmic selection knobs. Though I am sad to see some of this go - specifically the code for the different queuing policies after a notify(). I have vague recollections of applications encountering pathological behaviour with particular and excessive use of wait/notify, that was fixed by changing the queuing policy. But at least that code would be relative simple to add back if someone wanted to. > > I have some concerns about the handling of the spin related knobs. We have sophisticated spin logic to optimise performance** which involves a large number of tuning knobs. Many of those knobs are gone as their values could only change at build time. A few remain because they are affected by os::is_MP. So what we end up with is a partial simplification where the code is no longer readily tunable (if someone needed to do it), but nor is it that simple. > > ** What concerns me is that we have this sophisticated but unused code, not because it is stale/dead/un-needed, but because the collective "we" has lost the ability and/or motivation to actually try and tune this as hardware has evolved. We no longer know how optimal the remaining spin knobs actually are - and certainly not across the broader range of architectures that OpenJDK now supports. Maybe the better path for this "unused code" is to start using it? Right, it all comes down to priorities and where we spend our time (no pun intended). Since nobody seems to have looked at/used/changed this recently I think we?ll have to assume and accept that this is not the area we consider in need of the most attention right now. Simplifying the code at least means we get rid of the unused complexity, and it?s easier for people to understand the part of the algorithm and code actually used today. > I have a few specific comments: > > Knob_Verbose: instead of outright deleting this now should we instead have a RFE to convert to UL where appropriate and feasible (and perhaps just use tty and TraceXXX if UL can not be used). In particular logging around ForceMonitorScavenge might be useful (unless we're going to obsolete that too :) ). I?d be very hesitant to spend time on investigating the interaction with UL and/or introducing a trace flag unless the logging is actually useful, and I personally haven?t seen any evidence of that, at least not in modern times. Do speak up if you read this and have found it useful enough to motivate the investment! > --- > > thread.cpp: > > This comment block is no longer relevant: > > 1956 // Optionally release any monitors for regular JavaThread exits. This > 1957 // is provided as a work around for any bugs in monitor enter-exit > 1958 // matching. This can be expensive so it is not enabled by default. Good catch, consider it removed! > I wonder if we could just assert there are no held monitors in the regular JavaThread case ? ? Good question, I don?t have an answer :) > > --- > > synchronizer.cpp: > > is verifyInUse dead code now? (I have to wonder whether everything would be shown to be okay if we turned on these checks? More generally is this a sanity check we should actually be performing in debug builds, or was this really only useful during the development of the "in use" lists? I suspect the latter.) Yes, Coleen also found that verifyInUse is indeed dead - consider it gone (in webrev.01). > > --- > > objectMonitor.cpp: > > Aside: This comment block is out of date and can be deleted. > > 904 // I'd like to write one of the following: > 905 // A. OrderAccess::release() ; _owner = NULL > 906 // B. OrderAccess::loadstore(); OrderAccess::storestore(); _owner = NULL; > 907 // Unfortunately OrderAccess::release() and OrderAccess::loadstore() both > 908 // store into a _dummy variable. That store is not needed, but can result > 909 // in massive wasteful coherency traffic on classic SMP systems. > 910 // Instead, I use release_store(), which is implemented as just a simple > 911 // ST on x64, x86 and SPARC. Consider it removed! New webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-full/open/webrev/ Incremental changes from webrev.01: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-04.2-Knob_ExitRelease/open/webrev/ http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-20.2-Knob_ExitPolicy/open/webrev/ Cheers, Mikael > > Thanks, > David > > On 18/09/2018 5:03 PM, Mikael Vidstedt wrote: >> Please review this change which obsoletes the SyncKnobs flag, and simplifies the code by removing the resulting unused code paths. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ >> * Background (from the bug) >> The experimental SyncKnobs flag can in theory be used to tune the behavior of the synchronization primitives. The flag was convenient when the various algorithms were compared a long time ago. >> In practice the only algorithm used and tested today are the default one. The SyncKnobs flag no longer serves the purpose it used to, and is "Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. >> * About the change >> As mentioned above this change not only obsolete the SyncKnobs flag, but also removes the various sub-options/knobs and prunes the resulting dead code. Of course I?m happy to hear your thoughts on that. After having asked around it seems like the knobs have not been used the last decade or so, and I like to think that the synchronization code is complex enough without what is in that case effectively dead code. >> In order to make reviewing this slightly easier I have for your convenience (at least I hope it is) also created a bunch of smaller patches which stack, each removing one specific knob. Hopefully they?re more or less self-explanatory, but let me know if I can help clarify something: >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ >> * Testing >> A slightly earlier version of this patch passed the standard tier1-3 testing. I will run additional testing after I get some feedback. >> Cheers, >> Mikael From matthias.baesken at sap.com Thu Sep 20 06:43:19 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 20 Sep 2018 06:43:19 +0000 Subject: OOM counters In-Reply-To: <0d49f4e2-99e5-b22a-1127-057d30c2147e@oracle.com> References: <0d49f4e2-99e5-b22a-1127-057d30c2147e@oracle.com> Message-ID: Hi David , the values are already user-inspectable via jcmd vm.info , however this way is not very user friendly (and I am not sure how stable it is between updates / releases). Probably not as stable as an API . Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Donnerstag, 20. September 2018 03:13 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; serviceability- > dev at openjdk.java.net serviceability-dev at openjdk.java.net dev at openjdk.java.net> > Subject: Re: OOM counters > > Hi Matthias, > > > Those counters, as I recall, were added to the hs_err report purely to > show if an application/test had been "playing too close to the edge" > before it crashed. They were never intended as user-inspectable values. > > I have no opinion as to whether they should be. > > David > > On 19/09/2018 7:12 PM, Baesken, Matthias wrote: > > Hello,? Currently we have already counters in the Hotspot codebase > > counting Java heap, > > > > Metaspace and class metaspace related OOMs. > > > > See declarations: > > > > jdk/src/hotspot/share/utilities/exceptions.hpp > > > > 107? // Count out of memory errors that are interesting in error diagnosis > > > > 108? static volatile int _out_of_memory_error_java_heap_errors; > > > > 109? static volatile int _out_of_memory_error_metaspace_errors; > > > > 110? static volatile int _out_of_memory_error_class_metaspace_errors; > > > > output : > > > > jdk/src/hotspot/share/utilities/exceptions.cpp > > > > 460void Exceptions::print_exception_counts_on_error(outputStream* st) > { > > > > 461? print_oom_count(st, "java_heap_errors", > > _out_of_memory_error_java_heap_errors); > > > > 462? print_oom_count(st, "metaspace_errors", > > _out_of_memory_error_metaspace_errors); > > > > 463? print_oom_count(st, "class_metaspace_errors", > > _out_of_memory_error_class_metaspace_errors); > > > > 464? if (_stack_overflow_errors > 0) { > > > > 465??? st->print_cr("StackOverflowErrors=%d", _stack_overflow_errors); > > > > 466? } > > > > 467? if (_linkage_errors > 0) { > > > > 468??? st->print_cr("LinkageErrors=%d", _linkage_errors); > > > > 469? } > > > > 470} > > > > But currently? the output is? only done from vmError.cpp , in case of > > > > a)? error reporting > > > > b)? jcmd? vm.info? (in case exceptions happened, otherwise the section > > is not printed) > > > > (see void VMError::print_vm_info(outputStream* st) { ... } ) > > > > It would be interesting for us to get the values of the existing > > counters via JDK coding. > > > > In our proprietary JVM we had a similar mechanism. > > > > Is there anything planned for this (or even already something present) ? > > > > There exists already a class java/lang/management/MemoryMXBean.java > > with a? management interface for the memory system of > > > > the Java virtual machine.? It contains some "getter" - methods like > > > > ??? public int getObjectPendingFinalizationCount(); > > > > ??? public MemoryUsage getHeapMemoryUsage(); > > > > Do you think we could add a method (or methods) for accessing the > > existing OOM counters > > > > ( for example,? public OomCounters getOutOfMemoryCounters();? ) ? > > > > Best regards, Matthias > > From boris.ulasevich at bell-sw.com Thu Sep 20 07:31:34 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Thu, 20 Sep 2018 10:31:34 +0300 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: Message-ID: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> Hi David, > I have not updated the about-to-be-removed Oracle ARM port code. Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. I would propose the following change - I think we can either add it to your update or to create a separate RFR after your patch and JEP-340 commit: http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ regards, Boris On 18.09.2018 08:32, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 > Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ > > As previously discussed in the RFC thread: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html > > > this change obsoletes the AssumeMP flag and removes the bulk of the > logic that is conditional on os::is_MP() as follows: > > 1. to gate the introduction of MP-specific features, notably memory > barriers > > The is_MP check is removed and we will always issue memory barriers > or pre-pend lock prefix etc. > > 2. to align certain patchable code sequences (method entry, call sites) > > The is_MP is removed and we always align patchable locations. > > 3. to gate certain optimizations which are questionable on uniprocessors > (see quicken_jni_functions) > > These are psuedo-memory-barriers where we manufacture a data-dependency > instead of inserting mfence/lfence (x86 example). These are treated as > #1 and is_MP is removed. > > 4. to gate optimizations which are desirable on uniprocessors > (mutex/monitor short circuits) > > These are spin controls and so is_MP remains. > > I have not updated the about-to-be-removed Oracle ARM port code. > > Testing: > ? - Tiers 1 -3 (mach5) > > Performance run TBD. > > Thanks, > David From patric.hedlin at oracle.com Thu Sep 20 08:02:30 2018 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Thu, 20 Sep 2018 10:02:30 +0200 Subject: RFR(XS): 8210284: "assert((av & 0x00000001) == 0) failed: unsupported V8" on Solaris 11.4 In-Reply-To: <0ab89031-f452-0de0-4e1f-1fdfd5a6b422@oracle.com> References: <0ab89031-f452-0de0-4e1f-1fdfd5a6b422@oracle.com> Message-ID: <0616ff96-2d59-ed46-0420-0a0f89d61087@oracle.com> Thanks Nils, Erik and Vladimir. /Patric On 09/19/2018 06:22 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir On 09/19/2018 02:19 PM, Erik ?sterlund wrote: > Hi Patric, > > Looks good. > > Thanks, > /Erik On 09/19/2018 11:28 AM, Nils Eliasson wrote: > Looks good! > > // Nils > > > On 2018-09-19 11:25, Patric Hedlin wrote: >> Dear all, >> >> I would like to ask for help to review the following change/update: >> >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8210284 >> >> Webrev: http://cr.openjdk.java.net/~phedlin/tr8210284 >> >> >> >> Testing: Verified that the JVM (in debug build) will not assert on >> ???? ??? start-up when running Solaris 11.4, after applying the update. >> >> >> Best regards, >> Patric From patric.hedlin at oracle.com Thu Sep 20 09:53:12 2018 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Thu, 20 Sep 2018 11:53:12 +0200 Subject: RFR(S): JDK-8191339: [JVMCI] BigInteger compiler intrinsics on Graal. In-Reply-To: <02f34a26-2a97-6a30-384f-115327781aac@oracle.com> References: <28011331-bd43-2c32-dba4-e41879ffe28a@oracle.com> <02f34a26-2a97-6a30-384f-115327781aac@oracle.com> Message-ID: <661f70d5-7a09-d181-5669-9841b590c7a3@oracle.com> Hi Vladimir, Andrew, Sorry for dropping this after vacation. The testing is a simplistic benchmark (soon to be... I hope) added to Graal (and some directed, a bit to ad hoc, testing not meant for up-streaming to Graal). I also used a simplified version of a more general JVMCI/VM test case for these options only, but it really does only exercise the JVMCI (not the option propagation in Graal or some other JVMCI "client"), making it less useful. But in essence, Graal is the test-case. On 2018-06-22 18:04, Vladimir Kozlov wrote: > Hi Patric, > > Do you need Graal changes for this? Or it already has these intrinsics > and the only problem is these flags were not set in vm_version_x86.cpp? No further changes have been made to Graal. > > Small note. In vm_version_x86.cpp previous code has already > COMPILER2_OR_JVMCI check. You can remove previous #endif and new > #ifdef. Also change comment for closing #endif at line 1080 to // > COMPILER2_OR_JVMCI > > 1080 #endif // COMPILER2 You are right (actually the intended webrev) and it should look correct now (just a tad old). Best regards, Patric > > What testing you did? > > Thanks, > Vladimir > > On 6/21/18 8:26 AM, Patric Hedlin wrote: >> Dear all, >> >> I would like to ask for help to review the following change/update: >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8191339 >> >> Webrev: http://cr.openjdk.java.net/~phedlin/tr8191339/ >> >> >> 8191339: [JVMCI] BigInteger compiler intrinsics on Graal. >> >> ???? Enabling BigInteger intrinsics via JVMCI. >> >> >> >> Best regards, >> Patric From simon at cjnash.com Thu Sep 20 11:48:48 2018 From: simon at cjnash.com (Simon Nash) Date: Thu, 20 Sep 2018 12:48:48 +0100 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> Message-ID: <5BA38920.8020203@cjnash.com> On 19/09/2018 07:44, David Holmes wrote: > Hi Bob, > > On 18/09/2018 11:17 PM, Bob Vandette wrote: >> I only did some basic testing of the hard-float abi. Bell SW has >> offered to do more extensive testing >> as part of this JEP. >> >> I have no way of knowing if any of the other profiles are being used >> but I would think it?s >> worth keeping them in the event that someone wants to try to >> build/test these other configurations. >> >> The goal of this JEP is to eliminate the arm64 port and not cause any >> other changes in behavior. > > Sorry I was under the mistaken impression that all of the Oracle ARM > port was being removed, but it is only the 64-bit part. > > That said it would concern me greatly if people are still building for > anything older than ARMv7 with MP support! The work I'm doing to always > act as-if MP is not only potentially inefficient on a uniprocessor, but > for ARM variants without MP support, potentially it won't even run if > instructions don't exist. I need to look into this further. > > Thanks, > David > David, My build for arm-sflt needs to run on ARMv5 uniprocessor maschines and my build for arm-vfp-hflt needs to run on ARMv7 uniprocessor machines. Is the work you are doing that could cause problems with this included in JDK11 or just JDK12? Simon >> Bob. >> >> >>> On Sep 17, 2018, at 10:53 PM, David Holmes >>> wrote: >>> >>> Hi Bob, >>> >>> On 18/09/2018 2:20 AM, Bob Vandette wrote: >>>> Please review the changes related to JEP 340 which remove the second >>>> 64-bit ARM port >>>> from the JDK. >>>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >>>> I?ve testing building the remaining 32 and 64 bit ARM ports >>>> including the minimal, client and server VMs. >>>> I?ve run specJVM98 on the three 32-bit ARM VMs. >>> >>> Did you test all the ARM related abi-profiles? It seems to me they >>> were only for Oracle's ARM32 port and may have never been used >>> otherwise. I would have expected all that stuff to be removed. >>> >>> Cheers, >>> David >>> >>>> I also verified that Linux x64 builds. >>>> Bob. >> > From matthias.baesken at sap.com Thu Sep 20 12:13:07 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 20 Sep 2018 12:13:07 +0000 Subject: RFR [XS] : 8210961: [aix] enhance list of environment variables reported in error log file on AIX Message-ID: Hello, Please review this small enhancement. It adds these AIX-related environment variables to the already existing list of environment variables that should be reported in error log file (hs_err file) : LIBPATH : environment variable to locate shared libraries , see https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.1.0/com.ibm.java.aix.71.doc/user/setlpath.html LDR_PRELOAD / LDR_PRELOAD64 : similar to LD_PRELOAD on Linux , see https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.performance/preloading_shared_libraries.htm http://cr.openjdk.java.net/~mbaesken/webrevs/8210961/ bug : https://bugs.openjdk.java.net/browse/JDK-8210961 Thanks, Matthias From john.r.rose at oracle.com Thu Sep 20 13:34:48 2018 From: john.r.rose at oracle.com (John Rose) Date: Thu, 20 Sep 2018 09:34:48 -0400 Subject: RFC 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <7fc85a74-9309-556a-3fc6-eb4c7236f921@redhat.com> References: <6775CB01-428C-4214-B722-FD21FCEF93F5@oracle.com> <0a663580-17ab-413c-416d-c3af4773d8e4@oracle.com> <7475c0ef-4b75-6130-f43f-63c2e3806ddb@oracle.com> <7fc85a74-9309-556a-3fc6-eb4c7236f921@redhat.com> Message-ID: On Sep 15, 2018, at 4:32 AM, Andrew Haley wrote: > > On 09/14/2018 02:17 AM, John Rose wrote: > >> Therefore, if there is any chance of a race condition, we try to >> patch only naturally aligned words, as single, full-word writes. > > Thanks for that. It was very difficult to understand what the code was > doing when I ported it to AArch64. > > It would be very nice to have this commentary in the source code. May > I submit this as a comment-only patch? Yes, of course. ? John From daniel.daugherty at oracle.com Thu Sep 20 14:49:39 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 20 Sep 2018 10:49:39 -0400 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: <1D612813-2ABB-4226-8ED4-5F541C22B4E6@oracle.com> References: <1D612813-2ABB-4226-8ED4-5F541C22B4E6@oracle.com> Message-ID: >> I wonder if we could just assert there are no held monitors in the regular JavaThread case ? ? > Good question, I don?t have an answer :) > We have some JNI tests that intentionally leave monitors locked when the program exits. Jerry and I ran into this years ago when trying to add an assert there. Dan On 9/20/18 1:12 AM, Mikael Vidstedt wrote: > >> On Sep 18, 2018, at 11:33 PM, David Holmes wrote: >> >> Hi Mikael, >> >> Code review from 34,000ft :) > Ha! :) > >> Generally looks good for the algorithmic selection knobs. Though I am sad to see some of this go - specifically the code for the different queuing policies after a notify(). I have vague recollections of applications encountering pathological behaviour with particular and excessive use of wait/notify, that was fixed by changing the queuing policy. But at least that code would be relative simple to add back if someone wanted to. >> >> I have some concerns about the handling of the spin related knobs. We have sophisticated spin logic to optimise performance** which involves a large number of tuning knobs. Many of those knobs are gone as their values could only change at build time. A few remain because they are affected by os::is_MP. So what we end up with is a partial simplification where the code is no longer readily tunable (if someone needed to do it), but nor is it that simple. >> >> ** What concerns me is that we have this sophisticated but unused code, not because it is stale/dead/un-needed, but because the collective "we" has lost the ability and/or motivation to actually try and tune this as hardware has evolved. We no longer know how optimal the remaining spin knobs actually are - and certainly not across the broader range of architectures that OpenJDK now supports. Maybe the better path for this "unused code" is to start using it? > Right, it all comes down to priorities and where we spend our time (no pun intended). Since nobody seems to have looked at/used/changed this recently I think we?ll have to assume and accept that this is not the area we consider in need of the most attention right now. Simplifying the code at least means we get rid of the unused complexity, and it?s easier for people to understand the part of the algorithm and code actually used today. > >> I have a few specific comments: >> >> Knob_Verbose: instead of outright deleting this now should we instead have a RFE to convert to UL where appropriate and feasible (and perhaps just use tty and TraceXXX if UL can not be used). In particular logging around ForceMonitorScavenge might be useful (unless we're going to obsolete that too :) ). > I?d be very hesitant to spend time on investigating the interaction with UL and/or introducing a trace flag unless the logging is actually useful, and I personally haven?t seen any evidence of that, at least not in modern times. Do speak up if you read this and have found it useful enough to motivate the investment! > >> --- >> >> thread.cpp: >> >> This comment block is no longer relevant: >> >> 1956 // Optionally release any monitors for regular JavaThread exits. This >> 1957 // is provided as a work around for any bugs in monitor enter-exit >> 1958 // matching. This can be expensive so it is not enabled by default. > Good catch, consider it removed! > >> I wonder if we could just assert there are no held monitors in the regular JavaThread case ? ? > Good question, I don?t have an answer :) > >> --- >> >> synchronizer.cpp: >> >> is verifyInUse dead code now? (I have to wonder whether everything would be shown to be okay if we turned on these checks? More generally is this a sanity check we should actually be performing in debug builds, or was this really only useful during the development of the "in use" lists? I suspect the latter.) > Yes, Coleen also found that verifyInUse is indeed dead - consider it gone (in webrev.01). > >> --- >> >> objectMonitor.cpp: >> >> Aside: This comment block is out of date and can be deleted. >> >> 904 // I'd like to write one of the following: >> 905 // A. OrderAccess::release() ; _owner = NULL >> 906 // B. OrderAccess::loadstore(); OrderAccess::storestore(); _owner = NULL; >> 907 // Unfortunately OrderAccess::release() and OrderAccess::loadstore() both >> 908 // store into a _dummy variable. That store is not needed, but can result >> 909 // in massive wasteful coherency traffic on classic SMP systems. >> 910 // Instead, I use release_store(), which is implemented as just a simple >> 911 // ST on x64, x86 and SPARC. > Consider it removed! > > > New webrev: > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-full/open/webrev/ > > Incremental changes from webrev.01: > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-04.2-Knob_ExitRelease/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-20.2-Knob_ExitPolicy/open/webrev/ > > Cheers, > Mikael > >> Thanks, >> David >> >> On 18/09/2018 5:03 PM, Mikael Vidstedt wrote: >>> Please review this change which obsoletes the SyncKnobs flag, and simplifies the code by removing the resulting unused code paths. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 >>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ >>> * Background (from the bug) >>> The experimental SyncKnobs flag can in theory be used to tune the behavior of the synchronization primitives. The flag was convenient when the various algorithms were compared a long time ago. >>> In practice the only algorithm used and tested today are the default one. The SyncKnobs flag no longer serves the purpose it used to, and is "Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. >>> * About the change >>> As mentioned above this change not only obsolete the SyncKnobs flag, but also removes the various sub-options/knobs and prunes the resulting dead code. Of course I?m happy to hear your thoughts on that. After having asked around it seems like the knobs have not been used the last decade or so, and I like to think that the synchronization code is complex enough without what is in that case effectively dead code. >>> In order to make reviewing this slightly easier I have for your convenience (at least I hope it is) also created a bunch of smaller patches which stack, each removing one specific knob. Hopefully they?re more or less self-explanatory, but let me know if I can help clarify something: >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ >>> * Testing >>> A slightly earlier version of this patch passed the standard tier1-3 testing. I will run additional testing after I get some feedback. >>> Cheers, >>> Mikael From david.holmes at oracle.com Thu Sep 20 15:26:33 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Sep 2018 11:26:33 -0400 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> References: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> Message-ID: Hi Boris, Thanks for jumping on this. I hope you didn't spend too much time on it as I had actually started on the ARM code then decided I didn't need to make the changes, so I'd already gone through pretty much everything that is needed. My concern is with things like the change in src/hotspot/cpu/arm/assembler_arm_32.hpp where you removed the is_MP() check but in fact that needs to remain because the instruction pldw is not present on variants of the v7 architecture without the multi-processor extensions: http://www.keil.com/support/man/docs/armclang_asm/armclang_asm_pge1425899018492.htm That makes me wonder whether any of the memory barrier instructions may also be missing in some v6/v7 variants as well? Plus I have to account for uniprocessor ARMv5 so need to see whether MacroAssembler::membar, for example, must also retain the is_MP() check. Also in: src/hotspot/cpu/arm/stubGenerator_arm.cpp you can't remove the !is_MP() check and related code as that is needed for ARMv5 (uniprocessor) support. Similarly in src/hotspot/cpu/arm/vm_version_arm_32.cpp you'll probably still want to disable biased-locking for ARMv5. Cheers, David On 20/09/2018 3:31 AM, Boris Ulasevich wrote: > Hi David, > > > I have not updated the about-to-be-removed Oracle ARM port code. > > Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. > I would propose the following change - I think we can either add it to > your update or to create a separate RFR after your patch and JEP-340 > commit: > > http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ > > regards, > Boris > > On 18.09.2018 08:32, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >> >> As previously discussed in the RFC thread: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >> >> >> this change obsoletes the AssumeMP flag and removes the bulk of the >> logic that is conditional on os::is_MP() as follows: >> >> 1. to gate the introduction of MP-specific features, notably memory >> barriers >> >> The is_MP check is removed and we will always issue memory barriers >> or pre-pend lock prefix etc. >> >> 2. to align certain patchable code sequences (method entry, call sites) >> >> The is_MP is removed and we always align patchable locations. >> >> 3. to gate certain optimizations which are questionable on uniprocessors >> (see quicken_jni_functions) >> >> These are psuedo-memory-barriers where we manufacture a data-dependency >> instead of inserting mfence/lfence (x86 example). These are treated as >> #1 and is_MP is removed. >> >> 4. to gate optimizations which are desirable on uniprocessors >> (mutex/monitor short circuits) >> >> These are spin controls and so is_MP remains. >> >> I have not updated the about-to-be-removed Oracle ARM port code. >> >> Testing: >> ?? - Tiers 1 -3 (mach5) >> >> Performance run TBD. >> >> Thanks, >> David From volker.simonis at gmail.com Thu Sep 20 15:40:58 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 20 Sep 2018 17:40:58 +0200 Subject: RFR [XS] : 8210961: [aix] enhance list of environment variables reported in error log file on AIX In-Reply-To: References: Message-ID: Hi Matthias, looks good! Do we really need LDR_PRELOAD? The documentation you've linked mentions that it is only used for 32-bit process which we don't support anyway. I think it may be better to leave it out completely, otherwise people may get confused if they see that LDR_PRELOAD was defined. Thank you and best regards, Volker On Thu, Sep 20, 2018 at 2:13 PM Baesken, Matthias wrote: > > Hello, Please review this small enhancement. > > It adds these AIX-related environment variables to the already existing list of environment variables that should be reported in error log file (hs_err file) : > > LIBPATH : environment variable to locate shared libraries , see https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.1.0/com.ibm.java.aix.71.doc/user/setlpath.html > > LDR_PRELOAD / LDR_PRELOAD64 : similar to LD_PRELOAD on Linux , see https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm.aix.performance/preloading_shared_libraries.htm > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8210961/ > > bug : https://bugs.openjdk.java.net/browse/JDK-8210961 > > > Thanks, Matthias From aph at redhat.com Thu Sep 20 17:32:51 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Sep 2018 18:32:51 +0100 Subject: RFR: 8210972: Add comment text to C1 patching code Message-ID: John Rose explained how our patching algorithm is supposed to work. This information is much too useful to languish in an email. http://cr.openjdk.java.net/~aph/8210972/ -- 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 Thu Sep 20 17:57:35 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 20 Sep 2018 10:57:35 -0700 Subject: RFR: 8210972: Add comment text to C1 patching code In-Reply-To: References: Message-ID: Looks good. what is 'NB:'? Thanks, Vladimir On 9/20/18 10:32 AM, Andrew Haley wrote: > John Rose explained how our patching algorithm is supposed to > work. This information is much too useful to languish in an email. > > http://cr.openjdk.java.net/~aph/8210972/ > From forax at univ-mlv.fr Thu Sep 20 18:02:34 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 20 Sep 2018 20:02:34 +0200 (CEST) Subject: RFR: 8210972: Add comment text to C1 patching code In-Reply-To: References: Message-ID: <733398684.1135878.1537466554534.JavaMail.zimbra@u-pem.fr> Nota Bene. R?mi ----- Mail original ----- > De: "Vladimir Kozlov" > ?: "Andrew Haley" , "hotspot-dev" > Envoy?: Jeudi 20 Septembre 2018 19:57:35 > Objet: Re: RFR: 8210972: Add comment text to C1 patching code > Looks good. what is 'NB:'? > > Thanks, > Vladimir > > On 9/20/18 10:32 AM, Andrew Haley wrote: >> John Rose explained how our patching algorithm is supposed to >> work. This information is much too useful to languish in an email. >> >> http://cr.openjdk.java.net/~aph/8210972/ From david.holmes at oracle.com Fri Sep 21 02:34:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Sep 2018 22:34:19 -0400 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <5BA38920.8020203@cjnash.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> <5BA38920.8020203@cjnash.com> Message-ID: Hi Simon, On 20/09/2018 7:48 AM, Simon Nash wrote: > On 19/09/2018 07:44, David Holmes wrote: >> Hi Bob, >> >> On 18/09/2018 11:17 PM, Bob Vandette wrote: >>> I only did some basic testing of the hard-float abi.? Bell SW has >>> offered to do more extensive testing >>> as part of this JEP. >>> >>> I have no way of knowing if any of the other profiles are being used >>> but I would think it?s >>> worth keeping them in the event that someone wants to try to >>> build/test these other configurations. >>> >>> The goal of this JEP is to eliminate the arm64 port and not cause any >>> other changes in behavior. >> >> Sorry I was under the mistaken impression that all of the Oracle ARM >> port was being removed, but it is only the 64-bit part. >> >> That said it would concern me greatly if people are still building for >> anything older than ARMv7 with MP support! The work I'm doing to >> always act as-if MP is not only potentially inefficient on a >> uniprocessor, but for ARM variants without MP support, potentially it >> won't even run if instructions don't exist. I need to look into this >> further. >> >> Thanks, >> David >> > David, > My build for arm-sflt needs to run on ARMv5 uniprocessor maschines and > my build for arm-vfp-hflt needs to run on ARMv7 uniprocessor machines. > Is the work you are doing that could cause problems with this included > in JDK11 or just JDK12? This is for JDK 12. Of course the intent is to not cause problems for anyone. The changes aim at simplifying the code whilst marginally improving performance in the common case of a multi-processor system, at the expense of potentially decreasing performance for uniprocessors. Though as has been pointed out in my review thread, the existing use of AssumeMP (default true) will be causing the same performance changes and for spinlocks my changes will improve things for uniprocessors. My area of concern is where instructions issued for the MP case may not be valid on specific architectures. For example pldw is only available on ARMv7 with multi-processor extensions. I need to be sure, for example, only supported DMB/DSB variants are issued on ARMv5. Thanks, David > Simon > >>> Bob. >>> >>> >>>> On Sep 17, 2018, at 10:53 PM, David Holmes >>>> wrote: >>>> >>>> Hi Bob, >>>> >>>> On 18/09/2018 2:20 AM, Bob Vandette wrote: >>>>> Please review the changes related to JEP 340 which remove the >>>>> second 64-bit ARM port >>>>> from the JDK. >>>>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >>>>> I?ve testing building the remaining 32 and 64 bit ARM ports >>>>> including the minimal, client and server VMs. >>>>> I?ve run specJVM98 on the three 32-bit ARM VMs. >>>> >>>> Did you test all the ARM related abi-profiles? It seems to me they >>>> were only for Oracle's ARM32 port and may have never been used >>>> otherwise. I would have expected all that stuff to be removed. >>>> >>>> Cheers, >>>> David >>>> >>>>> I also verified that Linux x64 builds. >>>>> Bob. >>> >> > From matthias.baesken at sap.com Fri Sep 21 06:54:32 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 21 Sep 2018 06:54:32 +0000 Subject: RFR [XS] : 8210961: [aix] enhance list of environment variables reported in error log file on AIX In-Reply-To: References: Message-ID: Hi Volker, sure the LDR_PRELOAD might not be so important any more these days . However it might be fine to have it included in the list of environment variables for the sake of completeness ( in it is maybe of interest in cases where we start other (32bit) binaries from java ). Best regards, Matthias > -----Original Message----- > From: Volker Simonis > Sent: Donnerstag, 20. September 2018 17:41 > To: Baesken, Matthias > Cc: HotSpot Open Source Developers > Subject: Re: RFR [XS] : 8210961: [aix] enhance list of environment variables > reported in error log file on AIX > > Hi Matthias, > > looks good! > > Do we really need LDR_PRELOAD? The documentation you've linked > mentions that it is only used for 32-bit process which we don't > support anyway. > > I think it may be better to leave it out completely, otherwise people > may get confused if they see that LDR_PRELOAD was defined. > > Thank you and best regards, > Volker > > On Thu, Sep 20, 2018 at 2:13 PM Baesken, Matthias > wrote: > > > > Hello, Please review this small enhancement. > > > > It adds these AIX-related environment variables to the already existing list > of environment variables that should be reported in error log file (hs_err file) > : > > > > LIBPATH : environment variable to locate shared libraries , see > https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.1.0/com.ib > m.java.aix.71.doc/user/setlpath.html > > > > LDR_PRELOAD / LDR_PRELOAD64 : similar to LD_PRELOAD on Linux , see > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm. > aix.performance/preloading_shared_libraries.htm > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8210961/ > > > > bug : https://bugs.openjdk.java.net/browse/JDK-8210961 > > > > > > Thanks, Matthias From matthias.baesken at sap.com Fri Sep 21 09:13:10 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 21 Sep 2018 09:13:10 +0000 Subject: RFR [XS] 8210964: add more ld preloading info to hs_error file on Linux Message-ID: Hello , please review this small patch . It adds more information about pre-loading configs of libs on Linux (often used for monitoring tools). Currently the hs_err file contains already the LD_PRELOAD environment variable. However for system wide configuration, the /etc/ld.so.preload file is important as well on Linux. So display it as well (in case it is present). See the Environment / LD_PRELOAD and FILES sections of : http://man7.org/linux/man-pages/man8/ld.so.8.html for more information . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8210964 http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.0/ Thanks, Matthias From christoph.langer at sap.com Fri Sep 21 12:12:05 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 21 Sep 2018 12:12:05 +0000 Subject: RFR [XS] : 8210961: [aix] enhance list of environment variables reported in error log file on AIX In-Reply-To: References: Message-ID: Hi Matthias, this change looks good, helpful additions. Best regards Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Donnerstag, 20. September 2018 14:13 > To: 'hotspot-dev at openjdk.java.net' > Subject: RFR [XS] : 8210961: [aix] enhance list of environment variables > reported in error log file on AIX > > Hello, Please review this small enhancement. > > It adds these AIX-related environment variables to the already existing list > of environment variables that should be reported in error log file (hs_err file) > : > > LIBPATH : environment variable to locate shared libraries , see > https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.1.0/com.ib > m.java.aix.71.doc/user/setlpath.html > > LDR_PRELOAD / LDR_PRELOAD64 : similar to LD_PRELOAD on Linux , see > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm. > aix.performance/preloading_shared_libraries.htm > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8210961/ > > bug : https://bugs.openjdk.java.net/browse/JDK-8210961 > > > Thanks, Matthias From boris.ulasevich at bell-sw.com Fri Sep 21 13:34:05 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 21 Sep 2018 16:34:05 +0300 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> Message-ID: Hi David, On 20.09.2018 18:26, David Holmes wrote: > Hi Boris, > > Thanks for jumping on this. I hope you didn't spend too much time on it > as I had actually started on the ARM code then decided I didn't need to > make the changes, so I'd already gone through pretty much everything > that is needed. My concern is with things like the change in > > src/hotspot/cpu/arm/assembler_arm_32.hpp > > where you removed the is_MP() check but in fact that needs to remain > because the instruction pldw is not present on variants of the v7 > architecture without the multi-processor extensions: Ok. Good point. Sure, my hasty proposal to get rid of is_MP() check in arm32 codes was wrong. One note. I see there is an ambiguity here: is_MP() is a multiprocessor system flag (returns true when _processor_count != 1), but multi-processor extensions is an optional ARMv7 feature which is not related with processors count, so pldw usage should not be controlled by is_MP() flag. > http://www.keil.com/support/man/docs/armclang_asm/armclang_asm_pge1425899018492.htm > > That makes me wonder whether any of the memory barrier instructions may > also be missing in some v6/v7 variants as well? Nobody complained :) And Reference Manual says DMB/DSB are not optional. > Plus I have to account > for uniprocessor ARMv5 so need to see whether MacroAssembler::membar, > for example, must also retain the is_MP() check. Do you want to delete this check? Processor count check seems quite natural to see if it has sense to generate memory barriers. By the way, MacroAssembler::fast_lock have VM_Version::supports_ldrex() check assertion with message "unsupported, yet?". Looks like it is not going to work correctly on multiprocessor ARMv5. > Also in: > > src/hotspot/cpu/arm/stubGenerator_arm.cpp > > you can't remove the !is_MP() check and related code as that is needed > for ARMv5 (uniprocessor) support. > > Similarly in > > src/hotspot/cpu/arm/vm_version_arm_32.cpp > > you'll probably still want to disable biased-locking for ARMv5. > > Cheers, > David > > On 20/09/2018 3:31 AM, Boris Ulasevich wrote: >> Hi David, >> >> ?> I have not updated the about-to-be-removed Oracle ARM port code. >> >> Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. >> I would propose the following change - I think we can either add it to >> your update or to create a separate RFR after your patch and JEP-340 >> commit: >> >> http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ >> >> regards, >> Boris >> >> On 18.09.2018 08:32, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >>> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>> >>> As previously discussed in the RFC thread: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >>> >>> >>> this change obsoletes the AssumeMP flag and removes the bulk of the >>> logic that is conditional on os::is_MP() as follows: >>> >>> 1. to gate the introduction of MP-specific features, notably memory >>> barriers >>> >>> The is_MP check is removed and we will always issue memory barriers >>> or pre-pend lock prefix etc. >>> >>> 2. to align certain patchable code sequences (method entry, call sites) >>> >>> The is_MP is removed and we always align patchable locations. >>> >>> 3. to gate certain optimizations which are questionable on uniprocessors >>> (see quicken_jni_functions) >>> >>> These are psuedo-memory-barriers where we manufacture a data-dependency >>> instead of inserting mfence/lfence (x86 example). These are treated as >>> #1 and is_MP is removed. >>> >>> 4. to gate optimizations which are desirable on uniprocessors >>> (mutex/monitor short circuits) >>> >>> These are spin controls and so is_MP remains. >>> >>> I have not updated the about-to-be-removed Oracle ARM port code. >>> >>> Testing: >>> ?? - Tiers 1 -3 (mach5) >>> >>> Performance run TBD. >>> >>> Thanks, >>> David From david.holmes at oracle.com Fri Sep 21 13:41:06 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Sep 2018 09:41:06 -0400 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> Message-ID: <25a98e2e-2523-d221-429a-4284938082a9@oracle.com> Hi Boris, On 21/09/2018 9:34 AM, Boris Ulasevich wrote: > Hi David, > > On 20.09.2018 18:26, David Holmes wrote: >> Hi Boris, >> >> Thanks for jumping on this. I hope you didn't spend too much time on >> it as I had actually started on the ARM code then decided I didn't >> need to make the changes, so I'd already gone through pretty much >> everything that is needed. My concern is with things like the change in >> >> src/hotspot/cpu/arm/assembler_arm_32.hpp >> >> where you removed the is_MP() check but in fact that needs to remain >> because the instruction pldw is not present on variants of the v7 >> architecture without the multi-processor extensions: > > Ok. Good point. Sure, my hasty proposal to get rid of is_MP() check in > arm32 codes was wrong. > > One note. I see there is an ambiguity here: is_MP() is a multiprocessor > system flag (returns true when _processor_count != 1), but > multi-processor extensions is an optional ARMv7 feature which is not > related with processors count, so pldw usage should not be controlled by > is_MP() flag. is_MP can't return true unless there is more than one processor (ignoring the pre-initialization case), so if there's more than one processor there must be a MP supprting architecture. >> http://www.keil.com/support/man/docs/armclang_asm/armclang_asm_pge1425899018492.htm >> >> That makes me wonder whether any of the memory barrier instructions >> may also be missing in some v6/v7 variants as well? > > Nobody complained :) And Reference Manual says DMB/DSB are not optional. I need to double-check we don't define variants like "dmb sy" that are architecture specific. >> Plus I have to account for uniprocessor ARMv5 so need to see whether >> MacroAssembler::membar, for example, must also retain the is_MP() check. > > Do you want to delete this check? Processor count check seems quite > natural to see if it has sense to generate memory barriers. That is the general thrust of this change. We assume we always have MP and so always issue memory barriers. > By the way, MacroAssembler::fast_lock have VM_Version::supports_ldrex() > check assertion with message "unsupported, yet?". Looks like it is not > going to work correctly on multiprocessor ARMv5. The ARM code does not support multiprocessor ARMv5. Thanks, David >> Also in: >> >> src/hotspot/cpu/arm/stubGenerator_arm.cpp >> >> you can't remove the !is_MP() check and related code as that is needed >> for ARMv5 (uniprocessor) support. >> >> Similarly in >> >> src/hotspot/cpu/arm/vm_version_arm_32.cpp >> >> you'll probably still want to disable biased-locking for ARMv5. >> >> Cheers, >> David >> >> On 20/09/2018 3:31 AM, Boris Ulasevich wrote: >>> Hi David, >>> >>> ?> I have not updated the about-to-be-removed Oracle ARM port code. >>> >>> Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. >>> I would propose the following change - I think we can either add it >>> to your update or to create a separate RFR after your patch and >>> JEP-340 commit: >>> >>> http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ >>> >>> regards, >>> Boris >>> >>> On 18.09.2018 08:32, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >>>> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>>> >>>> As previously discussed in the RFC thread: >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >>>> >>>> >>>> this change obsoletes the AssumeMP flag and removes the bulk of the >>>> logic that is conditional on os::is_MP() as follows: >>>> >>>> 1. to gate the introduction of MP-specific features, notably memory >>>> barriers >>>> >>>> The is_MP check is removed and we will always issue memory barriers >>>> or pre-pend lock prefix etc. >>>> >>>> 2. to align certain patchable code sequences (method entry, call sites) >>>> >>>> The is_MP is removed and we always align patchable locations. >>>> >>>> 3. to gate certain optimizations which are questionable on >>>> uniprocessors >>>> (see quicken_jni_functions) >>>> >>>> These are psuedo-memory-barriers where we manufacture a data-dependency >>>> instead of inserting mfence/lfence (x86 example). These are treated as >>>> #1 and is_MP is removed. >>>> >>>> 4. to gate optimizations which are desirable on uniprocessors >>>> (mutex/monitor short circuits) >>>> >>>> These are spin controls and so is_MP remains. >>>> >>>> I have not updated the about-to-be-removed Oracle ARM port code. >>>> >>>> Testing: >>>> ?? - Tiers 1 -3 (mach5) >>>> >>>> Performance run TBD. >>>> >>>> Thanks, >>>> David From aph at redhat.com Fri Sep 21 13:55:22 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Sep 2018 14:55:22 +0100 Subject: [aarch64-port-dev ] hotspot jtreg runtime/BoolReturn/JNIBooleanTest.java failure In-Reply-To: <742bbaa7-9648-a0d8-b176-926233dc87a0@redhat.com> References: <493129BB-4BD9-4762-A2FE-E51B322EA6E5@gmail.com> <742bbaa7-9648-a0d8-b176-926233dc87a0@redhat.com> Message-ID: <3b3e8827-2354-bfb2-85eb-7894940c5d3a@redhat.com> Here's the bug in Java's runtime which provoked this error: JNIEXPORT jboolean JNICALL Java_java_io_Console_echo(JNIEnv *env, jclass cls, jboolean on) { struct termios tio; jboolean old; int tty = fileno(stdin); if (tcgetattr(tty, &tio) == -1) { JNU_ThrowIOExceptionWithLastError(env, "tcgetattr failed"); return !on; } old = (tio.c_lflag & ECHO); if (on) { tio.c_lflag |= ECHO; } else { tio.c_lflag &= ~ECHO; } if (tcsetattr(tty, TCSANOW, &tio) == -1) { JNU_ThrowIOExceptionWithLastError(env, "tcsetattr failed"); } return old; } It's super-hard to see the bug because you could (and I did) naively assume that jboolean behaves like boolean (or C++ bool) but it doesn't. It should be: old = (tio.c_lflag & ECHO) != 0; which is why, I guess, the author wrapped the expression in parentheses. But note that if we simply fix this in HotSpot, it's only right by accident: ECHO just happens to be 0000010, so we know the result of (tio.c_lflag & ECHO) will fit in a jboolean, but that's just an accident. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sgehwolf at redhat.com Fri Sep 21 15:14:05 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 21 Sep 2018 17:14:05 +0200 Subject: RFR: 8210761: libjsig is being compiled without optimization Message-ID: Hi, Please review this build change which turns on compiler optimization for libjsig. It doesn't look like there is a good reason to turn off all opt when libjsig is being compiled. Signal tests[1] which excercise libjsig in various configs show no regressions for me on Linux x86_64. Thoughts? Bug: https://bugs.openjdk.java.net/browse/JDK-8210761 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/webrev.01/ Testing: Signal tests[1] and jdk submit. Thanks, Severin [1] test/hotspot/jtreg/runtime/signal From sgehwolf at redhat.com Fri Sep 21 15:22:22 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 21 Sep 2018 17:22:22 +0200 Subject: What's the point of test/hotspot/jtreg/runtime/jsig? Message-ID: Hi, test/hotspot/jtreg/runtime/jsig seems to have come in with JDK-8017498. However, corresponding Test8017498.sh seems to have been removed since and nothing exercises this code as far as I can see. I wonder what's the point of it? There are two options as I see it: 1) Remove dead code in test/hotspot/jtreg/runtime/jsig 2) Rework old Test8017498.sh[1] so that it actually uses classes/natives in test/hotspot/jtreg/runtime/jsig. Which one should it be? I can work on a webrev once it's known what do do. Thanks, Severin [1] http://hg.openjdk.java.net/jdk/jdk/file/352debf44a39/hotspot/test/runtime/jsig/Test8017498.sh From coleen.phillimore at oracle.com Fri Sep 21 15:45:45 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 21 Sep 2018 11:45:45 -0400 Subject: RFR 8210856: Move InstanceKlass DependencyContext cleaning to SystemDictionary::do_unloading() Message-ID: <48247e1b-bb84-5508-7393-f286c83b600f@oracle.com> Summary: Already walk classes in ClassLoaderData::unload so generalize to also clean nmethod dependencies. The nmethod dependencies should be cleaned before metadata is purged.? See bug for more details. open webrev at http://cr.openjdk.java.net/~coleenp/8210856.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8210856 Tested with hs tier1-7, modified gtest, and compiler/codecache/stress/RandomAllocationTest.java from bug https://bugs.openjdk.java.net/browse/JDK-8143408. Thanks, Coleen From erik.joelsson at oracle.com Fri Sep 21 16:27:53 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 21 Sep 2018 09:27:53 -0700 Subject: RFR: 8210761: libjsig is being compiled without optimization In-Reply-To: References: Message-ID: <842b47e9-8019-288c-d4d1-86f5314abbea@oracle.com> Looks good. /Erik On 2018-09-21 08:14, Severin Gehwolf wrote: > Hi, > > Please review this build change which turns on compiler optimization > for libjsig. It doesn't look like there is a good reason to turn off > all opt when libjsig is being compiled. Signal tests[1] which excercise > libjsig in various configs show no regressions for me on Linux x86_64. > Thoughts? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210761 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/webrev.01/ > > Testing: Signal tests[1] and jdk submit. > > Thanks, > Severin > > [1] test/hotspot/jtreg/runtime/signal > From magnus.ihse.bursie at oracle.com Fri Sep 21 16:44:38 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 21 Sep 2018 18:44:38 +0200 Subject: RFR: 8210761: libjsig is being compiled without optimization In-Reply-To: References: Message-ID: <62BCEEA6-8AD1-4127-BACD-98C626CC83CC@oracle.com> Looks good. Thanks for fixing all these lingering OPT issues! I'm very grateful. /Magnus > 21 sep. 2018 kl. 17:14 skrev Severin Gehwolf : > > Hi, > > Please review this build change which turns on compiler optimization > for libjsig. It doesn't look like there is a good reason to turn off > all opt when libjsig is being compiled. Signal tests[1] which excercise > libjsig in various configs show no regressions for me on Linux x86_64. > Thoughts? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210761 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8210761/webrev.01/ > > Testing: Signal tests[1] and jdk submit. > > Thanks, > Severin > > [1] test/hotspot/jtreg/runtime/signal > From thomas.stuefe at gmail.com Fri Sep 21 16:47:21 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 21 Sep 2018 18:47:21 +0200 Subject: RFR [XS] 8210964: add more ld preloading info to hs_error file on Linux In-Reply-To: References: Message-ID: Hi Matthias, in the posted patch the new function is never called, or am I mistaken? Thanks, Thomas On Fri, Sep 21, 2018 at 11:13 AM, Baesken, Matthias wrote: > Hello , please review this small patch . > > It adds more information about pre-loading configs of libs on Linux (often used for monitoring tools). > > Currently the hs_err file contains already the LD_PRELOAD environment variable. > However for system wide configuration, the /etc/ld.so.preload file is important as well on Linux. So display it as well (in case it is present). > > See the Environment / LD_PRELOAD and FILES sections of : > > http://man7.org/linux/man-pages/man8/ld.so.8.html > > for more information . > > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8210964 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.0/ > > > Thanks, Matthias From thomas.stuefe at gmail.com Fri Sep 21 16:59:10 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 21 Sep 2018 18:59:10 +0200 Subject: RFR [XS] 8210964: add more ld preloading info to hs_error file on Linux In-Reply-To: References: Message-ID: On Fri, Sep 21, 2018 at 6:47 PM, Thomas St?fe wrote: > Hi Matthias, > > in the posted patch the new function is never called, or am I mistaken? > Scratch that, I was being blind. What I do not like is the very generic name of the function. It does one very specific thing, so could we name it accordingly, e.g. "os::Linux::print_system_config_info" -> "os::Linux::print_ld_preload_file"? Also, I personally would not expose it via os_linux.hpp. I would just put it as a file scope static function into os_linux.cpp. I see you follow the example of others here (os::Linux::print_proc_sys_info etc) but there too I feel this is a bad pattern and those functions do not belong into an external header. 2140 st->print_cr("/etc/ld.so.preload (system-wide LD_PRELOAD config file):"); I would shorten that to just "ld.so.preload:" or "/etc/ld.so.preload". Everyone looking at that section knows what that file does. I also would omit that header completely if the file cannot be opened. 2141 bool file_present = _print_ascii_file("/etc/ld.so.preload", st); 2142 if (!file_present) { st->print("file not present"); } 2143 st->cr(); You do not know that the file is not preset, all you know is that the open() call in _print_ascii_file() failed. Since existence of this file is optional, and not typical, I would just omit messages if it cannot be found. Best Regards, Thomas > Thanks, Thomas > > > > On Fri, Sep 21, 2018 at 11:13 AM, Baesken, Matthias > wrote: >> Hello , please review this small patch . >> >> It adds more information about pre-loading configs of libs on Linux (often used for monitoring tools). >> >> Currently the hs_err file contains already the LD_PRELOAD environment variable. >> However for system wide configuration, the /etc/ld.so.preload file is important as well on Linux. So display it as well (in case it is present). >> >> See the Environment / LD_PRELOAD and FILES sections of : >> >> http://man7.org/linux/man-pages/man8/ld.so.8.html >> >> for more information . >> >> >> >> Bug/webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8210964 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.0/ >> >> >> Thanks, Matthias From thomas.stuefe at gmail.com Fri Sep 21 19:08:09 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 21 Sep 2018 21:08:09 +0200 Subject: RFR [XS] : 8210961: [aix] enhance list of environment variables reported in error log file on AIX In-Reply-To: References: Message-ID: Hi Matthias, On Fri, Sep 21, 2018 at 8:54 AM, Baesken, Matthias wrote: > Hi Volker, sure the LDR_PRELOAD might not be so important any more these days . > However it might be fine to have it included in the list of environment variables for the sake of completeness ( in it is maybe of interest in cases where we start > other (32bit) binaries from java ). > You mean, starting 32bit AIX binaries from our 64bit jvm? Is this even possible? Best Regards, Thomas > Best regards, Matthias > > > >> -----Original Message----- >> From: Volker Simonis >> Sent: Donnerstag, 20. September 2018 17:41 >> To: Baesken, Matthias >> Cc: HotSpot Open Source Developers >> Subject: Re: RFR [XS] : 8210961: [aix] enhance list of environment variables >> reported in error log file on AIX >> >> Hi Matthias, >> >> looks good! >> >> Do we really need LDR_PRELOAD? The documentation you've linked >> mentions that it is only used for 32-bit process which we don't >> support anyway. >> >> I think it may be better to leave it out completely, otherwise people >> may get confused if they see that LDR_PRELOAD was defined. >> >> Thank you and best regards, >> Volker >> >> On Thu, Sep 20, 2018 at 2:13 PM Baesken, Matthias >> wrote: >> > >> > Hello, Please review this small enhancement. >> > >> > It adds these AIX-related environment variables to the already existing list >> of environment variables that should be reported in error log file (hs_err file) >> : >> > >> > LIBPATH : environment variable to locate shared libraries , see >> https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.1.0/com.ib >> m.java.aix.71.doc/user/setlpath.html >> > >> > LDR_PRELOAD / LDR_PRELOAD64 : similar to LD_PRELOAD on Linux , see >> https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm. >> aix.performance/preloading_shared_libraries.htm >> > >> > >> > http://cr.openjdk.java.net/~mbaesken/webrevs/8210961/ >> > >> > bug : https://bugs.openjdk.java.net/browse/JDK-8210961 >> > >> > >> > Thanks, Matthias From daniel.daugherty at oracle.com Fri Sep 21 21:25:52 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 21 Sep 2018 17:25:52 -0400 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: <1D612813-2ABB-4226-8ED4-5F541C22B4E6@oracle.com> References: <1D612813-2ABB-4226-8ED4-5F541C22B4E6@oracle.com> Message-ID: <1cfcf9f5-56a4-f2f2-a839-2fe021d8b731@oracle.com> > New webrev: > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-full/open/webrev/ src/hotspot/share/opto/library_call.cpp ??? No comments. src/hotspot/share/runtime/arguments.cpp ??? No comments. src/hotspot/share/runtime/globals.hpp ??? No comments. src/hotspot/share/runtime/objectMonitor.cpp ??? Wow. What a nightmare teasing that apart. src/hotspot/share/runtime/objectMonitor.hpp ??? No comments. src/hotspot/share/runtime/synchronizer.cpp ??? old L1799: ? if (ObjectMonitor::Knob_VerifyInUse) { ??? old L1800: ??? verifyInUse(thread); ??? old L1801: ? } ??????? The VerifyInUse support was useful in diagnosing bugs ??????? in the monitor list stuff. I guess if we need it again, ??????? we can pull it from the history and reapply/adapt it ??????? to the current code. ??? old L1829:? ?? if (mid->owner() == THREAD) { ??? old L1830: ????? if (ObjectMonitor::Knob_VerifyMatch != 0) { ??? old L1831: ??????? ResourceMark rm; ??? old L1832: ??????? Handle obj(THREAD, (oop) mid->object()); ??? old L1833: ??????? tty->print("INFO: unexpected locked object:"); ??? old L1834: javaVFrame::print_locked_object_class_name(tty, obj, "locked"); ??? old L1835: ??????? fatal("exiting JavaThread=" INTPTR_FORMAT ??? old L1836: ????????????? " unexpectedly owns ObjectMonitor=" INTPTR_FORMAT, ??? old L1837: ????????????? p2i(THREAD), p2i(mid)); ??? old L1838: ????? } ?? ? ?? The VerifyMatch code was very useful in debugging locked ?? ? ?? monitors where the unlock was somehow lost (opto bug, ?? ? ?? lock elision bug, etc). I guess if we need it again, ??????? we can pull it from the history and reapply/adapt it ??????? to the current code. src/hotspot/share/runtime/synchronizer.hpp ??? No comments. src/hotspot/share/runtime/thread.cpp ??? old L1956: ? // Optionally release any monitors for regular JavaThread exits. This ??? old L1957: ? // is provided as a work around for any bugs in monitor enter-exit ??? old L1958: ? // matching. This can be expensive so it is not enabled by default. ??? old L1959: ? // ??? old L1960: ? // ensure_join() ignores IllegalThreadStateExceptions, and so does ??? old L1961: ? // ObjectSynchronizer::release_monitors_owned_by_thread(). ??? old L1962: ? if (exit_type == jni_detach || ObjectMonitor::Knob_ExitRelease) { ??????? The ExitRelease code was provided as a possible work around ??????? for customers impacted by a lost monitor unlock. When a monitor ??????? is lost and the owning thread has exited, no other thread can ??????? enter that object monitor ever again which causes the application ??????? to deadlock. The only recourse without the ExitRelease code is ??????? to reboot the app. ??????? I guess if we need it again, we can pull it from the history and ??????? reapply/adapt it to the current code. src/hotspot/share/runtime/vframe.cpp ??? L258: ??????? if (ObjectMonitor::Knob_Verbose && mark != NULL) { ? ? L259: ????????? st->print("\t- lockbits="); ??? L260: ????????? mark->print_on(st); ??? L261: ????????? st->cr(); ??? L262: ??????? } ??????? This was the only way to see the lockbits in a thread dump. ??????? Often useful when trying to debug a deadlock. Sigh... So this looks like a clean removal of SyncKnobs so from that point of view, thumbs up! Dan On 9/20/18 1:12 AM, Mikael Vidstedt wrote: > >> On Sep 18, 2018, at 11:33 PM, David Holmes wrote: >> >> Hi Mikael, >> >> Code review from 34,000ft :) > Ha! :) > >> Generally looks good for the algorithmic selection knobs. Though I am sad to see some of this go - specifically the code for the different queuing policies after a notify(). I have vague recollections of applications encountering pathological behaviour with particular and excessive use of wait/notify, that was fixed by changing the queuing policy. But at least that code would be relative simple to add back if someone wanted to. >> >> I have some concerns about the handling of the spin related knobs. We have sophisticated spin logic to optimise performance** which involves a large number of tuning knobs. Many of those knobs are gone as their values could only change at build time. A few remain because they are affected by os::is_MP. So what we end up with is a partial simplification where the code is no longer readily tunable (if someone needed to do it), but nor is it that simple. >> >> ** What concerns me is that we have this sophisticated but unused code, not because it is stale/dead/un-needed, but because the collective "we" has lost the ability and/or motivation to actually try and tune this as hardware has evolved. We no longer know how optimal the remaining spin knobs actually are - and certainly not across the broader range of architectures that OpenJDK now supports. Maybe the better path for this "unused code" is to start using it? > Right, it all comes down to priorities and where we spend our time (no pun intended). Since nobody seems to have looked at/used/changed this recently I think we?ll have to assume and accept that this is not the area we consider in need of the most attention right now. Simplifying the code at least means we get rid of the unused complexity, and it?s easier for people to understand the part of the algorithm and code actually used today. > >> I have a few specific comments: >> >> Knob_Verbose: instead of outright deleting this now should we instead have a RFE to convert to UL where appropriate and feasible (and perhaps just use tty and TraceXXX if UL can not be used). In particular logging around ForceMonitorScavenge might be useful (unless we're going to obsolete that too :) ). > I?d be very hesitant to spend time on investigating the interaction with UL and/or introducing a trace flag unless the logging is actually useful, and I personally haven?t seen any evidence of that, at least not in modern times. Do speak up if you read this and have found it useful enough to motivate the investment! > >> --- >> >> thread.cpp: >> >> This comment block is no longer relevant: >> >> 1956 // Optionally release any monitors for regular JavaThread exits. This >> 1957 // is provided as a work around for any bugs in monitor enter-exit >> 1958 // matching. This can be expensive so it is not enabled by default. > Good catch, consider it removed! > >> I wonder if we could just assert there are no held monitors in the regular JavaThread case ? ? > Good question, I don?t have an answer :) > >> --- >> >> synchronizer.cpp: >> >> is verifyInUse dead code now? (I have to wonder whether everything would be shown to be okay if we turned on these checks? More generally is this a sanity check we should actually be performing in debug builds, or was this really only useful during the development of the "in use" lists? I suspect the latter.) > Yes, Coleen also found that verifyInUse is indeed dead - consider it gone (in webrev.01). > >> --- >> >> objectMonitor.cpp: >> >> Aside: This comment block is out of date and can be deleted. >> >> 904 // I'd like to write one of the following: >> 905 // A. OrderAccess::release() ; _owner = NULL >> 906 // B. OrderAccess::loadstore(); OrderAccess::storestore(); _owner = NULL; >> 907 // Unfortunately OrderAccess::release() and OrderAccess::loadstore() both >> 908 // store into a _dummy variable. That store is not needed, but can result >> 909 // in massive wasteful coherency traffic on classic SMP systems. >> 910 // Instead, I use release_store(), which is implemented as just a simple >> 911 // ST on x64, x86 and SPARC. > Consider it removed! > > > New webrev: > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-full/open/webrev/ > > Incremental changes from webrev.01: > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-04.2-Knob_ExitRelease/open/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-20.2-Knob_ExitPolicy/open/webrev/ > > Cheers, > Mikael > >> Thanks, >> David >> >> On 18/09/2018 5:03 PM, Mikael Vidstedt wrote: >>> Please review this change which obsoletes the SyncKnobs flag, and simplifies the code by removing the resulting unused code paths. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 >>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ >>> * Background (from the bug) >>> The experimental SyncKnobs flag can in theory be used to tune the behavior of the synchronization primitives. The flag was convenient when the various algorithms were compared a long time ago. >>> In practice the only algorithm used and tested today are the default one. The SyncKnobs flag no longer serves the purpose it used to, and is "Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. >>> * About the change >>> As mentioned above this change not only obsolete the SyncKnobs flag, but also removes the various sub-options/knobs and prunes the resulting dead code. Of course I?m happy to hear your thoughts on that. After having asked around it seems like the knobs have not been used the last decade or so, and I like to think that the synchronization code is complex enough without what is in that case effectively dead code. >>> In order to make reviewing this slightly easier I have for your convenience (at least I hope it is) also created a bunch of smaller patches which stack, each removing one specific knob. Hopefully they?re more or less self-explanatory, but let me know if I can help clarify something: >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ >>> * Testing >>> A slightly earlier version of this patch passed the standard tier1-3 testing. I will run additional testing after I get some feedback. >>> Cheers, >>> Mikael From david.holmes at oracle.com Fri Sep 21 21:43:42 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Sep 2018 17:43:42 -0400 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: <1D612813-2ABB-4226-8ED4-5F541C22B4E6@oracle.com> References: <1D612813-2ABB-4226-8ED4-5F541C22B4E6@oracle.com> Message-ID: Hi Mikael, On 20/09/2018 1:12 AM, Mikael Vidstedt wrote: > > >> On Sep 18, 2018, at 11:33 PM, David Holmes > > wrote: >> >> Hi Mikael, >> >> Code review from 34,000ft :) > > Ha! :) > >> Generally looks good for the algorithmic selection knobs. Though I am >> sad to see some of this go - specifically the code for the different >> queuing policies after a notify(). I have vague recollections of >> applications encountering pathological behaviour with particular and >> excessive use of wait/notify, that was fixed by changing the queuing >> policy. But at least that code would be relative simple to add back if >> someone wanted to. >> >> I have some concerns about the handling of the spin related knobs. We >> have sophisticated spin logic to optimise performance** which involves >> a large number of tuning knobs. Many of those knobs are gone as their >> values could only change at build time. A few remain because they are >> affected by os::is_MP. So what we end up with is a partial >> simplification where the code is no longer readily tunable (if someone >> needed to do it), but nor is it that simple. >> >> ** What concerns me is that we have this sophisticated but unused >> code, not because it is stale/dead/un-needed, but because the >> collective "we" has lost the ability and/or motivation to actually try >> and tune this as hardware has evolved. We no longer know how optimal >> the remaining spin knobs actually are - and certainly not across the >> broader range of architectures that OpenJDK now supports. Maybe the >> better path for this "unused code" is to start using it? > > Right, it all comes down to priorities and where we spend our time (no > pun intended). Since nobody seems to have looked at/used/changed this > recently I think we?ll have to assume and accept that this is not the > area we consider in need of the most attention right now. Simplifying > the code at least means we get rid of the unused complexity, and it?s > easier for people to understand the part of the algorithm and code > actually used today. I'll refrain from further comment on this. :) >> I have a few specific comments: >> >> Knob_Verbose: instead of outright deleting this now should we instead >> have a RFE to convert to UL where appropriate and feasible (and >> perhaps just use tty and TraceXXX if UL can not be used). In >> particular logging around ForceMonitorScavenge might be useful (unless >> we're going to obsolete that too :) ). > > I?d be very hesitant to spend time on investigating the interaction with > UL and/or introducing a trace flag unless the logging is actually > useful, and I personally haven?t seen any evidence of that, at least not > in modern times. Do speak up if you read this and have found it useful > enough to motivate the investment! I would think whomever is working on the monitor deflation problem might be interested in how ForceMonitorScavenge works. But I guess they can add something back if needed. >> --- >> >> thread.cpp: >> >> This comment block is no longer relevant: >> >> 1956 ??// Optionally release any monitors for regular JavaThread >> exits. This >> 1957 ??// is provided as a work around for any bugs in monitor enter-exit >> 1958 ??// matching. This can be expensive so it is not enabled by default. > > Good catch, consider it removed! > >> I wonder if we could just assert there are no held monitors in the >> regular JavaThread case ? ? > > Good question, I don?t have an answer :) I see Dan answered this. Note sure the tests he refers to are valid, on the other hand such usage does seem to fall into a spec hole. Normal Java lock usage can't forget to release monitors. JNI attached threads that don't release, have monitors released when they detach. But Java threads that use JNI to lock but not unlock are not covered. okay forget about the assert. >> >> --- >> >> synchronizer.cpp: >> >> is verifyInUse dead code now? (I have to wonder whether everything >> would be shown to be okay if we turned on these checks? More generally >> is this a sanity check we should actually be performing in debug >> builds, or was this really only useful during the development of the >> "in use" lists? I suspect the latter.) > > Yes, Coleen also found that verifyInUse is indeed dead - consider it > gone (in webrev.01). Ok >> >> --- >> >> objectMonitor.cpp: >> >> Aside: This comment block is out of date and can be deleted. >> >> 904 ????// I'd like to write one of the following: >> 905 ????// A. ?OrderAccess::release() ; _owner = NULL >> 906 ????// B. ?OrderAccess::loadstore(); OrderAccess::storestore(); >> _owner = NULL; >> 907 ????// Unfortunately OrderAccess::release() and >> OrderAccess::loadstore() both >> 908 ????// store into a _dummy variable. ?That store is not needed, >> but can result >> 909 ????// in massive wasteful coherency traffic on classic SMP systems. >> 910 ????// Instead, I use release_store(), which is implemented as >> just a simple >> 911 ????// ST on x64, x86 and SPARC. > > Consider it removed! > > > New webrev: > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-full/open/webrev/ > > > Incremental changes from webrev.01: > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-04.2-Knob_ExitRelease/open/webrev/ > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-20.2-Knob_ExitPolicy/open/webrev/ > No incremental for verifyInUse :( I looked at the full webrev. All seems okay. Thanks, David > Cheers, > Mikael > >> >> Thanks, >> David >> >> On 18/09/2018 5:03 PM, Mikael Vidstedt wrote: >>> Please review this change which obsoletes the SyncKnobs flag, and >>> simplifies the code by removing the resulting unused code paths. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 >>> Webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ >>> >>> >> > >>> * Background (from the bug) >>> The experimental SyncKnobs flag can in theory be used to tune the >>> behavior of the synchronization primitives. The flag was convenient >>> when the various algorithms were compared a long time ago. >>> In practice the only algorithm used and tested today are the default >>> one. The SyncKnobs flag no longer serves the purpose it used to, and >>> is "Unstable" (the documentation of the flag says so explicitly). It >>> should be obsoleted and later removed. >>> * About the change >>> As mentioned above this change not only obsolete the SyncKnobs flag, >>> but also removes the various sub-options/knobs and prunes the >>> resulting dead code. Of course I?m happy to hear your thoughts on >>> that. After having asked around it seems like the knobs have not been >>> used the last decade or so, and I like to think that the >>> synchronization code is complex enough without what is in that case >>> effectively dead code. >>> In order to make reviewing this slightly easier I have for your >>> convenience (at least I hope it is) also created a bunch of smaller >>> patches which stack, each removing one specific knob. Hopefully >>> they?re more or less self-explanatory, but let me know if I can help >>> clarify something: >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ >>> >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ >>> * Testing >>> A slightly earlier version of this patch passed the standard tier1-3 >>> testing. I will run additional testing after I get some feedback. >>> Cheers, >>> Mikael > From mikael.vidstedt at oracle.com Fri Sep 21 21:49:04 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 21 Sep 2018 14:49:04 -0700 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: References: <1D612813-2ABB-4226-8ED4-5F541C22B4E6@oracle.com> Message-ID: <6B90D6CC-A565-4DDA-A0F3-11209213AB6D@oracle.com> > On Sep 21, 2018, at 2:43 PM, David Holmes wrote: > > Hi Mikael, > > On 20/09/2018 1:12 AM, Mikael Vidstedt wrote: >>> On Sep 18, 2018, at 11:33 PM, David Holmes > wrote: >>> >>> Hi Mikael, >>> >>> Code review from 34,000ft :) >> Ha! :) >>> Generally looks good for the algorithmic selection knobs. Though I am sad to see some of this go - specifically the code for the different queuing policies after a notify(). I have vague recollections of applications encountering pathological behaviour with particular and excessive use of wait/notify, that was fixed by changing the queuing policy. But at least that code would be relative simple to add back if someone wanted to. >>> >>> I have some concerns about the handling of the spin related knobs. We have sophisticated spin logic to optimise performance** which involves a large number of tuning knobs. Many of those knobs are gone as their values could only change at build time. A few remain because they are affected by os::is_MP. So what we end up with is a partial simplification where the code is no longer readily tunable (if someone needed to do it), but nor is it that simple. >>> >>> ** What concerns me is that we have this sophisticated but unused code, not because it is stale/dead/un-needed, but because the collective "we" has lost the ability and/or motivation to actually try and tune this as hardware has evolved. We no longer know how optimal the remaining spin knobs actually are - and certainly not across the broader range of architectures that OpenJDK now supports. Maybe the better path for this "unused code" is to start using it? >> Right, it all comes down to priorities and where we spend our time (no pun intended). Since nobody seems to have looked at/used/changed this recently I think we?ll have to assume and accept that this is not the area we consider in need of the most attention right now. Simplifying the code at least means we get rid of the unused complexity, and it?s easier for people to understand the part of the algorithm and code actually used today. > > I'll refrain from further comment on this. :) > >>> I have a few specific comments: >>> >>> Knob_Verbose: instead of outright deleting this now should we instead have a RFE to convert to UL where appropriate and feasible (and perhaps just use tty and TraceXXX if UL can not be used). In particular logging around ForceMonitorScavenge might be useful (unless we're going to obsolete that too :) ). >> I?d be very hesitant to spend time on investigating the interaction with UL and/or introducing a trace flag unless the logging is actually useful, and I personally haven?t seen any evidence of that, at least not in modern times. Do speak up if you read this and have found it useful enough to motivate the investment! > > I would think whomever is working on the monitor deflation problem might be interested in how ForceMonitorScavenge works. But I guess they can add something back if needed. > >>> --- >>> >>> thread.cpp: >>> >>> This comment block is no longer relevant: >>> >>> 1956 // Optionally release any monitors for regular JavaThread exits. This >>> 1957 // is provided as a work around for any bugs in monitor enter-exit >>> 1958 // matching. This can be expensive so it is not enabled by default. >> Good catch, consider it removed! >>> I wonder if we could just assert there are no held monitors in the regular JavaThread case ? ? >> Good question, I don?t have an answer :) > > I see Dan answered this. Note sure the tests he refers to are valid, on the other hand such usage does seem to fall into a spec hole. Normal Java lock usage can't forget to release monitors. JNI attached threads that don't release, have monitors released when they detach. But Java threads that use JNI to lock but not unlock are not covered. okay forget about the assert. > >>> >>> --- >>> >>> synchronizer.cpp: >>> >>> is verifyInUse dead code now? (I have to wonder whether everything would be shown to be okay if we turned on these checks? More generally is this a sanity check we should actually be performing in debug builds, or was this really only useful during the development of the "in use" lists? I suspect the latter.) >> Yes, Coleen also found that verifyInUse is indeed dead - consider it gone (in webrev.01). > > Ok > >>> >>> --- >>> >>> objectMonitor.cpp: >>> >>> Aside: This comment block is out of date and can be deleted. >>> >>> 904 // I'd like to write one of the following: >>> 905 // A. OrderAccess::release() ; _owner = NULL >>> 906 // B. OrderAccess::loadstore(); OrderAccess::storestore(); _owner = NULL; >>> 907 // Unfortunately OrderAccess::release() and OrderAccess::loadstore() both >>> 908 // store into a _dummy variable. That store is not needed, but can result >>> 909 // in massive wasteful coherency traffic on classic SMP systems. >>> 910 // Instead, I use release_store(), which is implemented as just a simple >>> 911 // ST on x64, x86 and SPARC. >> Consider it removed! >> New webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-full/open/webrev/ >> Incremental changes from webrev.01: >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-04.2-Knob_ExitRelease/open/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-20.2-Knob_ExitPolicy/open/webrev/ > > No incremental for verifyInUse :( From http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034241.html: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.01/syncknobs-07.2-Knob_VerifyInUse/open/webrev/ Cheers, Mikael > > I looked at the full webrev. All seems okay. > > Thanks, > David > >> Cheers, >> Mikael >>> >>> Thanks, >>> David >>> >>> On 18/09/2018 5:03 PM, Mikael Vidstedt wrote: >>>> Please review this change which obsoletes the SyncKnobs flag, and simplifies the code by removing the resulting unused code paths. >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 >>>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ > >>>> * Background (from the bug) >>>> The experimental SyncKnobs flag can in theory be used to tune the behavior of the synchronization primitives. The flag was convenient when the various algorithms were compared a long time ago. >>>> In practice the only algorithm used and tested today are the default one. The SyncKnobs flag no longer serves the purpose it used to, and is "Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. >>>> * About the change >>>> As mentioned above this change not only obsolete the SyncKnobs flag, but also removes the various sub-options/knobs and prunes the resulting dead code. Of course I?m happy to hear your thoughts on that. After having asked around it seems like the knobs have not been used the last decade or so, and I like to think that the synchronization code is complex enough without what is in that case effectively dead code. >>>> In order to make reviewing this slightly easier I have for your convenience (at least I hope it is) also created a bunch of smaller patches which stack, each removing one specific knob. Hopefully they?re more or less self-explanatory, but let me know if I can help clarify something: >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ >>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ >>>> * Testing >>>> A slightly earlier version of this patch passed the standard tier1-3 testing. I will run additional testing after I get some feedback. >>>> Cheers, >>>> Mikael From david.holmes at oracle.com Fri Sep 21 22:48:33 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Sep 2018 18:48:33 -0400 Subject: What's the point of test/hotspot/jtreg/runtime/jsig? In-Reply-To: References: Message-ID: <4f347bcc-a918-dfd4-0a28-3de90812a1ef@oracle.com> Hi Severin, I would have to guess that this was intended to be converted to a Java test and either the main test file was not hg added, or else ... I can't find the changeset that removed the sh file to try and see what happened. Between file renames and repo reorgs hg log doesn't seem to be able to track this. David On 21/09/2018 11:22 AM, Severin Gehwolf wrote: > Hi, > > test/hotspot/jtreg/runtime/jsig seems to have come in with JDK-8017498. > However, corresponding Test8017498.sh seems to have been removed since > and nothing exercises this code as far as I can see. I wonder what's > the point of it? > > There are two options as I see it: > > 1) > Remove dead code in test/hotspot/jtreg/runtime/jsig > > 2) > Rework old Test8017498.sh[1] so that it actually uses classes/natives > in test/hotspot/jtreg/runtime/jsig. > > Which one should it be? I can work on a webrev once it's known what do > do. > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk/jdk/file/352debf44a39/hotspot/test/runtime/jsig/Test8017498.sh > From david.holmes at oracle.com Sun Sep 23 13:22:53 2018 From: david.holmes at oracle.com (David Holmes) Date: Sun, 23 Sep 2018 09:22:53 -0400 Subject: What's the point of test/hotspot/jtreg/runtime/jsig? In-Reply-To: <4f347bcc-a918-dfd4-0a28-3de90812a1ef@oracle.com> References: <4f347bcc-a918-dfd4-0a28-3de90812a1ef@oracle.com> Message-ID: This was done by: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a0cdf5e20489 "8144279: [TESTBUG] hotspot/runtime/jsig/Test8017498.sh should use native library build support" I would have to guess the main test file was not hg added for the commit. But I can't find the code review for it. I've filed: https://bugs.openjdk.java.net/browse/JDK-821104 Thanks, David On 21/09/2018 6:48 PM, David Holmes wrote: > Hi Severin, > > I would have to guess that this was intended to be converted to a Java > test and either the main test file was not hg added, or else ... > > I can't find the changeset that removed the sh file to try and see what > happened. Between file renames and repo reorgs hg log doesn't seem to be > able to track this. > > David > > On 21/09/2018 11:22 AM, Severin Gehwolf wrote: >> Hi, >> >> test/hotspot/jtreg/runtime/jsig seems to have come in with JDK-8017498. >> However, corresponding Test8017498.sh seems to have been removed since >> and nothing exercises this code as far as I can see. I wonder what's >> the point of it? >> >> There are two options as I see it: >> >> 1) >> Remove dead code in test/hotspot/jtreg/runtime/jsig >> >> 2) >> Rework old Test8017498.sh[1] so that it actually uses classes/natives >> in test/hotspot/jtreg/runtime/jsig. >> >> Which one should it be? I can work on a webrev once it's known what do >> do. >> >> Thanks, >> Severin >> >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/352debf44a39/hotspot/test/runtime/jsig/Test8017498.sh >> >> From lists at selckin.be Sun Sep 23 14:33:12 2018 From: lists at selckin.be (Thomas Matthijs) Date: Sun, 23 Sep 2018 16:33:12 +0200 Subject: What's the point of test/hotspot/jtreg/runtime/jsig? In-Reply-To: References: <4f347bcc-a918-dfd4-0a28-3de90812a1ef@oracle.com> Message-ID: Maybe this one ? apologies if incorrect http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-May/019305.html On Sun, 23 Sep 2018 at 15:53, David Holmes wrote: > This was done by: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a0cdf5e20489 > > "8144279: [TESTBUG] hotspot/runtime/jsig/Test8017498.sh should use > native library build support" > > I would have to guess the main test file was not hg added for the > commit. But I can't find the code review for it. > > I've filed: > > https://bugs.openjdk.java.net/browse/JDK-821104 > > Thanks, > David > > On 21/09/2018 6:48 PM, David Holmes wrote: > > Hi Severin, > > > > I would have to guess that this was intended to be converted to a Java > > test and either the main test file was not hg added, or else ... > > > > I can't find the changeset that removed the sh file to try and see what > > happened. Between file renames and repo reorgs hg log doesn't seem to be > > able to track this. > > > > David > > > > On 21/09/2018 11:22 AM, Severin Gehwolf wrote: > >> Hi, > >> > >> test/hotspot/jtreg/runtime/jsig seems to have come in with JDK-8017498. > >> However, corresponding Test8017498.sh seems to have been removed since > >> and nothing exercises this code as far as I can see. I wonder what's > >> the point of it? > >> > >> There are two options as I see it: > >> > >> 1) > >> Remove dead code in test/hotspot/jtreg/runtime/jsig > >> > >> 2) > >> Rework old Test8017498.sh[1] so that it actually uses classes/natives > >> in test/hotspot/jtreg/runtime/jsig. > >> > >> Which one should it be? I can work on a webrev once it's known what do > >> do. > >> > >> Thanks, > >> Severin > >> > >> [1] > >> > http://hg.openjdk.java.net/jdk/jdk/file/352debf44a39/hotspot/test/runtime/jsig/Test8017498.sh > >> > >> > From david.holmes at oracle.com Sun Sep 23 14:53:26 2018 From: david.holmes at oracle.com (David Holmes) Date: Sun, 23 Sep 2018 10:53:26 -0400 Subject: What's the point of test/hotspot/jtreg/runtime/jsig? In-Reply-To: References: <4f347bcc-a918-dfd4-0a28-3de90812a1ef@oracle.com> Message-ID: <585afd2a-8dbc-c3e3-2d5f-a639164931f2@oracle.com> Hi Thomas, On 23/09/2018 10:33 AM, Thomas Matthijs wrote: > Maybe this one ? apologies if incorrect > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-May/019305.html You're absolutely correct - thanks! I checked July and June manually but didn't go back to May (wow that was a long delay between review and push!). The Testjsig.java file indeed seems to have been omitted from the commit. I can fix that today. Thanks, David > > On Sun, 23 Sep 2018 at 15:53, David Holmes > wrote: > > This was done by: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a0cdf5e20489 > > "8144279: [TESTBUG] hotspot/runtime/jsig/Test8017498.sh should use > native library build support" > > I would have to guess the main test file was not hg added for the > commit. But I can't find the code review for it. > > I've filed: > > https://bugs.openjdk.java.net/browse/JDK-821104 > > Thanks, > David > > On 21/09/2018 6:48 PM, David Holmes wrote: > > Hi Severin, > > > > I would have to guess that this was intended to be converted to a > Java > > test and either the main test file was not hg added, or else ... > > > > I can't find the changeset that removed the sh file to try and > see what > > happened. Between file renames and repo reorgs hg log doesn't > seem to be > > able to track this. > > > > David > > > > On 21/09/2018 11:22 AM, Severin Gehwolf wrote: > >> Hi, > >> > >> test/hotspot/jtreg/runtime/jsig seems to have come in with > JDK-8017498. > >> However, corresponding Test8017498.sh seems to have been removed > since > >> and nothing exercises this code as far as I can see. I wonder what's > >> the point of it? > >> > >> There are two options as I see it: > >> > >> 1) > >> Remove dead code in test/hotspot/jtreg/runtime/jsig > >> > >> 2) > >> Rework old Test8017498.sh[1] so that it actually uses > classes/natives > >> in test/hotspot/jtreg/runtime/jsig. > >> > >> Which one should it be? I can work on a webrev once it's known > what do > >> do. > >> > >> Thanks, > >> Severin > >> > >> [1] > >> > http://hg.openjdk.java.net/jdk/jdk/file/352debf44a39/hotspot/test/runtime/jsig/Test8017498.sh > > >> > >> > From boris.ulasevich at bell-sw.com Sun Sep 23 15:45:17 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Sun, 23 Sep 2018 18:45:17 +0300 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <990eb025-8705-8633-abd7-0e87a3dc6d33@bell-sw.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <990eb025-8705-8633-abd7-0e87a3dc6d33@bell-sw.com> Message-ID: Hi Bob, I checked your changes with jtreg and jck. I see no new fails introduced by this change. regards, Boris On 19.09.2018 13:30, Boris Ulasevich wrote: > Hi Bob, > > Thank you for this job! > I have started testing. Will come back with results next week :) > The changes is Ok for me. Please see some minor comments below. > > regards, > Boris > > On 17.09.2018 20:49, Aleksey Shipilev wrote: >> On 09/17/2018 07:00 PM, Vladimir Kozlov wrote: >>> On 9/17/18 9:20 AM, Bob Vandette wrote: >>>> Please review the changes related to JEP 340 which remove the second >>>> 64-bit ARM port from the JDK.>> >>>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >> >> I read through the webrev, and it seems to be the clean removal. It >> also feels >> very satisfying to drop 15 KLOC of ifdef-ed code. >> >> Minor nits: >> >> ? *) In src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp and >> src/hotspot/cpu/arm/interp_masm_arm.cpp we have "#if defined(ASSERT)", >> which cab >> be just "#ifdef ASSERT" now >> >> ? *) Ditto in src/hotspot/cpu/arm/jniFastGetField_arm.cpp we have "#if >> defined(__ABI_HARD__)" >> >> ? *) In src/hotspot/cpu/arm/macroAssembler_arm.hpp, the comment below >> seems to >> apply to AArch64 only. > > Yes, the note looks like AArch64 specific comment, but I think it is > valid for arm32 too. So the change is Ok for me. > >> Yet, only the first line of the comment is removed. I >> think we should instead convert that comment into "TODO:" mentioning >> this might >> be revised after AArch64 removal? >> >> ? 992?? void branch_if_negative_32(Register r, Label& L) { >> ? 993???? // Note about branch_if_negative_32() / >> branch_if_any_negative_32() >> implementation for AArch64: >> ? 994???? // tbnz is not used instead of tst & b.mi because >> destination may be >> out of tbnz range (+-32KB) >> ? 995???? // since these methods are used in >> LIR_Assembler::emit_arraycopy() to >> jump to stub entry. >> ? 996???? tst_32(r, r); >> ? 997???? b(L, mi); >> ? 998?? } >> >> ? *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, lines L1204..1205, >> L1435..1436 >> can be merged together: >> >> 1203?? // Generate the inner loop for shifted forward array copy >> (unaligned copy). >> 1204?? // It can be used when bytes_per_count < wordSize, i.e. >> 1205?? //? byte/short copy >> >> 1434?? // Generate the inner loop for shifted backward array copy >> (unaligned copy). >> 1435?? // It can be used when bytes_per_count < wordSize, i.e. >> 1436?? //? byte/short copy >> >> >> ? *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, the comment changed >> incorrectly around L3363? > > I believe both (L3188 and L3363) comments should mention SP[0] (not R4) > as an input parameter now. > >> ?? - //??? R4 (AArch64) / SP[0] (32-bit ARM) -? element count (32-bit >> int) >> ?? + //??? R4??? -? element count (32-bit int) >> >> >> ? *) In src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp, >> "R4"/"R5" >> comments are missing: >> >> ?? - const Register Rsig_handler??? = AARCH64_ONLY(R21) >> NOT_AARCH64(Rtmp_save0 /* >> R4 */); >> ?? - const Register Rnative_code??? = AARCH64_ONLY(R22) >> NOT_AARCH64(Rtmp_save1 /* >> R5 */); >> ?? + const Register Rsig_handler??? = Rtmp_save0; >> ?? + const Register Rnative_code??? = Rtmp_save1; >> >> Thanks, >> -Aleksey >> From david.holmes at oracle.com Sun Sep 23 16:26:39 2018 From: david.holmes at oracle.com (David Holmes) Date: Sun, 23 Sep 2018 12:26:39 -0400 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <25a98e2e-2523-d221-429a-4284938082a9@oracle.com> References: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> <25a98e2e-2523-d221-429a-4284938082a9@oracle.com> Message-ID: Hi Boris, Here is latest webrev with the ARM code updated as well. http://cr.openjdk.java.net/~dholmes/8188764/webrev/ All is_MP removed except where needed for ARMv5 support, MP specific instructions, and controlling of biased locking. I checked the DMB variants and we only generate for ARMv7 anyway, so no issue there. Would very much appreciate whatever test builds you can do on different ARM variants Boris! Thanks, David On 21/09/2018 9:41 AM, David Holmes wrote: > Hi Boris, > > On 21/09/2018 9:34 AM, Boris Ulasevich wrote: >> Hi David, >> >> On 20.09.2018 18:26, David Holmes wrote: >>> Hi Boris, >>> >>> Thanks for jumping on this. I hope you didn't spend too much time on >>> it as I had actually started on the ARM code then decided I didn't >>> need to make the changes, so I'd already gone through pretty much >>> everything that is needed. My concern is with things like the change in >>> >>> src/hotspot/cpu/arm/assembler_arm_32.hpp >>> >>> where you removed the is_MP() check but in fact that needs to remain >>> because the instruction pldw is not present on variants of the v7 >>> architecture without the multi-processor extensions: >> >> Ok. Good point. Sure, my hasty proposal to get rid of is_MP() check in >> arm32 codes was wrong. >> >> One note. I see there is an ambiguity here: is_MP() is a >> multiprocessor system flag (returns true when _processor_count != 1), >> but multi-processor extensions is an optional ARMv7 feature which is >> not related with processors count, so pldw usage should not be >> controlled by is_MP() flag. > > is_MP can't return true unless there is more than one processor > (ignoring the pre-initialization case), so if there's more than one > processor there must be a MP supprting architecture. > >>> http://www.keil.com/support/man/docs/armclang_asm/armclang_asm_pge1425899018492.htm >>> >>> That makes me wonder whether any of the memory barrier instructions >>> may also be missing in some v6/v7 variants as well? >> >> Nobody complained :) And Reference Manual says DMB/DSB are not optional. > > I need to double-check we don't define variants like "dmb sy" that are > architecture specific. > >>> Plus I have to account for uniprocessor ARMv5 so need to see whether >>> MacroAssembler::membar, for example, must also retain the is_MP() check. >> >> Do you want to delete this check? Processor count check seems quite >> natural to see if it has sense to generate memory barriers. > > That is the general thrust of this change. We assume we always have MP > and so always issue memory barriers. > >> By the way, MacroAssembler::fast_lock have >> VM_Version::supports_ldrex() check assertion with message >> "unsupported, yet?". Looks like it is not going to work correctly on >> multiprocessor ARMv5. > > The ARM code does not support multiprocessor ARMv5. > > Thanks, > David > >>> Also in: >>> >>> src/hotspot/cpu/arm/stubGenerator_arm.cpp >>> >>> you can't remove the !is_MP() check and related code as that is >>> needed for ARMv5 (uniprocessor) support. >>> >>> Similarly in >>> >>> src/hotspot/cpu/arm/vm_version_arm_32.cpp >>> >>> you'll probably still want to disable biased-locking for ARMv5. >>> >>> Cheers, >>> David >>> >>> On 20/09/2018 3:31 AM, Boris Ulasevich wrote: >>>> Hi David, >>>> >>>> ?> I have not updated the about-to-be-removed Oracle ARM port code. >>>> >>>> Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. >>>> I would propose the following change - I think we can either add it >>>> to your update or to create a separate RFR after your patch and >>>> JEP-340 commit: >>>> >>>> http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ >>>> >>>> regards, >>>> Boris >>>> >>>> On 18.09.2018 08:32, David Holmes wrote: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>>>> >>>>> As previously discussed in the RFC thread: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >>>>> >>>>> >>>>> this change obsoletes the AssumeMP flag and removes the bulk of the >>>>> logic that is conditional on os::is_MP() as follows: >>>>> >>>>> 1. to gate the introduction of MP-specific features, notably memory >>>>> barriers >>>>> >>>>> The is_MP check is removed and we will always issue memory barriers >>>>> or pre-pend lock prefix etc. >>>>> >>>>> 2. to align certain patchable code sequences (method entry, call >>>>> sites) >>>>> >>>>> The is_MP is removed and we always align patchable locations. >>>>> >>>>> 3. to gate certain optimizations which are questionable on >>>>> uniprocessors >>>>> (see quicken_jni_functions) >>>>> >>>>> These are psuedo-memory-barriers where we manufacture a >>>>> data-dependency >>>>> instead of inserting mfence/lfence (x86 example). These are treated as >>>>> #1 and is_MP is removed. >>>>> >>>>> 4. to gate optimizations which are desirable on uniprocessors >>>>> (mutex/monitor short circuits) >>>>> >>>>> These are spin controls and so is_MP remains. >>>>> >>>>> I have not updated the about-to-be-removed Oracle ARM port code. >>>>> >>>>> Testing: >>>>> ?? - Tiers 1 -3 (mach5) >>>>> >>>>> Performance run TBD. >>>>> >>>>> Thanks, >>>>> David From erik.osterlund at oracle.com Sun Sep 23 20:19:27 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Sun, 23 Sep 2018 22:19:27 +0200 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> <25a98e2e-2523-d221-429a-4284938082a9@oracle.com> Message-ID: <491c5468-882c-7977-3b14-734234fd08db@oracle.com> Hi David, Before I forget about it... In src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp Note that the is_MP() check was used to conditionally poke in an xor trick to create a data dependency to the safepoint counter. You removed the not is_MP() path with this patch. However, note that this use of forced data dependency to elide the need for an acquire or loadload fence is nonsense on x86 hardware, as loadload simply does not reorder. If you look at the corresponding SPARC code, you will find that there is no such confused xor trick, and rightfully so. So while said xor trick is simply not needed, it isn't incorrect to do it. I'll leave it up to you if you want to fix this in this change or not. But that xor trick is confused and should IMO be removed. It makes readers think it's there for a reason. But the assumption that it is needed when is_MP() is wrong. Thanks, /Erik On 2018-09-23 18:26, David Holmes wrote: > Hi Boris, > > Here is latest webrev with the ARM code updated as well. > > http://cr.openjdk.java.net/~dholmes/8188764/webrev/ > > All is_MP removed except where needed for ARMv5 support, MP specific > instructions, and controlling of biased locking. > > I checked the DMB variants and we only generate for ARMv7 anyway, so > no issue there. > > Would very much appreciate whatever test builds you can do on > different ARM variants Boris! > > Thanks, > David > > On 21/09/2018 9:41 AM, David Holmes wrote: >> Hi Boris, >> >> On 21/09/2018 9:34 AM, Boris Ulasevich wrote: >>> Hi David, >>> >>> On 20.09.2018 18:26, David Holmes wrote: >>>> Hi Boris, >>>> >>>> Thanks for jumping on this. I hope you didn't spend too much time >>>> on it as I had actually started on the ARM code then decided I >>>> didn't need to make the changes, so I'd already gone through pretty >>>> much everything that is needed. My concern is with things like the >>>> change in >>>> >>>> src/hotspot/cpu/arm/assembler_arm_32.hpp >>>> >>>> where you removed the is_MP() check but in fact that needs to >>>> remain because the instruction pldw is not present on variants of >>>> the v7 architecture without the multi-processor extensions: >>> >>> Ok. Good point. Sure, my hasty proposal to get rid of is_MP() check >>> in arm32 codes was wrong. >>> >>> One note. I see there is an ambiguity here: is_MP() is a >>> multiprocessor system flag (returns true when _processor_count != >>> 1), but multi-processor extensions is an optional ARMv7 feature >>> which is not related with processors count, so pldw usage should not >>> be controlled by is_MP() flag. >> >> is_MP can't return true unless there is more than one processor >> (ignoring the pre-initialization case), so if there's more than one >> processor there must be a MP supprting architecture. >> >>>> http://www.keil.com/support/man/docs/armclang_asm/armclang_asm_pge1425899018492.htm >>>> >>>> That makes me wonder whether any of the memory barrier instructions >>>> may also be missing in some v6/v7 variants as well? >>> >>> Nobody complained :) And Reference Manual says DMB/DSB are not >>> optional. >> >> I need to double-check we don't define variants like "dmb sy" that >> are architecture specific. >> >>>> Plus I have to account for uniprocessor ARMv5 so need to see >>>> whether MacroAssembler::membar, for example, must also retain the >>>> is_MP() check. >>> >>> Do you want to delete this check? Processor count check seems quite >>> natural to see if it has sense to generate memory barriers. >> >> That is the general thrust of this change. We assume we always have >> MP and so always issue memory barriers. >> >>> By the way, MacroAssembler::fast_lock have >>> VM_Version::supports_ldrex() check assertion with message >>> "unsupported, yet?". Looks like it is not going to work correctly on >>> multiprocessor ARMv5. >> >> The ARM code does not support multiprocessor ARMv5. >> >> Thanks, >> David >> >>>> Also in: >>>> >>>> src/hotspot/cpu/arm/stubGenerator_arm.cpp >>>> >>>> you can't remove the !is_MP() check and related code as that is >>>> needed for ARMv5 (uniprocessor) support. >>>> >>>> Similarly in >>>> >>>> src/hotspot/cpu/arm/vm_version_arm_32.cpp >>>> >>>> you'll probably still want to disable biased-locking for ARMv5. >>>> >>>> Cheers, >>>> David >>>> >>>> On 20/09/2018 3:31 AM, Boris Ulasevich wrote: >>>>> Hi David, >>>>> >>>>> ?> I have not updated the about-to-be-removed Oracle ARM port code. >>>>> >>>>> Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. >>>>> I would propose the following change - I think we can either add >>>>> it to your update or to create a separate RFR after your patch and >>>>> JEP-340 commit: >>>>> >>>>> http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ >>>>> >>>>> regards, >>>>> Boris >>>>> >>>>> On 18.09.2018 08:32, David Holmes wrote: >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >>>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>>>>> >>>>>> As previously discussed in the RFC thread: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >>>>>> >>>>>> >>>>>> this change obsoletes the AssumeMP flag and removes the bulk of >>>>>> the logic that is conditional on os::is_MP() as follows: >>>>>> >>>>>> 1. to gate the introduction of MP-specific features, notably >>>>>> memory barriers >>>>>> >>>>>> The is_MP check is removed and we will always issue memory barriers >>>>>> or pre-pend lock prefix etc. >>>>>> >>>>>> 2. to align certain patchable code sequences (method entry, call >>>>>> sites) >>>>>> >>>>>> The is_MP is removed and we always align patchable locations. >>>>>> >>>>>> 3. to gate certain optimizations which are questionable on >>>>>> uniprocessors >>>>>> (see quicken_jni_functions) >>>>>> >>>>>> These are psuedo-memory-barriers where we manufacture a >>>>>> data-dependency >>>>>> instead of inserting mfence/lfence (x86 example). These are >>>>>> treated as >>>>>> #1 and is_MP is removed. >>>>>> >>>>>> 4. to gate optimizations which are desirable on uniprocessors >>>>>> (mutex/monitor short circuits) >>>>>> >>>>>> These are spin controls and so is_MP remains. >>>>>> >>>>>> I have not updated the about-to-be-removed Oracle ARM port code. >>>>>> >>>>>> Testing: >>>>>> ?? - Tiers 1 -3 (mach5) >>>>>> >>>>>> Performance run TBD. >>>>>> >>>>>> Thanks, >>>>>> David From erik.osterlund at oracle.com Sun Sep 23 21:18:54 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Sun, 23 Sep 2018 17:18:54 -0400 Subject: RFR 8210856: Move InstanceKlass DependencyContext cleaning to SystemDictionary::do_unloading() In-Reply-To: <48247e1b-bb84-5508-7393-f286c83b600f@oracle.com> References: <48247e1b-bb84-5508-7393-f286c83b600f@oracle.com> Message-ID: Hi Coleen, Thank you for sorting this out. Looks good. Thanks, /Erik > On 21 Sep 2018, at 11:45, coleen.phillimore at oracle.com wrote: > > Summary: Already walk classes in ClassLoaderData::unload so generalize to also clean nmethod dependencies. > > The nmethod dependencies should be cleaned before metadata is purged. See bug for more details. > > open webrev at http://cr.openjdk.java.net/~coleenp/8210856.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8210856 > > Tested with hs tier1-7, modified gtest, and compiler/codecache/stress/RandomAllocationTest.java from bug https://bugs.openjdk.java.net/browse/JDK-8143408. > > Thanks, > Coleen > > From david.holmes at oracle.com Sun Sep 23 22:18:26 2018 From: david.holmes at oracle.com (David Holmes) Date: Sun, 23 Sep 2018 18:18:26 -0400 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <491c5468-882c-7977-3b14-734234fd08db@oracle.com> References: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> <25a98e2e-2523-d221-429a-4284938082a9@oracle.com> <491c5468-882c-7977-3b14-734234fd08db@oracle.com> Message-ID: <25b154d1-c42b-f5ab-fd39-a86bb5fe0b50@oracle.com> Hi Erik, I'll file a separate RFE for that. Thanks, David On 23/09/2018 4:19 PM, Erik ?sterlund wrote: > Hi David, > > Before I forget about it... > In src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp > > Note that the is_MP() check was used to conditionally poke in an xor > trick to create a data dependency to the safepoint counter. You removed > the not is_MP() path with this patch. However, note that this use of > forced data dependency to elide the need for an acquire or loadload > fence is nonsense on x86 hardware, as loadload simply does not reorder. > If you look at the corresponding SPARC code, you will find that there is > no such confused xor trick, and rightfully so. > > So while said xor trick is simply not needed, it isn't incorrect to do it. > > I'll leave it up to you if you want to fix this in this change or not. > But that xor trick is confused and should IMO be removed. It makes > readers think it's there for a reason. But the assumption that it is > needed when is_MP() is wrong. > > Thanks, > /Erik > > On 2018-09-23 18:26, David Holmes wrote: >> Hi Boris, >> >> Here is latest webrev with the ARM code updated as well. >> >> http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >> >> All is_MP removed except where needed for ARMv5 support, MP specific >> instructions, and controlling of biased locking. >> >> I checked the DMB variants and we only generate for ARMv7 anyway, so >> no issue there. >> >> Would very much appreciate whatever test builds you can do on >> different ARM variants Boris! >> >> Thanks, >> David >> >> On 21/09/2018 9:41 AM, David Holmes wrote: >>> Hi Boris, >>> >>> On 21/09/2018 9:34 AM, Boris Ulasevich wrote: >>>> Hi David, >>>> >>>> On 20.09.2018 18:26, David Holmes wrote: >>>>> Hi Boris, >>>>> >>>>> Thanks for jumping on this. I hope you didn't spend too much time >>>>> on it as I had actually started on the ARM code then decided I >>>>> didn't need to make the changes, so I'd already gone through pretty >>>>> much everything that is needed. My concern is with things like the >>>>> change in >>>>> >>>>> src/hotspot/cpu/arm/assembler_arm_32.hpp >>>>> >>>>> where you removed the is_MP() check but in fact that needs to >>>>> remain because the instruction pldw is not present on variants of >>>>> the v7 architecture without the multi-processor extensions: >>>> >>>> Ok. Good point. Sure, my hasty proposal to get rid of is_MP() check >>>> in arm32 codes was wrong. >>>> >>>> One note. I see there is an ambiguity here: is_MP() is a >>>> multiprocessor system flag (returns true when _processor_count != >>>> 1), but multi-processor extensions is an optional ARMv7 feature >>>> which is not related with processors count, so pldw usage should not >>>> be controlled by is_MP() flag. >>> >>> is_MP can't return true unless there is more than one processor >>> (ignoring the pre-initialization case), so if there's more than one >>> processor there must be a MP supprting architecture. >>> >>>>> http://www.keil.com/support/man/docs/armclang_asm/armclang_asm_pge1425899018492.htm >>>>> >>>>> That makes me wonder whether any of the memory barrier instructions >>>>> may also be missing in some v6/v7 variants as well? >>>> >>>> Nobody complained :) And Reference Manual says DMB/DSB are not >>>> optional. >>> >>> I need to double-check we don't define variants like "dmb sy" that >>> are architecture specific. >>> >>>>> Plus I have to account for uniprocessor ARMv5 so need to see >>>>> whether MacroAssembler::membar, for example, must also retain the >>>>> is_MP() check. >>>> >>>> Do you want to delete this check? Processor count check seems quite >>>> natural to see if it has sense to generate memory barriers. >>> >>> That is the general thrust of this change. We assume we always have >>> MP and so always issue memory barriers. >>> >>>> By the way, MacroAssembler::fast_lock have >>>> VM_Version::supports_ldrex() check assertion with message >>>> "unsupported, yet?". Looks like it is not going to work correctly on >>>> multiprocessor ARMv5. >>> >>> The ARM code does not support multiprocessor ARMv5. >>> >>> Thanks, >>> David >>> >>>>> Also in: >>>>> >>>>> src/hotspot/cpu/arm/stubGenerator_arm.cpp >>>>> >>>>> you can't remove the !is_MP() check and related code as that is >>>>> needed for ARMv5 (uniprocessor) support. >>>>> >>>>> Similarly in >>>>> >>>>> src/hotspot/cpu/arm/vm_version_arm_32.cpp >>>>> >>>>> you'll probably still want to disable biased-locking for ARMv5. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 20/09/2018 3:31 AM, Boris Ulasevich wrote: >>>>>> Hi David, >>>>>> >>>>>> ?> I have not updated the about-to-be-removed Oracle ARM port code. >>>>>> >>>>>> Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. >>>>>> I would propose the following change - I think we can either add >>>>>> it to your update or to create a separate RFR after your patch and >>>>>> JEP-340 commit: >>>>>> >>>>>> http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ >>>>>> >>>>>> regards, >>>>>> Boris >>>>>> >>>>>> On 18.09.2018 08:32, David Holmes wrote: >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >>>>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>>>>>> >>>>>>> As previously discussed in the RFC thread: >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >>>>>>> >>>>>>> >>>>>>> this change obsoletes the AssumeMP flag and removes the bulk of >>>>>>> the logic that is conditional on os::is_MP() as follows: >>>>>>> >>>>>>> 1. to gate the introduction of MP-specific features, notably >>>>>>> memory barriers >>>>>>> >>>>>>> The is_MP check is removed and we will always issue memory barriers >>>>>>> or pre-pend lock prefix etc. >>>>>>> >>>>>>> 2. to align certain patchable code sequences (method entry, call >>>>>>> sites) >>>>>>> >>>>>>> The is_MP is removed and we always align patchable locations. >>>>>>> >>>>>>> 3. to gate certain optimizations which are questionable on >>>>>>> uniprocessors >>>>>>> (see quicken_jni_functions) >>>>>>> >>>>>>> These are psuedo-memory-barriers where we manufacture a >>>>>>> data-dependency >>>>>>> instead of inserting mfence/lfence (x86 example). These are >>>>>>> treated as >>>>>>> #1 and is_MP is removed. >>>>>>> >>>>>>> 4. to gate optimizations which are desirable on uniprocessors >>>>>>> (mutex/monitor short circuits) >>>>>>> >>>>>>> These are spin controls and so is_MP remains. >>>>>>> >>>>>>> I have not updated the about-to-be-removed Oracle ARM port code. >>>>>>> >>>>>>> Testing: >>>>>>> ?? - Tiers 1 -3 (mach5) >>>>>>> >>>>>>> Performance run TBD. >>>>>>> >>>>>>> Thanks, >>>>>>> David > From erik.osterlund at oracle.com Sun Sep 23 22:26:32 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 24 Sep 2018 00:26:32 +0200 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <25b154d1-c42b-f5ab-fd39-a86bb5fe0b50@oracle.com> References: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> <25a98e2e-2523-d221-429a-4284938082a9@oracle.com> <491c5468-882c-7977-3b14-734234fd08db@oracle.com> <25b154d1-c42b-f5ab-fd39-a86bb5fe0b50@oracle.com> Message-ID: <7614e754-25d4-8253-a4e6-5b54ce133aa8@oracle.com> Hi David, Okay, thanks. Note though that the exact code that you removed that was in the !is_MP() variant, is what we should really have all the time invariant of is_MP(). So in that new RFE, we need to basically throw away the is_MP() code and reintroduce the !is_MP() code. Thanks, /Erik On 2018-09-24 00:18, David Holmes wrote: > Hi Erik, > > I'll file a separate RFE for that. > > Thanks, > David > > On 23/09/2018 4:19 PM, Erik ?sterlund wrote: >> Hi David, >> >> Before I forget about it... >> In src/hotspot/cpu/x86/jniFastGetField_x86_64.cpp >> >> Note that the is_MP() check was used to conditionally poke in an xor >> trick to create a data dependency to the safepoint counter. You >> removed the not is_MP() path with this patch. However, note that this >> use of forced data dependency to elide the need for an acquire or >> loadload fence is nonsense on x86 hardware, as loadload simply does >> not reorder. If you look at the corresponding SPARC code, you will >> find that there is no such confused xor trick, and rightfully so. >> >> So while said xor trick is simply not needed, it isn't incorrect to >> do it. >> >> I'll leave it up to you if you want to fix this in this change or >> not. But that xor trick is confused and should IMO be removed. It >> makes readers think it's there for a reason. But the assumption that >> it is needed when is_MP() is wrong. >> >> Thanks, >> /Erik >> >> On 2018-09-23 18:26, David Holmes wrote: >>> Hi Boris, >>> >>> Here is latest webrev with the ARM code updated as well. >>> >>> http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>> >>> All is_MP removed except where needed for ARMv5 support, MP specific >>> instructions, and controlling of biased locking. >>> >>> I checked the DMB variants and we only generate for ARMv7 anyway, so >>> no issue there. >>> >>> Would very much appreciate whatever test builds you can do on >>> different ARM variants Boris! >>> >>> Thanks, >>> David >>> >>> On 21/09/2018 9:41 AM, David Holmes wrote: >>>> Hi Boris, >>>> >>>> On 21/09/2018 9:34 AM, Boris Ulasevich wrote: >>>>> Hi David, >>>>> >>>>> On 20.09.2018 18:26, David Holmes wrote: >>>>>> Hi Boris, >>>>>> >>>>>> Thanks for jumping on this. I hope you didn't spend too much time >>>>>> on it as I had actually started on the ARM code then decided I >>>>>> didn't need to make the changes, so I'd already gone through >>>>>> pretty much everything that is needed. My concern is with things >>>>>> like the change in >>>>>> >>>>>> src/hotspot/cpu/arm/assembler_arm_32.hpp >>>>>> >>>>>> where you removed the is_MP() check but in fact that needs to >>>>>> remain because the instruction pldw is not present on variants of >>>>>> the v7 architecture without the multi-processor extensions: >>>>> >>>>> Ok. Good point. Sure, my hasty proposal to get rid of is_MP() >>>>> check in arm32 codes was wrong. >>>>> >>>>> One note. I see there is an ambiguity here: is_MP() is a >>>>> multiprocessor system flag (returns true when _processor_count != >>>>> 1), but multi-processor extensions is an optional ARMv7 feature >>>>> which is not related with processors count, so pldw usage should >>>>> not be controlled by is_MP() flag. >>>> >>>> is_MP can't return true unless there is more than one processor >>>> (ignoring the pre-initialization case), so if there's more than one >>>> processor there must be a MP supprting architecture. >>>> >>>>>> http://www.keil.com/support/man/docs/armclang_asm/armclang_asm_pge1425899018492.htm >>>>>> >>>>>> That makes me wonder whether any of the memory barrier >>>>>> instructions may also be missing in some v6/v7 variants as well? >>>>> >>>>> Nobody complained :) And Reference Manual says DMB/DSB are not >>>>> optional. >>>> >>>> I need to double-check we don't define variants like "dmb sy" that >>>> are architecture specific. >>>> >>>>>> Plus I have to account for uniprocessor ARMv5 so need to see >>>>>> whether MacroAssembler::membar, for example, must also retain the >>>>>> is_MP() check. >>>>> >>>>> Do you want to delete this check? Processor count check seems >>>>> quite natural to see if it has sense to generate memory barriers. >>>> >>>> That is the general thrust of this change. We assume we always have >>>> MP and so always issue memory barriers. >>>> >>>>> By the way, MacroAssembler::fast_lock have >>>>> VM_Version::supports_ldrex() check assertion with message >>>>> "unsupported, yet?". Looks like it is not going to work correctly >>>>> on multiprocessor ARMv5. >>>> >>>> The ARM code does not support multiprocessor ARMv5. >>>> >>>> Thanks, >>>> David >>>> >>>>>> Also in: >>>>>> >>>>>> src/hotspot/cpu/arm/stubGenerator_arm.cpp >>>>>> >>>>>> you can't remove the !is_MP() check and related code as that is >>>>>> needed for ARMv5 (uniprocessor) support. >>>>>> >>>>>> Similarly in >>>>>> >>>>>> src/hotspot/cpu/arm/vm_version_arm_32.cpp >>>>>> >>>>>> you'll probably still want to disable biased-locking for ARMv5. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> On 20/09/2018 3:31 AM, Boris Ulasevich wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> ?> I have not updated the about-to-be-removed Oracle ARM port code. >>>>>>> >>>>>>> Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. >>>>>>> I would propose the following change - I think we can either add >>>>>>> it to your update or to create a separate RFR after your patch >>>>>>> and JEP-340 commit: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ >>>>>>> >>>>>>> regards, >>>>>>> Boris >>>>>>> >>>>>>> On 18.09.2018 08:32, David Holmes wrote: >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >>>>>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>>>>>>> >>>>>>>> As previously discussed in the RFC thread: >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >>>>>>>> >>>>>>>> >>>>>>>> this change obsoletes the AssumeMP flag and removes the bulk of >>>>>>>> the logic that is conditional on os::is_MP() as follows: >>>>>>>> >>>>>>>> 1. to gate the introduction of MP-specific features, notably >>>>>>>> memory barriers >>>>>>>> >>>>>>>> The is_MP check is removed and we will always issue memory >>>>>>>> barriers >>>>>>>> or pre-pend lock prefix etc. >>>>>>>> >>>>>>>> 2. to align certain patchable code sequences (method entry, >>>>>>>> call sites) >>>>>>>> >>>>>>>> The is_MP is removed and we always align patchable locations. >>>>>>>> >>>>>>>> 3. to gate certain optimizations which are questionable on >>>>>>>> uniprocessors >>>>>>>> (see quicken_jni_functions) >>>>>>>> >>>>>>>> These are psuedo-memory-barriers where we manufacture a >>>>>>>> data-dependency >>>>>>>> instead of inserting mfence/lfence (x86 example). These are >>>>>>>> treated as >>>>>>>> #1 and is_MP is removed. >>>>>>>> >>>>>>>> 4. to gate optimizations which are desirable on uniprocessors >>>>>>>> (mutex/monitor short circuits) >>>>>>>> >>>>>>>> These are spin controls and so is_MP remains. >>>>>>>> >>>>>>>> I have not updated the about-to-be-removed Oracle ARM port code. >>>>>>>> >>>>>>>> Testing: >>>>>>>> ?? - Tiers 1 -3 (mach5) >>>>>>>> >>>>>>>> Performance run TBD. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >> From sgehwolf at redhat.com Mon Sep 24 07:46:43 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 24 Sep 2018 09:46:43 +0200 Subject: What's the point of test/hotspot/jtreg/runtime/jsig? In-Reply-To: <585afd2a-8dbc-c3e3-2d5f-a639164931f2@oracle.com> References: <4f347bcc-a918-dfd4-0a28-3de90812a1ef@oracle.com> <585afd2a-8dbc-c3e3-2d5f-a639164931f2@oracle.com> Message-ID: <7c597f1a0b88f20855d71fe7d547b3cfa03f4fd0.camel@redhat.com> On Sun, 2018-09-23 at 10:53 -0400, David Holmes wrote: > Hi Thomas, > > On 23/09/2018 10:33 AM, Thomas Matthijs wrote: > > Maybe this one ? apologies if incorrect > > > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-May/019305.html > > You're absolutely correct - thanks! I checked July and June manually but > didn't go back to May (wow that was a long delay between review and push!). > > The Testjsig.java file indeed seems to have been omitted from the > commit. I can fix that today. Thanks for the detective work! Cheers, Severin From matthias.baesken at sap.com Mon Sep 24 08:21:05 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 24 Sep 2018 08:21:05 +0000 Subject: RFR [XS] : 8210961: [aix] enhance list of environment variables reported in error log file on AIX In-Reply-To: References: Message-ID: > You mean, starting 32bit AIX binaries from our 64bit jvm? Is this even > possible? Yes , it is possible to start 32bit executables (e.g. via ProcessBuilder) from Java on AIX . Would be bad if it would not be possible - because a lot of system commands (like /usr/bin/pwd) are 32bit . At least this is what dump shows we when looking at the executables in /usr/bin on an AIX 7.1 server . Best regards, Matthias > -----Original Message----- > From: Thomas St?fe > Sent: Freitag, 21. September 2018 21:08 > To: Baesken, Matthias > Cc: Volker Simonis ; HotSpot Open Source > Developers > Subject: Re: RFR [XS] : 8210961: [aix] enhance list of environment variables > reported in error log file on AIX > > Hi Matthias, > > On Fri, Sep 21, 2018 at 8:54 AM, Baesken, Matthias > wrote: > > Hi Volker, sure the LDR_PRELOAD might not be so important any more > these days . > > However it might be fine to have it included in the list of environment > variables for the sake of completeness ( in it is maybe of interest in cases > where we start > > other (32bit) binaries from java ). > > > > You mean, starting 32bit AIX binaries from our 64bit jvm? Is this even > possible? > > Best Regards, Thomas > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: Volker Simonis > >> Sent: Donnerstag, 20. September 2018 17:41 > >> To: Baesken, Matthias > >> Cc: HotSpot Open Source Developers > >> Subject: Re: RFR [XS] : 8210961: [aix] enhance list of environment > variables > >> reported in error log file on AIX > >> > >> Hi Matthias, > >> > >> looks good! > >> > >> Do we really need LDR_PRELOAD? The documentation you've linked > >> mentions that it is only used for 32-bit process which we don't > >> support anyway. > >> > >> I think it may be better to leave it out completely, otherwise people > >> may get confused if they see that LDR_PRELOAD was defined. > >> > >> Thank you and best regards, > >> Volker > >> > >> On Thu, Sep 20, 2018 at 2:13 PM Baesken, Matthias > >> wrote: > >> > > >> > Hello, Please review this small enhancement. > >> > > >> > It adds these AIX-related environment variables to the already existing > list > >> of environment variables that should be reported in error log file (hs_err > file) > >> : > >> > > >> > LIBPATH : environment variable to locate shared libraries , see > >> > https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.1.0/com.ib > >> m.java.aix.71.doc/user/setlpath.html > >> > > >> > LDR_PRELOAD / LDR_PRELOAD64 : similar to LD_PRELOAD on Linux , > see > >> > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm. > >> aix.performance/preloading_shared_libraries.htm > >> > > >> > > >> > http://cr.openjdk.java.net/~mbaesken/webrevs/8210961/ > >> > > >> > bug : https://bugs.openjdk.java.net/browse/JDK-8210961 > >> > > >> > > >> > Thanks, Matthias From thomas.stuefe at gmail.com Mon Sep 24 11:06:27 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 24 Sep 2018 13:06:27 +0200 Subject: RFR [XS] : 8210961: [aix] enhance list of environment variables reported in error log file on AIX In-Reply-To: References: Message-ID: Interesting. Thank you for clarifying. In that case, I think the patch is fine. Best Regards, Thomas On Mon, Sep 24, 2018, 10:21 Baesken, Matthias wrote: > > You mean, starting 32bit AIX binaries from our 64bit jvm? Is this even > > possible? > > > Yes , it is possible to start 32bit executables (e.g. via > ProcessBuilder) from Java on AIX . > Would be bad if it would not be possible - because a lot of system > commands (like /usr/bin/pwd) are 32bit . > At least this is what dump shows we when looking at the executables > in /usr/bin on an AIX 7.1 server . > > > Best regards, Matthias > > > > > -----Original Message----- > > From: Thomas St?fe > > Sent: Freitag, 21. September 2018 21:08 > > To: Baesken, Matthias > > Cc: Volker Simonis ; HotSpot Open Source > > Developers > > Subject: Re: RFR [XS] : 8210961: [aix] enhance list of environment > variables > > reported in error log file on AIX > > > > Hi Matthias, > > > > On Fri, Sep 21, 2018 at 8:54 AM, Baesken, Matthias > > wrote: > > > Hi Volker, sure the LDR_PRELOAD might not be so important any more > > these days . > > > However it might be fine to have it included in the list of > environment > > variables for the sake of completeness ( in it is maybe of interest in > cases > > where we start > > > other (32bit) binaries from java ). > > > > > > > You mean, starting 32bit AIX binaries from our 64bit jvm? Is this even > > possible? > > > > Best Regards, Thomas > > > > > Best regards, Matthias > > > > > > > > > > > >> -----Original Message----- > > >> From: Volker Simonis > > >> Sent: Donnerstag, 20. September 2018 17:41 > > >> To: Baesken, Matthias > > >> Cc: HotSpot Open Source Developers > > >> Subject: Re: RFR [XS] : 8210961: [aix] enhance list of environment > > variables > > >> reported in error log file on AIX > > >> > > >> Hi Matthias, > > >> > > >> looks good! > > >> > > >> Do we really need LDR_PRELOAD? The documentation you've linked > > >> mentions that it is only used for 32-bit process which we don't > > >> support anyway. > > >> > > >> I think it may be better to leave it out completely, otherwise people > > >> may get confused if they see that LDR_PRELOAD was defined. > > >> > > >> Thank you and best regards, > > >> Volker > > >> > > >> On Thu, Sep 20, 2018 at 2:13 PM Baesken, Matthias > > >> wrote: > > >> > > > >> > Hello, Please review this small enhancement. > > >> > > > >> > It adds these AIX-related environment variables to the already > existing > > list > > >> of environment variables that should be reported in error log file > (hs_err > > file) > > >> : > > >> > > > >> > LIBPATH : environment variable to locate shared libraries , see > > >> > > https://www.ibm.com/support/knowledgecenter/en/SSYKE2_7.1.0/com.ib > > >> m.java.aix.71.doc/user/setlpath.html > > >> > > > >> > LDR_PRELOAD / LDR_PRELOAD64 : similar to LD_PRELOAD on Linux , > > see > > >> > > https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/com.ibm. > > >> aix.performance/preloading_shared_libraries.htm > > >> > > > >> > > > >> > http://cr.openjdk.java.net/~mbaesken/webrevs/8210961/ > > >> > > > >> > bug : https://bugs.openjdk.java.net/browse/JDK-8210961 > > >> > > > >> > > > >> > Thanks, Matthias > From matthias.baesken at sap.com Mon Sep 24 13:14:34 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 24 Sep 2018 13:14:34 +0000 Subject: RFR [XS] 8210964: add more ld preloading info to hs_error file on Linux In-Reply-To: References: Message-ID: Hi Thomas, thanks for your input ! I followed your suggestions : - renamed the function to os::Linux::print_ld_preload_file - output the header only in case the file is opened - changed (shortened) the header > > Also, I personally would not expose it via os_linux.hpp. However I kept it there, to keep it in line with the other info-functions. New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.1/ Best regards, Matthias > -----Original Message----- > From: Thomas St?fe > Sent: Freitag, 21. September 2018 18:59 > To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR [XS] 8210964: add more ld preloading info to hs_error file on > Linux > > On Fri, Sep 21, 2018 at 6:47 PM, Thomas St?fe > wrote: > > Hi Matthias, > > > > in the posted patch the new function is never called, or am I mistaken? > > > > Scratch that, I was being blind. > > What I do not like is the very generic name of the function. It does > one very specific thing, so could we name it accordingly, e.g. > "os::Linux::print_system_config_info" -> > "os::Linux::print_ld_preload_file"? > > Also, I personally would not expose it via os_linux.hpp. I would just > put it as a file scope static function into os_linux.cpp. I see you > follow the example of others here (os::Linux::print_proc_sys_info etc) > but there too I feel this is a bad pattern and those functions do not > belong into an external header. > > 2140 st->print_cr("/etc/ld.so.preload (system-wide LD_PRELOAD config > file):"); > > I would shorten that to just "ld.so.preload:" or "/etc/ld.so.preload". > Everyone looking at that section knows what that file does. I also > would omit that header completely if the file cannot be opened. > > 2141 bool file_present = _print_ascii_file("/etc/ld.so.preload", st); > 2142 if (!file_present) { st->print("file not present"); } > 2143 st->cr(); > > You do not know that the file is not preset, all you know is that the > open() call in _print_ascii_file() failed. Since existence of this > file is optional, and not typical, I would just omit messages if it > cannot be found. > > Best Regards, Thomas > From thomas.stuefe at gmail.com Mon Sep 24 14:45:09 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 24 Sep 2018 16:45:09 +0200 Subject: RFR [XS] 8210964: add more ld preloading info to hs_error file on Linux In-Reply-To: References: Message-ID: Hi Matthias, Hm. I see now that my request to not print the header line of ld.preload made the patch more complicated than necessary. Sorry for that. If you like, you can revert to the previous version, I would just ask you to change the error message to a more generic sentence, e.g.: void os::Linux::print_system_config_info(outputStream* st) { st->cr(); st->print_cr("/etc/ld.so.preload (system-wide LD_PRELOAD config file):"); bool success = _print_ascii_file("/etc/ld.so.preload", st); if (!success) { st->print("not available"); } st->cr(); st->cr(); } I am fine with both versions. I leave it up to you if you ship the second variant of the first one (with the changed error message). I do not need another webrev. Thanks, Thomas On Mon, Sep 24, 2018 at 3:14 PM, Baesken, Matthias wrote: > Hi Thomas, thanks for your input ! > > I followed your suggestions : > - renamed the function to os::Linux::print_ld_preload_file > - output the header only in case the file is opened > - changed (shortened) the header > >> > Also, I personally would not expose it via os_linux.hpp. > > However I kept it there, to keep it in line with the other info-functions. > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.1/ > > > Best regards, Matthias > > > >> -----Original Message----- >> From: Thomas St?fe >> Sent: Freitag, 21. September 2018 18:59 >> To: Baesken, Matthias >> Cc: hotspot-dev at openjdk.java.net >> Subject: Re: RFR [XS] 8210964: add more ld preloading info to hs_error file on >> Linux >> >> On Fri, Sep 21, 2018 at 6:47 PM, Thomas St?fe >> wrote: >> > Hi Matthias, >> > >> > in the posted patch the new function is never called, or am I mistaken? >> > >> >> Scratch that, I was being blind. >> >> What I do not like is the very generic name of the function. It does >> one very specific thing, so could we name it accordingly, e.g. >> "os::Linux::print_system_config_info" -> >> "os::Linux::print_ld_preload_file"? >> >> Also, I personally would not expose it via os_linux.hpp. I would just >> put it as a file scope static function into os_linux.cpp. I see you >> follow the example of others here (os::Linux::print_proc_sys_info etc) >> but there too I feel this is a bad pattern and those functions do not >> belong into an external header. >> >> 2140 st->print_cr("/etc/ld.so.preload (system-wide LD_PRELOAD config >> file):"); >> >> I would shorten that to just "ld.so.preload:" or "/etc/ld.so.preload". >> Everyone looking at that section knows what that file does. I also >> would omit that header completely if the file cannot be opened. >> >> 2141 bool file_present = _print_ascii_file("/etc/ld.so.preload", st); >> 2142 if (!file_present) { st->print("file not present"); } >> 2143 st->cr(); >> >> You do not know that the file is not preset, all you know is that the >> open() call in _print_ascii_file() failed. Since existence of this >> file is optional, and not typical, I would just omit messages if it >> cannot be found. >> >> Best Regards, Thomas >> > From daniel.daugherty at oracle.com Mon Sep 24 14:46:49 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 24 Sep 2018 10:46:49 -0400 Subject: What's the point of test/hotspot/jtreg/runtime/jsig? In-Reply-To: References: <4f347bcc-a918-dfd4-0a28-3de90812a1ef@oracle.com> Message-ID: On 9/23/18 9:22 AM, David Holmes wrote: > This was done by: > > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a0cdf5e20489 > > "8144279: [TESTBUG] hotspot/runtime/jsig/Test8017498.sh should use > native library build support" > > I would have to guess the main test file was not hg added for the > commit. But I can't find the code review for it. > > I've filed: > > https://bugs.openjdk.java.net/browse/JDK-821104 The correct bug link: https://bugs.openjdk.java.net/browse/JDK-8211045 Dan > > Thanks, > David > > On 21/09/2018 6:48 PM, David Holmes wrote: >> Hi Severin, >> >> I would have to guess that this was intended to be converted to a >> Java test and either the main test file was not hg added, or else ... >> >> I can't find the changeset that removed the sh file to try and see >> what happened. Between file renames and repo reorgs hg log doesn't >> seem to be able to track this. >> >> David >> >> On 21/09/2018 11:22 AM, Severin Gehwolf wrote: >>> Hi, >>> >>> test/hotspot/jtreg/runtime/jsig seems to have come in with JDK-8017498. >>> However, corresponding Test8017498.sh seems to have been removed since >>> and nothing exercises this code as far as I can see. I wonder what's >>> the point of it? >>> >>> There are two options as I see it: >>> >>> 1) >>> Remove dead code in test/hotspot/jtreg/runtime/jsig >>> >>> 2) >>> Rework old Test8017498.sh[1] so that it actually uses classes/natives >>> in test/hotspot/jtreg/runtime/jsig. >>> >>> Which one should it be? I can work on a webrev once it's known what do >>> do. >>> >>> Thanks, >>> Severin >>> >>> [1] >>> http://hg.openjdk.java.net/jdk/jdk/file/352debf44a39/hotspot/test/runtime/jsig/Test8017498.sh >>> >>> From daniel.daugherty at oracle.com Mon Sep 24 16:56:14 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 24 Sep 2018 12:56:14 -0400 Subject: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the ProblemList Message-ID: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com> Greetings, The following bug was used to ProblemList a couple of tests: ??? JDK-8209018 ProblemList tests affected by JDK-8208690 ??? https://bugs.openjdk.java.net/browse/JDK-8209018 Jon's fix for JTREG has been in a promoted JTREG build for a while now so it's time to remove those tests from the ProblemList. Here's the subtask bug to remove the tests from the ProblemList: ??? JDK-8209019 Remove tests affected by JDK-8208690 from the ProblemList ??? https://bugs.openjdk.java.net/browse/JDK-8209019 Here's the diff: $ hg diff diff -r 6c17cf410d7c test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt??? Mon Sep 24 12:18:51 2018 -0400 +++ b/test/jdk/ProblemList.txt??? Mon Sep 24 12:49:53 2018 -0400 @@ -559,9 +559,6 @@ ?java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all -java/net/Socket/LingerTest.java 8208690 generic-all -sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all - ?############################################################################ ?# jdk_nio Thanks, in advance, for any questions, comments or suggestions. Dan From aleksei.voitylov at bell-sw.com Mon Sep 24 17:02:34 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 24 Sep 2018 20:02:34 +0300 Subject: RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <990eb025-8705-8633-abd7-0e87a3dc6d33@bell-sw.com> Message-ID: <02709fdc-5924-1ed5-0654-068434320698@bell-sw.com> Bob, Thank you for doing this. In the meanwhile, some of my fixes were pushed that invalidated your diff, for which I apologize. Here is an updated version of your patch which applies cleanly: http://cr.openjdk.java.net/~avoitylov/webrev.8209093.02/ -Aleksei On 23/09/2018 18:45, Boris Ulasevich wrote: > Hi Bob, > > ? I checked your changes with jtreg and jck. I see no new fails > introduced by this change. > > regards, > Boris > > On 19.09.2018 13:30, Boris Ulasevich wrote: >> Hi Bob, >> >> Thank you for this job! >> I have started testing. Will come back with results next week :) >> The changes is Ok for me. Please see some minor comments below. >> >> regards, >> Boris >> >> On 17.09.2018 20:49, Aleksey Shipilev wrote: >>> On 09/17/2018 07:00 PM, Vladimir Kozlov wrote: >>>> On 9/17/18 9:20 AM, Bob Vandette wrote: >>>>> Please review the changes related to JEP 340 which remove the second >>>>> 64-bit ARM port from the JDK.>> >>>>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >>> >>> I read through the webrev, and it seems to be the clean removal. It >>> also feels >>> very satisfying to drop 15 KLOC of ifdef-ed code. >>> >>> Minor nits: >>> >>> ? *) In src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp and >>> src/hotspot/cpu/arm/interp_masm_arm.cpp we have "#if >>> defined(ASSERT)", which cab >>> be just "#ifdef ASSERT" now >>> >>> ? *) Ditto in src/hotspot/cpu/arm/jniFastGetField_arm.cpp we have "#if >>> defined(__ABI_HARD__)" >>> >>> ? *) In src/hotspot/cpu/arm/macroAssembler_arm.hpp, the comment >>> below seems to >>> apply to AArch64 only. >> >> Yes, the note looks like AArch64 specific comment, but I think it is >> valid for arm32 too. So the change is Ok for me. >> >>> Yet, only the first line of the comment is removed. I >>> think we should instead convert that comment into "TODO:" mentioning >>> this might >>> be revised after AArch64 removal? >>> >>> ? 992?? void branch_if_negative_32(Register r, Label& L) { >>> ? 993???? // Note about branch_if_negative_32() / >>> branch_if_any_negative_32() >>> implementation for AArch64: >>> ? 994???? // tbnz is not used instead of tst & b.mi because >>> destination may be >>> out of tbnz range (+-32KB) >>> ? 995???? // since these methods are used in >>> LIR_Assembler::emit_arraycopy() to >>> jump to stub entry. >>> ? 996???? tst_32(r, r); >>> ? 997???? b(L, mi); >>> ? 998?? } >>> >>> ? *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, lines >>> L1204..1205, L1435..1436 >>> can be merged together: >>> >>> 1203?? // Generate the inner loop for shifted forward array copy >>> (unaligned copy). >>> 1204?? // It can be used when bytes_per_count < wordSize, i.e. >>> 1205?? //? byte/short copy >>> >>> 1434?? // Generate the inner loop for shifted backward array copy >>> (unaligned copy). >>> 1435?? // It can be used when bytes_per_count < wordSize, i.e. >>> 1436?? //? byte/short copy >>> >>> >>> ? *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, the comment changed >>> incorrectly around L3363? >> >> I believe both (L3188 and L3363) comments should mention SP[0] (not >> R4) as an input parameter now. >> >>> ?? - //??? R4 (AArch64) / SP[0] (32-bit ARM) -? element count >>> (32-bit int) >>> ?? + //??? R4??? -? element count (32-bit int) >>> >>> >>> ? *) In src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp, >>> "R4"/"R5" >>> comments are missing: >>> >>> ?? - const Register Rsig_handler??? = AARCH64_ONLY(R21) >>> NOT_AARCH64(Rtmp_save0 /* >>> R4 */); >>> ?? - const Register Rnative_code??? = AARCH64_ONLY(R22) >>> NOT_AARCH64(Rtmp_save1 /* >>> R5 */); >>> ?? + const Register Rsig_handler??? = Rtmp_save0; >>> ?? + const Register Rnative_code??? = Rtmp_save1; >>> >>> Thanks, >>> -Aleksey >>> From daniel.fuchs at oracle.com Mon Sep 24 17:03:52 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 24 Sep 2018 18:03:52 +0100 Subject: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the ProblemList In-Reply-To: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com> References: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com> Message-ID: Looks good to me Dan! Let's see if the errant failure reappear... best regards, -- daniel On 24/09/2018 17:56, Daniel D. Daugherty wrote: > Greetings, > > The following bug was used to ProblemList a couple of tests: > > ??? JDK-8209018 ProblemList tests affected by JDK-8208690 > ??? https://bugs.openjdk.java.net/browse/JDK-8209018 > > Jon's fix for JTREG has been in a promoted JTREG build for > a while now so it's time to remove those tests from the > ProblemList. > > Here's the subtask bug to remove the tests from the ProblemList: > > ??? JDK-8209019 Remove tests affected by JDK-8208690 from the ProblemList > ??? https://bugs.openjdk.java.net/browse/JDK-8209019 > > > Here's the diff: > > $ hg diff > diff -r 6c17cf410d7c test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt??? Mon Sep 24 12:18:51 2018 -0400 > +++ b/test/jdk/ProblemList.txt??? Mon Sep 24 12:49:53 2018 -0400 > @@ -559,9 +559,6 @@ > > ?java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all > > -java/net/Socket/LingerTest.java 8208690 generic-all > -sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all > - > ?############################################################################ > > ?# jdk_nio > > Thanks, in advance, for any questions, comments or suggestions. > > Dan From daniel.daugherty at oracle.com Mon Sep 24 17:04:18 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 24 Sep 2018 13:04:18 -0400 Subject: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the ProblemList In-Reply-To: References: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com> Message-ID: <73330dc5-28c8-1ca4-e9a2-c116b9f7849a@oracle.com> Daniel, Thanks for the fast review! Dan On 9/24/18 1:03 PM, Daniel Fuchs wrote: > Looks good to me Dan! > > Let's see if the errant failure reappear... > > best regards, > > -- daniel > > On 24/09/2018 17:56, Daniel D. Daugherty wrote: >> Greetings, >> >> The following bug was used to ProblemList a couple of tests: >> >> ???? JDK-8209018 ProblemList tests affected by JDK-8208690 >> ???? https://bugs.openjdk.java.net/browse/JDK-8209018 >> >> Jon's fix for JTREG has been in a promoted JTREG build for >> a while now so it's time to remove those tests from the >> ProblemList. >> >> Here's the subtask bug to remove the tests from the ProblemList: >> >> ???? JDK-8209019 Remove tests affected by JDK-8208690 from the >> ProblemList >> ???? https://bugs.openjdk.java.net/browse/JDK-8209019 >> >> >> Here's the diff: >> >> $ hg diff >> diff -r 6c17cf410d7c test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt??? Mon Sep 24 12:18:51 2018 -0400 >> +++ b/test/jdk/ProblemList.txt??? Mon Sep 24 12:49:53 2018 -0400 >> @@ -559,9 +559,6 @@ >> >> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 >> macosx-all >> >> -java/net/Socket/LingerTest.java 8208690 generic-all >> -sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all >> - >> ??############################################################################ >> >> >> ??# jdk_nio >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan > From chris.hegarty at oracle.com Mon Sep 24 17:18:09 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 24 Sep 2018 18:18:09 +0100 Subject: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the ProblemList In-Reply-To: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com> References: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com> Message-ID: <771C0E5A-8E2A-4FD0-B2EC-64CF7975DCF4@oracle.com> Looks good. -Chris. > On 24 Sep 2018, at 17:56, Daniel D. Daugherty wrote: > > Greetings, > > The following bug was used to ProblemList a couple of tests: > > JDK-8209018 ProblemList tests affected by JDK-8208690 > https://bugs.openjdk.java.net/browse/JDK-8209018 > > Jon's fix for JTREG has been in a promoted JTREG build for > a while now so it's time to remove those tests from the > ProblemList. > > Here's the subtask bug to remove the tests from the ProblemList: > > JDK-8209019 Remove tests affected by JDK-8208690 from the ProblemList > https://bugs.openjdk.java.net/browse/JDK-8209019 > > > Here's the diff: > > $ hg diff > diff -r 6c17cf410d7c test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt Mon Sep 24 12:18:51 2018 -0400 > +++ b/test/jdk/ProblemList.txt Mon Sep 24 12:49:53 2018 -0400 > @@ -559,9 +559,6 @@ > > java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all > > -java/net/Socket/LingerTest.java 8208690 generic-all > -sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all > - > ############################################################################ > > # jdk_nio > > Thanks, in advance, for any questions, comments or suggestions. > > Dan From bob.vandette at oracle.com Mon Sep 24 17:34:58 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 24 Sep 2018 13:34:58 -0400 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> <25a98e2e-2523-d221-429a-4284938082a9@oracle.com> Message-ID: David, I assume that you are going to push this change independent of the ARM code removal JEP, right? I just changed the JEP to ?Propose to Target? and will merge any updates with my patch once it is ?Targeted?. Bob. > On Sep 23, 2018, at 12:26 PM, David Holmes wrote: > > Hi Boris, > > Here is latest webrev with the ARM code updated as well. > > http://cr.openjdk.java.net/~dholmes/8188764/webrev/ > > All is_MP removed except where needed for ARMv5 support, MP specific instructions, and controlling of biased locking. > > I checked the DMB variants and we only generate for ARMv7 anyway, so no issue there. > > Would very much appreciate whatever test builds you can do on different ARM variants Boris! > > Thanks, > David > > On 21/09/2018 9:41 AM, David Holmes wrote: >> Hi Boris, >> On 21/09/2018 9:34 AM, Boris Ulasevich wrote: >>> Hi David, >>> >>> On 20.09.2018 18:26, David Holmes wrote: >>>> Hi Boris, >>>> >>>> Thanks for jumping on this. I hope you didn't spend too much time on it as I had actually started on the ARM code then decided I didn't need to make the changes, so I'd already gone through pretty much everything that is needed. My concern is with things like the change in >>>> >>>> src/hotspot/cpu/arm/assembler_arm_32.hpp >>>> >>>> where you removed the is_MP() check but in fact that needs to remain because the instruction pldw is not present on variants of the v7 architecture without the multi-processor extensions: >>> >>> Ok. Good point. Sure, my hasty proposal to get rid of is_MP() check in arm32 codes was wrong. >>> >>> One note. I see there is an ambiguity here: is_MP() is a multiprocessor system flag (returns true when _processor_count != 1), but multi-processor extensions is an optional ARMv7 feature which is not related with processors count, so pldw usage should not be controlled by is_MP() flag. >> is_MP can't return true unless there is more than one processor (ignoring the pre-initialization case), so if there's more than one processor there must be a MP supprting architecture. >>>> http://www.keil.com/support/man/docs/armclang_asm/armclang_asm_pge1425899018492.htm >>>> That makes me wonder whether any of the memory barrier instructions may also be missing in some v6/v7 variants as well? >>> >>> Nobody complained :) And Reference Manual says DMB/DSB are not optional. >> I need to double-check we don't define variants like "dmb sy" that are architecture specific. >>>> Plus I have to account for uniprocessor ARMv5 so need to see whether MacroAssembler::membar, for example, must also retain the is_MP() check. >>> >>> Do you want to delete this check? Processor count check seems quite natural to see if it has sense to generate memory barriers. >> That is the general thrust of this change. We assume we always have MP and so always issue memory barriers. >>> By the way, MacroAssembler::fast_lock have VM_Version::supports_ldrex() check assertion with message "unsupported, yet?". Looks like it is not going to work correctly on multiprocessor ARMv5. >> The ARM code does not support multiprocessor ARMv5. >> Thanks, >> David >>>> Also in: >>>> >>>> src/hotspot/cpu/arm/stubGenerator_arm.cpp >>>> >>>> you can't remove the !is_MP() check and related code as that is needed for ARMv5 (uniprocessor) support. >>>> >>>> Similarly in >>>> >>>> src/hotspot/cpu/arm/vm_version_arm_32.cpp >>>> >>>> you'll probably still want to disable biased-locking for ARMv5. >>>> >>>> Cheers, >>>> David >>>> >>>> On 20/09/2018 3:31 AM, Boris Ulasevich wrote: >>>>> Hi David, >>>>> >>>>> > I have not updated the about-to-be-removed Oracle ARM port code. >>>>> >>>>> Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. >>>>> I would propose the following change - I think we can either add it to your update or to create a separate RFR after your patch and JEP-340 commit: >>>>> >>>>> http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ >>>>> >>>>> regards, >>>>> Boris >>>>> >>>>> On 18.09.2018 08:32, David Holmes wrote: >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >>>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>>>>> >>>>>> As previously discussed in the RFC thread: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >>>>>> >>>>>> this change obsoletes the AssumeMP flag and removes the bulk of the logic that is conditional on os::is_MP() as follows: >>>>>> >>>>>> 1. to gate the introduction of MP-specific features, notably memory barriers >>>>>> >>>>>> The is_MP check is removed and we will always issue memory barriers >>>>>> or pre-pend lock prefix etc. >>>>>> >>>>>> 2. to align certain patchable code sequences (method entry, call sites) >>>>>> >>>>>> The is_MP is removed and we always align patchable locations. >>>>>> >>>>>> 3. to gate certain optimizations which are questionable on uniprocessors >>>>>> (see quicken_jni_functions) >>>>>> >>>>>> These are psuedo-memory-barriers where we manufacture a data-dependency >>>>>> instead of inserting mfence/lfence (x86 example). These are treated as >>>>>> #1 and is_MP is removed. >>>>>> >>>>>> 4. to gate optimizations which are desirable on uniprocessors >>>>>> (mutex/monitor short circuits) >>>>>> >>>>>> These are spin controls and so is_MP remains. >>>>>> >>>>>> I have not updated the about-to-be-removed Oracle ARM port code. >>>>>> >>>>>> Testing: >>>>>> - Tiers 1 -3 (mach5) >>>>>> >>>>>> Performance run TBD. >>>>>> >>>>>> Thanks, >>>>>> David From david.holmes at oracle.com Mon Sep 24 17:49:21 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 24 Sep 2018 13:49:21 -0400 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> <25a98e2e-2523-d221-429a-4284938082a9@oracle.com> Message-ID: <56054ffe-85dd-b131-9459-46473467cbd5@oracle.com> Hi Bob, On 24/09/2018 1:34 PM, Bob Vandette wrote: > David, > > I assume that you are going to push this change independent of the ARM code removal JEP, right? Right - unless you get there first. :) I'm unlikely to push this week. David > I just changed the JEP to ?Propose to Target? and will merge any updates with my patch once > it is ?Targeted?. > > > Bob. > >> On Sep 23, 2018, at 12:26 PM, David Holmes wrote: >> >> Hi Boris, >> >> Here is latest webrev with the ARM code updated as well. >> >> http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >> >> All is_MP removed except where needed for ARMv5 support, MP specific instructions, and controlling of biased locking. >> >> I checked the DMB variants and we only generate for ARMv7 anyway, so no issue there. >> >> Would very much appreciate whatever test builds you can do on different ARM variants Boris! >> >> Thanks, >> David >> >> On 21/09/2018 9:41 AM, David Holmes wrote: >>> Hi Boris, >>> On 21/09/2018 9:34 AM, Boris Ulasevich wrote: >>>> Hi David, >>>> >>>> On 20.09.2018 18:26, David Holmes wrote: >>>>> Hi Boris, >>>>> >>>>> Thanks for jumping on this. I hope you didn't spend too much time on it as I had actually started on the ARM code then decided I didn't need to make the changes, so I'd already gone through pretty much everything that is needed. My concern is with things like the change in >>>>> >>>>> src/hotspot/cpu/arm/assembler_arm_32.hpp >>>>> >>>>> where you removed the is_MP() check but in fact that needs to remain because the instruction pldw is not present on variants of the v7 architecture without the multi-processor extensions: >>>> >>>> Ok. Good point. Sure, my hasty proposal to get rid of is_MP() check in arm32 codes was wrong. >>>> >>>> One note. I see there is an ambiguity here: is_MP() is a multiprocessor system flag (returns true when _processor_count != 1), but multi-processor extensions is an optional ARMv7 feature which is not related with processors count, so pldw usage should not be controlled by is_MP() flag. >>> is_MP can't return true unless there is more than one processor (ignoring the pre-initialization case), so if there's more than one processor there must be a MP supprting architecture. >>>>> http://www.keil.com/support/man/docs/armclang_asm/armclang_asm_pge1425899018492.htm >>>>> That makes me wonder whether any of the memory barrier instructions may also be missing in some v6/v7 variants as well? >>>> >>>> Nobody complained :) And Reference Manual says DMB/DSB are not optional. >>> I need to double-check we don't define variants like "dmb sy" that are architecture specific. >>>>> Plus I have to account for uniprocessor ARMv5 so need to see whether MacroAssembler::membar, for example, must also retain the is_MP() check. >>>> >>>> Do you want to delete this check? Processor count check seems quite natural to see if it has sense to generate memory barriers. >>> That is the general thrust of this change. We assume we always have MP and so always issue memory barriers. >>>> By the way, MacroAssembler::fast_lock have VM_Version::supports_ldrex() check assertion with message "unsupported, yet?". Looks like it is not going to work correctly on multiprocessor ARMv5. >>> The ARM code does not support multiprocessor ARMv5. >>> Thanks, >>> David >>>>> Also in: >>>>> >>>>> src/hotspot/cpu/arm/stubGenerator_arm.cpp >>>>> >>>>> you can't remove the !is_MP() check and related code as that is needed for ARMv5 (uniprocessor) support. >>>>> >>>>> Similarly in >>>>> >>>>> src/hotspot/cpu/arm/vm_version_arm_32.cpp >>>>> >>>>> you'll probably still want to disable biased-locking for ARMv5. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 20/09/2018 3:31 AM, Boris Ulasevich wrote: >>>>>> Hi David, >>>>>> >>>>>> > I have not updated the about-to-be-removed Oracle ARM port code. >>>>>> >>>>>> Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. >>>>>> I would propose the following change - I think we can either add it to your update or to create a separate RFR after your patch and JEP-340 commit: >>>>>> >>>>>> http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ >>>>>> >>>>>> regards, >>>>>> Boris >>>>>> >>>>>> On 18.09.2018 08:32, David Holmes wrote: >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >>>>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>>>>>> >>>>>>> As previously discussed in the RFC thread: >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >>>>>>> >>>>>>> this change obsoletes the AssumeMP flag and removes the bulk of the logic that is conditional on os::is_MP() as follows: >>>>>>> >>>>>>> 1. to gate the introduction of MP-specific features, notably memory barriers >>>>>>> >>>>>>> The is_MP check is removed and we will always issue memory barriers >>>>>>> or pre-pend lock prefix etc. >>>>>>> >>>>>>> 2. to align certain patchable code sequences (method entry, call sites) >>>>>>> >>>>>>> The is_MP is removed and we always align patchable locations. >>>>>>> >>>>>>> 3. to gate certain optimizations which are questionable on uniprocessors >>>>>>> (see quicken_jni_functions) >>>>>>> >>>>>>> These are psuedo-memory-barriers where we manufacture a data-dependency >>>>>>> instead of inserting mfence/lfence (x86 example). These are treated as >>>>>>> #1 and is_MP is removed. >>>>>>> >>>>>>> 4. to gate optimizations which are desirable on uniprocessors >>>>>>> (mutex/monitor short circuits) >>>>>>> >>>>>>> These are spin controls and so is_MP remains. >>>>>>> >>>>>>> I have not updated the about-to-be-removed Oracle ARM port code. >>>>>>> >>>>>>> Testing: >>>>>>> - Tiers 1 -3 (mach5) >>>>>>> >>>>>>> Performance run TBD. >>>>>>> >>>>>>> Thanks, >>>>>>> David > From daniel.daugherty at oracle.com Mon Sep 24 18:37:09 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 24 Sep 2018 14:37:09 -0400 Subject: RFR(XXS): 8209019 remove tests affected by JDK-8208690 from the ProblemList In-Reply-To: <771C0E5A-8E2A-4FD0-B2EC-64CF7975DCF4@oracle.com> References: <80c973be-6d55-738f-d218-9e29b06e3c64@oracle.com> <771C0E5A-8E2A-4FD0-B2EC-64CF7975DCF4@oracle.com> Message-ID: <2c6b970b-0782-972e-b2ce-14dc3027ed16@oracle.com> Chris, Thanks for the review. I can't list you as a reviewer since I pushed right after I got dfuch's review. Dan On 9/24/18 1:18 PM, Chris Hegarty wrote: > Looks good. > > -Chris. > >> On 24 Sep 2018, at 17:56, Daniel D. Daugherty wrote: >> >> Greetings, >> >> The following bug was used to ProblemList a couple of tests: >> >> JDK-8209018 ProblemList tests affected by JDK-8208690 >> https://bugs.openjdk.java.net/browse/JDK-8209018 >> >> Jon's fix for JTREG has been in a promoted JTREG build for >> a while now so it's time to remove those tests from the >> ProblemList. >> >> Here's the subtask bug to remove the tests from the ProblemList: >> >> JDK-8209019 Remove tests affected by JDK-8208690 from the ProblemList >> https://bugs.openjdk.java.net/browse/JDK-8209019 >> >> >> Here's the diff: >> >> $ hg diff >> diff -r 6c17cf410d7c test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt Mon Sep 24 12:18:51 2018 -0400 >> +++ b/test/jdk/ProblemList.txt Mon Sep 24 12:49:53 2018 -0400 >> @@ -559,9 +559,6 @@ >> >> java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all >> >> -java/net/Socket/LingerTest.java 8208690 generic-all >> -sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all >> - >> ############################################################################ >> >> # jdk_nio >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan From igor.ignatyev at oracle.com Mon Sep 24 18:40:54 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 24 Sep 2018 11:40:54 -0700 Subject: RFR (M) 8211036 : Remove the NSK_STUB macros from vmTestbase for non jvmti In-Reply-To: References: Message-ID: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> (cc-ing hotspot-dev alias) Hi Jc, the fix looks good to me. don't forget to clean up nsk/share/jni/README at the end. Thanks, -- Igor > On Sep 24, 2018, at 9:28 AM, JC Beyler wrote: > > Hi all, > > As the tests have become C++ tests, the NSK_CPP_STUBS are no longer needed. I did two awk scripts to remove them and will be rolling them out in 50 file max reviews to streamline the reviews for the reviewers. > > So here is the first which handles all the cases outside of the jvmti subfolder: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211036 > > The bug contains information on the two scripts I used. > > Thanks, > Jc From rkennke at redhat.com Mon Sep 24 19:29:36 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 24 Sep 2018 21:29:36 +0200 Subject: RFR: JDK-8211061: Tests fail with assert(VM_Version::supports_sse4_1()) on ThreadRipper CPU Message-ID: <8470d1f1-e878-7a01-ca1b-bacbb0b845e6@redhat.com> Some tests fail with: # Internal Error (/home/rkennke/src/openjdk/jdk-jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3819), pid=5051, tid=5055 # Error: assert(VM_Version::supports_sse4_1()) failed When running hotspot/jtreg:tier1 on my ThreadRipper 1950X box. On my Intel box, this works fine. It looks like it attempts to generate fast_sha1 stubs, which use Assembler::pinsrd() but then runs into supports_sse4_1(). The failing tier1 tests are: compiler/c1/Test6579789.java compiler/c1/Test6855215.java compiler/cpuflags/TestSSE4Disabled.java The failing tests seem to disable SSE4 or SSE altogether and check if it still compiles fine. This does not go well for the SHA1 and SHA256 stubs because they use SSE4.1 instructions. It seems that it compiles on my Intel box because that doesn't support_sha(), and thus disables those intrinsics altogether. The proposed fix is to check for SSE4.1 present before enabling the affected intrinsics. Bug: https://bugs.openjdk.java.net/browse/JDK-8211061 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8211061/webrev.00/ Testing: hotspot/jtreg:tier1 failed before, now passes Thanks, Roman From magnus.ihse.bursie at oracle.com Mon Sep 24 20:31:35 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 24 Sep 2018 22:31:35 +0200 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot Message-ID: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> The -Wextra option to gcc enables a bunch of useful warnings.[1] Some of them, but not all, can be individually enabled or disabled. All other libraries in OpenJDK are compiled with -Wextra, but not Hotspot. Enabling -Wextra on Hotspot triggers a couple of warnings for zero that can be individually disabled. However, -Wextra also includes some check that cannot be disabled individually, so to be able to add this, we must at the same time fix those warnings. The warnings that cannot be disabled and which have been triggered in Hotspot is "enumeral and non-enumeral type in conditional expression" and "base class should be explicitly initialized in the copy constructor". The former complains about mixing enums and integers in the tertiary operator (x ? enum_val : int_val). If you think that gcc is a bit too picky here, I agree. It's not obvious per se that the added casts improve the code. However, this is the price we need to pay to be able to enable -Wextra, and *that* is something that is likely to improve the code. The second warning about the copy constructor is, for what I can tell, a highly valid warning and the code it warned on was indeed broken. As far as I can tell, in a derived copy constructor you should always explicitly initialize the base class. Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8211073-remove-Wno-extra-from-hotspot/webrev.01 /Magnus [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html From erik.joelsson at oracle.com Mon Sep 24 21:07:09 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 24 Sep 2018 14:07:09 -0700 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> References: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> Message-ID: Build change looks ok. I will leave it for someone better versed in C++ for the code changes. /Erik On 2018-09-24 13:31, Magnus Ihse Bursie wrote: > The -Wextra option to gcc enables a bunch of useful warnings.[1] Some > of them, but not all, can be individually enabled or disabled. All > other libraries in OpenJDK are compiled with -Wextra, but not Hotspot. > Enabling -Wextra on Hotspot triggers a couple of warnings for zero > that can be individually disabled. > > However, -Wextra also includes some check that cannot be disabled > individually, so to be able to add this, we must at the same time fix > those warnings. > > The warnings that cannot be disabled and which have been triggered in > Hotspot is "enumeral and non-enumeral type in conditional expression" > and "base class should be explicitly initialized in the copy > constructor". The former complains about mixing enums and integers in > the tertiary operator (x ? enum_val : int_val). If you think that gcc > is a bit too picky here, I agree. It's not obvious per se that the > added casts improve the code. However, this is the price we need to > pay to be able to enable -Wextra, and *that* is something that is > likely to improve the code. > > The second warning about the copy constructor is, for what I can tell, > a highly valid warning and the code it warned on was indeed broken. As > far as I can tell, in a derived copy constructor you should always > explicitly initialize the base class. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8211073-remove-Wno-extra-from-hotspot/webrev.01 > > /Magnus > > [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html > From jcbeyler at google.com Mon Sep 24 21:17:03 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 24 Sep 2018 14:17:03 -0700 Subject: RFR (M) 8211036 : Remove the NSK_STUB macros from vmTestbase for non jvmti In-Reply-To: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> References: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> Message-ID: Thanks Igor, I added https://bugs.openjdk.java.net/browse/JDK-8211072 to not forget it. Thanks again! Jc On Mon, Sep 24, 2018 at 11:40 AM Igor Ignatyev wrote: > (cc-ing hotspot-dev alias) > > Hi Jc, > > the fix looks good to me. don't forget to clean up nsk/share/jni/README at > the end. > > Thanks, > -- Igor > > On Sep 24, 2018, at 9:28 AM, JC Beyler wrote: > > Hi all, > > As the tests have become C++ tests, the NSK_CPP_STUBS are no longer > needed. I did two awk scripts to remove them and will be rolling them out > in 50 file max reviews to streamline the reviews for the reviewers. > > So here is the first which handles all the cases outside of the jvmti > subfolder: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211036 > > The bug contains information on the two scripts I used. > > Thanks, > Jc > > > -- Thanks, Jc From dean.long at oracle.com Mon Sep 24 22:05:48 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 24 Sep 2018 15:05:48 -0700 Subject: RFR 8210856: Move InstanceKlass DependencyContext cleaning to SystemDictionary::do_unloading() In-Reply-To: <48247e1b-bb84-5508-7393-f286c83b600f@oracle.com> References: <48247e1b-bb84-5508-7393-f286c83b600f@oracle.com> Message-ID: <51375a10-4a8f-9c85-56c4-5942077910db@oracle.com> Hi Coleen.? The fix seems straightforward now, so I'm wondering, was there something that changed since the earlier JDK-8143408 was fixed that allows us to do this simpler fix now, like walking classes in ClassLoaderData::unload? dl On 9/21/18 8:45 AM, coleen.phillimore at oracle.com wrote: > Summary: Already walk classes in ClassLoaderData::unload so generalize > to also clean nmethod dependencies. > > The nmethod dependencies should be cleaned before metadata is purged.? > See bug for more details. > > open webrev at http://cr.openjdk.java.net/~coleenp/8210856.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8210856 > > Tested with hs tier1-7, modified gtest, and > compiler/codecache/stress/RandomAllocationTest.java from bug > https://bugs.openjdk.java.net/browse/JDK-8143408. > > Thanks, > Coleen > > From mikael.vidstedt at oracle.com Tue Sep 25 05:20:01 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 24 Sep 2018 22:20:01 -0700 Subject: RFR(M): 8210848: Obsolete SyncKnobs In-Reply-To: <6B90D6CC-A565-4DDA-A0F3-11209213AB6D@oracle.com> References: <1D612813-2ABB-4226-8ED4-5F541C22B4E6@oracle.com> <6B90D6CC-A565-4DDA-A0F3-11209213AB6D@oracle.com> Message-ID: Claes/Coleen/David/Dan - thanks a lot for the reviews! Change pushed. I?ll follow up with additional cleanup changes shortly, specifically: * Removal of DeferredInitialize * Knob variable rename Cheers, Mikael > On Sep 21, 2018, at 2:49 PM, Mikael Vidstedt wrote: > > > >> On Sep 21, 2018, at 2:43 PM, David Holmes wrote: >> >> Hi Mikael, >> >> On 20/09/2018 1:12 AM, Mikael Vidstedt wrote: >>>> On Sep 18, 2018, at 11:33 PM, David Holmes > wrote: >>>> >>>> Hi Mikael, >>>> >>>> Code review from 34,000ft :) >>> Ha! :) >>>> Generally looks good for the algorithmic selection knobs. Though I am sad to see some of this go - specifically the code for the different queuing policies after a notify(). I have vague recollections of applications encountering pathological behaviour with particular and excessive use of wait/notify, that was fixed by changing the queuing policy. But at least that code would be relative simple to add back if someone wanted to. >>>> >>>> I have some concerns about the handling of the spin related knobs. We have sophisticated spin logic to optimise performance** which involves a large number of tuning knobs. Many of those knobs are gone as their values could only change at build time. A few remain because they are affected by os::is_MP. So what we end up with is a partial simplification where the code is no longer readily tunable (if someone needed to do it), but nor is it that simple. >>>> >>>> ** What concerns me is that we have this sophisticated but unused code, not because it is stale/dead/un-needed, but because the collective "we" has lost the ability and/or motivation to actually try and tune this as hardware has evolved. We no longer know how optimal the remaining spin knobs actually are - and certainly not across the broader range of architectures that OpenJDK now supports. Maybe the better path for this "unused code" is to start using it? >>> Right, it all comes down to priorities and where we spend our time (no pun intended). Since nobody seems to have looked at/used/changed this recently I think we?ll have to assume and accept that this is not the area we consider in need of the most attention right now. Simplifying the code at least means we get rid of the unused complexity, and it?s easier for people to understand the part of the algorithm and code actually used today. >> >> I'll refrain from further comment on this. :) >> >>>> I have a few specific comments: >>>> >>>> Knob_Verbose: instead of outright deleting this now should we instead have a RFE to convert to UL where appropriate and feasible (and perhaps just use tty and TraceXXX if UL can not be used). In particular logging around ForceMonitorScavenge might be useful (unless we're going to obsolete that too :) ). >>> I?d be very hesitant to spend time on investigating the interaction with UL and/or introducing a trace flag unless the logging is actually useful, and I personally haven?t seen any evidence of that, at least not in modern times. Do speak up if you read this and have found it useful enough to motivate the investment! >> >> I would think whomever is working on the monitor deflation problem might be interested in how ForceMonitorScavenge works. But I guess they can add something back if needed. >> >>>> --- >>>> >>>> thread.cpp: >>>> >>>> This comment block is no longer relevant: >>>> >>>> 1956 // Optionally release any monitors for regular JavaThread exits. This >>>> 1957 // is provided as a work around for any bugs in monitor enter-exit >>>> 1958 // matching. This can be expensive so it is not enabled by default. >>> Good catch, consider it removed! >>>> I wonder if we could just assert there are no held monitors in the regular JavaThread case ? ? >>> Good question, I don?t have an answer :) >> >> I see Dan answered this. Note sure the tests he refers to are valid, on the other hand such usage does seem to fall into a spec hole. Normal Java lock usage can't forget to release monitors. JNI attached threads that don't release, have monitors released when they detach. But Java threads that use JNI to lock but not unlock are not covered. okay forget about the assert. >> >>>> >>>> --- >>>> >>>> synchronizer.cpp: >>>> >>>> is verifyInUse dead code now? (I have to wonder whether everything would be shown to be okay if we turned on these checks? More generally is this a sanity check we should actually be performing in debug builds, or was this really only useful during the development of the "in use" lists? I suspect the latter.) >>> Yes, Coleen also found that verifyInUse is indeed dead - consider it gone (in webrev.01). >> >> Ok >> >>>> >>>> --- >>>> >>>> objectMonitor.cpp: >>>> >>>> Aside: This comment block is out of date and can be deleted. >>>> >>>> 904 // I'd like to write one of the following: >>>> 905 // A. OrderAccess::release() ; _owner = NULL >>>> 906 // B. OrderAccess::loadstore(); OrderAccess::storestore(); _owner = NULL; >>>> 907 // Unfortunately OrderAccess::release() and OrderAccess::loadstore() both >>>> 908 // store into a _dummy variable. That store is not needed, but can result >>>> 909 // in massive wasteful coherency traffic on classic SMP systems. >>>> 910 // Instead, I use release_store(), which is implemented as just a simple >>>> 911 // ST on x64, x86 and SPARC. >>> Consider it removed! >>> New webrev: >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-full/open/webrev/ >>> Incremental changes from webrev.01: >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-04.2-Knob_ExitRelease/open/webrev/ >>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.02/syncknobs-20.2-Knob_ExitPolicy/open/webrev/ >> >> No incremental for verifyInUse :( > > From http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034241.html: > > http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.01/syncknobs-07.2-Knob_VerifyInUse/open/webrev/ > > Cheers, > Mikael > >> >> I looked at the full webrev. All seems okay. >> >> Thanks, >> David >> >>> Cheers, >>> Mikael >>>> >>>> Thanks, >>>> David >>>> >>>> On 18/09/2018 5:03 PM, Mikael Vidstedt wrote: >>>>> Please review this change which obsoletes the SyncKnobs flag, and simplifies the code by removing the resulting unused code paths. >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210848 >>>>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-full/open/webrev/ > >>>>> * Background (from the bug) >>>>> The experimental SyncKnobs flag can in theory be used to tune the behavior of the synchronization primitives. The flag was convenient when the various algorithms were compared a long time ago. >>>>> In practice the only algorithm used and tested today are the default one. The SyncKnobs flag no longer serves the purpose it used to, and is "Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. >>>>> * About the change >>>>> As mentioned above this change not only obsolete the SyncKnobs flag, but also removes the various sub-options/knobs and prunes the resulting dead code. Of course I?m happy to hear your thoughts on that. After having asked around it seems like the knobs have not been used the last decade or so, and I like to think that the synchronization code is complex enough without what is in that case effectively dead code. >>>>> In order to make reviewing this slightly easier I have for your convenience (at least I hope it is) also created a bunch of smaller patches which stack, each removing one specific knob. Hopefully they?re more or less self-explanatory, but let me know if I can help clarify something: >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-00-base/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-01-Knob_ReportSettings/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-02-Knob_SpinBackOff/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-03-BackOffMask/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-04-Knob_ExitRelease/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-05-Knob_InlineNotify/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-06-Knob_Verbose/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-07-Knob_VerifyInUse/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-08-Knob_VerifyMatch/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-09-Knob_SpinBase/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-10-Knob_CASPenalty/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-11-Knob_OXPenalty/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-12-Knob_SpinSetSucc/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-13-Knob_SpinEarly/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-14-Knob_SuccEnabled/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-15-Knob_SuccRestrict/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-16-Knob_MaxSpinners/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-17-Knob_SpinAfterFutile/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-18-Knob_OState/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-19-Knob_UsePause/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-20-Knob_ExitPolicy/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-21-Knob_ResetEvent/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-22-Knob_FastHSSEC/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-23-Knob_MoveNotifyee/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-24-Knob_QMode/open/webrev/ >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8210848/webrev.00/syncknobs-25-Obsolete/open/webrev/ >>>>> * Testing >>>>> A slightly earlier version of this patch passed the standard tier1-3 testing. I will run additional testing after I get some feedback. >>>>> Cheers, >>>>> Mikael From roshanmangal at gmail.com Tue Sep 25 06:48:19 2018 From: roshanmangal at gmail.com (roshan mangal) Date: Tue, 25 Sep 2018 12:18:19 +0530 Subject: [PATCH] JDK-8205051 (UseNUMA memory interleaving vs cpunodebind & localalloc) Message-ID: Hi All, This Patch is for https://bugs.openjdk.java.net/browse/JDK-8205051 Issue: If the JVM isn't allowed to run on all of the nodes (by numactl, cgroups, docker, etc), then a significant fraction of the Java heap will be unusable, causing early GC. Every Thread captures their locality group(lgrp) and allocates memory from that lgrp. lgrp id is same as NUMA node id. Thread running on CPU belongs to NUMA node 0, will capture Thread->lgrp as lgrp0 and will allocate memory from NUMA node 0. Once NUMA node 0 is full, it will trigger GC irrespective of other NUMA node having memory. Solution proposed: Create List of NUMA nodes based on distance and allocate memory from near NUMA node when other closest NUMA node is/are full. Below system has eight NUMA nodes and distance table given below. node distances: node 0 1 2 3 4 5 6 7 0: 10 16 16 16 32 32 32 32 1: 16 10 16 16 32 32 32 32 2: 16 16 10 16 32 32 32 32 3: 16 16 16 10 32 32 32 32 4: 32 32 32 32 10 16 16 16 5: 32 32 32 32 16 10 16 16 6: 32 32 32 32 16 16 10 16 7: 32 32 32 32 16 16 16 10 The corresponding list for each lgrp will be like this. Thread's lgrp Order of Allocation in NUMA node lgrp0 [ numaNode0->numaNode1->numaNode2->numaNode3-> numaNode4->numaNode5->numaNode6->numaNode7 ] lgrp1 [ numaNode1->numaNode0->numaNode2->numaNode3-> numaNode4->numaNode5->numaNode6->numaNode7 ] lgrp2 [ numaNode2->numaNode0->numaNode1->numaNode3-> numaNode4->numaNode5->numaNode6->numaNode7 ] lgrp3 [ numaNode3->numaNode0->numaNode1->numaNode2-> numaNode4->numaNode5->numaNode6->numaNode7 ] lgrp4 [ numaNode4->numaNode5->numaNode6->numaNode7-> numaNode0->numaNode1->numaNode2->numaNode3 ] lgrp5 [ numaNode5->numaNode4->numaNode6->numaNode7-> numaNode0->numaNode1->numaNode2->numaNode3 ] lgrp6 [ numaNode6->numaNode4->numaNode5->numaNode7-> numaNode0->numaNode1->numaNode2->numaNode3 ] lgrp7 [ numaNode7->numaNode4->numaNode5->numaNode6-> numaNode0->numaNode1->numaNode2->numaNode3 ] Allocation on NUMA node, which is far from CPU can lead to performance issue. Sometimes triggering GC is a better option than allocating from NUMA node at large distance i.e. high memory latency. For this, I have added option "NumaAllocationDistanceLimit", which will restrict memory allocation from the far nodes. In above system if we set -XX:NumaAllocationDistanceLimit=16. The corresponding list for each lgrp will be like this. Thread's lgrp Order of Allocation in NUMA node lgrp0 [ numaNode0->numaNode1->numaNode2->numaNode3 ] lgrp1 [ numaNode1->numaNode0->numaNode2->numaNode3 ] lgrp2 [ numaNode2->numaNode0->numaNode1->numaNode3 ] lgrp3 [ numaNode3->numaNode0->numaNode1->numaNode2 ] lgrp4 [ numaNode4->numaNode5->numaNode6->numaNode7 ] lgrp5 [ numaNode5->numaNode4->numaNode6->numaNode7 ] lgrp6 [ numaNode6->numaNode4->numaNode5->numaNode7 ] lgrp7 [ numaNode7->numaNode4->numaNode5->numaNode6 ] #################################################### PATCH ################################ diff --git a/src/hotspot/os/linux/globals_linux.hpp b/src/hotspot/os/linux/ globals_linux.hpp --- a/src/hotspot/os/linux/globals_linux.hpp +++ b/src/hotspot/os/linux/globals_linux.hpp @@ -62,6 +62,9 @@ product(bool, UseContainerSupport, true, \ "Enable detection and runtime container configuration support") \ \ + product(int, NUMAAllocationDistanceLimit, INT_MAX, \ + "NUMA node distance limit for across lgrp memory allocation") \ + \ product(bool, PreferContainerQuotaForCPUCount, true, \ "Calculate the container CPU availability based on the value" \ " of quotas (if set), when true. Otherwise, use the CPU" \ diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_ linux.cpp --- a/src/hotspot/os/linux/os_linux.cpp +++ b/src/hotspot/os/linux/os_linux.cpp @@ -2939,10 +2939,13 @@ set_numa_nodes_ptr((struct bitmask **)libnuma_dlsym(handle, "numa_nodes_ptr")); // Create an index -> node mapping, since nodes are not always consecutive _nindex_to_node = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(0, true); + // Create a numaNode index array for node mapping. Each index points to link list of numaNodes + _nindex_to_numaNode = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(0, true); rebuild_nindex_to_node_map(); // Create a cpu -> node mapping _cpu_to_node = new (ResourceObj::C_HEAP, mtInternal) GrowableArray(0, true); rebuild_cpu_to_node_map(); + build_numaNode_distance_map(); return true; } } @@ -2968,6 +2971,34 @@ } } +void os::Linux::build_numaNode_distance_map() { + // Get highest numbered numa node in system + int highest_node_number = Linux::numa_max_node(); + nindex_to_numaNode()->clear(); + // In each NumaNode list add first node as self node + for (int node = 0; node <= highest_node_number; node++) { + os::Linux::numaNode* newNumaNode = NULL; + if (Linux::isnode_in_existing_nodes(node) && Linux::isnode_in_bound_nodes(node)) { + newNumaNode = new (ResourceObj::C_HEAP, mtInternal) os::Linux::numaNode(node, numa_distance(node, node)); + } + nindex_to_numaNode()->append(newNumaNode); + } + // In each list add other NumaNodes in ascending order of distance + for (int node = 0; node <= highest_node_number; node++) { + if (Linux::isnode_in_existing_nodes(node) && Linux::isnode_in_bound_nodes(node) && nindex_to_numaNode()->at(node) != NULL) { + for (int next_node = 0; next_node <= highest_node_number; next_node++) { + if (node != next_node && Linux::isnode_in_existing_nodes(next_node) && Linux::isnode_in_bound_nodes(next_node)) { + int distance = numa_distance(node, next_node); + // Insert next_node in list corresponing to node if distance is within NUMAAllocationDistanceLimit + if (distance <= NUMAAllocationDistanceLimit) { + os::Linux::numaNode::insert_node(&nindex_to_numaNode()->at(node), next_node, distance); + } + } + } + } + } +} + // rebuild_cpu_to_node_map() constructs a table mapping cpud id to node id. // The table is later used in get_node_by_cpu(). void os::Linux::rebuild_cpu_to_node_map() { @@ -3051,6 +3082,7 @@ GrowableArray* os::Linux::_cpu_to_node; GrowableArray* os::Linux::_nindex_to_node; +GrowableArray* os::Linux::_nindex_to_numaNode; os::Linux::sched_getcpu_func_t os::Linux::_sched_getcpu; os::Linux::numa_node_to_cpus_func_t os::Linux::_numa_node_to_cpus; os::Linux::numa_max_node_func_t os::Linux::_numa_max_node; diff --git a/src/hotspot/os/linux/os_linux.hpp b/src/hotspot/os/linux/os_ linux.hpp --- a/src/hotspot/os/linux/os_linux.hpp +++ b/src/hotspot/os/linux/os_linux.hpp @@ -66,7 +66,46 @@ // BB, Minor Version // CC, Fix Version static uint32_t _os_version; + public: + + // Class numaNode has NUMA node number and distance field, to create list of nodes + // w.r.t one numaNode in ascending order of numa distance + class numaNode : public ResourceObj { + public: + int nodeId; + int nodeDistance; + numaNode* next; + numaNode() { + nodeId = -1; + nodeDistance = INT_MAX; + next = NULL; + } + numaNode(int newNodeId, int newNodeDistance) { + nodeId = newNodeId; + nodeDistance = newNodeDistance; + next = NULL; + } + // Insert node in list with head_ref and ascending order of numa distances. + static void insert_node(numaNode** head_ref, int newNodeId, int newNodeDistance) { + // Create node with newNodeId and newNodeDistance + numaNode* new_node = new (ResourceObj::C_HEAP, mtInternal) numaNode(newNodeId, newNodeDistance); + // List is empty, make new_node as first node + if (*head_ref == NULL || (*head_ref)->nodeDistance > newNodeDistance) { + new_node->next = *head_ref; + *head_ref = new_node; + } else { + numaNode* itr = *head_ref; + // Insert new_node in ascending order of nodeDistance in List + while (itr->next != NULL && itr->next->nodeDistance <= newNodeDistance) { + itr = itr->next; + } + new_node->next = itr->next; + itr->next = new_node; + } + } + }; + static GrowableArray* _nindex_to_numaNode; protected: static julong _physical_memory; @@ -90,6 +129,7 @@ static void rebuild_cpu_to_node_map(); static void rebuild_nindex_to_node_map(); + static void build_numaNode_distance_map(); static GrowableArray* cpu_to_node() { return _cpu_to_node; } static GrowableArray* nindex_to_node() { return _nindex_to_node; } @@ -120,6 +160,7 @@ static void *dlopen_helper(const char *name, char *ebuf, int ebuflen); static void *dll_load_in_vmthread(const char *name, char *ebuf, int ebuflen); + static GrowableArray* nindex_to_numaNode() { return _nindex_to_numaNode; } static void init_thread_fpu_state(); static int get_fpu_control_word(); static void set_fpu_control_word(int fpu_control); diff --git a/src/hotspot/share/gc/parallel/mutableNUMASpace.cpp b/src/hotspot/share/gc/parallel/mutableNUMASpace.cpp --- a/src/hotspot/share/gc/parallel/mutableNUMASpace.cpp +++ b/src/hotspot/share/gc/parallel/mutableNUMASpace.cpp @@ -795,36 +795,55 @@ thr->set_lgrp_id(lgrp_id); } - int i = lgrp_spaces()->find(&lgrp_id, LGRPSpace::equals); + // Get the nearest list of nodes for lgrp_id which are sorted based on NUMA distance + os::Linux::numaNode* itr_numaNode = os::Linux::nindex_to_numaNode( )->at(lgrp_id); - // It is possible that a new CPU has been hotplugged and - // we haven't reshaped the space accordingly. - if (i == -1) { - i = os::random() % lgrp_spaces()->length(); - } + LGRPSpace* ls = NULL; + MutableSpace* s = NULL; + HeapWord* p = NULL; + // Try in each lgrp in list till get memory + while (itr_numaNode != NULL) { + // numaNode id is same as lgrp_id + int nearest_avaliable_lg = itr_numaNode->nodeId; + int i = lgrp_spaces()->find(&nearest_avaliable_lg, LGRPSpace::equals); + // It is possible that a new CPU has been hotplugged and + // we haven't reshaped the space accordingly. + if (i == -1) { + i = os::random() % lgrp_spaces()->length(); + } + ls = lgrp_spaces()->at(i); + s = ls->space(); + p = s->allocate(size); - LGRPSpace* ls = lgrp_spaces()->at(i); - MutableSpace *s = ls->space(); - HeapWord *p = s->allocate(size); - - if (p != NULL) { - size_t remainder = s->free_in_words(); - if (remainder < CollectedHeap::min_fill_size() && remainder > 0) { - s->set_top(s->top() - size); - p = NULL; + if (p != NULL) { + size_t remainder = s->free_in_words(); + if (remainder < CollectedHeap::min_fill_size() && remainder > 0) { + s->set_top(s->top() - size); + p = NULL; + } } - } - if (p != NULL) { - if (top() < s->top()) { // Keep _top updated. - MutableSpace::set_top(s->top()); + if (p != NULL) { + if (top() < s->top()) { // Keep _top updated. + MutableSpace::set_top(s->top()); + } } - } - // Make the page allocation happen here if there is no static binding.. - if (p != NULL && !os::numa_has_static_binding()) { - for (HeapWord *i = p; i < p + size; i += os::vm_page_size() >> LogHeapWordSize) { - *(int*)i = 0; + // Make the page allocation happen here if there is no static binding.. + if (p != NULL && !os::numa_has_static_binding()) { + for (HeapWord* j = p; j < p + size; j += os::vm_page_size() >> LogHeapWordSize) { + *(int*)j = 0; + } } - } + // If p is NULL , Move to next nearest numaNode for allocation from numaNode list + if (p == NULL) { + ls->set_allocation_failed(); + itr_numaNode = itr_numaNode->next; + if (itr_numaNode != NULL) { + thr->set_lgrp_id(itr_numaNode->nodeId); + } + } else { + return p; + } + } // End of while if (p == NULL) { ls->set_allocation_failed(); } @@ -839,43 +858,62 @@ lgrp_id = os::numa_get_group_id(); thr->set_lgrp_id(lgrp_id); } + // Get the nearest list of nodes for lgrp_id which are sorted based on NUMA distance + os::Linux::numaNode* itr_numaNode = os::Linux::nindex_to_numaNode( )->at(lgrp_id); - int i = lgrp_spaces()->find(&lgrp_id, LGRPSpace::equals); - // It is possible that a new CPU has been hotplugged and - // we haven't reshaped the space accordingly. - if (i == -1) { - i = os::random() % lgrp_spaces()->length(); - } - LGRPSpace *ls = lgrp_spaces()->at(i); - MutableSpace *s = ls->space(); - HeapWord *p = s->cas_allocate(size); - if (p != NULL) { - size_t remainder = pointer_delta(s->end(), p + size); - if (remainder < CollectedHeap::min_fill_size() && remainder > 0) { - if (s->cas_deallocate(p, size)) { - // We were the last to allocate and created a fragment less than - // a minimal object. - p = NULL; - } else { - guarantee(false, "Deallocation should always succeed"); + LGRPSpace* ls = NULL; + MutableSpace* s = NULL; + HeapWord* p = NULL; + + while (itr_numaNode != NULL) { + // numaNode id is same as lgrp_id + int nearest_avaliable_lg = itr_numaNode->nodeId; + int i = lgrp_spaces()->find(&nearest_avaliable_lg, LGRPSpace::equals); + // It is possible that a new CPU has been hotplugged and + // we haven't reshaped the space accordingly. + if (i == -1) { + i = os::random() % lgrp_spaces()->length(); + } + ls = lgrp_spaces()->at(i); + s = ls->space(); + p = s->cas_allocate(size); + if (p != NULL) { + size_t remainder = pointer_delta(s->end(), p + size); + if (remainder < CollectedHeap::min_fill_size() && remainder > 0) { + if (s->cas_deallocate(p, size)) { + // We were the last to allocate and created a fragment less than + // a minimal object. + p = NULL; + } else { + guarantee(false, "Deallocation should always succeed"); + } } } - } - if (p != NULL) { - HeapWord* cur_top, *cur_chunk_top = p + size; - while ((cur_top = top()) < cur_chunk_top) { // Keep _top updated. - if (Atomic::cmpxchg(cur_chunk_top, top_addr(), cur_top) == cur_top) { - break; + if (p != NULL) { + HeapWord* cur_top, *cur_chunk_top = p + size; + while ((cur_top = top()) < cur_chunk_top) { // Keep _top updated. + if (Atomic::cmpxchg(cur_chunk_top, top_addr(), cur_top) == cur_top) { + break; + } } } - } - - // Make the page allocation happen here if there is no static binding. - if (p != NULL && !os::numa_has_static_binding() ) { - for (HeapWord *i = p; i < p + size; i += os::vm_page_size() >> LogHeapWordSize) { - *(int*)i = 0; + // Make the page allocation happen here if there is no static binding. + if (p != NULL && !os::numa_has_static_binding() ) { + for (HeapWord *j = p; j < p + size; j += os::vm_page_size() >> LogHeapWordSize) { + *(int*)j = 0; + } } - } + // If p is NULL , Move to next nearest numaNode for allocation from numaNode list + if (p == NULL) { + ls->set_allocation_failed(); + itr_numaNode = itr_numaNode->next; + if (itr_numaNode != NULL) { + thr->set_lgrp_id(itr_numaNode->nodeId); + } + } else { + return p; + } + } // End of while if (p == NULL) { ls->set_allocation_failed(); } ################################# PATCH END ############################## ################## CMD1 and CMD2 are tests mentioned in bug. CMD1> numactl -N 0 java -Xlog:gc*=info -XX:+UseParallelGC -XX:+UseNUMA -version ... [0.212s][info][gc,heap,exit ] PSYoungGen total 611840K, used 13129K [0x0000000580100000, 0x00000005aab80000, 0x0000000800000000) [0.212s][info][gc,heap,exit ] eden space 524800K, 2% used [0x0000000580100000,0x0000000580dd2700,0x00000005a0180000) [0.212s][info][gc,heap,exit ] lgrp 0 space 65600K, 20% used [0x0000000580100000,0x0000000580dd2700,0x0000000584110000) [0.212s][info][gc,heap,exit ] lgrp 1 space 65600K, 0% used [0x0000000584110000,0x0000000584110000,0x0000000588120000) [0.212s][info][gc,heap,exit ] lgrp 2 space 65600K, 0% used [0x0000000588120000,0x0000000588120000,0x000000058c130000) [0.212s][info][gc,heap,exit ] lgrp 3 space 65600K, 0% used [0x000000058c130000,0x000000058c130000,0x0000000590140000) [0.212s][info][gc,heap,exit ] lgrp 4 space 65600K, 0% used [0x0000000590140000,0x0000000590140000,0x0000000594150000) [0.212s][info][gc,heap,exit ] lgrp 5 space 65600K, 0% used [0x0000000594150000,0x0000000594150000,0x0000000598160000) [0.212s][info][gc,heap,exit ] lgrp 6 space 65600K, 0% used [0x0000000598160000,0x0000000598160000,0x000000059c170000) [0.212s][info][gc,heap,exit ] lgrp 7 space 65600K, 0% used [0x000000059c170000,0x000000059c170000,0x00000005a0180000) ... CMD2 > numactl -N 0 --localalloc java -Xlog:gc*=info -XX:+UseParallelGC -XX:+UseNUMA -version ... [0.221s][info][gc,heap,exit ] PSYoungGen total 611840K, used 13129K [0x0000000580100000, 0x00000005aab80000, 0x0000000800000000) [0.221s][info][gc,heap,exit ] eden space 524800K, 2% used [0x0000000580100000,0x0000000580dd26f8,0x00000005a0180000) [0.221s][info][gc,heap,exit ] lgrp 0 space 65600K, 20% used [0x0000000580100000,0x0000000580dd26f8,0x0000000584110000) [0.221s][info][gc,heap,exit ] lgrp 1 space 65600K, 0% used [0x0000000584110000,0x0000000584110000,0x0000000588120000) [0.221s][info][gc,heap,exit ] lgrp 2 space 65600K, 0% used [0x0000000588120000,0x0000000588120000,0x000000058c130000) [0.221s][info][gc,heap,exit ] lgrp 3 space 65600K, 0% used [0x000000058c130000,0x000000058c130000,0x0000000590140000) [0.221s][info][gc,heap,exit ] lgrp 4 space 65600K, 0% used [0x0000000590140000,0x0000000590140000,0x0000000594150000) [0.221s][info][gc,heap,exit ] lgrp 5 space 65600K, 0% used [0x0000000594150000,0x0000000594150000,0x0000000598160000) [0.221s][info][gc,heap,exit ] lgrp 6 space 65600K, 0% used [0x0000000598160000,0x0000000598160000,0x000000059c170000) [0.221s][info][gc,heap,exit ] lgrp 7 space 65600K, 0% used [0x000000059c170000,0x000000059c170000,0x00000005a0180000) ... Note: -- localalloc is default configuration in numactl, Hence there is no difference in CMD1 and CMD2. If the "local node" is low on free memory, the kernel will try to allocate memory from other nodes. There is documentation issue in numactl man page. I have filed bug for that https://bugzilla.kernel.org/show_bug.cgi?id=200777 CMD3( with Fix)>numactl -N 0 java -Xlog:gc*=info -XX:+UseParallelGC -XX:+UseNUMA GCBench ... [0.465s][info][gc,heap,exit ] Heap [0.465s][info][gc,heap,exit ] PSYoungGen total 611840K, used 498561K [0x0000000580100000, 0x00000005aab80000, 0x0000000800000000) [0.465s][info][gc,heap,exit ] eden space 524800K, 95% used [0x0000000580100000,0x000000059e7e0550,0x00000005a0180000) [0.465s][info][gc,heap,exit ] lgrp 0 space 65600K, 100% used [0x0000000580100000,0x0000000584110000,0x0000000584110000) [0.465s][info][gc,heap,exit ] lgrp 1 space 65600K, 100% used [0x0000000584110000,0x0000000588120000,0x0000000588120000) [0.465s][info][gc,heap,exit ] lgrp 2 space 65600K, 100% used [0x0000000588120000,0x000000058c130000,0x000000058c130000) [0.465s][info][gc,heap,exit ] lgrp 3 space 65600K, 100% used [0x000000058c130000,0x0000000590140000,0x0000000590140000) [0.465s][info][gc,heap,exit ] lgrp 4 space 65600K, 100% used [0x0000000590140000,0x0000000594150000,0x0000000594150000) [0.465s][info][gc,heap,exit ] lgrp 5 space 65600K, 100% used [0x0000000594150000,0x0000000598160000,0x0000000598160000) [0.465s][info][gc,heap,exit ] lgrp 6 space 65600K, 100% used [0x0000000598160000,0x000000059c170000,0x000000059c170000) [0.465s][info][gc,heap,exit ] lgrp 7 space 65600K, 60% used [0x000000059c170000,0x000000059e7e0550,0x00000005a0180000) ... After fix , allocation happens from all lgrps. CMD4(Without Fix)> numactl -N 0 java -Xlog:gc*=info -XX:+UseParallelGC -XX:+UseNUMA GCBench ... [0.991s][info][gc,heap,exit ] Heap [0.991s][info][gc,heap,exit ] PSYoungGen total 2186240K, used 120371K [0x0000000580100000, 0x000000060ad00000, 0x0000000800000000) [0.991s][info][gc,heap,exit ] eden space 2099200K, 5% used [0x0000000580100000,0x0000000586d70358,0x0000000600300000) [0.991s][info][gc,heap,exit ] lgrp 0 space 262400K, 42% used [0x0000000580100000,0x0000000586d70358,0x0000000590140000) [0.991s][info][gc,heap,exit ] lgrp 1 space 262400K, 0% used [0x0000000590140000,0x0000000590140000,0x00000005a0180000) [0.991s][info][gc,heap,exit ] lgrp 2 space 262400K, 0% used [0x00000005a0180000,0x00000005a0180000,0x00000005b01c0000) [0.991s][info][gc,heap,exit ] lgrp 3 space 262400K, 0% used [0x00000005b01c0000,0x00000005b01c0000,0x00000005c0200000) [0.991s][info][gc,heap,exit ] lgrp 4 space 262400K, 0% used [0x00000005c0200000,0x00000005c0200000,0x00000005d0240000) [0.991s][info][gc,heap,exit ] lgrp 5 space 262400K, 0% used [0x00000005d0240000,0x00000005d0240000,0x00000005e0280000) [0.991s][info][gc,heap,exit ] lgrp 6 space 262400K, 0% used [0x00000005e0280000,0x00000005e0280000,0x00000005f02c0000) [0.991s][info][gc,heap,exit ] lgrp 7 space 262400K, 0% used [0x00000005f02c0000,0x00000005f02c0000,0x0000000600300000) ... Without fix, allocation only in lgrp0. I did run ?make run-test TEST="tier1 tier2" JTREG="JOBS=1"?. No new regression failure after fix. Thanks, Roshan Mangal From matthias.baesken at sap.com Tue Sep 25 07:14:21 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 25 Sep 2018 07:14:21 +0000 Subject: RFR [XS] 8210964: add more ld preloading info to hs_error file on Linux In-Reply-To: References: Message-ID: Thanks, can I have a second review please ? (maybe with opinions what people like better, http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.0/ or http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.1/ ) Best regards, Matthias > -----Original Message----- > From: Thomas St?fe > Sent: Montag, 24. September 2018 16:45 > To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net > Subject: Re: RFR [XS] 8210964: add more ld preloading info to hs_error file on > Linux > > Hi Matthias, > > Hm. I see now that my request to not print the header line of > ld.preload made the patch more complicated than necessary. Sorry for > that. > > If you like, you can revert to the previous version, I would just ask > you to change the error message to a more generic sentence, e.g.: > > void os::Linux::print_system_config_info(outputStream* st) { > st->cr(); > st->print_cr("/etc/ld.so.preload (system-wide LD_PRELOAD config file):"); > bool success = _print_ascii_file("/etc/ld.so.preload", st); > if (!success) { st->print("not available"); } > st->cr(); > st->cr(); > } > > I am fine with both versions. I leave it up to you if you ship the > second variant of the first one (with the changed error message). > > I do not need another webrev. > > Thanks, Thomas > > > > On Mon, Sep 24, 2018 at 3:14 PM, Baesken, Matthias > wrote: > > Hi Thomas, thanks for your input ! > > > > I followed your suggestions : > > - renamed the function to os::Linux::print_ld_preload_file > > - output the header only in case the file is opened > > - changed (shortened) the header > > > >> > Also, I personally would not expose it via os_linux.hpp. > > > > However I kept it there, to keep it in line with the other info-functions. > > > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.1/ > > > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: Thomas St?fe > >> Sent: Freitag, 21. September 2018 18:59 > >> To: Baesken, Matthias > >> Cc: hotspot-dev at openjdk.java.net > >> Subject: Re: RFR [XS] 8210964: add more ld preloading info to hs_error file > on > >> Linux > >> > >> On Fri, Sep 21, 2018 at 6:47 PM, Thomas St?fe > > >> wrote: > >> > Hi Matthias, > >> > > >> > in the posted patch the new function is never called, or am I mistaken? > >> > > >> > >> Scratch that, I was being blind. > >> > >> What I do not like is the very generic name of the function. It does > >> one very specific thing, so could we name it accordingly, e.g. > >> "os::Linux::print_system_config_info" -> > >> "os::Linux::print_ld_preload_file"? > >> > >> Also, I personally would not expose it via os_linux.hpp. I would just > >> put it as a file scope static function into os_linux.cpp. I see you > >> follow the example of others here (os::Linux::print_proc_sys_info etc) > >> but there too I feel this is a bad pattern and those functions do not > >> belong into an external header. > >> > >> 2140 st->print_cr("/etc/ld.so.preload (system-wide LD_PRELOAD config > >> file):"); > >> > >> I would shorten that to just "ld.so.preload:" or "/etc/ld.so.preload". > >> Everyone looking at that section knows what that file does. I also > >> would omit that header completely if the file cannot be opened. > >> > >> 2141 bool file_present = _print_ascii_file("/etc/ld.so.preload", st); > >> 2142 if (!file_present) { st->print("file not present"); } > >> 2143 st->cr(); > >> > >> You do not know that the file is not preset, all you know is that the > >> open() call in _print_ascii_file() failed. Since existence of this > >> file is optional, and not typical, I would just omit messages if it > >> cannot be found. > >> > >> Best Regards, Thomas > >> > > From rkennke at redhat.com Tue Sep 25 07:19:06 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 25 Sep 2018 09:19:06 +0200 Subject: RFR: JDK-8211061: Tests fail with assert(VM_Version::supports_sse4_1()) on ThreadRipper CPU In-Reply-To: <8470d1f1-e878-7a01-ca1b-bacbb0b845e6@redhat.com> References: <8470d1f1-e878-7a01-ca1b-bacbb0b845e6@redhat.com> Message-ID: Involving hotspot-compiler-dev... > Some tests fail with: > > # Internal Error > (/home/rkennke/src/openjdk/jdk-jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3819), > pid=5051, tid=5055 > # Error: assert(VM_Version::supports_sse4_1()) failed > > When running hotspot/jtreg:tier1 on my ThreadRipper 1950X box. On my > Intel box, this works fine. It looks like it attempts to generate > fast_sha1 stubs, which use Assembler::pinsrd() but then runs into > supports_sse4_1(). > > The failing tier1 tests are: > compiler/c1/Test6579789.java > compiler/c1/Test6855215.java > compiler/cpuflags/TestSSE4Disabled.java > > The failing tests seem to disable SSE4 or SSE altogether and check if it > still compiles fine. This does not go well for the SHA1 and SHA256 stubs > because they use SSE4.1 instructions. It seems that it compiles on my > Intel box because that doesn't support_sha(), and thus disables those > intrinsics altogether. > > The proposed fix is to check for SSE4.1 present before enabling the > affected intrinsics. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211061 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8211061/webrev.00/ > > Testing: hotspot/jtreg:tier1 failed before, now passes > > Thanks, > Roman > From tobias.hartmann at oracle.com Tue Sep 25 07:42:05 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 25 Sep 2018 09:42:05 +0200 Subject: RFR: JDK-8211061: Tests fail with assert(VM_Version::supports_sse4_1()) on ThreadRipper CPU In-Reply-To: References: <8470d1f1-e878-7a01-ca1b-bacbb0b845e6@redhat.com> Message-ID: <5b44471e-0d24-4d65-71d5-0ccf589cc4e6@oracle.com> Hi Roman, this looks good to me. Best regards, Tobias On 25.09.2018 09:19, Roman Kennke wrote: > Involving hotspot-compiler-dev... > >> Some tests fail with: >> >> # Internal Error >> (/home/rkennke/src/openjdk/jdk-jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3819), >> pid=5051, tid=5055 >> # Error: assert(VM_Version::supports_sse4_1()) failed >> >> When running hotspot/jtreg:tier1 on my ThreadRipper 1950X box. On my >> Intel box, this works fine. It looks like it attempts to generate >> fast_sha1 stubs, which use Assembler::pinsrd() but then runs into >> supports_sse4_1(). >> >> The failing tier1 tests are: >> compiler/c1/Test6579789.java >> compiler/c1/Test6855215.java >> compiler/cpuflags/TestSSE4Disabled.java >> >> The failing tests seem to disable SSE4 or SSE altogether and check if it >> still compiles fine. This does not go well for the SHA1 and SHA256 stubs >> because they use SSE4.1 instructions. It seems that it compiles on my >> Intel box because that doesn't support_sha(), and thus disables those >> intrinsics altogether. >> >> The proposed fix is to check for SSE4.1 present before enabling the >> affected intrinsics. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8211061 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8211061/webrev.00/ >> >> Testing: hotspot/jtreg:tier1 failed before, now passes >> >> Thanks, >> Roman >> > > From rkennke at redhat.com Tue Sep 25 08:23:05 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 25 Sep 2018 10:23:05 +0200 Subject: RFR: JDK-8211061: Tests fail with assert(VM_Version::supports_sse4_1()) on ThreadRipper CPU In-Reply-To: <5b44471e-0d24-4d65-71d5-0ccf589cc4e6@oracle.com> References: <8470d1f1-e878-7a01-ca1b-bacbb0b845e6@redhat.com> <5b44471e-0d24-4d65-71d5-0ccf589cc4e6@oracle.com> Message-ID: <4554cf90-c0dd-baa4-ba41-e3f46b2c8871@redhat.com> Thanks for reviewing, Tobias! Roman > Hi Roman, > > this looks good to me. > > Best regards, > Tobias > > On 25.09.2018 09:19, Roman Kennke wrote: >> Involving hotspot-compiler-dev... >> >>> Some tests fail with: >>> >>> # Internal Error >>> (/home/rkennke/src/openjdk/jdk-jdk/src/hotspot/cpu/x86/assembler_x86.cpp:3819), >>> pid=5051, tid=5055 >>> # Error: assert(VM_Version::supports_sse4_1()) failed >>> >>> When running hotspot/jtreg:tier1 on my ThreadRipper 1950X box. On my >>> Intel box, this works fine. It looks like it attempts to generate >>> fast_sha1 stubs, which use Assembler::pinsrd() but then runs into >>> supports_sse4_1(). >>> >>> The failing tier1 tests are: >>> compiler/c1/Test6579789.java >>> compiler/c1/Test6855215.java >>> compiler/cpuflags/TestSSE4Disabled.java >>> >>> The failing tests seem to disable SSE4 or SSE altogether and check if it >>> still compiles fine. This does not go well for the SHA1 and SHA256 stubs >>> because they use SSE4.1 instructions. It seems that it compiles on my >>> Intel box because that doesn't support_sha(), and thus disables those >>> intrinsics altogether. >>> >>> The proposed fix is to check for SSE4.1 present before enabling the >>> affected intrinsics. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8211061 >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8211061/webrev.00/ >>> >>> Testing: hotspot/jtreg:tier1 failed before, now passes >>> >>> Thanks, >>> Roman >>> >> >> From rwestrel at redhat.com Tue Sep 25 08:32:49 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 25 Sep 2018 10:32:49 +0200 Subject: RFR: JDK-8211061: Tests fail with assert(VM_Version::supports_sse4_1()) on ThreadRipper CPU In-Reply-To: <8470d1f1-e878-7a01-ca1b-bacbb0b845e6@redhat.com> References: <8470d1f1-e878-7a01-ca1b-bacbb0b845e6@redhat.com> Message-ID: > http://cr.openjdk.java.net/~rkennke/JDK-8211061/webrev.00/ Looks reasonable to me. Roland. From Pengfei.Li at arm.com Tue Sep 25 08:38:07 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Tue, 25 Sep 2018 08:38:07 +0000 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: References: <91d1bf82-eb60-c0a1-449d-8bb9246ddedd@oracle.com> Message-ID: Hi Vladimir, I still didn't get other comments during the past week. Do you think it is ok to push this patch? http://cr.openjdk.java.net/~njian/8210152/webrev.01/ -- Thanks, Pengfei > -----Original Message----- > > Hi Reviewers, > > Is there any other comments, objections or suggestions on the new webrev? > If no problems, could anyone help to push this commit? > > I look forward to your response. > > -- > Thanks, > Pengfei > > > -----Original Message----- > > > > Looks good. > > > > Thanks, > > Vladimir > > > > On 9/12/18 2:50 AM, Pengfei Li (Arm Technology China) wrote: > > > Hi, > > > > > > I've updated the patch based on Vladimir's comment. I added checks > > > for > > SubI on both branches of the diamond phi. > > > Also thanks Roland for the suggestion that supporting a Phi with 3 > > > or more > > inputs. But I think the matching rule will be much more complex if we > > add this. And I'm not sure if there are any real case scenario which > > can benefit from this support. So I didn't add it in. > > > > > > New webrev: http://cr.openjdk.java.net/~njian/8210152/webrev.01/ > > > I've run jtreg full test with the new patch and no new issues found. > > > > > > Please let me know if you have other comments or suggestions. If no > > further issues, I need your help to sponsor and push the patch. > > > > > > -- > > > Thanks, > > > Pengfei > > > > > > From tobias.hartmann at oracle.com Tue Sep 25 09:38:02 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 25 Sep 2018 11:38:02 +0200 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: References: <91d1bf82-eb60-c0a1-449d-8bb9246ddedd@oracle.com> Message-ID: <8a5aba14-5feb-e6ca-953b-a91d12e4b5bc@oracle.com> Hi Pengfei, this looks good to me but please fix the whitespacing before pushing: "if( a == b )" -> "if (a == b)" "method( param )" -> "method(param)" It's not consistently like that in old HotSpot code but we should at least fix it in new code. Thanks, Tobias On 25.09.2018 10:38, Pengfei Li (Arm Technology China) wrote: > Hi Vladimir, > > I still didn't get other comments during the past week. > Do you think it is ok to push this patch? > http://cr.openjdk.java.net/~njian/8210152/webrev.01/ > > -- > Thanks, > Pengfei > >> -----Original Message----- >> >> Hi Reviewers, >> >> Is there any other comments, objections or suggestions on the new webrev? >> If no problems, could anyone help to push this commit? >> >> I look forward to your response. >> >> -- >> Thanks, >> Pengfei >> >>> -----Original Message----- >>> >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 9/12/18 2:50 AM, Pengfei Li (Arm Technology China) wrote: >>>> Hi, >>>> >>>> I've updated the patch based on Vladimir's comment. I added checks >>>> for >>> SubI on both branches of the diamond phi. >>>> Also thanks Roland for the suggestion that supporting a Phi with 3 >>>> or more >>> inputs. But I think the matching rule will be much more complex if we >>> add this. And I'm not sure if there are any real case scenario which >>> can benefit from this support. So I didn't add it in. >>>> >>>> New webrev: http://cr.openjdk.java.net/~njian/8210152/webrev.01/ >>>> I've run jtreg full test with the new patch and no new issues found. >>>> >>>> Please let me know if you have other comments or suggestions. If no >>> further issues, I need your help to sponsor and push the patch. >>>> >>>> -- >>>> Thanks, >>>> Pengfei >>>> >>>> From Pengfei.Li at arm.com Tue Sep 25 10:13:56 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Tue, 25 Sep 2018 10:13:56 +0000 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: <8a5aba14-5feb-e6ca-953b-a91d12e4b5bc@oracle.com> References: <91d1bf82-eb60-c0a1-449d-8bb9246ddedd@oracle.com> <8a5aba14-5feb-e6ca-953b-a91d12e4b5bc@oracle.com> Message-ID: Hi Tobias, Thanks for your review comment. I've fixed the whitespaces and below is a new webrev. http://cr.openjdk.java.net/~njian/8210152/webrev.02/ Could you help push this patch since I don't have permissions to do that? -- Thanks, Pengfei > -----Original Message----- > > Hi Pengfei, > > this looks good to me but please fix the whitespacing before pushing: > "if( a == b )" -> "if (a == b)" > "method( param )" -> "method(param)" > > It's not consistently like that in old HotSpot code but we should at least fix it > in new code. > > Thanks, > Tobias > > On 25.09.2018 10:38, Pengfei Li (Arm Technology China) wrote: > > Hi Vladimir, > > > > I still didn't get other comments during the past week. > > Do you think it is ok to push this patch? > > http://cr.openjdk.java.net/~njian/8210152/webrev.01/ > > > > -- > > Thanks, > > Pengfei > > > >> -----Original Message----- > >> > >> Hi Reviewers, > >> > >> Is there any other comments, objections or suggestions on the new > webrev? > >> If no problems, could anyone help to push this commit? > >> > >> I look forward to your response. > >> > >> -- > >> Thanks, > >> Pengfei > >> > >>> -----Original Message----- > >>> > >>> Looks good. > >>> > >>> Thanks, > >>> Vladimir > >>> > >>> On 9/12/18 2:50 AM, Pengfei Li (Arm Technology China) wrote: > >>>> Hi, > >>>> > >>>> I've updated the patch based on Vladimir's comment. I added checks > >>>> for > >>> SubI on both branches of the diamond phi. > >>>> Also thanks Roland for the suggestion that supporting a Phi with 3 > >>>> or more > >>> inputs. But I think the matching rule will be much more complex if > >>> we add this. And I'm not sure if there are any real case scenario > >>> which can benefit from this support. So I didn't add it in. > >>>> > >>>> New webrev: http://cr.openjdk.java.net/~njian/8210152/webrev.01/ > >>>> I've run jtreg full test with the new patch and no new issues found. > >>>> > >>>> Please let me know if you have other comments or suggestions. If no > >>> further issues, I need your help to sponsor and push the patch. > >>>> > >>>> -- > >>>> Thanks, > >>>> Pengfei > >>>> > >>>> From tobias.hartmann at oracle.com Tue Sep 25 12:22:25 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 25 Sep 2018 14:22:25 +0200 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: References: <91d1bf82-eb60-c0a1-449d-8bb9246ddedd@oracle.com> <8a5aba14-5feb-e6ca-953b-a91d12e4b5bc@oracle.com> Message-ID: <54cd88be-ed94-9ffa-0862-f803496577fc@oracle.com> Hi Pengfei, sure, pushed: http://hg.openjdk.java.net/jdk/jdk/rev/bc38c75eed57 Best regards, Tobias On 25.09.2018 12:13, Pengfei Li (Arm Technology China) wrote: > Hi Tobias, > > Thanks for your review comment. I've fixed the whitespaces and below is a new webrev. > http://cr.openjdk.java.net/~njian/8210152/webrev.02/ > > Could you help push this patch since I don't have permissions to do that? > > -- > Thanks, > Pengfei > > >> -----Original Message----- >> >> Hi Pengfei, >> >> this looks good to me but please fix the whitespacing before pushing: >> "if( a == b )" -> "if (a == b)" >> "method( param )" -> "method(param)" >> >> It's not consistently like that in old HotSpot code but we should at least fix it >> in new code. >> >> Thanks, >> Tobias >> >> On 25.09.2018 10:38, Pengfei Li (Arm Technology China) wrote: >>> Hi Vladimir, >>> >>> I still didn't get other comments during the past week. >>> Do you think it is ok to push this patch? >>> http://cr.openjdk.java.net/~njian/8210152/webrev.01/ >>> >>> -- >>> Thanks, >>> Pengfei >>> >>>> -----Original Message----- >>>> >>>> Hi Reviewers, >>>> >>>> Is there any other comments, objections or suggestions on the new >> webrev? >>>> If no problems, could anyone help to push this commit? >>>> >>>> I look forward to your response. >>>> >>>> -- >>>> Thanks, >>>> Pengfei >>>> >>>>> -----Original Message----- >>>>> >>>>> Looks good. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/12/18 2:50 AM, Pengfei Li (Arm Technology China) wrote: >>>>>> Hi, >>>>>> >>>>>> I've updated the patch based on Vladimir's comment. I added checks >>>>>> for >>>>> SubI on both branches of the diamond phi. >>>>>> Also thanks Roland for the suggestion that supporting a Phi with 3 >>>>>> or more >>>>> inputs. But I think the matching rule will be much more complex if >>>>> we add this. And I'm not sure if there are any real case scenario >>>>> which can benefit from this support. So I didn't add it in. >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~njian/8210152/webrev.01/ >>>>>> I've run jtreg full test with the new patch and no new issues found. >>>>>> >>>>>> Please let me know if you have other comments or suggestions. If no >>>>> further issues, I need your help to sponsor and push the patch. >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Pengfei >>>>>> >>>>>> From matthias.baesken at sap.com Tue Sep 25 13:52:40 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 25 Sep 2018 13:52:40 +0000 Subject: RFR : 8211089: windows : print process heaps information in hs_err file Message-ID: Hello , please review this small change. It adds output of information regarding Windows process heaps (see https://docs.microsoft.com/en-us/windows/desktop/api/heapapi/nf-heapapi-getprocessheaps ) to the hs_error file. we had this for some time in our internal JVM and want to bring it to OpenJDK as well. It is a Windows-only extension. bug : 8211089: windows : print process heaps information in hs_err file https://bugs.openjdk.java.net/browse/JDK-8211089 webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8211089.0/ extended output is usually small, and looks like this : --------------- S Y S T E M --------------- OS: Windows 10 , 64 bit Build ...... .... 4 Process Heaps: Heap ID: 1 0x00000186491a0000 default crt low-fragmentation Heap ID: 2 0x0000018649000000 standard Heap ID: 3 0x0000018649430000 low-fragmentation Heap ID: 4 0x000001864adb0000 low-fragmentation Thanks, Matthias From Pengfei.Li at arm.com Tue Sep 25 13:54:06 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Tue, 25 Sep 2018 13:54:06 +0000 Subject: [PING] RE: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: <54cd88be-ed94-9ffa-0862-f803496577fc@oracle.com> References: <91d1bf82-eb60-c0a1-449d-8bb9246ddedd@oracle.com> <8a5aba14-5feb-e6ca-953b-a91d12e4b5bc@oracle.com> , <54cd88be-ed94-9ffa-0862-f803496577fc@oracle.com> Message-ID: Thanks Tobias. Hi Pengfei, sure, pushed: http://hg.openjdk.java.net/jdk/jdk/rev/bc38c75eed57 Best regards, Tobias On 25.09.2018 12:13, Pengfei Li (Arm Technology China) wrote: > Hi Tobias, > > Thanks for your review comment. I've fixed the whitespaces and below is a new webrev. > http://cr.openjdk.java.net/~njian/8210152/webrev.02/ > > Could you help push this patch since I don't have permissions to do that? > > -- > Thanks, > Pengfei > > >> -----Original Message----- >> >> Hi Pengfei, >> >> this looks good to me but please fix the whitespacing before pushing: >> "if( a == b )" -> "if (a == b)" >> "method( param )" -> "method(param)" >> >> It's not consistently like that in old HotSpot code but we should at least fix it >> in new code. >> >> Thanks, >> Tobias >> >> On 25.09.2018 10:38, Pengfei Li (Arm Technology China) wrote: >>> Hi Vladimir, >>> >>> I still didn't get other comments during the past week. >>> Do you think it is ok to push this patch? >>> http://cr.openjdk.java.net/~njian/8210152/webrev.01/ >>> >>> -- >>> Thanks, >>> Pengfei >>> >>>> -----Original Message----- >>>> >>>> Hi Reviewers, >>>> >>>> Is there any other comments, objections or suggestions on the new >> webrev? >>>> If no problems, could anyone help to push this commit? >>>> >>>> I look forward to your response. >>>> >>>> -- >>>> Thanks, >>>> Pengfei >>>> >>>>> -----Original Message----- >>>>> >>>>> Looks good. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/12/18 2:50 AM, Pengfei Li (Arm Technology China) wrote: >>>>>> Hi, >>>>>> >>>>>> I've updated the patch based on Vladimir's comment. I added checks >>>>>> for >>>>> SubI on both branches of the diamond phi. >>>>>> Also thanks Roland for the suggestion that supporting a Phi with 3 >>>>>> or more >>>>> inputs. But I think the matching rule will be much more complex if >>>>> we add this. And I'm not sure if there are any real case scenario >>>>> which can benefit from this support. So I didn't add it in. >>>>>> >>>>>> New webrev: http://cr.openjdk.java.net/~njian/8210152/webrev.01/ >>>>>> I've run jtreg full test with the new patch and no new issues found. >>>>>> >>>>>> Please let me know if you have other comments or suggestions. If no >>>>> further issues, I need your help to sponsor and push the patch. >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Pengfei >>>>>> >>>>>> From coleen.phillimore at oracle.com Tue Sep 25 16:08:21 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 25 Sep 2018 12:08:21 -0400 Subject: RFR 8210856: Move InstanceKlass DependencyContext cleaning to SystemDictionary::do_unloading() In-Reply-To: <51375a10-4a8f-9c85-56c4-5942077910db@oracle.com> References: <48247e1b-bb84-5508-7393-f286c83b600f@oracle.com> <51375a10-4a8f-9c85-56c4-5942077910db@oracle.com> Message-ID: On 9/24/18 6:05 PM, dean.long at oracle.com wrote: > Hi Coleen.? The fix seems straightforward now, so I'm wondering, was > there something that changed since the earlier JDK-8143408 was fixed > that allows us to do this simpler fix now, like walking classes in > ClassLoaderData::unload? I think this fix could have been done instead for JDK-8143408, but the code for DependencyContext::remove_all_dependents() was originally added where the code for cleaning the nmethod buckets was in version 8139595, and it was just fixed at that location for 8143408.?? At least, that's what I'm guessing from the history. thanks, Coleen > > dl > > On 9/21/18 8:45 AM, coleen.phillimore at oracle.com wrote: >> Summary: Already walk classes in ClassLoaderData::unload so >> generalize to also clean nmethod dependencies. >> >> The nmethod dependencies should be cleaned before metadata is >> purged.? See bug for more details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8210856.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8210856 >> >> Tested with hs tier1-7, modified gtest, and >> compiler/codecache/stress/RandomAllocationTest.java from bug >> https://bugs.openjdk.java.net/browse/JDK-8143408. >> >> Thanks, >> Coleen >> >> > From alexey.menkov at oracle.com Tue Sep 25 17:53:19 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 25 Sep 2018 10:53:19 -0700 Subject: RFR (M) 8211036 : Remove the NSK_STUB macros from vmTestbase for non jvmti In-Reply-To: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> References: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> Message-ID: <312465f1-fd55-ea31-ae73-9e464566764b@oracle.com> +1 --alex On 09/24/2018 11:40, Igor Ignatyev wrote: > (cc-ing hotspot-dev alias) > > Hi Jc, > > the fix looks good to me. don't forget to clean up nsk/share/jni/README at the end. > > Thanks, > -- Igor > >> On Sep 24, 2018, at 9:28 AM, JC Beyler wrote: >> >> Hi all, >> >> As the tests have become C++ tests, the NSK_CPP_STUBS are no longer needed. I did two awk scripts to remove them and will be rolling them out in 50 file max reviews to streamline the reviews for the reviewers. >> >> So here is the first which handles all the cases outside of the jvmti subfolder: >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211036 >> >> The bug contains information on the two scripts I used. >> >> Thanks, >> Jc > From igor.ignatyev at oracle.com Wed Sep 26 00:44:43 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 25 Sep 2018 17:44:43 -0700 Subject: RFR(XXS) : 8211134 : problem list compiler/whitebox/ForceNMethodSweepTest.java Message-ID: <1DCA132C-3FDA-4678-8825-14855E880AE7@oracle.com> http://cr.openjdk.java.net/~iignatyev//8211134/webrev.00/index.html > 2 lines changed: 2 ins; 0 del; 0 mod; Hi all, could you please review this tiny fix which problem-lists ForceNMethodSweepTest till 8211129 is fixed? webrev: http://cr.openjdk.java.net/~iignatyev//8211134/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8211134 Thanks, -- Igor From vladimir.kozlov at oracle.com Wed Sep 26 01:22:54 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 25 Sep 2018 18:22:54 -0700 Subject: RFR(XXS) : 8211134 : problem list compiler/whitebox/ForceNMethodSweepTest.java In-Reply-To: <1DCA132C-3FDA-4678-8825-14855E880AE7@oracle.com> References: <1DCA132C-3FDA-4678-8825-14855E880AE7@oracle.com> Message-ID: Good. Thanks, Vladimir On 9/25/18 5:44 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8211134/webrev.00/index.html >> 2 lines changed: 2 ins; 0 del; 0 mod; > > Hi all, > > could you please review this tiny fix which problem-lists ForceNMethodSweepTest till 8211129 is fixed? > > webrev: http://cr.openjdk.java.net/~iignatyev//8211134/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8211134 > > Thanks, > -- Igor > From rkennke at redhat.com Wed Sep 26 08:30:17 2018 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 26 Sep 2018 10:30:17 +0200 Subject: RFR: JDK-8211129: [Testbug] compiler/whitebox/ForceNMethodSweepTest.java fails after JDK-8132849 Message-ID: Please review the following change: Several tests fail because after forcing nmethod sweep via Whitebox API, the sweeper doesn't actually kick in. The reason is the changed heuristic in NMethodSweeper: before JDK-8132849, we would scan stacks and mark nmethods at every safepoint, during safepoint cleanup phase. This would subsequently trigger a sweep cycle via _should_sweep. If no stack-scanning is performed, the sweeper would skip sweeping because the CompiledMethodIterator _current has not been reset. I propose to change the following: - In the sweep-loop, call into do_stack_scanning() whenever it's forced (via WhiteBox API) or if should_sweep has been determined by other heuristics (code-cache-change, time-since-last-sweep,..) - Instead let do_stack_scanning() not set _should_sweep anymore. Bug: https://bugs.openjdk.java.net/browse/JDK-8211129 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8211129/webrev.00/ Testing: Fixes previously failing: compiler/whitebox/ForceNMethodSweepTest.java jdk/jfr/event/compiler/TestCodeSweeperStats.java Passes: hotspot/jtreg:tier1 From sgehwolf at redhat.com Wed Sep 26 11:26:34 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 26 Sep 2018 13:26:34 +0200 Subject: [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling Message-ID: Hi, Could I please get reviews for this JDK 8 backport which fixes some tooling issues on Linux ppc64le? Prior this patch, a ppc64le build would report as "ppc64" via os.arch system property which breaks tooling such as maven in as much as if some dependency needs native libraries it would download BE binaries where it actually should download LE binaries. Example for os.arch/java.library.path: pre: $ ./jdk8-pre-ppc64le/bin/java TestProperty java.library.path = /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib os.arch = ppc64 post: $ ./jdk8-post-ppc64le/bin/java TestProperty java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib os.arch = ppc64le Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/ Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev for JDK/hotspot changes. This backport should only have minor differences to the changes in JDK 11. We have been using similar patches in Fedora for months. Thoughts? Thanks, Severin From david.holmes at oracle.com Wed Sep 26 11:39:18 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Sep 2018 07:39:18 -0400 Subject: [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: Message-ID: Hi Severin, Changes present seem okay, but I don't see the SA changes, and don't you want the JDK test change from this as well: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2ff471390a03 ?? Thanks, David On 26/09/2018 7:26 AM, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this JDK 8 backport which fixes some > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > would report as "ppc64" via os.arch system property which breaks > tooling such as maven in as much as if some dependency needs native > libraries it would download BE binaries where it actually should > download LE binaries. Example for os.arch/java.library.path: > > pre: > $ ./jdk8-pre-ppc64le/bin/java TestProperty > java.library.path = /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > os.arch = ppc64 > > post: > $ ./jdk8-post-ppc64le/bin/java TestProperty > java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > os.arch = ppc64le > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/ > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev > for JDK/hotspot changes. > > This backport should only have minor differences to the changes in JDK > 11. We have been using similar patches in Fedora for months. Thoughts? > > Thanks, > Severin > From sgehwolf at redhat.com Wed Sep 26 11:52:05 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 26 Sep 2018 13:52:05 +0200 Subject: [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: Message-ID: <3e076712a19ee7b29665543e46699497018ba886.camel@redhat.com> Hi David, Thanks for the review! On Wed, 2018-09-26 at 07:39 -0400, David Holmes wrote: > Hi Severin, > > Changes present seem okay, but I don't see the SA changes, and don't you > want the JDK test change from this as well: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2ff471390a03 > > ?? Test changes are there: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/jdk/test/sun/security/pkcs11/PKCS11Test.java.udiff.html http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/jdk/test/tools/launcher/Settings.java.udiff.html The SA isn't built on ppc64/ppc64le (INCLUDE_SA=false). I can include SA changes in the backport, but they won't do anything. Thanks, Severin > On 26/09/2018 7:26 AM, Severin Gehwolf wrote: > > Hi, > > > > Could I please get reviews for this JDK 8 backport which fixes some > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > > would report as "ppc64" via os.arch system property which breaks > > tooling such as maven in as much as if some dependency needs native > > libraries it would download BE binaries where it actually should > > download LE binaries. Example for os.arch/java.library.path: > > > > pre: > > $ ./jdk8-pre-ppc64le/bin/java TestProperty > > java.library.path = /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > > os.arch = ppc64 > > > > post: > > $ ./jdk8-post-ppc64le/bin/java TestProperty > > java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > > os.arch = ppc64le > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/ > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev > > for JDK/hotspot changes. > > > > This backport should only have minor differences to the changes in JDK > > 11. We have been using similar patches in Fedora for months. Thoughts? > > > > Thanks, > > Severin > > From david.holmes at oracle.com Wed Sep 26 12:20:38 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Sep 2018 08:20:38 -0400 Subject: [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: <3e076712a19ee7b29665543e46699497018ba886.camel@redhat.com> References: <3e076712a19ee7b29665543e46699497018ba886.camel@redhat.com> Message-ID: On 26/09/2018 7:52 AM, Severin Gehwolf wrote: > Hi David, > > Thanks for the review! > > On Wed, 2018-09-26 at 07:39 -0400, David Holmes wrote: >> Hi Severin, >> >> Changes present seem okay, but I don't see the SA changes, and don't you >> want the JDK test change from this as well: >> >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2ff471390a03 >> >> ?? > > Test changes are there: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/jdk/test/sun/security/pkcs11/PKCS11Test.java.udiff.html > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/jdk/test/tools/launcher/Settings.java.udiff.html Oops I missed the split up. Thanks. All seems fine, > The SA isn't built on ppc64/ppc64le (INCLUDE_SA=false). I can include > SA changes in the backport, but they won't do anything. Okay. Thanks, David > Thanks, > Severin > >> On 26/09/2018 7:26 AM, Severin Gehwolf wrote: >>> Hi, >>> >>> Could I please get reviews for this JDK 8 backport which fixes some >>> tooling issues on Linux ppc64le? Prior this patch, a ppc64le build >>> would report as "ppc64" via os.arch system property which breaks >>> tooling such as maven in as much as if some dependency needs native >>> libraries it would download BE binaries where it actually should >>> download LE binaries. Example for os.arch/java.library.path: >>> >>> pre: >>> $ ./jdk8-pre-ppc64le/bin/java TestProperty >>> java.library.path = /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib >>> os.arch = ppc64 >>> >>> post: >>> $ ./jdk8-post-ppc64le/bin/java TestProperty >>> java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib >>> os.arch = ppc64le >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 >>> webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/ >>> >>> Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev >>> for JDK/hotspot changes. >>> >>> This backport should only have minor differences to the changes in JDK >>> 11. We have been using similar patches in Fedora for months. Thoughts? >>> >>> Thanks, >>> Severin >>> > From christoph.langer at sap.com Wed Sep 26 13:14:22 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 26 Sep 2018 13:14:22 +0000 Subject: RFR [XS] 8210964: add more ld preloading info to hs_error file on Linux In-Reply-To: References: Message-ID: <2da63d051a784ccd82a38f1880bd5314@sap.com> Hi Matthias, just checked the change. I like the second variant (8210964.1) better. Reviewed. Best regards Christoph > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Dienstag, 25. September 2018 09:14 > To: Thomas St?fe > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR [XS] 8210964: add more ld preloading info to hs_error file on > Linux > > Thanks, can I have a second review please ? > > (maybe with opinions what people like better, > > http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.0/ > > or > > http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.1/ > > ) > > Best regards, Matthias > > > > -----Original Message----- > > From: Thomas St?fe > > Sent: Montag, 24. September 2018 16:45 > > To: Baesken, Matthias > > Cc: hotspot-dev at openjdk.java.net > > Subject: Re: RFR [XS] 8210964: add more ld preloading info to hs_error file > on > > Linux > > > > Hi Matthias, > > > > Hm. I see now that my request to not print the header line of > > ld.preload made the patch more complicated than necessary. Sorry for > > that. > > > > If you like, you can revert to the previous version, I would just ask > > you to change the error message to a more generic sentence, e.g.: > > > > void os::Linux::print_system_config_info(outputStream* st) { > > st->cr(); > > st->print_cr("/etc/ld.so.preload (system-wide LD_PRELOAD config file):"); > > bool success = _print_ascii_file("/etc/ld.so.preload", st); > > if (!success) { st->print("not available"); } > > st->cr(); > > st->cr(); > > } > > > > I am fine with both versions. I leave it up to you if you ship the > > second variant of the first one (with the changed error message). > > > > I do not need another webrev. > > > > Thanks, Thomas > > > > > > > > On Mon, Sep 24, 2018 at 3:14 PM, Baesken, Matthias > > wrote: > > > Hi Thomas, thanks for your input ! > > > > > > I followed your suggestions : > > > - renamed the function to os::Linux::print_ld_preload_file > > > - output the header only in case the file is opened > > > - changed (shortened) the header > > > > > >> > Also, I personally would not expose it via os_linux.hpp. > > > > > > However I kept it there, to keep it in line with the other info-functions. > > > > > > New webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.1/ > > > > > > > > > Best regards, Matthias > > > > > > > > > > > >> -----Original Message----- > > >> From: Thomas St?fe > > >> Sent: Freitag, 21. September 2018 18:59 > > >> To: Baesken, Matthias > > >> Cc: hotspot-dev at openjdk.java.net > > >> Subject: Re: RFR [XS] 8210964: add more ld preloading info to hs_error > file > > on > > >> Linux > > >> > > >> On Fri, Sep 21, 2018 at 6:47 PM, Thomas St?fe > > > > >> wrote: > > >> > Hi Matthias, > > >> > > > >> > in the posted patch the new function is never called, or am I > mistaken? > > >> > > > >> > > >> Scratch that, I was being blind. > > >> > > >> What I do not like is the very generic name of the function. It does > > >> one very specific thing, so could we name it accordingly, e.g. > > >> "os::Linux::print_system_config_info" -> > > >> "os::Linux::print_ld_preload_file"? > > >> > > >> Also, I personally would not expose it via os_linux.hpp. I would just > > >> put it as a file scope static function into os_linux.cpp. I see you > > >> follow the example of others here (os::Linux::print_proc_sys_info etc) > > >> but there too I feel this is a bad pattern and those functions do not > > >> belong into an external header. > > >> > > >> 2140 st->print_cr("/etc/ld.so.preload (system-wide LD_PRELOAD config > > >> file):"); > > >> > > >> I would shorten that to just "ld.so.preload:" or "/etc/ld.so.preload". > > >> Everyone looking at that section knows what that file does. I also > > >> would omit that header completely if the file cannot be opened. > > >> > > >> 2141 bool file_present = _print_ascii_file("/etc/ld.so.preload", st); > > >> 2142 if (!file_present) { st->print("file not present"); } > > >> 2143 st->cr(); > > >> > > >> You do not know that the file is not preset, all you know is that the > > >> open() call in _print_ascii_file() failed. Since existence of this > > >> file is optional, and not typical, I would just omit messages if it > > >> cannot be found. > > >> > > >> Best Regards, Thomas > > >> > > > From coleen.phillimore at oracle.com Wed Sep 26 13:26:15 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Sep 2018 09:26:15 -0400 Subject: RFR 8210856: Move InstanceKlass DependencyContext cleaning to SystemDictionary::do_unloading() In-Reply-To: References: <48247e1b-bb84-5508-7393-f286c83b600f@oracle.com> Message-ID: <8f70e1cf-0071-4b0e-21ea-b3c83f158182@oracle.com> On 9/23/18 5:18 PM, Erik Osterlund wrote: > Hi Coleen, > > Thank you for sorting this out. Looks good. Thanks Erik, Coleen > > Thanks, > /Erik > >> On 21 Sep 2018, at 11:45, coleen.phillimore at oracle.com wrote: >> >> Summary: Already walk classes in ClassLoaderData::unload so generalize to also clean nmethod dependencies. >> >> The nmethod dependencies should be cleaned before metadata is purged. See bug for more details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8210856.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8210856 >> >> Tested with hs tier1-7, modified gtest, and compiler/codecache/stress/RandomAllocationTest.java from bug https://bugs.openjdk.java.net/browse/JDK-8143408. >> >> Thanks, >> Coleen >> >> From boris.ulasevich at bell-sw.com Wed Sep 26 13:47:43 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 26 Sep 2018 16:47:43 +0300 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> <25a98e2e-2523-d221-429a-4284938082a9@oracle.com> Message-ID: Hi David, For this change the most interesting would be to check it with ARMv5, but I do not have the hardware now. I hope I will get one ARMv5 machine next week. For ARMv7 the change is Ok. Almost Ok. There is a minor build issue: /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp:3724:9: error: redeclaration of ?Label notVolatile? Label notVolatile; ^~~~~~~~~~~ /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp:3492:9: note: ?Label notVolatile? previously declared here Label notVolatile; ^~~~~~~~~~~ /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp: In static member function ?static void TemplateTable::fast_storefield(TosState)?: /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp:3885:9: error: redeclaration of ?Label notVolatile? Label notVolatile; ^~~~~~~~~~~ /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp:3832:9: note: ?Label notVolatile? previously declared here Label notVolatile; ^~~~~~~~~~~ regards, Boris On 23.09.2018 19:26, David Holmes wrote: > Hi Boris, > > Here is latest webrev with the ARM code updated as well. > > http://cr.openjdk.java.net/~dholmes/8188764/webrev/ > > All is_MP removed except where needed for ARMv5 support, MP specific > instructions, and controlling of biased locking. > > I checked the DMB variants and we only generate for ARMv7 anyway, so no > issue there. > > Would very much appreciate whatever test builds you can do on different > ARM variants Boris! > > Thanks, > David > > On 21/09/2018 9:41 AM, David Holmes wrote: >> Hi Boris, >> >> On 21/09/2018 9:34 AM, Boris Ulasevich wrote: >>> Hi David, >>> >>> On 20.09.2018 18:26, David Holmes wrote: >>>> Hi Boris, >>>> >>>> Thanks for jumping on this. I hope you didn't spend too much time on >>>> it as I had actually started on the ARM code then decided I didn't >>>> need to make the changes, so I'd already gone through pretty much >>>> everything that is needed. My concern is with things like the change in >>>> >>>> src/hotspot/cpu/arm/assembler_arm_32.hpp >>>> >>>> where you removed the is_MP() check but in fact that needs to remain >>>> because the instruction pldw is not present on variants of the v7 >>>> architecture without the multi-processor extensions: >>> >>> Ok. Good point. Sure, my hasty proposal to get rid of is_MP() check >>> in arm32 codes was wrong. >>> >>> One note. I see there is an ambiguity here: is_MP() is a >>> multiprocessor system flag (returns true when _processor_count != 1), >>> but multi-processor extensions is an optional ARMv7 feature which is >>> not related with processors count, so pldw usage should not be >>> controlled by is_MP() flag. >> >> is_MP can't return true unless there is more than one processor >> (ignoring the pre-initialization case), so if there's more than one >> processor there must be a MP supprting architecture. >> >>>> http://www.keil.com/support/man/docs/armclang_asm/armclang_asm_pge1425899018492.htm >>>> >>>> That makes me wonder whether any of the memory barrier instructions >>>> may also be missing in some v6/v7 variants as well? >>> >>> Nobody complained :) And Reference Manual says DMB/DSB are not optional. >> >> I need to double-check we don't define variants like "dmb sy" that are >> architecture specific. >> >>>> Plus I have to account for uniprocessor ARMv5 so need to see whether >>>> MacroAssembler::membar, for example, must also retain the is_MP() >>>> check. >>> >>> Do you want to delete this check? Processor count check seems quite >>> natural to see if it has sense to generate memory barriers. >> >> That is the general thrust of this change. We assume we always have MP >> and so always issue memory barriers. >> >>> By the way, MacroAssembler::fast_lock have >>> VM_Version::supports_ldrex() check assertion with message >>> "unsupported, yet?". Looks like it is not going to work correctly on >>> multiprocessor ARMv5. >> >> The ARM code does not support multiprocessor ARMv5. >> >> Thanks, >> David >> >>>> Also in: >>>> >>>> src/hotspot/cpu/arm/stubGenerator_arm.cpp >>>> >>>> you can't remove the !is_MP() check and related code as that is >>>> needed for ARMv5 (uniprocessor) support. >>>> >>>> Similarly in >>>> >>>> src/hotspot/cpu/arm/vm_version_arm_32.cpp >>>> >>>> you'll probably still want to disable biased-locking for ARMv5. >>>> >>>> Cheers, >>>> David >>>> >>>> On 20/09/2018 3:31 AM, Boris Ulasevich wrote: >>>>> Hi David, >>>>> >>>>> ?> I have not updated the about-to-be-removed Oracle ARM port code. >>>>> >>>>> Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. >>>>> I would propose the following change - I think we can either add it >>>>> to your update or to create a separate RFR after your patch and >>>>> JEP-340 commit: >>>>> >>>>> http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ >>>>> >>>>> regards, >>>>> Boris >>>>> >>>>> On 18.09.2018 08:32, David Holmes wrote: >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >>>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>>>>> >>>>>> As previously discussed in the RFC thread: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >>>>>> >>>>>> >>>>>> this change obsoletes the AssumeMP flag and removes the bulk of >>>>>> the logic that is conditional on os::is_MP() as follows: >>>>>> >>>>>> 1. to gate the introduction of MP-specific features, notably >>>>>> memory barriers >>>>>> >>>>>> The is_MP check is removed and we will always issue memory barriers >>>>>> or pre-pend lock prefix etc. >>>>>> >>>>>> 2. to align certain patchable code sequences (method entry, call >>>>>> sites) >>>>>> >>>>>> The is_MP is removed and we always align patchable locations. >>>>>> >>>>>> 3. to gate certain optimizations which are questionable on >>>>>> uniprocessors >>>>>> (see quicken_jni_functions) >>>>>> >>>>>> These are psuedo-memory-barriers where we manufacture a >>>>>> data-dependency >>>>>> instead of inserting mfence/lfence (x86 example). These are >>>>>> treated as >>>>>> #1 and is_MP is removed. >>>>>> >>>>>> 4. to gate optimizations which are desirable on uniprocessors >>>>>> (mutex/monitor short circuits) >>>>>> >>>>>> These are spin controls and so is_MP remains. >>>>>> >>>>>> I have not updated the about-to-be-removed Oracle ARM port code. >>>>>> >>>>>> Testing: >>>>>> ?? - Tiers 1 -3 (mach5) >>>>>> >>>>>> Performance run TBD. >>>>>> >>>>>> Thanks, >>>>>> David From david.holmes at oracle.com Wed Sep 26 13:49:53 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Sep 2018 09:49:53 -0400 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: References: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> <25a98e2e-2523-d221-429a-4284938082a9@oracle.com> Message-ID: <321a4c56-dba1-2028-4920-257e542dc83c@oracle.com> Thanks Boris, I'll fix the label problem. I'm travelling at the moment so won't push till later next week. Hopefully you'll have access to the hardware by then. Thanks, David On 26/09/2018 9:47 AM, Boris Ulasevich wrote: > Hi David, > > ? For this change the most interesting would be to check it with ARMv5, > but I do not have the hardware now. I hope I will get one ARMv5 machine > next week. > > ? For ARMv7 the change is Ok. Almost Ok. There is a minor build issue: > > /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp:3724:9: > error: redeclaration of ?Label notVolatile? > ?? Label notVolatile; > ???????? ^~~~~~~~~~~ > /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp:3492:9: > note: ?Label notVolatile? previously declared here > ?? Label notVolatile; > ???????? ^~~~~~~~~~~ > /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp: In static > member function ?static void TemplateTable::fast_storefield(TosState)?: > /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp:3885:9: > error: redeclaration of ?Label notVolatile? > ?? Label notVolatile; > ???????? ^~~~~~~~~~~ > /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp:3832:9: > note: ?Label notVolatile? previously declared here > ?? Label notVolatile; > ???????? ^~~~~~~~~~~ > > regards, > Boris > > On 23.09.2018 19:26, David Holmes wrote: >> Hi Boris, >> >> Here is latest webrev with the ARM code updated as well. >> >> http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >> >> All is_MP removed except where needed for ARMv5 support, MP specific >> instructions, and controlling of biased locking. >> >> I checked the DMB variants and we only generate for ARMv7 anyway, so >> no issue there. >> >> Would very much appreciate whatever test builds you can do on >> different ARM variants Boris! >> >> Thanks, >> David >> >> On 21/09/2018 9:41 AM, David Holmes wrote: >>> Hi Boris, >>> >>> On 21/09/2018 9:34 AM, Boris Ulasevich wrote: >>>> Hi David, >>>> >>>> On 20.09.2018 18:26, David Holmes wrote: >>>>> Hi Boris, >>>>> >>>>> Thanks for jumping on this. I hope you didn't spend too much time >>>>> on it as I had actually started on the ARM code then decided I >>>>> didn't need to make the changes, so I'd already gone through pretty >>>>> much everything that is needed. My concern is with things like the >>>>> change in >>>>> >>>>> src/hotspot/cpu/arm/assembler_arm_32.hpp >>>>> >>>>> where you removed the is_MP() check but in fact that needs to >>>>> remain because the instruction pldw is not present on variants of >>>>> the v7 architecture without the multi-processor extensions: >>>> >>>> Ok. Good point. Sure, my hasty proposal to get rid of is_MP() check >>>> in arm32 codes was wrong. >>>> >>>> One note. I see there is an ambiguity here: is_MP() is a >>>> multiprocessor system flag (returns true when _processor_count != >>>> 1), but multi-processor extensions is an optional ARMv7 feature >>>> which is not related with processors count, so pldw usage should not >>>> be controlled by is_MP() flag. >>> >>> is_MP can't return true unless there is more than one processor >>> (ignoring the pre-initialization case), so if there's more than one >>> processor there must be a MP supprting architecture. >>> >>>>> http://www.keil.com/support/man/docs/armclang_asm/armclang_asm_pge1425899018492.htm >>>>> >>>>> That makes me wonder whether any of the memory barrier instructions >>>>> may also be missing in some v6/v7 variants as well? >>>> >>>> Nobody complained :) And Reference Manual says DMB/DSB are not >>>> optional. >>> >>> I need to double-check we don't define variants like "dmb sy" that >>> are architecture specific. >>> >>>>> Plus I have to account for uniprocessor ARMv5 so need to see >>>>> whether MacroAssembler::membar, for example, must also retain the >>>>> is_MP() check. >>>> >>>> Do you want to delete this check? Processor count check seems quite >>>> natural to see if it has sense to generate memory barriers. >>> >>> That is the general thrust of this change. We assume we always have >>> MP and so always issue memory barriers. >>> >>>> By the way, MacroAssembler::fast_lock have >>>> VM_Version::supports_ldrex() check assertion with message >>>> "unsupported, yet?". Looks like it is not going to work correctly on >>>> multiprocessor ARMv5. >>> >>> The ARM code does not support multiprocessor ARMv5. >>> >>> Thanks, >>> David >>> >>>>> Also in: >>>>> >>>>> src/hotspot/cpu/arm/stubGenerator_arm.cpp >>>>> >>>>> you can't remove the !is_MP() check and related code as that is >>>>> needed for ARMv5 (uniprocessor) support. >>>>> >>>>> Similarly in >>>>> >>>>> src/hotspot/cpu/arm/vm_version_arm_32.cpp >>>>> >>>>> you'll probably still want to disable biased-locking for ARMv5. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>> On 20/09/2018 3:31 AM, Boris Ulasevich wrote: >>>>>> Hi David, >>>>>> >>>>>> ?> I have not updated the about-to-be-removed Oracle ARM port code. >>>>>> >>>>>> Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. >>>>>> I would propose the following change - I think we can either add >>>>>> it to your update or to create a separate RFR after your patch and >>>>>> JEP-340 commit: >>>>>> >>>>>> http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ >>>>>> >>>>>> regards, >>>>>> Boris >>>>>> >>>>>> On 18.09.2018 08:32, David Holmes wrote: >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >>>>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>>>>>> >>>>>>> As previously discussed in the RFC thread: >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >>>>>>> >>>>>>> >>>>>>> this change obsoletes the AssumeMP flag and removes the bulk of >>>>>>> the logic that is conditional on os::is_MP() as follows: >>>>>>> >>>>>>> 1. to gate the introduction of MP-specific features, notably >>>>>>> memory barriers >>>>>>> >>>>>>> The is_MP check is removed and we will always issue memory barriers >>>>>>> or pre-pend lock prefix etc. >>>>>>> >>>>>>> 2. to align certain patchable code sequences (method entry, call >>>>>>> sites) >>>>>>> >>>>>>> The is_MP is removed and we always align patchable locations. >>>>>>> >>>>>>> 3. to gate certain optimizations which are questionable on >>>>>>> uniprocessors >>>>>>> (see quicken_jni_functions) >>>>>>> >>>>>>> These are psuedo-memory-barriers where we manufacture a >>>>>>> data-dependency >>>>>>> instead of inserting mfence/lfence (x86 example). These are >>>>>>> treated as >>>>>>> #1 and is_MP is removed. >>>>>>> >>>>>>> 4. to gate optimizations which are desirable on uniprocessors >>>>>>> (mutex/monitor short circuits) >>>>>>> >>>>>>> These are spin controls and so is_MP remains. >>>>>>> >>>>>>> I have not updated the about-to-be-removed Oracle ARM port code. >>>>>>> >>>>>>> Testing: >>>>>>> ?? - Tiers 1 -3 (mach5) >>>>>>> >>>>>>> Performance run TBD. >>>>>>> >>>>>>> Thanks, >>>>>>> David From coleen.phillimore at oracle.com Wed Sep 26 14:00:58 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Sep 2018 10:00:58 -0400 Subject: RFR [XS] 8210964: add more ld preloading info to hs_error file on Linux In-Reply-To: <2da63d051a784ccd82a38f1880bd5314@sap.com> References: <2da63d051a784ccd82a38f1880bd5314@sap.com> Message-ID: This version .1 seems fine.? This isn't a very long file, is it? People post the whole hs_err_pid file in bug descriptions which makes for a lot of scrolling. Looks good to me. Coleen On 9/26/18 9:14 AM, Langer, Christoph wrote: > Hi Matthias, > > just checked the change. I like the second variant (8210964.1) better. Reviewed. > > Best regards > Christoph > >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> Baesken, Matthias >> Sent: Dienstag, 25. September 2018 09:14 >> To: Thomas St?fe >> Cc: hotspot-dev at openjdk.java.net >> Subject: RE: RFR [XS] 8210964: add more ld preloading info to hs_error file on >> Linux >> >> Thanks, can I have a second review please ? >> >> (maybe with opinions what people like better, >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.0/ >> >> or >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.1/ >> >> ) >> >> Best regards, Matthias >> >> >>> -----Original Message----- >>> From: Thomas St?fe >>> Sent: Montag, 24. September 2018 16:45 >>> To: Baesken, Matthias >>> Cc: hotspot-dev at openjdk.java.net >>> Subject: Re: RFR [XS] 8210964: add more ld preloading info to hs_error file >> on >>> Linux >>> >>> Hi Matthias, >>> >>> Hm. I see now that my request to not print the header line of >>> ld.preload made the patch more complicated than necessary. Sorry for >>> that. >>> >>> If you like, you can revert to the previous version, I would just ask >>> you to change the error message to a more generic sentence, e.g.: >>> >>> void os::Linux::print_system_config_info(outputStream* st) { >>> st->cr(); >>> st->print_cr("/etc/ld.so.preload (system-wide LD_PRELOAD config file):"); >>> bool success = _print_ascii_file("/etc/ld.so.preload", st); >>> if (!success) { st->print("not available"); } >>> st->cr(); >>> st->cr(); >>> } >>> >>> I am fine with both versions. I leave it up to you if you ship the >>> second variant of the first one (with the changed error message). >>> >>> I do not need another webrev. >>> >>> Thanks, Thomas >>> >>> >>> >>> On Mon, Sep 24, 2018 at 3:14 PM, Baesken, Matthias >>> wrote: >>>> Hi Thomas, thanks for your input ! >>>> >>>> I followed your suggestions : >>>> - renamed the function to os::Linux::print_ld_preload_file >>>> - output the header only in case the file is opened >>>> - changed (shortened) the header >>>> >>>>>> Also, I personally would not expose it via os_linux.hpp. >>>> However I kept it there, to keep it in line with the other info-functions. >>>> >>>> New webrev : >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.1/ >>>> >>>> >>>> Best regards, Matthias >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Thomas St?fe >>>>> Sent: Freitag, 21. September 2018 18:59 >>>>> To: Baesken, Matthias >>>>> Cc: hotspot-dev at openjdk.java.net >>>>> Subject: Re: RFR [XS] 8210964: add more ld preloading info to hs_error >> file >>> on >>>>> Linux >>>>> >>>>> On Fri, Sep 21, 2018 at 6:47 PM, Thomas St?fe >>> >>>>> wrote: >>>>>> Hi Matthias, >>>>>> >>>>>> in the posted patch the new function is never called, or am I >> mistaken? >>>>> Scratch that, I was being blind. >>>>> >>>>> What I do not like is the very generic name of the function. It does >>>>> one very specific thing, so could we name it accordingly, e.g. >>>>> "os::Linux::print_system_config_info" -> >>>>> "os::Linux::print_ld_preload_file"? >>>>> >>>>> Also, I personally would not expose it via os_linux.hpp. I would just >>>>> put it as a file scope static function into os_linux.cpp. I see you >>>>> follow the example of others here (os::Linux::print_proc_sys_info etc) >>>>> but there too I feel this is a bad pattern and those functions do not >>>>> belong into an external header. >>>>> >>>>> 2140 st->print_cr("/etc/ld.so.preload (system-wide LD_PRELOAD config >>>>> file):"); >>>>> >>>>> I would shorten that to just "ld.so.preload:" or "/etc/ld.so.preload". >>>>> Everyone looking at that section knows what that file does. I also >>>>> would omit that header completely if the file cannot be opened. >>>>> >>>>> 2141 bool file_present = _print_ascii_file("/etc/ld.so.preload", st); >>>>> 2142 if (!file_present) { st->print("file not present"); } >>>>> 2143 st->cr(); >>>>> >>>>> You do not know that the file is not preset, all you know is that the >>>>> open() call in _print_ascii_file() failed. Since existence of this >>>>> file is optional, and not typical, I would just omit messages if it >>>>> cannot be found. >>>>> >>>>> Best Regards, Thomas >>>>> From matthias.baesken at sap.com Wed Sep 26 14:33:52 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 26 Sep 2018 14:33:52 +0000 Subject: RFR [XS] 8210964: add more ld preloading info to hs_error file on Linux In-Reply-To: <2da63d051a784ccd82a38f1880bd5314@sap.com> References: <2da63d051a784ccd82a38f1880bd5314@sap.com> Message-ID: Hi Christoph and Thomas , thanks for the reviews . > just checked the change. I like the second variant (8210964.1) better. Then I take this one ?? ! Best regards, Matthias > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 26. September 2018 15:14 > To: Baesken, Matthias ; Thomas St?fe > > Cc: hotspot-dev at openjdk.java.net > Subject: RE: RFR [XS] 8210964: add more ld preloading info to hs_error file on > Linux > > Hi Matthias, > > just checked the change. I like the second variant (8210964.1) better. > Reviewed. > > Best regards > Christoph > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Dienstag, 25. September 2018 09:14 > > To: Thomas St?fe > > Cc: hotspot-dev at openjdk.java.net > > Subject: RE: RFR [XS] 8210964: add more ld preloading info to hs_error file > on > > Linux > > > > Thanks, can I have a second review please ? > > > > (maybe with opinions what people like better, > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.0/ > > > > or > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8210964.1/ > > > > ) > > > > Best regards, Matthias > > > > From vladimir.x.ivanov at oracle.com Wed Sep 26 14:38:54 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 26 Sep 2018 07:38:54 -0700 Subject: RFR 8210856: Move InstanceKlass DependencyContext cleaning to SystemDictionary::do_unloading() In-Reply-To: <48247e1b-bb84-5508-7393-f286c83b600f@oracle.com> References: <48247e1b-bb84-5508-7393-f286c83b600f@oracle.com> Message-ID: <47006357-6932-e65b-f234-cb4989635163@oracle.com> Looks good. Best regards, Vladimir Ivanov On 21/09/2018 08:45, coleen.phillimore at oracle.com wrote: > Summary: Already walk classes in ClassLoaderData::unload so generalize > to also clean nmethod dependencies. > > The nmethod dependencies should be cleaned before metadata is purged. > See bug for more details. > > open webrev at http://cr.openjdk.java.net/~coleenp/8210856.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8210856 > > Tested with hs tier1-7, modified gtest, and > compiler/codecache/stress/RandomAllocationTest.java from bug > https://bugs.openjdk.java.net/browse/JDK-8143408. > > Thanks, > Coleen > > From matthias.baesken at sap.com Wed Sep 26 15:41:18 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 26 Sep 2018 15:41:18 +0000 Subject: AllocateHeapAt disabling on AIX Message-ID: Hello, we want to disable the globals-flag AllocateHeapAt on AIX . It currently does not really work on this platform, and there is no current plan to support it . My question : Should I just add a check to argument.cpp ? Or should I use the constraint function feature for this ? E.g. add a constraint function to globals.hpp and then do something like this ? JVMFlag::Error AllocateHeapAtConstraintFunc(ccstr value, bool verbose) { #if defined(_AIX) return JVMFlag::VIOLATES_CONSTRAINT; #endif return JVMFlag::SUCCESS; } To me the current usages of the constraint functions do not look like they were intended for platform-handling, but for Checking validity/sanity of some flag values . Thanks for your comments, Matthias From david.holmes at oracle.com Wed Sep 26 15:45:16 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Sep 2018 11:45:16 -0400 Subject: AllocateHeapAt disabling on AIX In-Reply-To: References: Message-ID: Hi Matthias, On 26/09/2018 11:41 AM, Baesken, Matthias wrote: > Hello, we want to disable the globals-flag AllocateHeapAt on AIX . > It currently does not really work on this platform, and there is no current plan to support it . > > My question : > > Should I just add a check to argument.cpp ? > Or should I use the constraint function feature for this ? Do you want the flag to be non-existent or non-settable? What kind of error report do you want for the end user? Thanks, David > E.g. add a constraint function to globals.hpp and then do something like this ? > > JVMFlag::Error AllocateHeapAtConstraintFunc(ccstr value, bool verbose) { > #if defined(_AIX) > return JVMFlag::VIOLATES_CONSTRAINT; > #endif > return JVMFlag::SUCCESS; > } > > > To me the current usages of the constraint functions do not look like they were intended for platform-handling, but for > Checking validity/sanity of some flag values . > > > Thanks for your comments, Matthias > From lutz.schmidt at sap.com Wed Sep 26 15:45:18 2018 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 26 Sep 2018 15:45:18 +0000 Subject: RFR(S): 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) Message-ID: <3C71CFD0-3764-464F-A12F-FD71BE44658E@sap.com> Dear all, may I please request reviews for this small patch, fixing some ?default case missing? issues in platform code (ppc and s390). Bug: https://bugs.openjdk.java.net/browse/JDK-8211145 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8211145.00/ Thank you, Lutz From shade at redhat.com Wed Sep 26 15:50:34 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Sep 2018 17:50:34 +0200 Subject: RFR(S): 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) In-Reply-To: <3C71CFD0-3764-464F-A12F-FD71BE44658E@sap.com> References: <3C71CFD0-3764-464F-A12F-FD71BE44658E@sap.com> Message-ID: <6629adb8-f0d5-1f9d-15b5-3159c67e9c3e@redhat.com> On 09/26/2018 05:45 PM, Schmidt, Lutz wrote: > Dear all, > > may I please request reviews for this small patch, fixing some ?default case missing? issues in platform code (ppc and s390). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211145 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8211145.00/ *) What is this change in assembler_s390.hpp? These new enum values are not used. 1445 bcondLowOrNotOrdered = bcondLow | bcondNotOrdered, // float comparisons 1446 bcondHighOrNotOrdered = bcondHigh | bcondNotOrdered, // float comparisons 1447 bcondNotLowOrNotOrdered = bcondNotLow | bcondNotOrdered, // float comparisons 1448 bcondNotHighOrNotOrdered = bcondNotHigh | bcondNotOrdered, // float comparisons *) Stylistically, it seems more consistent to break the line after "default" in some switches, for example here: 3214 case Bytecodes::_fast_lputfield: 3215 __ pop_l(Z_tos); 3216 break; 3217 default: break; -Aleksey From matthias.baesken at sap.com Wed Sep 26 16:02:34 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 26 Sep 2018 16:02:34 +0000 Subject: AllocateHeapAt disabling on AIX In-Reply-To: References: Message-ID: Hi David, I would like to print something like "AllocateHeapAt not supported on AIX" . And then exit (probably just ignoring the flag and printing the message might be bad ). The constraint functions were suggested to me as an option but it looks to me they are Intended for other use cases . Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Mittwoch, 26. September 2018 17:45 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: AllocateHeapAt disabling on AIX > > Hi Matthias, > > On 26/09/2018 11:41 AM, Baesken, Matthias wrote: > > Hello, we want to disable the globals-flag AllocateHeapAt on AIX . > > It currently does not really work on this platform, and there is no current > plan to support it . > > > > My question : > > > > Should I just add a check to argument.cpp ? > > Or should I use the constraint function feature for this ? > > Do you want the flag to be non-existent or non-settable? What kind of > error report do you want for the end user? > > Thanks, > David > > > E.g. add a constraint function to globals.hpp and then do something like > this ? > > > > JVMFlag::Error AllocateHeapAtConstraintFunc(ccstr value, bool verbose) { > > #if defined(_AIX) > > return JVMFlag::VIOLATES_CONSTRAINT; > > #endif > > return JVMFlag::SUCCESS; > > } > > > > > > To me the current usages of the constraint functions do not look like they > were intended for platform-handling, but for > > Checking validity/sanity of some flag values . > > > > > > Thanks for your comments, Matthias > > From lutz.schmidt at sap.com Wed Sep 26 16:08:19 2018 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 26 Sep 2018 16:08:19 +0000 Subject: RFR(S): 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) In-Reply-To: <6629adb8-f0d5-1f9d-15b5-3159c67e9c3e@redhat.com> References: <3C71CFD0-3764-464F-A12F-FD71BE44658E@sap.com> <6629adb8-f0d5-1f9d-15b5-3159c67e9c3e@redhat.com> Message-ID: <6D26E4F8-51E0-4171-B644-ED92C5830D82@sap.com> Hi Aleksey, you got me! I forgot to mention this one, sorry! With -Werror=switch, the compiler complains about line 131 in cpu/s390/assembler_s390.cpp: case bcondNotHigh + bcondNotOrdered : inverse_cc = bcondHigh; break; // 13 The resulting case label was not declared in the enum Assembler::branch_condition. Thanks, Lutz ?On 26.09.18, 17:50, "Aleksey Shipilev" wrote: On 09/26/2018 05:45 PM, Schmidt, Lutz wrote: > Dear all, > > may I please request reviews for this small patch, fixing some ?default case missing? issues in platform code (ppc and s390). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211145 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8211145.00/ *) What is this change in assembler_s390.hpp? These new enum values are not used. 1445 bcondLowOrNotOrdered = bcondLow | bcondNotOrdered, // float comparisons 1446 bcondHighOrNotOrdered = bcondHigh | bcondNotOrdered, // float comparisons 1447 bcondNotLowOrNotOrdered = bcondNotLow | bcondNotOrdered, // float comparisons 1448 bcondNotHighOrNotOrdered = bcondNotHigh | bcondNotOrdered, // float comparisons *) Stylistically, it seems more consistent to break the line after "default" in some switches, for example here: 3214 case Bytecodes::_fast_lputfield: 3215 __ pop_l(Z_tos); 3216 break; 3217 default: break; -Aleksey From david.holmes at oracle.com Wed Sep 26 16:09:59 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 26 Sep 2018 12:09:59 -0400 Subject: AllocateHeapAt disabling on AIX In-Reply-To: References: Message-ID: <49965314-df9e-8acf-e5c3-cba98ac2e162@oracle.com> On 26/09/2018 12:02 PM, Baesken, Matthias wrote: > Hi David, I would like to print something like "AllocateHeapAt not supported on AIX" . > And then exit (probably just ignoring the flag and printing the message might be bad ). > > The constraint functions were suggested to me as an option but it looks to me they are > Intended for other use cases . Yes, I think a check in argument.cpp would be better. Thanks, David > Best regards, Matthias > > >> -----Original Message----- >> From: David Holmes >> Sent: Mittwoch, 26. September 2018 17:45 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' >> Subject: Re: AllocateHeapAt disabling on AIX >> >> Hi Matthias, >> >> On 26/09/2018 11:41 AM, Baesken, Matthias wrote: >>> Hello, we want to disable the globals-flag AllocateHeapAt on AIX . >>> It currently does not really work on this platform, and there is no current >> plan to support it . >>> >>> My question : >>> >>> Should I just add a check to argument.cpp ? >>> Or should I use the constraint function feature for this ? >> >> Do you want the flag to be non-existent or non-settable? What kind of >> error report do you want for the end user? >> >> Thanks, >> David >> >>> E.g. add a constraint function to globals.hpp and then do something like >> this ? >>> >>> JVMFlag::Error AllocateHeapAtConstraintFunc(ccstr value, bool verbose) { >>> #if defined(_AIX) >>> return JVMFlag::VIOLATES_CONSTRAINT; >>> #endif >>> return JVMFlag::SUCCESS; >>> } >>> >>> >>> To me the current usages of the constraint functions do not look like they >> were intended for platform-handling, but for >>> Checking validity/sanity of some flag values . >>> >>> >>> Thanks for your comments, Matthias >>> From shade at redhat.com Wed Sep 26 16:11:24 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Sep 2018 18:11:24 +0200 Subject: RFR(S): 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) In-Reply-To: <6D26E4F8-51E0-4171-B644-ED92C5830D82@sap.com> References: <3C71CFD0-3764-464F-A12F-FD71BE44658E@sap.com> <6629adb8-f0d5-1f9d-15b5-3159c67e9c3e@redhat.com> <6D26E4F8-51E0-4171-B644-ED92C5830D82@sap.com> Message-ID: On 09/26/2018 06:08 PM, Schmidt, Lutz wrote: > Hi Aleksey, > > you got me! I forgot to mention this one, sorry! With -Werror=switch, the compiler complains about line 131 in cpu/s390/assembler_s390.cpp: > > case bcondNotHigh + bcondNotOrdered : inverse_cc = bcondHigh; break; // 13 > > The resulting case label was not declared in the enum Assembler::branch_condition. Sneaky. Dear God. Can we please use the new enum constant in those case labels then? This would be a fun source of bugs otherwise if "bcondNotHigh + bcondNotOrdered" carries over some bits :) -Aleksey From shade at redhat.com Wed Sep 26 16:13:00 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Sep 2018 18:13:00 +0200 Subject: AllocateHeapAt disabling on AIX In-Reply-To: <49965314-df9e-8acf-e5c3-cba98ac2e162@oracle.com> References: <49965314-df9e-8acf-e5c3-cba98ac2e162@oracle.com> Message-ID: <5a12f49a-fbcd-8c77-b88d-78f3df835c13@redhat.com> On 09/26/2018 06:09 PM, David Holmes wrote: > On 26/09/2018 12:02 PM, Baesken, Matthias wrote: >> Hi David,? I would like to? print something like? "AllocateHeapAt? not supported on AIX" . >> And then exit?? (probably just ignoring the flag and printing the message might be bad ). >> >> The constraint functions were suggested to me as an option but? it looks to me they are >> Intended for other use cases . > > Yes, I think a check in argument.cpp would be better. There is already a similar block there at L3848: #if defined(_ALLBSD_SOURCE) || defined(AIX) // UseLargePages is not yet supported on BSD and AIX. UNSUPPORTED_OPTION(UseLargePages); #endif ...I think you can add the AllocateHeapAt check nearby, Matthias. -Aleksey From matthias.baesken at sap.com Wed Sep 26 16:14:24 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 26 Sep 2018 16:14:24 +0000 Subject: AllocateHeapAt disabling on AIX In-Reply-To: <5a12f49a-fbcd-8c77-b88d-78f3df835c13@redhat.com> References: <49965314-df9e-8acf-e5c3-cba98ac2e162@oracle.com> <5a12f49a-fbcd-8c77-b88d-78f3df835c13@redhat.com> Message-ID: Hi Aleksey and David , sounds like a good idea. Thanks for your input ! > -----Original Message----- > From: Aleksey Shipilev > Sent: Mittwoch, 26. September 2018 18:13 > To: David Holmes ; Baesken, Matthias > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: Re: AllocateHeapAt disabling on AIX > > On 09/26/2018 06:09 PM, David Holmes wrote: > > On 26/09/2018 12:02 PM, Baesken, Matthias wrote: > >> Hi David,? I would like to? print something like? "AllocateHeapAt? not > supported on AIX" . > >> And then exit?? (probably just ignoring the flag and printing the message > might be bad ). > >> > >> The constraint functions were suggested to me as an option but? it looks > to me they are > >> Intended for other use cases . > > > > Yes, I think a check in argument.cpp would be better. > > There is already a similar block there at L3848: > > #if defined(_ALLBSD_SOURCE) || defined(AIX) // UseLargePages is not yet > supported on BSD and AIX. > UNSUPPORTED_OPTION(UseLargePages); > #endif > > ...I think you can add the AllocateHeapAt check nearby, Matthias. > > -Aleksey From lutz.schmidt at sap.com Wed Sep 26 16:21:41 2018 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 26 Sep 2018 16:21:41 +0000 Subject: RFR(S): 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) In-Reply-To: References: <3C71CFD0-3764-464F-A12F-FD71BE44658E@sap.com> <6629adb8-f0d5-1f9d-15b5-3159c67e9c3e@redhat.com> <6D26E4F8-51E0-4171-B644-ED92C5830D82@sap.com> Message-ID: <1D9C7321-3E84-40AB-87CD-1BA6012B768C@sap.com> ?On 26.09.18, 18:11, "Aleksey Shipilev" wrote: On 09/26/2018 06:08 PM, Schmidt, Lutz wrote: > Hi Aleksey, > > you got me! I forgot to mention this one, sorry! With -Werror=switch, the compiler complains about line 131 in cpu/s390/assembler_s390.cpp: > > case bcondNotHigh + bcondNotOrdered : inverse_cc = bcondHigh; break; // 13 > > The resulting case label was not declared in the enum Assembler::branch_condition. Sneaky. Dear God. Can we please use the new enum constant in those case labels then? This would be a fun source of bugs otherwise if "bcondNotHigh + bcondNotOrdered" carries over some bits :) Sure. I will provide a new webrev first thing Thursday morning. Need to rush out now... Thanks, Lutz -Aleksey From rkennke at redhat.com Wed Sep 26 17:26:29 2018 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 26 Sep 2018 19:26:29 +0200 Subject: RFR: JDK-8211129: compiler/whitebox/ForceNMethodSweepTest.java fails after JDK-8132849 In-Reply-To: References: Message-ID: Ping! This fixes two failing tests... (also changed subject to remove [Testbug]) Thanks, Roman Am 26.09.18 um 10:30 schrieb Roman Kennke: > Please review the following change: > > Several tests fail because after forcing nmethod sweep via Whitebox API, > the sweeper doesn't actually kick in. > > The reason is the changed heuristic in NMethodSweeper: before > JDK-8132849, we would scan stacks and mark nmethods at every safepoint, > during safepoint cleanup phase. This would subsequently trigger a sweep > cycle via _should_sweep. If no stack-scanning is performed, the sweeper > would skip sweeping because the CompiledMethodIterator _current has not > been reset. > > I propose to change the following: > > - In the sweep-loop, call into do_stack_scanning() whenever it's forced > (via WhiteBox API) or if should_sweep has been determined by other > heuristics (code-cache-change, time-since-last-sweep,..) > > - Instead let do_stack_scanning() not set _should_sweep anymore. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211129 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8211129/webrev.00/ > > Testing: Fixes previously failing: > compiler/whitebox/ForceNMethodSweepTest.java > jdk/jfr/event/compiler/TestCodeSweeperStats.java > > Passes: hotspot/jtreg:tier1 > From coleen.phillimore at oracle.com Wed Sep 26 18:23:41 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 26 Sep 2018 14:23:41 -0400 Subject: RFR 8210856: Move InstanceKlass DependencyContext cleaning to SystemDictionary::do_unloading() In-Reply-To: <47006357-6932-e65b-f234-cb4989635163@oracle.com> References: <48247e1b-bb84-5508-7393-f286c83b600f@oracle.com> <47006357-6932-e65b-f234-cb4989635163@oracle.com> Message-ID: Thanks Vladimir, Coleen On 9/26/18 10:38 AM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 21/09/2018 08:45, coleen.phillimore at oracle.com wrote: >> Summary: Already walk classes in ClassLoaderData::unload so >> generalize to also clean nmethod dependencies. >> >> The nmethod dependencies should be cleaned before metadata is purged. >> See bug for more details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8210856.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8210856 >> >> Tested with hs tier1-7, modified gtest, and >> compiler/codecache/stress/RandomAllocationTest.java from bug >> https://bugs.openjdk.java.net/browse/JDK-8143408. >> >> Thanks, >> Coleen >> >> From erik.osterlund at oracle.com Thu Sep 27 01:36:38 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Wed, 26 Sep 2018 21:36:38 -0400 Subject: RFR: JDK-8211129: compiler/whitebox/ForceNMethodSweepTest.java fails after JDK-8132849 In-Reply-To: References: Message-ID: <88708510-05E6-494F-937D-D9B91BB70E11@oracle.com> Hi Roman, Looks reasonable. Thanks, /Erik > On 26 Sep 2018, at 13:26, Roman Kennke wrote: > > Ping! This fixes two failing tests... > > (also changed subject to remove [Testbug]) > > Thanks, > Roman > > >> Am 26.09.18 um 10:30 schrieb Roman Kennke: >> Please review the following change: >> >> Several tests fail because after forcing nmethod sweep via Whitebox API, >> the sweeper doesn't actually kick in. >> >> The reason is the changed heuristic in NMethodSweeper: before >> JDK-8132849, we would scan stacks and mark nmethods at every safepoint, >> during safepoint cleanup phase. This would subsequently trigger a sweep >> cycle via _should_sweep. If no stack-scanning is performed, the sweeper >> would skip sweeping because the CompiledMethodIterator _current has not >> been reset. >> >> I propose to change the following: >> >> - In the sweep-loop, call into do_stack_scanning() whenever it's forced >> (via WhiteBox API) or if should_sweep has been determined by other >> heuristics (code-cache-change, time-since-last-sweep,..) >> >> - Instead let do_stack_scanning() not set _should_sweep anymore. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8211129 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8211129/webrev.00/ >> >> Testing: Fixes previously failing: >> compiler/whitebox/ForceNMethodSweepTest.java >> jdk/jfr/event/compiler/TestCodeSweeperStats.java >> >> Passes: hotspot/jtreg:tier1 >> > From jcbeyler at google.com Thu Sep 27 03:51:26 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 26 Sep 2018 20:51:26 -0700 Subject: RFR (M) 8211036 : Remove the NSK_STUB macros from vmTestbase for non jvmti In-Reply-To: <312465f1-fd55-ea31-ae73-9e464566764b@oracle.com> References: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> <312465f1-fd55-ea31-ae73-9e464566764b@oracle.com> Message-ID: Hi all, Anybody on the hotspot-dev list have any comments or a LGTM? Thanks! Jc On Tue, Sep 25, 2018 at 10:56 AM Alex Menkov wrote: > +1 > > --alex > > On 09/24/2018 11:40, Igor Ignatyev wrote: > > (cc-ing hotspot-dev alias) > > > > Hi Jc, > > > > the fix looks good to me. don't forget to clean up nsk/share/jni/README > at the end. > > > > Thanks, > > -- Igor > > > >> On Sep 24, 2018, at 9:28 AM, JC Beyler wrote: > >> > >> Hi all, > >> > >> As the tests have become C++ tests, the NSK_CPP_STUBS are no longer > needed. I did two awk scripts to remove them and will be rolling them out > in 50 file max reviews to streamline the reviews for the reviewers. > >> > >> So here is the first which handles all the cases outside of the jvmti > subfolder: > >> > >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/ < > http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211036 < > https://bugs.openjdk.java.net/browse/JDK-8211036> > >> > >> The bug contains information on the two scripts I used. > >> > >> Thanks, > >> Jc > > > -- Thanks, Jc From tobias.hartmann at oracle.com Thu Sep 27 09:05:50 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 27 Sep 2018 11:05:50 +0200 Subject: RFR: JDK-8211129: compiler/whitebox/ForceNMethodSweepTest.java fails after JDK-8132849 In-Reply-To: References: Message-ID: Hi Roman, this looks reasonable to me as well. Please verify that all failing tests now pass (TestCodeSweeperStats.java, ForceNMethodSweepTest.java). Thanks, Tobias On 26.09.2018 19:26, Roman Kennke wrote: > Ping! This fixes two failing tests... > > (also changed subject to remove [Testbug]) > > Thanks, > Roman > > > Am 26.09.18 um 10:30 schrieb Roman Kennke: >> Please review the following change: >> >> Several tests fail because after forcing nmethod sweep via Whitebox API, >> the sweeper doesn't actually kick in. >> >> The reason is the changed heuristic in NMethodSweeper: before >> JDK-8132849, we would scan stacks and mark nmethods at every safepoint, >> during safepoint cleanup phase. This would subsequently trigger a sweep >> cycle via _should_sweep. If no stack-scanning is performed, the sweeper >> would skip sweeping because the CompiledMethodIterator _current has not >> been reset. >> >> I propose to change the following: >> >> - In the sweep-loop, call into do_stack_scanning() whenever it's forced >> (via WhiteBox API) or if should_sweep has been determined by other >> heuristics (code-cache-change, time-since-last-sweep,..) >> >> - Instead let do_stack_scanning() not set _should_sweep anymore. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8211129 >> Webrev: >> http://cr.openjdk.java.net/~rkennke/JDK-8211129/webrev.00/ >> >> Testing: Fixes previously failing: >> compiler/whitebox/ForceNMethodSweepTest.java >> jdk/jfr/event/compiler/TestCodeSweeperStats.java >> >> Passes: hotspot/jtreg:tier1 >> > From rkennke at redhat.com Thu Sep 27 09:07:08 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 27 Sep 2018 11:07:08 +0200 Subject: RFR: JDK-8211129: compiler/whitebox/ForceNMethodSweepTest.java fails after JDK-8132849 In-Reply-To: References: Message-ID: Hi Tobias and Erik, the two tests pass now. I'm submitting it to jdk/submit and will push if it comes back clean. Thanks, Roman Am 27.09.18 um 11:05 schrieb Tobias Hartmann: > Hi Roman, > > this looks reasonable to me as well. Please verify that all failing tests now pass > (TestCodeSweeperStats.java, ForceNMethodSweepTest.java). > > Thanks, > Tobias > > On 26.09.2018 19:26, Roman Kennke wrote: >> Ping! This fixes two failing tests... >> >> (also changed subject to remove [Testbug]) >> >> Thanks, >> Roman >> >> >> Am 26.09.18 um 10:30 schrieb Roman Kennke: >>> Please review the following change: >>> >>> Several tests fail because after forcing nmethod sweep via Whitebox API, >>> the sweeper doesn't actually kick in. >>> >>> The reason is the changed heuristic in NMethodSweeper: before >>> JDK-8132849, we would scan stacks and mark nmethods at every safepoint, >>> during safepoint cleanup phase. This would subsequently trigger a sweep >>> cycle via _should_sweep. If no stack-scanning is performed, the sweeper >>> would skip sweeping because the CompiledMethodIterator _current has not >>> been reset. >>> >>> I propose to change the following: >>> >>> - In the sweep-loop, call into do_stack_scanning() whenever it's forced >>> (via WhiteBox API) or if should_sweep has been determined by other >>> heuristics (code-cache-change, time-since-last-sweep,..) >>> >>> - Instead let do_stack_scanning() not set _should_sweep anymore. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8211129 >>> Webrev: >>> http://cr.openjdk.java.net/~rkennke/JDK-8211129/webrev.00/ >>> >>> Testing: Fixes previously failing: >>> compiler/whitebox/ForceNMethodSweepTest.java >>> jdk/jfr/event/compiler/TestCodeSweeperStats.java >>> >>> Passes: hotspot/jtreg:tier1 >>> >> From lutz.schmidt at sap.com Thu Sep 27 10:08:52 2018 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 27 Sep 2018 10:08:52 +0000 Subject: RFR(S): 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) In-Reply-To: <1D9C7321-3E84-40AB-87CD-1BA6012B768C@sap.com> References: <3C71CFD0-3764-464F-A12F-FD71BE44658E@sap.com> <6629adb8-f0d5-1f9d-15b5-3159c67e9c3e@redhat.com> <6D26E4F8-51E0-4171-B644-ED92C5830D82@sap.com> <1D9C7321-3E84-40AB-87CD-1BA6012B768C@sap.com> Message-ID: Hi Aleksey & All, I have changed the "sneaky" code such that it now looks more "enterprise grade". Please find an updated webrev at Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8211145.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211145 Thanks, Lutz ?On 26.09.18, 18:21, "Schmidt, Lutz" wrote: On 26.09.18, 18:11, "Aleksey Shipilev" wrote: On 09/26/2018 06:08 PM, Schmidt, Lutz wrote: > Hi Aleksey, > > you got me! I forgot to mention this one, sorry! With -Werror=switch, the compiler complains about line 131 in cpu/s390/assembler_s390.cpp: > > case bcondNotHigh + bcondNotOrdered : inverse_cc = bcondHigh; break; // 13 > > The resulting case label was not declared in the enum Assembler::branch_condition. Sneaky. Dear God. Can we please use the new enum constant in those case labels then? This would be a fun source of bugs otherwise if "bcondNotHigh + bcondNotOrdered" carries over some bits :) Sure. I will provide a new webrev first thing Thursday morning. Need to rush out now... Thanks, Lutz -Aleksey From shade at redhat.com Thu Sep 27 10:17:57 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Sep 2018 12:17:57 +0200 Subject: RFR(S): 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) In-Reply-To: References: <3C71CFD0-3764-464F-A12F-FD71BE44658E@sap.com> <6629adb8-f0d5-1f9d-15b5-3159c67e9c3e@redhat.com> <6D26E4F8-51E0-4171-B644-ED92C5830D82@sap.com> <1D9C7321-3E84-40AB-87CD-1BA6012B768C@sap.com> Message-ID: <37f0b889-3d9a-cba1-f51c-76ba56d7d4e2@redhat.com> On 09/27/2018 12:08 PM, Schmidt, Lutz wrote: > Hi Aleksey & All, > > I have changed the "sneaky" code such that it now looks more "enterprise grade". Please find an updated webrev at > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8211145.01/ Looks much better, thanks. Should the switches over BasicType in sharedRuntime_s390.cpp be defaulted to ShouldNotReachHere(), like they are in sharedRuntime_ppc.cpp? -Aleksey From aleksei.voitylov at bell-sw.com Thu Sep 27 11:20:30 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 27 Sep 2018 14:20:30 +0300 Subject: RFR(S): 8211212: ARM: -Werror=switch build failure Message-ID: <22accb8e-29eb-d022-0642-e09cce38c396@bell-sw.com> Hi, it's ARM32 port turn. Please review the following fix for -Werror=switch build failure. webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8211212.01/ issue: https://bugs.openjdk.java.net/browse/JDK-8211212 Thanks, -Aleksei From matthias.baesken at sap.com Thu Sep 27 12:12:42 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 27 Sep 2018 12:12:42 +0000 Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 Message-ID: Hello , please review this small change that fixes our AIX build after ?8196341: Add JFR events for parallel phases of G1? was pushed . After 8196341 , compile errors occurred, example : /openjdk/nb/rs6000_64/nightly/jdk/src/hotspot/share/gc/g1/g1CollectedHeap.cpp", line 3185.15: 1540-0215 (S) The wrong number of arguments has been specified for "JfrEvent::commit()" ? This seems to be an xlc compiler bug to me. The overloaded commit function is not resolved correctly, The xlc-compiler seems to notice only the commit without arguments , which is brought into the EventGCPhaseParallel via ?using? . The 3-parameter commit is not taken ? . The fix replaces the currently used commit-calls by set* + commit() . Seems it is done the same way at most (all?) places in hs code . Webrev/bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8211213.0/ https://bugs.openjdk.java.net/browse/JDK-8211213 Thanks, Matthias From shade at redhat.com Thu Sep 27 12:47:10 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Sep 2018 14:47:10 +0200 Subject: RFR(S): 8211212: ARM: -Werror=switch build failure In-Reply-To: <22accb8e-29eb-d022-0642-e09cce38c396@bell-sw.com> References: <22accb8e-29eb-d022-0642-e09cce38c396@bell-sw.com> Message-ID: <1db4ee72-88d0-a92d-99b1-0fdffe94bf79@redhat.com> On 09/27/2018 01:20 PM, Aleksei Voitylov wrote: > it's ARM32 port turn. Please review the following fix for -Werror=switch build failure. > > webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8211212.01/ > issue: https://bugs.openjdk.java.net/browse/JDK-8211212 Looks good! That is what AArch64 did. -Aleksey From magnus.ihse.bursie at oracle.com Thu Sep 27 12:47:13 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 27 Sep 2018 14:47:13 +0200 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> References: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> Message-ID: <07a8f2ff-aefb-be70-8002-c12a37d30b90@oracle.com> Anyone from Hotspot who can review the code changes? /Magnus On 2018-09-24 22:31, Magnus Ihse Bursie wrote: > The -Wextra option to gcc enables a bunch of useful warnings.[1] Some > of them, but not all, can be individually enabled or disabled. All > other libraries in OpenJDK are compiled with -Wextra, but not Hotspot. > Enabling -Wextra on Hotspot triggers a couple of warnings for zero > that can be individually disabled. > > However, -Wextra also includes some check that cannot be disabled > individually, so to be able to add this, we must at the same time fix > those warnings. > > The warnings that cannot be disabled and which have been triggered in > Hotspot is "enumeral and non-enumeral type in conditional expression" > and "base class should be explicitly initialized in the copy > constructor". The former complains about mixing enums and integers in > the tertiary operator (x ? enum_val : int_val). If you think that gcc > is a bit too picky here, I agree. It's not obvious per se that the > added casts improve the code. However, this is the price we need to > pay to be able to enable -Wextra, and *that* is something that is > likely to improve the code. > > The second warning about the copy constructor is, for what I can tell, > a highly valid warning and the code it warned on was indeed broken. As > far as I can tell, in a derived copy constructor you should always > explicitly initialize the base class. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8211073-remove-Wno-extra-from-hotspot/webrev.01 > > /Magnus > > [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html > From david.holmes at oracle.com Thu Sep 27 13:00:13 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Sep 2018 09:00:13 -0400 Subject: RFR (M) 8211036 : Remove the NSK_STUB macros from vmTestbase for non jvmti In-Reply-To: References: <536E34B7-E247-4664-83E5-C6D9A1512D2E@oracle.com> <312465f1-fd55-ea31-ae73-9e464566764b@oracle.com> Message-ID: LGTM :) Thanks, David On 26/09/2018 11:51 PM, JC Beyler wrote: > Hi all, > > Anybody on the hotspot-dev list have any comments or a LGTM? > > Thanks! > Jc > > On Tue, Sep 25, 2018 at 10:56 AM Alex Menkov > wrote: > >> +1 >> >> --alex >> >> On 09/24/2018 11:40, Igor Ignatyev wrote: >>> (cc-ing hotspot-dev alias) >>> >>> Hi Jc, >>> >>> the fix looks good to me. don't forget to clean up nsk/share/jni/README >> at the end. >>> >>> Thanks, >>> -- Igor >>> >>>> On Sep 24, 2018, at 9:28 AM, JC Beyler wrote: >>>> >>>> Hi all, >>>> >>>> As the tests have become C++ tests, the NSK_CPP_STUBS are no longer >> needed. I did two awk scripts to remove them and will be rolling them out >> in 50 file max reviews to streamline the reviews for the reviewers. >>>> >>>> So here is the first which handles all the cases outside of the jvmti >> subfolder: >>>> >>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/ < >> http://cr.openjdk.java.net/~jcbeyler/8211036/webrev.00/> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211036 < >> https://bugs.openjdk.java.net/browse/JDK-8211036> >>>> >>>> The bug contains information on the two scripts I used. >>>> >>>> Thanks, >>>> Jc >>> >> > > From david.holmes at oracle.com Thu Sep 27 13:01:43 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Sep 2018 09:01:43 -0400 Subject: RFR (M): 8188764: Obsolete AssumeMP and then remove all support for non-MP builds In-Reply-To: <321a4c56-dba1-2028-4920-257e542dc83c@oracle.com> References: <167caf7d-a6b8-e230-d2cf-ee7470780725@bell-sw.com> <25a98e2e-2523-d221-429a-4284938082a9@oracle.com> <321a4c56-dba1-2028-4920-257e542dc83c@oracle.com> Message-ID: Webrev was updated in place. Second occurrence was renamed. Thanks, David On 26/09/2018 9:49 AM, David Holmes wrote: > Thanks Boris, I'll fix the label problem. > > I'm travelling at the moment so won't push till later next week. > Hopefully you'll have access to the hardware by then. > > Thanks, > David > > On 26/09/2018 9:47 AM, Boris Ulasevich wrote: >> Hi David, >> >> ?? For this change the most interesting would be to check it with >> ARMv5, but I do not have the hardware now. I hope I will get one ARMv5 >> machine next week. >> >> ?? For ARMv7 the change is Ok. Almost Ok. There is a minor build issue: >> >> /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp:3724:9: >> error: redeclaration of ?Label notVolatile? >> ??? Label notVolatile; >> ????????? ^~~~~~~~~~~ >> /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp:3492:9: >> note: ?Label notVolatile? previously declared here >> ??? Label notVolatile; >> ????????? ^~~~~~~~~~~ >> /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp: In >> static member function ?static void >> TemplateTable::fast_storefield(TosState)?: >> /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp:3885:9: >> error: redeclaration of ?Label notVolatile? >> ??? Label notVolatile; >> ????????? ^~~~~~~~~~~ >> /home/boris/jdk-jdk/src/hotspot/cpu/arm/templateTable_arm.cpp:3832:9: >> note: ?Label notVolatile? previously declared here >> ??? Label notVolatile; >> ????????? ^~~~~~~~~~~ >> >> regards, >> Boris >> >> On 23.09.2018 19:26, David Holmes wrote: >>> Hi Boris, >>> >>> Here is latest webrev with the ARM code updated as well. >>> >>> http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>> >>> All is_MP removed except where needed for ARMv5 support, MP specific >>> instructions, and controlling of biased locking. >>> >>> I checked the DMB variants and we only generate for ARMv7 anyway, so >>> no issue there. >>> >>> Would very much appreciate whatever test builds you can do on >>> different ARM variants Boris! >>> >>> Thanks, >>> David >>> >>> On 21/09/2018 9:41 AM, David Holmes wrote: >>>> Hi Boris, >>>> >>>> On 21/09/2018 9:34 AM, Boris Ulasevich wrote: >>>>> Hi David, >>>>> >>>>> On 20.09.2018 18:26, David Holmes wrote: >>>>>> Hi Boris, >>>>>> >>>>>> Thanks for jumping on this. I hope you didn't spend too much time >>>>>> on it as I had actually started on the ARM code then decided I >>>>>> didn't need to make the changes, so I'd already gone through >>>>>> pretty much everything that is needed. My concern is with things >>>>>> like the change in >>>>>> >>>>>> src/hotspot/cpu/arm/assembler_arm_32.hpp >>>>>> >>>>>> where you removed the is_MP() check but in fact that needs to >>>>>> remain because the instruction pldw is not present on variants of >>>>>> the v7 architecture without the multi-processor extensions: >>>>> >>>>> Ok. Good point. Sure, my hasty proposal to get rid of is_MP() check >>>>> in arm32 codes was wrong. >>>>> >>>>> One note. I see there is an ambiguity here: is_MP() is a >>>>> multiprocessor system flag (returns true when _processor_count != >>>>> 1), but multi-processor extensions is an optional ARMv7 feature >>>>> which is not related with processors count, so pldw usage should >>>>> not be controlled by is_MP() flag. >>>> >>>> is_MP can't return true unless there is more than one processor >>>> (ignoring the pre-initialization case), so if there's more than one >>>> processor there must be a MP supprting architecture. >>>> >>>>>> http://www.keil.com/support/man/docs/armclang_asm/armclang_asm_pge1425899018492.htm >>>>>> >>>>>> That makes me wonder whether any of the memory barrier >>>>>> instructions may also be missing in some v6/v7 variants as well? >>>>> >>>>> Nobody complained :) And Reference Manual says DMB/DSB are not >>>>> optional. >>>> >>>> I need to double-check we don't define variants like "dmb sy" that >>>> are architecture specific. >>>> >>>>>> Plus I have to account for uniprocessor ARMv5 so need to see >>>>>> whether MacroAssembler::membar, for example, must also retain the >>>>>> is_MP() check. >>>>> >>>>> Do you want to delete this check? Processor count check seems quite >>>>> natural to see if it has sense to generate memory barriers. >>>> >>>> That is the general thrust of this change. We assume we always have >>>> MP and so always issue memory barriers. >>>> >>>>> By the way, MacroAssembler::fast_lock have >>>>> VM_Version::supports_ldrex() check assertion with message >>>>> "unsupported, yet?". Looks like it is not going to work correctly >>>>> on multiprocessor ARMv5. >>>> >>>> The ARM code does not support multiprocessor ARMv5. >>>> >>>> Thanks, >>>> David >>>> >>>>>> Also in: >>>>>> >>>>>> src/hotspot/cpu/arm/stubGenerator_arm.cpp >>>>>> >>>>>> you can't remove the !is_MP() check and related code as that is >>>>>> needed for ARMv5 (uniprocessor) support. >>>>>> >>>>>> Similarly in >>>>>> >>>>>> src/hotspot/cpu/arm/vm_version_arm_32.cpp >>>>>> >>>>>> you'll probably still want to disable biased-locking for ARMv5. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>> On 20/09/2018 3:31 AM, Boris Ulasevich wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> ?> I have not updated the about-to-be-removed Oracle ARM port code. >>>>>>> >>>>>>> Ok, but we can do the changes in ARM32 codes leaving ARM64 intact. >>>>>>> I would propose the following change - I think we can either add >>>>>>> it to your update or to create a separate RFR after your patch >>>>>>> and JEP-340 commit: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~bulasevich/8188764/webrev.00/ >>>>>>> >>>>>>> regards, >>>>>>> Boris >>>>>>> >>>>>>> On 18.09.2018 08:32, David Holmes wrote: >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8188764 >>>>>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8188764/webrev/ >>>>>>>> >>>>>>>> As previously discussed in the RFC thread: >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-September/034166.html >>>>>>>> >>>>>>>> >>>>>>>> this change obsoletes the AssumeMP flag and removes the bulk of >>>>>>>> the logic that is conditional on os::is_MP() as follows: >>>>>>>> >>>>>>>> 1. to gate the introduction of MP-specific features, notably >>>>>>>> memory barriers >>>>>>>> >>>>>>>> The is_MP check is removed and we will always issue memory barriers >>>>>>>> or pre-pend lock prefix etc. >>>>>>>> >>>>>>>> 2. to align certain patchable code sequences (method entry, call >>>>>>>> sites) >>>>>>>> >>>>>>>> The is_MP is removed and we always align patchable locations. >>>>>>>> >>>>>>>> 3. to gate certain optimizations which are questionable on >>>>>>>> uniprocessors >>>>>>>> (see quicken_jni_functions) >>>>>>>> >>>>>>>> These are psuedo-memory-barriers where we manufacture a >>>>>>>> data-dependency >>>>>>>> instead of inserting mfence/lfence (x86 example). These are >>>>>>>> treated as >>>>>>>> #1 and is_MP is removed. >>>>>>>> >>>>>>>> 4. to gate optimizations which are desirable on uniprocessors >>>>>>>> (mutex/monitor short circuits) >>>>>>>> >>>>>>>> These are spin controls and so is_MP remains. >>>>>>>> >>>>>>>> I have not updated the about-to-be-removed Oracle ARM port code. >>>>>>>> >>>>>>>> Testing: >>>>>>>> ?? - Tiers 1 -3 (mach5) >>>>>>>> >>>>>>>> Performance run TBD. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David From matthias.baesken at sap.com Thu Sep 27 14:16:40 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 27 Sep 2018 14:16:40 +0000 Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 In-Reply-To: References: Message-ID: Small update - while my change fixes the build issues on AIX (and maybe also the issues on zero) , My comment that the AIX compiler xlc12 is guilty was most likely wrong . What happens, is that INCLUDE_JFR is not set on AIX (means : jfr is disabled on this platform). However , in the generated file jfrEventClasses.hpp , We have different classes for the cases INCLUDE_JFR and not INCLUDE_JFR . The not INCLUDE_JFR - versions of the classes only have the commit() method without params , and the set*-methods : See : jfrEventClasses.hpp #else // !INCLUDE_JFR class JfrEvent { public: JfrEvent() {} void set_starttime(const Ticks&) const {} void set_endtime(const Ticks&) const {} bool should_commit() const { return false; } static bool is_enabled() { return false; } void commit() {} }; and class EventGCPhaseParallel : public JfrEvent { public: EventGCPhaseParallel(EventStartTime ignore=TIMED) {} EventGCPhaseParallel( unsigned, unsigned, const char*) { } void set_gcId(unsigned) { } void set_gcWorkerId(unsigned) { } void set_name(const char*) { } }; Probably that?s why in the hs-code commit is used usually in the way of set*-calls + commit() , which works on both platforms with and without JFR . Questions : * Should the generator be changed to generate the missing methods in both cases ? * Or should in non-JFR case the complete event coding be removed/guarded by macros ? Best regards, Matthias From: Baesken, Matthias Sent: Donnerstag, 27. September 2018 14:13 To: 'hotspot-dev at openjdk.java.net' ; 'build-dev at openjdk.java.net' Cc: 'Leo Korinth' Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 Hello , please review this small change that fixes our AIX build after ?8196341: Add JFR events for parallel phases of G1? was pushed . After 8196341 , compile errors occurred, example : /openjdk/nb/rs6000_64/nightly/jdk/src/hotspot/share/gc/g1/g1CollectedHeap.cpp", line 3185.15: 1540-0215 (S) The wrong number of arguments has been specified for "JfrEvent::commit()" ? This seems to be an xlc compiler bug to me. The overloaded commit function is not resolved correctly, The xlc-compiler seems to notice only the commit without arguments , which is brought into the EventGCPhaseParallel via ?using? . The 3-parameter commit is not taken ? . The fix replaces the currently used commit-calls by set* + commit() . Seems it is done the same way at most (all?) places in hs code . Webrev/bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8211213.0/ https://bugs.openjdk.java.net/browse/JDK-8211213 Thanks, Matthias From lutz.schmidt at sap.com Thu Sep 27 14:28:25 2018 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 27 Sep 2018 14:28:25 +0000 Subject: RFR(S): 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) In-Reply-To: <37f0b889-3d9a-cba1-f51c-76ba56d7d4e2@redhat.com> References: <3C71CFD0-3764-464F-A12F-FD71BE44658E@sap.com> <6629adb8-f0d5-1f9d-15b5-3159c67e9c3e@redhat.com> <6D26E4F8-51E0-4171-B644-ED92C5830D82@sap.com> <1D9C7321-3E84-40AB-87CD-1BA6012B768C@sap.com> <37f0b889-3d9a-cba1-f51c-76ba56d7d4e2@redhat.com> Message-ID: Hi Aleksey, re break vs. ShouldNotReachHere(), I tried to change semantics as little as possible. After discussion with colleagues, we concluded that ShouldNotReachHere() is the better choice. Code was modified accordingly. Your concerns re. coding style are reflected in the new webrev as well. It can be found here: http://cr.openjdk.java.net/~lucy/webrevs/8211145.02/ Regards, Lutz ?On 27.09.18, 12:17, "Aleksey Shipilev" wrote: On 09/27/2018 12:08 PM, Schmidt, Lutz wrote: > Hi Aleksey & All, > > I have changed the "sneaky" code such that it now looks more "enterprise grade". Please find an updated webrev at > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8211145.01/ Looks much better, thanks. Should the switches over BasicType in sharedRuntime_s390.cpp be defaulted to ShouldNotReachHere(), like they are in sharedRuntime_ppc.cpp? -Aleksey From david.holmes at oracle.com Thu Sep 27 14:31:39 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 27 Sep 2018 10:31:39 -0400 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <07a8f2ff-aefb-be70-8002-c12a37d30b90@oracle.com> References: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> <07a8f2ff-aefb-be70-8002-c12a37d30b90@oracle.com> Message-ID: Hi Magnus, On 27/09/2018 8:47 AM, Magnus Ihse Bursie wrote: > Anyone from Hotspot who can review the code changes? I had looked at this but it is unclear whether the casts are the right fix or whether we have a poor type selection in the first place. For example, ./share/opto/node.hpp: enum { NO_HASH = 0 }; defines NO_HASH which is implicitly treated as int but then it's used everywhere as uint - which just seems odd. So I'm unclear whether this needs more indepth examination by the various code owners. Thanks, David > /Magnus > > On 2018-09-24 22:31, Magnus Ihse Bursie wrote: >> The -Wextra option to gcc enables a bunch of useful warnings.[1] Some >> of them, but not all, can be individually enabled or disabled. All >> other libraries in OpenJDK are compiled with -Wextra, but not Hotspot. >> Enabling -Wextra on Hotspot triggers a couple of warnings for zero >> that can be individually disabled. >> >> However, -Wextra also includes some check that cannot be disabled >> individually, so to be able to add this, we must at the same time fix >> those warnings. >> >> The warnings that cannot be disabled and which have been triggered in >> Hotspot is "enumeral and non-enumeral type in conditional expression" >> and "base class should be explicitly initialized in the copy >> constructor". The former complains about mixing enums and integers in >> the tertiary operator (x ? enum_val : int_val). If you think that gcc >> is a bit too picky here, I agree. It's not obvious per se that the >> added casts improve the code. However, this is the price we need to >> pay to be able to enable -Wextra, and *that* is something that is >> likely to improve the code. >> >> The second warning about the copy constructor is, for what I can tell, >> a highly valid warning and the code it warned on was indeed broken. As >> far as I can tell, in a derived copy constructor you should always >> explicitly initialize the base class. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8211073-remove-Wno-extra-from-hotspot/webrev.01 >> >> >> /Magnus >> >> [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html >> > From thomas.schatzl at oracle.com Thu Sep 27 14:32:10 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 27 Sep 2018 16:32:10 +0200 Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 In-Reply-To: References: Message-ID: <8de12bb64e19e067b8c914f03aca759e91da8188.camel@oracle.com> Hi, On Thu, 2018-09-27 at 14:16 +0000, Baesken, Matthias wrote: > Small update - while my change fixes the build issues on > AIX (and maybe also the issues on zero) , > My comment that the AIX compiler xlc12 is guilty was most likely > wrong . > > What happens, is that INCLUDE_JFR is not set on AIX (means : > jfr is disabled on this platform). > However , in the generated file jfrEventClasses.hpp , > We have different classes for the > cases INCLUDE_JFR and not INCLUDE_JFR . > > The not INCLUDE_JFR - versions of the classes only have the > commit() method without params , and the set*-methods : > > [...] > > * Should the generator be changed to generate the missing > methods in both cases ? > * Or should in non-JFR case the complete event coding be > removed/guarded by macros ? I would prefer the former as the latter just adds more clutter, i.e. ifdefs. Thanks, Thomas From matthias.baesken at sap.com Thu Sep 27 14:39:56 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 27 Sep 2018 14:39:56 +0000 Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 In-Reply-To: <8de12bb64e19e067b8c914f03aca759e91da8188.camel@oracle.com> References: <8de12bb64e19e067b8c914f03aca759e91da8188.camel@oracle.com> Message-ID: Hi Thomas, do you know some fast and helpful person who can bring the INCLUDE_JFR and ! INCLUDE_JFR cases in sync ? (or maybe there was a reason to have these differences we observe ? ) Best regards, Matthias > -----Original Message----- > From: Thomas Schatzl > Sent: Donnerstag, 27. September 2018 16:32 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; 'build- > dev at openjdk.java.net' > Subject: Re: RFR : 8211213: fix aix build after 8196341: Add JFR events for > parallel phases of G1 > > Hi, > > On Thu, 2018-09-27 at 14:16 +0000, Baesken, Matthias wrote: > > Small update - while my change fixes the build issues on > > AIX (and maybe also the issues on zero) , > > My comment that the AIX compiler xlc12 is guilty was most likely > > wrong . > > > > What happens, is that INCLUDE_JFR is not set on AIX (means : > > jfr is disabled on this platform). > > However , in the generated file jfrEventClasses.hpp , > > We have different classes for the > > cases INCLUDE_JFR and not INCLUDE_JFR . > > > > The not INCLUDE_JFR - versions of the classes only have the > > commit() method without params , and the set*-methods : > > > > [...] > > > > * Should the generator be changed to generate the missing > > methods in both cases ? > > * Or should in non-JFR case the complete event coding be > > removed/guarded by macros ? > > I would prefer the former as the latter just adds more clutter, i.e. > ifdefs. > > Thanks, > Thomas From kim.barrett at oracle.com Thu Sep 27 14:55:20 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 27 Sep 2018 10:55:20 -0400 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> References: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> Message-ID: <99ED4415-08D5-433F-B0EB-415EE9C65F82@oracle.com> > On Sep 24, 2018, at 4:31 PM, Magnus Ihse Bursie wrote: > > The -Wextra option to gcc enables a bunch of useful warnings.[1] Some of them, but not all, can be individually enabled or disabled. All other libraries in OpenJDK are compiled with -Wextra, but not Hotspot. Enabling -Wextra on Hotspot triggers a couple of warnings for zero that can be individually disabled. > > However, -Wextra also includes some check that cannot be disabled individually, so to be able to add this, we must at the same time fix those warnings. > > The warnings that cannot be disabled and which have been triggered in Hotspot is "enumeral and non-enumeral type in conditional expression" and "base class should be explicitly initialized in the copy constructor". The former complains about mixing enums and integers in the tertiary operator (x ? enum_val : int_val). If you think that gcc is a bit too picky here, I agree. It's not obvious per se that the added casts improve the code. However, this is the price we need to pay to be able to enable -Wextra, and *that* is something that is likely to improve the code. > > The second warning about the copy constructor is, for what I can tell, a highly valid warning and the code it warned on was indeed broken. As far as I can tell, in a derived copy constructor you should always explicitly initialize the base class. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8211073-remove-Wno-extra-from-hotspot/webrev.01 > > /Magnus > > [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html The last time I looked at -Wextra, there were several warnings that seemed questionable to me. As the set may change between versions (which is itself a potential issue), I took a quick look and -Wempty-body seems quite problematic, -Wshift-negative-value arguably so, and I haven't had time to think about others. I'm somewhat dubious about -Wextra, -Wall, &etc for a project of this size and usage that also uses -Werror. Those umbrella sets change from version to version of the compiler, and the overall project doesn't have tight control over which compiler versions might be used (even though individual organizations, like Oracle, might have specific blessed versions). From aleksei.voitylov at bell-sw.com Thu Sep 27 16:29:17 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 27 Sep 2018 19:29:17 +0300 Subject: RFR(S): 8211212: ARM: -Werror=switch build failure In-Reply-To: <1db4ee72-88d0-a92d-99b1-0fdffe94bf79@redhat.com> References: <22accb8e-29eb-d022-0642-e09cce38c396@bell-sw.com> <1db4ee72-88d0-a92d-99b1-0fdffe94bf79@redhat.com> Message-ID: <10775009-e927-0d79-1bb7-f838148929bd@bell-sw.com> Thank you for review, Aleksey! On 27/09/2018 15:47, Aleksey Shipilev wrote: > On 09/27/2018 01:20 PM, Aleksei Voitylov wrote: >> it's ARM32 port turn. Please review the following fix for -Werror=switch build failure. >> >> webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8211212.01/ >> issue: https://bugs.openjdk.java.net/browse/JDK-8211212 > Looks good! That is what AArch64 did. > > -Aleksey > From shade at redhat.com Thu Sep 27 18:03:19 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Sep 2018 20:03:19 +0200 Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 In-Reply-To: References: <8de12bb64e19e067b8c914f03aca759e91da8188.camel@oracle.com> Message-ID: On 09/27/2018 04:39 PM, Baesken, Matthias wrote: > Hi Thomas, do you know some fast and helpful person who can bring the INCLUDE_JFR and ! INCLUDE_JFR cases in sync ? > (or maybe there was a reason to have these differences we observe ? ) I am not a JFR person, but I think this should do it -- I copied printCommitMethod into printEmptyEvent and gutted it: http://cr.openjdk.java.net/~shade/8211213/webrev.01/ This fixes x86_64 Zero build. -Aleksey From kishor.kharbas at intel.com Thu Sep 27 18:38:13 2018 From: kishor.kharbas at intel.com (Kharbas, Kishor) Date: Thu, 27 Sep 2018 18:38:13 +0000 Subject: AllocateHeapAt disabling on AIX In-Reply-To: References: <49965314-df9e-8acf-e5c3-cba98ac2e162@oracle.com> <5a12f49a-fbcd-8c77-b88d-78f3df835c13@redhat.com> Message-ID: Hi Matthias, May I ask out of curiosity, whether you see any error using or having this option? -Kishor > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Baesken, Matthias > Sent: Wednesday, September 26, 2018 9:14 AM > To: Aleksey Shipilev ; David Holmes > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RE: AllocateHeapAt disabling on AIX > > Hi Aleksey and David , sounds like a good idea. > > Thanks for your input ! > > > -----Original Message----- > > From: Aleksey Shipilev > > Sent: Mittwoch, 26. September 2018 18:13 > > To: David Holmes ; Baesken, Matthias > > ; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net> > > Subject: Re: AllocateHeapAt disabling on AIX > > > > On 09/26/2018 06:09 PM, David Holmes wrote: > > > On 26/09/2018 12:02 PM, Baesken, Matthias wrote: > > >> Hi David,? I would like to? print something like? "AllocateHeapAt > > >> not > > supported on AIX" . > > >> And then exit?? (probably just ignoring the flag and printing the > > >> message > > might be bad ). > > >> > > >> The constraint functions were suggested to me as an option but? it > > >> looks > > to me they are > > >> Intended for other use cases . > > > > > > Yes, I think a check in argument.cpp would be better. > > > > There is already a similar block there at L3848: > > > > #if defined(_ALLBSD_SOURCE) || defined(AIX) // UseLargePages is not > > yet supported on BSD and AIX. > > UNSUPPORTED_OPTION(UseLargePages); > > #endif > > > > ...I think you can add the AllocateHeapAt check nearby, Matthias. > > > > -Aleksey From thomas.schatzl at oracle.com Thu Sep 27 19:01:54 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 27 Sep 2018 21:01:54 +0200 Subject: [PATCH] JDK-8205051 (UseNUMA memory interleaving vs cpunodebind & localalloc) In-Reply-To: References: Message-ID: <5362f42009cb7caddf43444c322410f3ee364112.camel@oracle.com> Hi Roshan, On Tue, 2018-09-25 at 12:18 +0530, roshan mangal wrote: > Hi All, > > This Patch is for https://bugs.openjdk.java.net/browse/JDK-8205051 > > Issue: > > If the JVM isn't allowed to run on all of the nodes (by numactl, > cgroups, docker, etc), then a significant fraction of the Java heap > will be unusable, causing early GC. > > Every Thread captures their locality group(lgrp) and allocates memory > from that lgrp. > > lgrp id is same as NUMA node id. > > Thread running on CPU belongs to NUMA node 0, will capture Thread- > >lgrp as lgrp0 and will allocate memory from NUMA node 0. Once NUMA > node 0 is full, it will trigger GC irrespective of other NUMA node > having memory. > > Solution proposed: > > Create List of NUMA nodes based on distance and allocate memory from > near NUMA node when other closest NUMA node is/are full. > > Below system has eight NUMA nodes and distance table given below. > > node distances: > > node 0 1 2 3 4 5 6 7 > 0: 10 16 16 16 32 32 32 32 > 1: 16 10 16 16 32 32 32 32 > 2: 16 16 10 16 32 32 32 32 > 3: 16 16 16 10 32 32 32 32 > 4: 32 32 32 32 10 16 16 16 > 5: 32 32 32 32 16 10 16 16 > 6: 32 32 32 32 16 16 10 16 > 7: 32 32 32 32 16 16 16 10 > > The corresponding list for each lgrp will be like this. > > Thread's lgrp > Order of Allocation in NUMA node > > lgrp0 [ numaNode0->numaNode1->numaNode2->numaNode3-> > numaNode4->numaNode5->numaNode6->numaNode7 ] > lgrp1 [ numaNode1->numaNode0->numaNode2->numaNode3-> > numaNode4->numaNode5->numaNode6->numaNode7 ] > lgrp2 [ numaNode2->numaNode0->numaNode1->numaNode3-> > numaNode4->numaNode5->numaNode6->numaNode7 ] > lgrp3 [ numaNode3->numaNode0->numaNode1->numaNode2-> > numaNode4->numaNode5->numaNode6->numaNode7 ] > lgrp4 [ numaNode4->numaNode5->numaNode6->numaNode7-> > numaNode0->numaNode1->numaNode2->numaNode3 ] > lgrp5 [ numaNode5->numaNode4->numaNode6->numaNode7-> > numaNode0->numaNode1->numaNode2->numaNode3 ] > lgrp6 [ numaNode6->numaNode4->numaNode5->numaNode7-> > numaNode0->numaNode1->numaNode2->numaNode3 ] > lgrp7 [ numaNode7->numaNode4->numaNode5->numaNode6-> > numaNode0->numaNode1->numaNode2->numaNode3 ] I have a question about this: lgrps often have the same distance from each other, and this order-of-allocation list seems to be deterministic. So in this case nodes with lower lgrp id (but the same distance) are preferred to ones with higher lgrp id. Do you expect some imbalance because of that? If so, couldn't it be useful to randomize lgrps with the same distance in this list, and regularly change them? Long ago I have been implementing some NUMA support for G1 and had that issue (in this case the distribution is a nice lattice with everyone connected by everyone else with two hops), with the above mentioned solution to that "problem". Do you think something like this would make sense (not particularly in this change). > Allocation on NUMA node, which is far from CPU can lead to > performance issue. Sometimes triggering GC is a better option than > allocating from NUMA node at large distance i.e. high memory latency. > > For this, I have added option "NumaAllocationDistanceLimit", which > will restrict memory allocation from the far nodes. > > In above system if we set -XX:NumaAllocationDistanceLimit=16. That makes sense imho, although it is a bit sad that this number is specific to the machine. > > The corresponding list for each lgrp will be like this. > > Thread's lgrp Order of Allocation in NUMA node > lgrp0 [ numaNode0->numaNode1->numaNode2->numaNode3 ] > lgrp1 [ numaNode1->numaNode0->numaNode2->numaNode3 ] > lgrp2 [ numaNode2->numaNode0->numaNode1->numaNode3 ] > lgrp3 [ numaNode3->numaNode0->numaNode1->numaNode2 ] > lgrp4 [ numaNode4->numaNode5->numaNode6->numaNode7 ] > lgrp5 [ numaNode5->numaNode4->numaNode6->numaNode7 ] > lgrp6 [ numaNode6->numaNode4->numaNode5->numaNode7 ] > lgrp7 [ numaNode7->numaNode4->numaNode5->numaNode6 ] > > #################################################### PATCH > ################################ could you send me a patch as webrev so I can put it on cr.openjdk.java.net? (Or maybe sending the patch as attachment helps too). It got mangled by your email program, adding many linebreaks. Thanks, Thomas From leo.korinth at oracle.com Thu Sep 27 19:25:13 2018 From: leo.korinth at oracle.com (Leo Korinth) Date: Thu, 27 Sep 2018 21:25:13 +0200 Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 In-Reply-To: References: <8de12bb64e19e067b8c914f03aca759e91da8188.camel@oracle.com> Message-ID: <9929a9f2-cff6-ffee-f345-3c9431275fee@oracle.com> Hi! This is no review. I did something similar (http://cr.openjdk.java.net/~lkorinth/8211213/00/) to you Aleksey before I noticed your solution. I prefer your version to my own as your version makes the JFR disabled class closer to the JFR enabled one (with regards to templates). I was more conservative (and did it a bit different). I do not know the reason for this template difference, nor the difference with regards to the protected constructor and non-argument commit that also differ and is public in the JFR disabled class. I guess these differences are by mistake, but maybe it would be good if it was confirmed by the JFR people. Thanks, Leo On 27/09/18 20:03, Aleksey Shipilev wrote: > On 09/27/2018 04:39 PM, Baesken, Matthias wrote: >> Hi Thomas, do you know some fast and helpful person who can bring the INCLUDE_JFR and ! INCLUDE_JFR cases in sync ? >> (or maybe there was a reason to have these differences we observe ? ) > > I am not a JFR person, but I think this should do it -- I copied printCommitMethod into > printEmptyEvent and gutted it: > http://cr.openjdk.java.net/~shade/8211213/webrev.01/ > > This fixes x86_64 Zero build. > > -Aleksey > From shade at redhat.com Thu Sep 27 19:48:38 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Sep 2018 21:48:38 +0200 Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 In-Reply-To: <9929a9f2-cff6-ffee-f345-3c9431275fee@oracle.com> References: <8de12bb64e19e067b8c914f03aca759e91da8188.camel@oracle.com> <9929a9f2-cff6-ffee-f345-3c9431275fee@oracle.com> Message-ID: On 09/27/2018 09:25 PM, Leo Korinth wrote: > I guess these differences are by mistake, but maybe it would be good if it was confirmed by the JFR > people. Yes, I submitted: https://bugs.openjdk.java.net/browse/JDK-8211239 and linked your patch there. -Aleksey From rkennke at redhat.com Thu Sep 27 20:07:19 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 27 Sep 2018 22:07:19 +0200 Subject: RFR: JDK-8211241: Missing obj equals in TemplateTable::fast_aldc Message-ID: TemplateTable::fast_aldc compares the just-loaded reference with Universe::the_null_sentinel. If it really is that null-sentinel, we may get a false negative (with GCs like Shenandoah that allow both from-space and to-space copies of an object to be around), and thus skip NULL-ing the ref. In other words, it would allow to get the-null-sentinel out into the wild as oop which can cause subtle and not-so-subtle bugs. Fix is easy, call cmpoop() which re-routes through GC-interface for GCs that need it: http://cr.openjdk.java.net/~rkennke/JDK-8211241/webrev.00/ Testing: hotspot/jtreg:tier1 Ok? Roman From rkennke at redhat.com Thu Sep 27 20:33:10 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 27 Sep 2018 22:33:10 +0200 Subject: RFR: JDK-8211241: Missing obj equals in TemplateTable::fast_aldc In-Reply-To: References: Message-ID: Included hotspot-runtime-dev because it's an interpreter bug, excluded hotspot-compiler dev, and also here's all the links: Bug: https://bugs.openjdk.java.net/browse/JDK-8211241 Webrev: http://cr.openjdk.java.net/~rkennke/JDK-8211241/webrev.00/ It's never been quite clear to me where to put interpreter bugs. hotspot/runtime in Jira and hotspot-runtime-dev on mailing lists? Is that right? Thanks, Roman > TemplateTable::fast_aldc compares the just-loaded reference with > Universe::the_null_sentinel. If it really is that null-sentinel, we may > get a false negative (with GCs like Shenandoah that allow both > from-space and to-space copies of an object to be around), and thus skip > NULL-ing the ref. In other words, it would allow to get > the-null-sentinel out into the wild as oop which can cause subtle and > not-so-subtle bugs. > > Fix is easy, call cmpoop() which re-routes through GC-interface for GCs > that need it: > > http://cr.openjdk.java.net/~rkennke/JDK-8211241/webrev.00/ > > Testing: hotspot/jtreg:tier1 > > Ok? > > Roman > From daniel.daugherty at oracle.com Thu Sep 27 20:34:05 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 27 Sep 2018 16:34:05 -0400 Subject: RFR: JDK-8211241: Missing obj equals in TemplateTable::fast_aldc In-Reply-To: References: Message-ID: <5492869d-c359-0a72-ebcd-fed24072ccc9@oracle.com> On 9/27/18 4:07 PM, Roman Kennke wrote: > TemplateTable::fast_aldc compares the just-loaded reference with > Universe::the_null_sentinel. If it really is that null-sentinel, we may > get a false negative (with GCs like Shenandoah that allow both > from-space and to-space copies of an object to be around), and thus skip > NULL-ing the ref. In other words, it would allow to get > the-null-sentinel out into the wild as oop which can cause subtle and > not-so-subtle bugs. > > Fix is easy, call cmpoop() which re-routes through GC-interface for GCs > that need it: > > http://cr.openjdk.java.net/~rkennke/JDK-8211241/webrev.00/ src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ??? No comments. src/hotspot/cpu/x86/templateTable_x86.cpp ??? No comments. Thumbs up (on the change)! > Testing: hotspot/jtreg:tier1 Did you use jdk_submit or local testing? I don't expect build problems but the templateTable_x86.cpp will affect all X86/X64 platforms right? Dan > > Ok? > > Roman > From daniel.daugherty at oracle.com Thu Sep 27 20:37:01 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 27 Sep 2018 16:37:01 -0400 Subject: RFR: JDK-8211241: Missing obj equals in TemplateTable::fast_aldc In-Reply-To: References: Message-ID: <438c14ed-c7af-ba4f-636c-5f0132a5d94f@oracle.com> On 9/27/18 4:33 PM, Roman Kennke wrote: > Included hotspot-runtime-dev because it's an interpreter bug, excluded > hotspot-compiler dev, and also here's all the links: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211241 Thanks for adding the direct bug link. > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8211241/webrev.00/ > > It's never been quite clear to me where to put interpreter bugs. > hotspot/runtime in Jira and hotspot-runtime-dev on mailing lists? Is > that right? Yes, the interpreter is owned by the Runtime team. Dan > > Thanks, Roman > > > >> TemplateTable::fast_aldc compares the just-loaded reference with >> Universe::the_null_sentinel. If it really is that null-sentinel, we may >> get a false negative (with GCs like Shenandoah that allow both >> from-space and to-space copies of an object to be around), and thus skip >> NULL-ing the ref. In other words, it would allow to get >> the-null-sentinel out into the wild as oop which can cause subtle and >> not-so-subtle bugs. >> >> Fix is easy, call cmpoop() which re-routes through GC-interface for GCs >> that need it: >> >> http://cr.openjdk.java.net/~rkennke/JDK-8211241/webrev.00/ >> >> Testing: hotspot/jtreg:tier1 >> >> Ok? >> >> Roman >> From rkennke at redhat.com Thu Sep 27 20:37:42 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 27 Sep 2018 22:37:42 +0200 Subject: RFR: JDK-8211241: Missing obj equals in TemplateTable::fast_aldc In-Reply-To: <5492869d-c359-0a72-ebcd-fed24072ccc9@oracle.com> References: <5492869d-c359-0a72-ebcd-fed24072ccc9@oracle.com> Message-ID: <4b57bab3-723a-eedb-5654-5ce893c8573f@redhat.com> > On 9/27/18 4:07 PM, Roman Kennke wrote: >> TemplateTable::fast_aldc compares the just-loaded reference with >> Universe::the_null_sentinel. If it really is that null-sentinel, we may >> get a false negative (with GCs like Shenandoah that allow both >> from-space and to-space copies of an object to be around), and thus skip >> NULL-ing the ref. In other words, it would allow to get >> the-null-sentinel out into the wild as oop which can cause subtle and >> not-so-subtle bugs. >> >> Fix is easy, call cmpoop() which re-routes through GC-interface for GCs >> that need it: >> >> http://cr.openjdk.java.net/~rkennke/JDK-8211241/webrev.00/ > > src/hotspot/cpu/aarch64/templateTable_aarch64.cpp > ??? No comments. > > src/hotspot/cpu/x86/templateTable_x86.cpp > ??? No comments. > > Thumbs up (on the change)! > >> Testing: hotspot/jtreg:tier1 > > Did you use jdk_submit or local testing? I don't expect build > problems but the templateTable_x86.cpp will affect all X86/X64 > platforms right? I tested locally on x86_64 and aarch64. I always push my stuff through jdk/submit before pushing to jdk/jdk, usually after or during reviews. Thanks for reviewing! Roman From daniel.daugherty at oracle.com Thu Sep 27 20:39:01 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 27 Sep 2018 16:39:01 -0400 Subject: RFR: JDK-8211241: Missing obj equals in TemplateTable::fast_aldc In-Reply-To: <4b57bab3-723a-eedb-5654-5ce893c8573f@redhat.com> References: <5492869d-c359-0a72-ebcd-fed24072ccc9@oracle.com> <4b57bab3-723a-eedb-5654-5ce893c8573f@redhat.com> Message-ID: On 9/27/18 4:37 PM, Roman Kennke wrote: >> On 9/27/18 4:07 PM, Roman Kennke wrote: >>> TemplateTable::fast_aldc compares the just-loaded reference with >>> Universe::the_null_sentinel. If it really is that null-sentinel, we may >>> get a false negative (with GCs like Shenandoah that allow both >>> from-space and to-space copies of an object to be around), and thus skip >>> NULL-ing the ref. In other words, it would allow to get >>> the-null-sentinel out into the wild as oop which can cause subtle and >>> not-so-subtle bugs. >>> >>> Fix is easy, call cmpoop() which re-routes through GC-interface for GCs >>> that need it: >>> >>> http://cr.openjdk.java.net/~rkennke/JDK-8211241/webrev.00/ >> src/hotspot/cpu/aarch64/templateTable_aarch64.cpp >> ??? No comments. >> >> src/hotspot/cpu/x86/templateTable_x86.cpp >> ??? No comments. >> >> Thumbs up (on the change)! >> >>> Testing: hotspot/jtreg:tier1 >> Did you use jdk_submit or local testing? I don't expect build >> problems but the templateTable_x86.cpp will affect all X86/X64 >> platforms right? > I tested locally on x86_64 and aarch64. I always push my stuff through > jdk/submit before pushing to jdk/jdk, usually after or during reviews. Thanks for confirming the testing. Dan > > Thanks for reviewing! > Roman > From vladimir.kozlov at oracle.com Thu Sep 27 21:28:28 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 27 Sep 2018 14:28:28 -0700 Subject: RFR(S): JDK-8191339: [JVMCI] BigInteger compiler intrinsics on Graal. In-Reply-To: <661f70d5-7a09-d181-5669-9841b590c7a3@oracle.com> References: <28011331-bd43-2c32-dba4-e41879ffe28a@oracle.com> <02f34a26-2a97-6a30-384f-115327781aac@oracle.com> <661f70d5-7a09-d181-5669-9841b590c7a3@oracle.com> Message-ID: <343cef9d-15f2-a01d-d3e3-0d4e2bc4cb06@oracle.com> Good. Thanks, Vladimir On 9/20/18 2:53 AM, Patric Hedlin wrote: > Hi Vladimir, Andrew, > > Sorry for dropping this after vacation. The testing is a simplistic benchmark (soon to be... I hope) > added to Graal (and some directed, a bit to ad hoc, testing not meant for up-streaming to Graal). I > also used a simplified version of a more general JVMCI/VM test case for these options only, but it > really does only exercise the JVMCI (not the option propagation in Graal or some other JVMCI > "client"), making it less useful. > > But in essence, Graal is the test-case. > > > On 2018-06-22 18:04, Vladimir Kozlov wrote: >> Hi Patric, >> >> Do you need Graal changes for this? Or it already has these intrinsics and the only problem is >> these flags were not set in vm_version_x86.cpp? > > No further changes have been made to Graal. > >> >> Small note. In vm_version_x86.cpp previous code has already COMPILER2_OR_JVMCI check. You can >> remove previous #endif and new #ifdef. Also change comment for closing #endif at line 1080 to // >> COMPILER2_OR_JVMCI >> >> 1080 #endif // COMPILER2 > > You are right (actually the intended webrev) and it should look correct now (just a tad old). > > Best regards, > Patric >> >> What testing you did? >> >> Thanks, >> Vladimir >> >> On 6/21/18 8:26 AM, Patric Hedlin wrote: >>> Dear all, >>> >>> I would like to ask for help to review the following change/update: >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8191339 >>> >>> Webrev: http://cr.openjdk.java.net/~phedlin/tr8191339/ >>> >>> >>> 8191339: [JVMCI] BigInteger compiler intrinsics on Graal. >>> >>> ???? Enabling BigInteger intrinsics via JVMCI. >>> >>> >>> >>> Best regards, >>> Patric > From matthias.baesken at sap.com Fri Sep 28 06:43:13 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Sep 2018 06:43:13 +0000 Subject: AllocateHeapAt disabling on AIX In-Reply-To: References: <49965314-df9e-8acf-e5c3-cba98ac2e162@oracle.com> <5a12f49a-fbcd-8c77-b88d-78f3df835c13@redhat.com> Message-ID: Hello , you run into an error : "Error in mapping Java heap at the given filesystem directory ..." In early VM startup when setting -XX:AllocateHeapAt=/where-to-map On AIX . Best regards, Matthias > -----Original Message----- > From: Kharbas, Kishor > Sent: Donnerstag, 27. September 2018 20:38 > To: Baesken, Matthias ; Aleksey Shipilev > ; David Holmes ; > 'hotspot-dev at openjdk.java.net' > Cc: Kharbas, Kishor > Subject: RE: AllocateHeapAt disabling on AIX > > Hi Matthias, > May I ask out of curiosity, whether you see any error using or having this > option? > > -Kishor > > > -----Original Message----- > > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > > Behalf Of Baesken, Matthias > > Sent: Wednesday, September 26, 2018 9:14 AM > > To: Aleksey Shipilev ; David Holmes > > ; 'hotspot-dev at openjdk.java.net' > dev at openjdk.java.net> > > Subject: RE: AllocateHeapAt disabling on AIX > > > > Hi Aleksey and David , sounds like a good idea. > > > > Thanks for your input ! > > > > > -----Original Message----- > > > From: Aleksey Shipilev > > > Sent: Mittwoch, 26. September 2018 18:13 > > > To: David Holmes ; Baesken, Matthias > > > ; 'hotspot-dev at openjdk.java.net' > > > dev at openjdk.java.net> > > > Subject: Re: AllocateHeapAt disabling on AIX > > > > > > On 09/26/2018 06:09 PM, David Holmes wrote: > > > > On 26/09/2018 12:02 PM, Baesken, Matthias wrote: > > > >> Hi David,? I would like to? print something like? "AllocateHeapAt > > > >> not > > > supported on AIX" . > > > >> And then exit?? (probably just ignoring the flag and printing the > > > >> message > > > might be bad ). > > > >> > > > >> The constraint functions were suggested to me as an option but? it > > > >> looks > > > to me they are > > > >> Intended for other use cases . > > > > > > > > Yes, I think a check in argument.cpp would be better. > > > > > > There is already a similar block there at L3848: > > > > > > #if defined(_ALLBSD_SOURCE) || defined(AIX) // UseLargePages is not > > > yet supported on BSD and AIX. > > > UNSUPPORTED_OPTION(UseLargePages); > > > #endif > > > > > > ...I think you can add the AllocateHeapAt check nearby, Matthias. > > > > > > -Aleksey From matthias.baesken at sap.com Fri Sep 28 06:53:26 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Sep 2018 06:53:26 +0000 Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 In-Reply-To: References: <8de12bb64e19e067b8c914f03aca759e91da8188.camel@oracle.com> Message-ID: Hi Aleksey, sounds great - thanks for looking into this JFR generating stuff and figuring out what to do where ?? ! So I guess we do not need my AIX-related patch any more , after your change is in ( and the commit-with parameters calls get usable as well on the non - JFR platforms ). I think we could simplify then quite a few places in the hs codebase that deal with JFR events ( where currently set_*(param1) + ... set_*(param_n) + commit() is used, this could be just commit(param1,...param_n) instead ) . However this is probably out of scope of my (and your ) patch . Best regards, Matthias > -----Original Message----- > From: Aleksey Shipilev > Sent: Donnerstag, 27. September 2018 20:03 > To: Baesken, Matthias ; Thomas Schatzl > ; 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net>; 'build-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: Re: RFR : 8211213: fix aix build after 8196341: Add JFR events for > parallel phases of G1 > > On 09/27/2018 04:39 PM, Baesken, Matthias wrote: > > Hi Thomas, do you know some fast and helpful person who can bring the > INCLUDE_JFR and ! INCLUDE_JFR cases in sync ? > > (or maybe there was a reason to have these differences we observe ? ) > > I am not a JFR person, but I think this should do it -- I copied > printCommitMethod into > printEmptyEvent and gutted it: > http://cr.openjdk.java.net/~shade/8211213/webrev.01/ > > This fixes x86_64 Zero build. > > -Aleksey From matthias.baesken at sap.com Fri Sep 28 07:02:51 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Sep 2018 07:02:51 +0000 Subject: RFR : 8211208 : make AllocateHeapAt an unsupported option on AIX - was : RE: AllocateHeapAt disabling on AIX Message-ID: Please review this small change , it makes AllocateHeapAt an unsupported option on AIX And adjusts a number of tests dealing with this flag . Webrev/bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8211208.0/ https://bugs.openjdk.java.net/browse/JDK-8211208 Thanks, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Freitag, 28. September 2018 08:43 > To: 'Kharbas, Kishor' ; Aleksey Shipilev > ; David Holmes ; > 'hotspot-dev at openjdk.java.net' > Subject: RE: AllocateHeapAt disabling on AIX > > Hello , you run into an error : > > "Error in mapping Java heap at the given filesystem directory ..." > > In early VM startup when setting -XX:AllocateHeapAt=/where-to-map > > On AIX . > > Best regards, Matthias > > > > -----Original Message----- > > From: Kharbas, Kishor > > Sent: Donnerstag, 27. September 2018 20:38 > > To: Baesken, Matthias ; Aleksey Shipilev > > ; David Holmes ; > > 'hotspot-dev at openjdk.java.net' > > Cc: Kharbas, Kishor > > Subject: RE: AllocateHeapAt disabling on AIX > > > > Hi Matthias, > > May I ask out of curiosity, whether you see any error using or having this > > option? > > > > -Kishor > > > > > -----Original Message----- > > > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > > > Behalf Of Baesken, Matthias > > > Sent: Wednesday, September 26, 2018 9:14 AM > > > To: Aleksey Shipilev ; David Holmes > > > ; 'hotspot-dev at openjdk.java.net' > > > dev at openjdk.java.net> > > > Subject: RE: AllocateHeapAt disabling on AIX > > > > > > Hi Aleksey and David , sounds like a good idea. > > > > > > Thanks for your input ! > > > > > > > -----Original Message----- > > > > From: Aleksey Shipilev > > > > Sent: Mittwoch, 26. September 2018 18:13 > > > > To: David Holmes ; Baesken, Matthias > > > > ; 'hotspot-dev at openjdk.java.net' > > > > > dev at openjdk.java.net> > > > > Subject: Re: AllocateHeapAt disabling on AIX > > > > > > > > On 09/26/2018 06:09 PM, David Holmes wrote: > > > > > On 26/09/2018 12:02 PM, Baesken, Matthias wrote: > > > > >> Hi David,? I would like to? print something like? "AllocateHeapAt > > > > >> not > > > > supported on AIX" . > > > > >> And then exit?? (probably just ignoring the flag and printing the > > > > >> message > > > > might be bad ). > > > > >> > > > > >> The constraint functions were suggested to me as an option but? it > > > > >> looks > > > > to me they are > > > > >> Intended for other use cases . > > > > > > > > > > Yes, I think a check in argument.cpp would be better. > > > > > > > > There is already a similar block there at L3848: > > > > > > > > #if defined(_ALLBSD_SOURCE) || defined(AIX) // UseLargePages is not > > > > yet supported on BSD and AIX. > > > > UNSUPPORTED_OPTION(UseLargePages); > > > > #endif > > > > > > > > ...I think you can add the AllocateHeapAt check nearby, Matthias. > > > > > > > > -Aleksey From matthias.baesken at sap.com Fri Sep 28 07:40:57 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Sep 2018 07:40:57 +0000 Subject: RFR : 8211089: windows : print process heaps information in hs_err file In-Reply-To: References: Message-ID: Ping .... Would be great to have some reviews on this ! Thanks, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 25. September 2018 15:53 > To: 'hotspot-dev at openjdk.java.net' > Subject: RFR : 8211089: windows : print process heaps information in hs_err > file > > Hello , please review this small change. > It adds output of information regarding Windows process heaps (see > https://docs.microsoft.com/en-us/windows/desktop/api/heapapi/nf- > heapapi-getprocessheaps ) > to the hs_error file. > we had this for some time in our internal JVM and want to bring it to > OpenJDK as well. > It is a Windows-only extension. > > bug : 8211089: windows : print process heaps information in hs_err file > https://bugs.openjdk.java.net/browse/JDK-8211089 > > > webrev : > http://cr.openjdk.java.net/~mbaesken/webrevs/8211089.0/ > > > > extended output is usually small, and looks like this : > > > --------------- S Y S T E M --------------- > > OS: Windows 10 , 64 bit Build ...... > > .... > > 4 Process Heaps: > Heap ID: 1 0x00000186491a0000 default crt low-fragmentation > Heap ID: 2 0x0000018649000000 standard > Heap ID: 3 0x0000018649430000 low-fragmentation > Heap ID: 4 0x000001864adb0000 low-fragmentation > > > Thanks, Matthias From roshanmangal at gmail.com Fri Sep 28 09:31:23 2018 From: roshanmangal at gmail.com (roshan mangal) Date: Fri, 28 Sep 2018 15:01:23 +0530 Subject: [PATCH] JDK-8205051 (UseNUMA memory interleaving vs cpunodebind & localalloc) In-Reply-To: <5362f42009cb7caddf43444c322410f3ee364112.camel@oracle.com> References: <5362f42009cb7caddf43444c322410f3ee364112.camel@oracle.com> Message-ID: Hi Thomas, > Hi Roshan, > > On Tue, 2018-09-25 at 12:18 +0530, roshan mangal wrote: > > Hi All, > > > > This Patch is for https://bugs.openjdk.java.net/browse/JDK-8205051 > > > > Issue: > > > > If the JVM isn't allowed to run on all of the nodes (by numactl, > > cgroups, docker, etc), then a significant fraction of the Java heap > > will be unusable, causing early GC. > > > > Every Thread captures their locality group(lgrp) and allocates memory > > from that lgrp. > > > > lgrp id is same as NUMA node id. > > > > Thread running on CPU belongs to NUMA node 0, will capture Thread- > > >lgrp as lgrp0 and will allocate memory from NUMA node 0. Once NUMA > > node 0 is full, it will trigger GC irrespective of other NUMA node > > having memory. > > > > Solution proposed: > > > > Create List of NUMA nodes based on distance and allocate memory from > > near NUMA node when other closest NUMA node is/are full. > > > > Below system has eight NUMA nodes and distance table given below. > > > > node distances: > > > > node 0 1 2 3 4 5 6 7 > > 0: 10 16 16 16 32 32 32 32 > > 1: 16 10 16 16 32 32 32 32 > > 2: 16 16 10 16 32 32 32 32 > > 3: 16 16 16 10 32 32 32 32 > > 4: 32 32 32 32 10 16 16 16 > > 5: 32 32 32 32 16 10 16 16 > > 6: 32 32 32 32 16 16 10 16 > > 7: 32 32 32 32 16 16 16 10 > > > > The corresponding list for each lgrp will be like this. > > > > Thread's lgrp > > Order of Allocation in NUMA node > > > > lgrp0 [ numaNode0->numaNode1->numaNode2->numaNode3-> > > numaNode4->numaNode5->numaNode6->numaNode7 ] > > lgrp1 [ numaNode1->numaNode0->numaNode2->numaNode3-> > > numaNode4->numaNode5->numaNode6->numaNode7 ] > > lgrp2 [ numaNode2->numaNode0->numaNode1->numaNode3-> > > numaNode4->numaNode5->numaNode6->numaNode7 ] > > lgrp3 [ numaNode3->numaNode0->numaNode1->numaNode2-> > > numaNode4->numaNode5->numaNode6->numaNode7 ] > > lgrp4 [ numaNode4->numaNode5->numaNode6->numaNode7-> > > numaNode0->numaNode1->numaNode2->numaNode3 ] > > lgrp5 [ numaNode5->numaNode4->numaNode6->numaNode7-> > > numaNode0->numaNode1->numaNode2->numaNode3 ] > > lgrp6 [ numaNode6->numaNode4->numaNode5->numaNode7-> > > numaNode0->numaNode1->numaNode2->numaNode3 ] > > lgrp7 [ numaNode7->numaNode4->numaNode5->numaNode6-> > > numaNode0->numaNode1->numaNode2->numaNode3 ] > > I have a question about this: lgrps often have the same distance from > each other, and this order-of-allocation list seems to be > deterministic. So in this case nodes with lower lgrp id (but the same > distance) are preferred to ones with higher lgrp id. > > Do you expect some imbalance because of that? If so, couldn't it be > useful to randomize lgrps with the same distance in this list, and > regularly change them? Yes, I agree there will be an imbalance because of that. Another option would be to select lgrp based on largest free memory available. What is your opinion on this ? For Example, node 0 1 2 3 0: 10 16 16 16 1: 16 10 16 16 2: 16 16 10 16 3: 16 16 16 10 Threads T0,T1,T2 and T3 are running on different numa node with lgrp0,lgrp1,lgrp2 and lgrp3 respectively. Allocation within the node has distance 10 but outside is 16. Suppose lgrp0 gets OOM and memory available at that time is lgrp0(0%) lgrp1(10%) lgrp2(5%) lgrp3(50%). If we choose 'lgrp' randomly e.g. lgrp2 over lgrp3 for T0, lgrp2 will be filled faster and once lgrp2 is full, T2 also need to go other lgrp with distance 16. In this scenario, T0 choosing lgrp3 with 50% free memory will be a better option, which will allow T2 to run for longer time on lgrp2 having lower memory latency (10). > Long ago I have been implementing some NUMA support for G1 and had that > issue (in this case the distribution is a nice lattice with everyone > connected by everyone else with two hops), with the above mentioned > solution to that "problem". > > Do you think something like this would make sense (not particularly in > this change). > Selecting the best possible lgrp dynamically will be a better option instead of deterministic selection (as in my patch) but that will add slightly more overhead during memory allocation. Will that be ok? > > Allocation on NUMA node, which is far from CPU can lead to > > performance issue. Sometimes triggering GC is a better option than > > allocating from NUMA node at large distance i.e. high memory latency. > > > > For this, I have added option "NumaAllocationDistanceLimit", which > > will restrict memory allocation from the far nodes. > > > > In above system if we set -XX:NumaAllocationDistanceLimit=16. > > That makes sense imho, although it is a bit sad that this number is > specific to the machine. > > > > > The corresponding list for each lgrp will be like this. > > > > Thread's lgrp Order of Allocation in NUMA node > > lgrp0 [ numaNode0->numaNode1->numaNode2->numaNode3 ] > > lgrp1 [ numaNode1->numaNode0->numaNode2->numaNode3 ] > > lgrp2 [ numaNode2->numaNode0->numaNode1->numaNode3 ] > > lgrp3 [ numaNode3->numaNode0->numaNode1->numaNode2 ] > > lgrp4 [ numaNode4->numaNode5->numaNode6->numaNode7 ] > > lgrp5 [ numaNode5->numaNode4->numaNode6->numaNode7 ] > > lgrp6 [ numaNode6->numaNode4->numaNode5->numaNode7 ] > > lgrp7 [ numaNode7->numaNode4->numaNode5->numaNode6 ] > > > > #################################################### PATCH > > ################################ > > could you send me a patch as webrev so I can put it on > cr.openjdk.java.net? (Or maybe sending the patch as attachment helps > too). It got mangled by your email program, adding many linebreaks. > Please find patch as attachment. I have run specjbb2015 composite run with "numactl -N 0 " on 8 NUMA node system. it has improved score composite Max-jOPS: +29% composite Critical-jOPS: +24% > Thanks, > Thomas Thanks, Roshan Mangal From shade at redhat.com Fri Sep 28 10:29:49 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Sep 2018 12:29:49 +0200 Subject: RFR(S): 8211145: [ppc] [s390]: Build fails due to -Werror=switch (introduced with JDK-8211029) In-Reply-To: References: <3C71CFD0-3764-464F-A12F-FD71BE44658E@sap.com> <6629adb8-f0d5-1f9d-15b5-3159c67e9c3e@redhat.com> <6D26E4F8-51E0-4171-B644-ED92C5830D82@sap.com> <1D9C7321-3E84-40AB-87CD-1BA6012B768C@sap.com> <37f0b889-3d9a-cba1-f51c-76ba56d7d4e2@redhat.com> Message-ID: On 09/27/2018 04:28 PM, Schmidt, Lutz wrote: > re break vs. ShouldNotReachHere(), I tried to change semantics as little as possible. After > discussion with colleagues, we concluded that ShouldNotReachHere() is the better choice. Code was > modified accordingly. Your concerns re. coding style are reflected in the new webrev as well. It > can be found here: http://cr.openjdk.java.net/~lucy/webrevs/8211145.02/ Looks good! Ship it. -Aleksey From shade at redhat.com Fri Sep 28 10:31:53 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Sep 2018 12:31:53 +0200 Subject: RFR(S): 8211212: ARM: -Werror=switch build failure In-Reply-To: <10775009-e927-0d79-1bb7-f838148929bd@bell-sw.com> References: <22accb8e-29eb-d022-0642-e09cce38c396@bell-sw.com> <1db4ee72-88d0-a92d-99b1-0fdffe94bf79@redhat.com> <10775009-e927-0d79-1bb7-f838148929bd@bell-sw.com> Message-ID: Please push it. I would like to see jdk/jdk unbroken :) Do you need a sponsor? -Aleksey On 09/27/2018 06:29 PM, Aleksei Voitylov wrote: > Thank you for review, Aleksey! > > > On 27/09/2018 15:47, Aleksey Shipilev wrote: >> On 09/27/2018 01:20 PM, Aleksei Voitylov wrote: >>> it's ARM32 port turn. Please review the following fix for -Werror=switch build failure. >>> >>> webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8211212.01/ >>> issue: https://bugs.openjdk.java.net/browse/JDK-8211212 >> Looks good! That is what AArch64 did. >> >> -Aleksey >> > From shade at redhat.com Fri Sep 28 10:33:41 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Sep 2018 12:33:41 +0200 Subject: RFR : 8211208 : make AllocateHeapAt an unsupported option on AIX - was : RE: AllocateHeapAt disabling on AIX In-Reply-To: References: Message-ID: <14e9db7c-f5d9-aa8d-81c4-74173b3b4cee@redhat.com> On 09/28/2018 09:02 AM, Baesken, Matthias wrote: > http://cr.openjdk.java.net/~mbaesken/webrevs/8211208.0/ This looks good to me. -Aleksey From thomas.schatzl at oracle.com Fri Sep 28 10:47:28 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 28 Sep 2018 12:47:28 +0200 Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 In-Reply-To: References: <8de12bb64e19e067b8c914f03aca759e91da8188.camel@oracle.com> Message-ID: <1f70cc6ca44b27bd045720b98b3f9071ec1faab2.camel@oracle.com> Hi, On Thu, 2018-09-27 at 20:03 +0200, Aleksey Shipilev wrote: > On 09/27/2018 04:39 PM, Baesken, Matthias wrote: > > Hi Thomas, do you know some fast and helpful person who can bring > > the INCLUDE_JFR and ! INCLUDE_JFR cases in sync ? > > (or maybe there was a reason to have these differences we observe ? > > ) > > I am not a JFR person, but I think this should do it -- I copied > printCommitMethod into > printEmptyEvent and gutted it: > http://cr.openjdk.java.net/~shade/8211213/webrev.01/ > > This fixes x86_64 Zero build. > ... and AIX or any build built with --with-jvm-variants=-jfr I suppose. looks good to me. Btw, I closed out a few bugs created in JIRA as apparent duplicate of this one. If there is something wrong with that, please reopen with a comment. Thanks, Thomas From thomas.schatzl at oracle.com Fri Sep 28 10:51:33 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 28 Sep 2018 12:51:33 +0200 Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 In-Reply-To: References: <8de12bb64e19e067b8c914f03aca759e91da8188.camel@oracle.com> Message-ID: <6637cf0e72c885b76c866a101023d3d91cc64aab.camel@oracle.com> Hi, On Fri, 2018-09-28 at 06:53 +0000, Baesken, Matthias wrote: > Hi Aleksey, sounds great - thanks for looking into this JFR > generating stuff and figuring out what to do where ?? ! > > So I guess we do not need my AIX-related patch any more , > after your change is in ( and the commit-with > parameters calls get usable as well on the non - JFR platforms ). > > I think we could simplify then quite a few places in the > hs codebase that deal with JFR events ( where > currently set_*(param1) + ... set_*(param_n) + commit() is > used, this could be just > commit(param1,...param_n) instead ) . > > However this is probably out of scope of my (and your ) patch . I filed JDK-8211273 :) Thanks, Thomas From shade at redhat.com Fri Sep 28 10:51:56 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Sep 2018 12:51:56 +0200 Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 In-Reply-To: <1f70cc6ca44b27bd045720b98b3f9071ec1faab2.camel@oracle.com> References: <8de12bb64e19e067b8c914f03aca759e91da8188.camel@oracle.com> <1f70cc6ca44b27bd045720b98b3f9071ec1faab2.camel@oracle.com> Message-ID: On 09/28/2018 12:47 PM, Thomas Schatzl wrote: > Btw, I closed out a few bugs created in JIRA as apparent duplicate of > this one. If there is something wrong with that, please reopen with a > comment. I'd probably do that in reverse: if AIX folks can confirm that JFR events fix (https://bugs.openjdk.java.net/browse/JDK-8211239) resolves their trouble, we can close this one (https://bugs.openjdk.java.net/browse/JDK-8211213) as duplicate. JFR events fix ticket has the clear assignee, and I like that. -Aleksey From thomas.schatzl at oracle.com Fri Sep 28 10:54:19 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 28 Sep 2018 12:54:19 +0200 Subject: RFR : 8211208 : make AllocateHeapAt an unsupported option on AIX - was : RE: AllocateHeapAt disabling on AIX In-Reply-To: References: Message-ID: Hi, On Fri, 2018-09-28 at 07:02 +0000, Baesken, Matthias wrote: > Please review this small change , it > makes AllocateHeapAt an unsupported option on AIX > And adjusts a number of tests dealing with this flag . > > Webrev/bug : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211208.0/ > > https://bugs.openjdk.java.net/browse/JDK-8211208 > ship it. Thomas From thomas.schatzl at oracle.com Fri Sep 28 11:02:19 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 28 Sep 2018 13:02:19 +0200 Subject: RFR : 8211213: fix aix build after 8196341: Add JFR events for parallel phases of G1 In-Reply-To: References: <8de12bb64e19e067b8c914f03aca759e91da8188.camel@oracle.com> <1f70cc6ca44b27bd045720b98b3f9071ec1faab2.camel@oracle.com> Message-ID: Hi, On Fri, 2018-09-28 at 12:51 +0200, Aleksey Shipilev wrote: > On 09/28/2018 12:47 PM, Thomas Schatzl wrote: > > Btw, I closed out a few bugs created in JIRA as apparent duplicate > > of > > this one. If there is something wrong with that, please reopen with > > a > > comment. > > I'd probably do that in reverse: if AIX folks can confirm that JFR > events fix > (https://bugs.openjdk.java.net/browse/JDK-8211239) resolves their > trouble, we can close this one > (https://bugs.openjdk.java.net/browse/JDK-8211213) as duplicate. JFR > events fix ticket has the clear > assignee, and I like that. > I do not really care for which bug number this issue is fixed as long as it is fixed :) However if you change this and use JDK-8211239, please make sure in the comments that the RFR thread is labelled as the one for JDK-8211213 to be able to find the review thread in the future. Thanks, Thomas From shade at redhat.com Fri Sep 28 11:33:29 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Sep 2018 13:33:29 +0200 Subject: RFR (XS) 8211274: x86_32 build failures after JDK-8211029 (Have a common set of enabled warnings for all native libraries) Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8211274 Fix: http://cr.openjdk.java.net/~shade/8211274/webrev.01/ This fixes the fatal build warnings when building on x86_32. New default to ShouldNotReachHere in jniFastGetField_x86_32 is safe, because it matches the similar switch 30 lines above it. Testing: x86_32 build, trivial sanity checks Thanks, -Aleksey From sgehwolf at redhat.com Fri Sep 28 11:59:49 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 28 Sep 2018 13:59:49 +0200 Subject: [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: <3e076712a19ee7b29665543e46699497018ba886.camel@redhat.com> Message-ID: Any more reviewers for this? Thanks, Severin On Wed, 2018-09-26 at 08:20 -0400, David Holmes wrote: > On 26/09/2018 7:52 AM, Severin Gehwolf wrote: > > Hi David, > > > > Thanks for the review! > > > > On Wed, 2018-09-26 at 07:39 -0400, David Holmes wrote: > > > Hi Severin, > > > > > > Changes present seem okay, but I don't see the SA changes, and don't you > > > want the JDK test change from this as well: > > > > > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/2ff471390a03 > > > > > > ?? > > > > Test changes are there: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/jdk/test/sun/security/pkcs11/PKCS11Test.java.udiff.html > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/jdk/test/tools/launcher/Settings.java.udiff.html > > Oops I missed the split up. Thanks. > > All seems fine, > > > The SA isn't built on ppc64/ppc64le (INCLUDE_SA=false). I can include > > SA changes in the backport, but they won't do anything. > > Okay. > > Thanks, > David > > > Thanks, > > Severin > > > > > On 26/09/2018 7:26 AM, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could I please get reviews for this JDK 8 backport which fixes some > > > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > > > > would report as "ppc64" via os.arch system property which breaks > > > > tooling such as maven in as much as if some dependency needs native > > > > libraries it would download BE binaries where it actually should > > > > download LE binaries. Example for os.arch/java.library.path: > > > > > > > > pre: > > > > $ ./jdk8-pre-ppc64le/bin/java TestProperty > > > > java.library.path = /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > > > > os.arch = ppc64 > > > > > > > > post: > > > > $ ./jdk8-post-ppc64le/bin/java TestProperty > > > > java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > > > > os.arch = ppc64le > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > > > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/ > > > > > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev > > > > for JDK/hotspot changes. > > > > > > > > This backport should only have minor differences to the changes in JDK > > > > 11. We have been using similar patches in Fedora for months. Thoughts? > > > > > > > > Thanks, > > > > Severin > > > > From thomas.schatzl at oracle.com Fri Sep 28 12:24:46 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 28 Sep 2018 05:24:46 -0700 (PDT) Subject: RFR (XS) 8211274: x86_32 build failures after JDK-8211029 (Have a common set of enabled warnings for all native libraries) In-Reply-To: References: Message-ID: <2f982d04094059ab1a309023935cda936bbb4a0b.camel@oracle.com> Hi, On Fri, 2018-09-28 at 13:33 +0200, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211274 > > Fix: > http://cr.openjdk.java.net/~shade/8211274/webrev.01/ > > This fixes the fatal build warnings when building on x86_32. New > default to ShouldNotReachHere in > jniFastGetField_x86_32 is safe, because it matches the similar switch > 30 lines above it. > > Testing: x86_32 build, trivial sanity checks looks good to me. Thomas From david.holmes at oracle.com Fri Sep 28 12:31:26 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 28 Sep 2018 08:31:26 -0400 Subject: RFR (XS) 8211274: x86_32 build failures after JDK-8211029 (Have a common set of enabled warnings for all native libraries) In-Reply-To: References: Message-ID: Looks good! Thanks, David On 28/09/2018 7:33 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211274 > > Fix: > http://cr.openjdk.java.net/~shade/8211274/webrev.01/ > > This fixes the fatal build warnings when building on x86_32. New default to ShouldNotReachHere in > jniFastGetField_x86_32 is safe, because it matches the similar switch 30 lines above it. > > Testing: x86_32 build, trivial sanity checks > > Thanks, > -Aleksey > From aleksei.voitylov at bell-sw.com Fri Sep 28 13:27:52 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 28 Sep 2018 16:27:52 +0300 Subject: RFR(S): 8211212: ARM: -Werror=switch build failure In-Reply-To: References: <22accb8e-29eb-d022-0642-e09cce38c396@bell-sw.com> <1db4ee72-88d0-a92d-99b1-0fdffe94bf79@redhat.com> <10775009-e927-0d79-1bb7-f838148929bd@bell-sw.com> Message-ID: <87eebaf1-2f75-3a65-85fc-3a1b96c2c869@bell-sw.com> So do I. Pushed. On 28/09/2018 13:31, Aleksey Shipilev wrote: > Please push it. I would like to see jdk/jdk unbroken :) > > Do you need a sponsor? > > -Aleksey > > On 09/27/2018 06:29 PM, Aleksei Voitylov wrote: >> Thank you for review, Aleksey! >> >> >> On 27/09/2018 15:47, Aleksey Shipilev wrote: >>> On 09/27/2018 01:20 PM, Aleksei Voitylov wrote: >>>> it's ARM32 port turn. Please review the following fix for -Werror=switch build failure. >>>> >>>> webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8211212.01/ >>>> issue: https://bugs.openjdk.java.net/browse/JDK-8211212 >>> Looks good! That is what AArch64 did. >>> >>> -Aleksey >>> > From matthias.baesken at sap.com Fri Sep 28 13:51:00 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Sep 2018 13:51:00 +0000 Subject: RFR : 8211208 : make AllocateHeapAt an unsupported option on AIX - was : RE: AllocateHeapAt disabling on AIX In-Reply-To: References: Message-ID: Hi Thomas / Aleksey, thanks for the reviews ! Best regards, Matthias > -----Original Message----- > From: Thomas Schatzl > Sent: Freitag, 28. September 2018 12:54 > To: Baesken, Matthias ; Kharbas, Kishor > ; Aleksey Shipilev ; David > Holmes ; 'hotspot-dev at openjdk.java.net' > > Subject: Re: RFR : 8211208 : make AllocateHeapAt an unsupported option on > AIX - was : RE: AllocateHeapAt disabling on AIX > > Hi, > > On Fri, 2018-09-28 at 07:02 +0000, Baesken, Matthias wrote: > > Please review this small change , it > > makes AllocateHeapAt an unsupported option on AIX > > And adjusts a number of tests dealing with this flag . > > > > Webrev/bug : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211208.0/ > > > > https://bugs.openjdk.java.net/browse/JDK-8211208 > > > > ship it. > > Thomas From glaubitz at physik.fu-berlin.de Fri Sep 28 14:35:56 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 28 Sep 2018 16:35:56 +0200 Subject: Build broken on linux-sparc64 Message-ID: <4403fa35-34a5-4edd-1348-d453c531048f@physik.fu-berlin.de> Hello! Just did a test build after a longer hiatus on linux-sparc64 and ran into this: === Output from failing command(s) repeated here === /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_g1CollectedHeap.o:\n" * For target hotspot_variant-server_libjvm_objs_g1CollectedHeap.o: (/bin/grep -v -e "^Note: including file:" < /srv/openjdk/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_g1CollectedHeap.o.log || true) | /usr/bin/head -n 12 /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1CollectedHeap.cpp: In member function ?bool G1ParEvacuateFollowersClosure::offer_termination()?: /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:3177:106: error: no matching function for call to ?EventGCPhaseParallel::commit(uint, uint, const char*)? event.commit(GCId::current(), pss->worker_id(), G1GCPhaseTimes::phase_name(G1GCPhaseTimes::Termination)); ^ In file included from /srv/openjdk/jdk/src/hotspot/share/jfr/jfrEvents.hpp:32, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp:30, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1Policy.hpp:29, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1ParScanThreadState.hpp:32, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp:28, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1OopClosures.inline.hpp:31, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp:32, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp:31, if test `/usr/bin/wc -l < /srv/openjdk/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_g1CollectedHeap.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_g1GCPhaseTimes.o:\n" * For target hotspot_variant-server_libjvm_objs_g1GCPhaseTimes.o: (/bin/grep -v -e "^Note: including file:" < /srv/openjdk/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_g1GCPhaseTimes.o.log || true) | /usr/bin/head -n 12 /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp: In destructor ?virtual G1GCParPhaseTimesTracker::~G1GCParPhaseTimesTracker()?: /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:544:82: error: no matching function for call to ?EventGCPhaseParallel::commit(uint, uint&, const char*)? _event.commit(GCId::current(), _worker_id, G1GCPhaseTimes::phase_name(_phase)); ^ In file included from /srv/openjdk/jdk/src/hotspot/share/jfr/jfrEvents.hpp:32, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp:30, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1Policy.hpp:29, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1ParScanThreadState.hpp:32, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp:28, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1OopClosures.inline.hpp:31, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp:32, from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp:31, if test `/usr/bin/wc -l < /srv/openjdk/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_g1GCPhaseTimes.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi ... (rest of output omitted) /usr/bin/printf "* For target jdk_modules_java.base__the.java.base_batch:\n" * For target jdk_modules_java.base__the.java.base_batch: (/bin/grep -v -e "^Note: including file:" < /srv/openjdk/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log || true) | /usr/bin/head -n 12 if test `/usr/bin/wc -l < /srv/openjdk/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/jdk_modules_java.base__the.java.base_batch.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "\n* All command lines available in /srv/openjdk/jdk/build/linux-sparcv9-server-release/make-support/failure-logs.\n" * All command lines available in /srv/openjdk/jdk/build/linux-sparcv9-server-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === The issue does not show on linux-x86_64, so it must be linux-sparc64-specific. I assume that the internal interface for the G1 changed and needs to be updated for linux-sparc64. I'm just pointing this here already, so in case someone wants to give some pointers. I will look into fixing the issue later. 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 Fri Sep 28 14:40:24 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 28 Sep 2018 16:40:24 +0200 Subject: Build broken on linux-sparc64 In-Reply-To: <4403fa35-34a5-4edd-1348-d453c531048f@physik.fu-berlin.de> References: <4403fa35-34a5-4edd-1348-d453c531048f@physik.fu-berlin.de> Message-ID: On 9/28/18 4:35 PM, John Paul Adrian Glaubitz wrote: > The issue does not show on linux-x86_64, so it must be linux-sparc64-specific. > > I assume that the internal interface for the G1 changed and needs to be updated > for linux-sparc64. I'm just pointing this here already, so in case someone wants > to give some pointers. I will look into fixing the issue later. hg blame leads to this: http://hg.openjdk.java.net/jdk/jdk/rev/5f931e3e7a63 I don't see anything changed for the other targets though. Must be in a different commit, I assume. 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 Fri Sep 28 14:41:29 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Sep 2018 16:41:29 +0200 Subject: Build broken on linux-sparc64 In-Reply-To: <4403fa35-34a5-4edd-1348-d453c531048f@physik.fu-berlin.de> References: <4403fa35-34a5-4edd-1348-d453c531048f@physik.fu-berlin.de> Message-ID: On 09/28/2018 04:35 PM, John Paul Adrian Glaubitz wrote: > Hello! > > Just did a test build after a longer hiatus on linux-sparc64 and ran into this: > > === Output from failing command(s) repeated here === > /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_g1CollectedHeap.o:\n" > * For target hotspot_variant-server_libjvm_objs_g1CollectedHeap.o: > (/bin/grep -v -e "^Note: including file:" < /srv/openjdk/jdk/build/linux-sparcv9-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_g1CollectedHeap.o.log || true) | /usr/bin/head -n 12 > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1CollectedHeap.cpp: In member function ?bool G1ParEvacuateFollowersClosure::offer_termination()?: > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:3177:106: error: no matching function for call to ?EventGCPhaseParallel::commit(uint, uint, const char*)? > event.commit(GCId::current(), pss->worker_id(), G1GCPhaseTimes::phase_name(G1GCPhaseTimes::Termination)); > ^ This looks like: https://bugs.openjdk.java.net/browse/JDK-8211228 https://bugs.openjdk.java.net/browse/JDK-8211239 Thanks, -Aleksey From matthias.baesken at sap.com Fri Sep 28 15:05:08 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 28 Sep 2018 15:05:08 +0000 Subject: Build broken on linux-sparc64 Message-ID: Hi, there is a fix coming for this . Aleksey fixed the JFR code generation . See : http://cr.openjdk.java.net/~shade/8211213/webrev.01/ some more info : https://bugs.openjdk.java.net/browse/JDK-8211213 Best regards, Matthias > > ------------------------------ > > Message: 5 > Date: Fri, 28 Sep 2018 16:35:56 +0200 > From: John Paul Adrian Glaubitz > To: hotspot-dev developers > Subject: Build broken on linux-sparc64 > Message-ID: <4403fa35-34a5-4edd-1348-d453c531048f at physik.fu-berlin.de> > Content-Type: text/plain; charset=utf-8 > > Hello! > > Just did a test build after a longer hiatus on linux-sparc64 and ran into this: > > === Output from failing command(s) repeated here === > /usr/bin/printf "* For target hotspot_variant- > server_libjvm_objs_g1CollectedHeap.o:\n" > * For target hotspot_variant-server_libjvm_objs_g1CollectedHeap.o: > (/bin/grep -v -e "^Note: including file:" < /srv/openjdk/jdk/build/linux- > sparcv9-server-release/make-support/failure-logs/hotspot_variant- > server_libjvm_objs_g1CollectedHeap.o.log || true) | /usr/bin/head -n 12 > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1CollectedHeap.cpp: In > member function ?bool > G1ParEvacuateFollowersClosure::offer_termination()?: > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:3177:106: > error: no matching function for call to ?EventGCPhaseParallel::commit(uint, > uint, const char*)? > event.commit(GCId::current(), pss->worker_id(), > G1GCPhaseTimes::phase_name(G1GCPhaseTimes::Termination)); > ^ > In file included from > /srv/openjdk/jdk/src/hotspot/share/jfr/jfrEvents.hpp:32, > from > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp:30, > from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1Policy.hpp:29, > from > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1ParScanThreadState.hpp:32, > from > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp > :28, > from > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1OopClosures.inline.hpp:31, > from > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp:32, > from > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp:31, > if test `/usr/bin/wc -l < /srv/openjdk/jdk/build/linux-sparcv9-server- > release/make-support/failure-logs/hotspot_variant- > server_libjvm_objs_g1CollectedHeap.o.log` -gt 12; then /bin/echo " ... (rest > of output omitted)" ; fi > ... (rest of output omitted) > /usr/bin/printf "* For target hotspot_variant- > server_libjvm_objs_g1GCPhaseTimes.o:\n" > * For target hotspot_variant-server_libjvm_objs_g1GCPhaseTimes.o: > (/bin/grep -v -e "^Note: including file:" < /srv/openjdk/jdk/build/linux- > sparcv9-server-release/make-support/failure-logs/hotspot_variant- > server_libjvm_objs_g1GCPhaseTimes.o.log || true) | /usr/bin/head -n 12 > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp: In > destructor ?virtual > G1GCParPhaseTimesTracker::~G1GCParPhaseTimesTracker()?: > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp:544:82: > error: no matching function for call to ?EventGCPhaseParallel::commit(uint, > uint&, const char*)? > _event.commit(GCId::current(), _worker_id, > G1GCPhaseTimes::phase_name(_phase)); > ^ > In file included from > /srv/openjdk/jdk/src/hotspot/share/jfr/jfrEvents.hpp:32, > from > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp:30, > from /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1Policy.hpp:29, > from > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1ParScanThreadState.hpp:32, > from > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp > :28, > from > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1OopClosures.inline.hpp:31, > from > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp:32, > from > /srv/openjdk/jdk/src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp:31, > if test `/usr/bin/wc -l < /srv/openjdk/jdk/build/linux-sparcv9-server- > release/make-support/failure-logs/hotspot_variant- > server_libjvm_objs_g1GCPhaseTimes.o.log` -gt 12; then /bin/echo " ... (rest > of output omitted)" ; fi > ... (rest of output omitted) > /usr/bin/printf "* For target > jdk_modules_java.base__the.java.base_batch:\n" > * For target jdk_modules_java.base__the.java.base_batch: > (/bin/grep -v -e "^Note: including file:" < /srv/openjdk/jdk/build/linux- > sparcv9-server-release/make-support/failure- > logs/jdk_modules_java.base__the.java.base_batch.log || true) | > /usr/bin/head -n 12 > if test `/usr/bin/wc -l < /srv/openjdk/jdk/build/linux-sparcv9-server- > release/make-support/failure- > logs/jdk_modules_java.base__the.java.base_batch.log` -gt 12; then > /bin/echo " ... (rest of output omitted)" ; fi > /usr/bin/printf "\n* All command lines available in > /srv/openjdk/jdk/build/linux-sparcv9-server-release/make-support/failure- > logs.\n" > > * All command lines available in /srv/openjdk/jdk/build/linux-sparcv9- > server-release/make-support/failure-logs. > /usr/bin/printf "=== End of repeated output ===\n" > === End of repeated output === > > The issue does not show on linux-x86_64, so it must be linux-sparc64- > specific. > > I assume that the internal interface for the G1 changed and needs to be > updated > for linux-sparc64. I'm just pointing this here already, so in case someone > wants > to give some pointers. I will look into fixing the issue later. > > Thanks, > Adrian > From erik.joelsson at oracle.com Fri Sep 28 15:56:10 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 28 Sep 2018 08:56:10 -0700 Subject: [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: Message-ID: Build changes look ok to me. /Erik On 2018-09-26 04:26, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this JDK 8 backport which fixes some > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > would report as "ppc64" via os.arch system property which breaks > tooling such as maven in as much as if some dependency needs native > libraries it would download BE binaries where it actually should > download LE binaries. Example for os.arch/java.library.path: > > pre: > $ ./jdk8-pre-ppc64le/bin/java TestProperty > java.library.path = /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > os.arch = ppc64 > > post: > $ ./jdk8-post-ppc64le/bin/java TestProperty > java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > os.arch = ppc64le > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/ > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev > for JDK/hotspot changes. > > This backport should only have minor differences to the changes in JDK > 11. We have been using similar patches in Fedora for months. Thoughts? > > Thanks, > Severin > From sgehwolf at redhat.com Fri Sep 28 16:02:27 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 28 Sep 2018 18:02:27 +0200 Subject: [8u] RFR: 8073139: PPC64: User-visible arch directory and os.arch value on ppc64le cause issues with Java tooling In-Reply-To: References: Message-ID: <976dfd6869753347e19cbfba246393e1fe6a1c4f.camel@redhat.com> On Fri, 2018-09-28 at 08:56 -0700, Erik Joelsson wrote: > Build changes look ok to me. Thanks for the review, Erik! Cheers, Severin > /Erik > > > On 2018-09-26 04:26, Severin Gehwolf wrote: > > Hi, > > > > Could I please get reviews for this JDK 8 backport which fixes some > > tooling issues on Linux ppc64le? Prior this patch, a ppc64le build > > would report as "ppc64" via os.arch system property which breaks > > tooling such as maven in as much as if some dependency needs native > > libraries it would download BE binaries where it actually should > > download LE binaries. Example for os.arch/java.library.path: > > > > pre: > > $ ./jdk8-pre-ppc64le/bin/java TestProperty > > java.library.path = /usr/java/packages/lib/ppc64:/usr/lib64:/lib64:/lib:/usr/lib > > os.arch = ppc64 > > > > post: > > $ ./jdk8-post-ppc64le/bin/java TestProperty > > java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > > os.arch = ppc64le > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8073139 > > webrevs: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8073139/jdk8/01/ > > > > Including build-dev for build changes. hotspot-dev and ppc-aix-port-dev > > for JDK/hotspot changes. > > > > This backport should only have minor differences to the changes in JDK > > 11. We have been using similar patches in Fedora for months. Thoughts? > > > > Thanks, > > Severin > > > > From vladimir.kozlov at oracle.com Fri Sep 28 16:46:38 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 28 Sep 2018 09:46:38 -0700 Subject: RFR (XS) 8211274: x86_32 build failures after JDK-8211029 (Have a common set of enabled warnings for all native libraries) In-Reply-To: References: Message-ID: <8702a78c-e4cc-9948-f9a2-b61a8648feff@oracle.com> Good. Thanks, Vladimir On 9/28/18 4:33 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211274 > > Fix: > http://cr.openjdk.java.net/~shade/8211274/webrev.01/ > > This fixes the fatal build warnings when building on x86_32. New default to ShouldNotReachHere in > jniFastGetField_x86_32 is safe, because it matches the similar switch 30 lines above it. > > Testing: x86_32 build, trivial sanity checks > > Thanks, > -Aleksey > From shade at redhat.com Fri Sep 28 16:47:42 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Sep 2018 18:47:42 +0200 Subject: RFR (XS) 8211274: x86_32 build failures after JDK-8211029 (Have a common set of enabled warnings for all native libraries) In-Reply-To: <8702a78c-e4cc-9948-f9a2-b61a8648feff@oracle.com> References: <8702a78c-e4cc-9948-f9a2-b61a8648feff@oracle.com> Message-ID: <561e64d1-39ba-3040-60e1-03b00dafbd20@redhat.com> Thanks, pushed. On 09/28/2018 06:46 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 9/28/18 4:33 AM, Aleksey Shipilev wrote: >> Bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8211274 >> >> Fix: >> ?? http://cr.openjdk.java.net/~shade/8211274/webrev.01/ >> >> This fixes the fatal build warnings when building on x86_32. New default to ShouldNotReachHere in >> jniFastGetField_x86_32 is safe, because it matches the similar switch 30 lines above it. >> >> Testing: x86_32 build, trivial sanity checks >> >> Thanks, >> -Aleksey >> From shade at redhat.com Fri Sep 28 17:24:48 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Sep 2018 19:24:48 +0200 Subject: RFR (S) 8211239: Build fails without JFR: empty JFR events signatures mismatch Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8211239 Fix: http://cr.openjdk.java.net/~shade/8211239/webrev.02/ Anything that disables JFR as JVM feature would break the build. It started to happen with Zero, AIX, Sparc64 builds after recent G1+JFR improvement. The underlying reason for this breakage is that JFR events generator produces two versions for each event: "full" and "empty", and the version is then selected by INCLUDE_JFR macro during build time. When those two versions have different signatures, jfr-enabled build may pass, and jfr-disabled build may fail. The way out is to rewire events generator to produce consistent signatures for events. This should be more future-proof than just fixing the printers for empty events. The downside is that autogenerated events look a bit uglier with empty bodies, but that seems to be a fair price to pay for automatic consistency. Testing: Linux/x86_64 +jfr/-jfr build, Linux/x86_64 run-test jdk/jfr Thanks, -Aleksey From markus.gronlund at oracle.com Fri Sep 28 20:46:19 2018 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Fri, 28 Sep 2018 13:46:19 -0700 (PDT) Subject: RFR (S) 8211239: Build fails without JFR: empty JFR events signatures mismatch In-Reply-To: References: Message-ID: <1a971dfb-e2f4-441d-8a5d-4aaa1ae266c1@default> Hi Aleksey, I am currently travelling and I have not been following this in detail. As I understand it, JDK-8196341, extended the signatures for the commit() methods, but the associated !INCLUDE_JFR section was not updated, causing compilation errors. I have not checked everything in detail, but it seems the fix does add those missing signature(s). I am ok with this from a JFR perspective. Thanks for addressing Markus -----Original Message----- From: Aleksey Shipilev Sent: den 28 september 2018 13:25 To: hotspot-dev at openjdk.java.net Subject: RFR (S) 8211239: Build fails without JFR: empty JFR events signatures mismatch Bug: https://bugs.openjdk.java.net/browse/JDK-8211239 Fix: http://cr.openjdk.java.net/~shade/8211239/webrev.02/ Anything that disables JFR as JVM feature would break the build. It started to happen with Zero, AIX, Sparc64 builds after recent G1+JFR improvement. The underlying reason for this breakage is that JFR events generator produces two versions for each event: "full" and "empty", and the version is then selected by INCLUDE_JFR macro during build time. When those two versions have different signatures, jfr-enabled build may pass, and jfr-disabled build may fail. The way out is to rewire events generator to produce consistent signatures for events. This should be more future-proof than just fixing the printers for empty events. The downside is that autogenerated events look a bit uglier with empty bodies, but that seems to be a fair price to pay for automatic consistency. Testing: Linux/x86_64 +jfr/-jfr build, Linux/x86_64 run-test jdk/jfr Thanks, -Aleksey From coleen.phillimore at oracle.com Fri Sep 28 21:07:34 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 28 Sep 2018 17:07:34 -0400 Subject: RFR: JDK-8211241: Missing obj equals in TemplateTable::fast_aldc In-Reply-To: References: Message-ID: <2f9e2610-68ff-2da6-6a71-2398381a601a@oracle.com> This looks good. Did you search for other cmpptr() to see if they should be cmpoop?? Wonder if you can do a negative verify_oop in cmpptr.? Probably not. Lots of people look at the interpreter code, but they're on hotspot-runtime. Thanks, Coleen On 9/27/18 4:33 PM, Roman Kennke wrote: > Included hotspot-runtime-dev because it's an interpreter bug, excluded > hotspot-compiler dev, and also here's all the links: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211241 > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8211241/webrev.00/ > > It's never been quite clear to me where to put interpreter bugs. > hotspot/runtime in Jira and hotspot-runtime-dev on mailing lists? Is > that right? > > Thanks, Roman > > > >> TemplateTable::fast_aldc compares the just-loaded reference with >> Universe::the_null_sentinel. If it really is that null-sentinel, we may >> get a false negative (with GCs like Shenandoah that allow both >> from-space and to-space copies of an object to be around), and thus skip >> NULL-ing the ref. In other words, it would allow to get >> the-null-sentinel out into the wild as oop which can cause subtle and >> not-so-subtle bugs. >> >> Fix is easy, call cmpoop() which re-routes through GC-interface for GCs >> that need it: >> >> http://cr.openjdk.java.net/~rkennke/JDK-8211241/webrev.00/ >> >> Testing: hotspot/jtreg:tier1 >> >> Ok? >> >> Roman >> From kim.barrett at oracle.com Fri Sep 28 21:22:48 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 28 Sep 2018 17:22:48 -0400 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> References: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> Message-ID: <47ABAD88-9376-45D3-86DB-16A47B81F061@oracle.com> > On Sep 24, 2018, at 4:31 PM, Magnus Ihse Bursie wrote: > The second warning about the copy constructor is, for what I can tell, a highly valid warning and the code it warned on was indeed broken. As far as I can tell, in a derived copy constructor you should always explicitly initialize the base class. I agree the copy constructor warnings are correct and indicate potentially serious bugs. These copy constructor changes look correct to me. The code that is being missed because of this bug is debug-only usage verification. I think bad things might happen if we C-heap allocated a ResourceObj and then copied that object. Maybe we fortuitously don?t ever do that? It?s unfortunate that the only way to get these warnings from gcc seems to be via -Wextra. > Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8211073-remove-Wno-extra-from-hotspot/webrev.01 > > /Magnus > > [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html From mikael.vidstedt at oracle.com Fri Sep 28 22:03:28 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 28 Sep 2018 15:03:28 -0700 Subject: 8211291: Backout JDK-8210842 Handle JNIGlobalRefLocker.cpp Message-ID: <03F0AC3F-3F37-4F95-B06B-75DFDD97CF1A@oracle.com> Backout of JDK-8210842 since it seems to cause some build issues on Windows and Solaris: bug: https://bugs.openjdk.java.net/browse/JDK-8211291 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211291/webrev.00/open/webrev/ Produced using: hg backout -r 2712735bc434 Running a job to make sure it resolves the build issues. Cheers, Mikael From igor.ignatyev at oracle.com Fri Sep 28 22:03:26 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 28 Sep 2018 15:03:26 -0700 Subject: 8211291: Backout JDK-8210842 Handle JNIGlobalRefLocker.cpp In-Reply-To: <03F0AC3F-3F37-4F95-B06B-75DFDD97CF1A@oracle.com> References: <03F0AC3F-3F37-4F95-B06B-75DFDD97CF1A@oracle.com> Message-ID: <927FCC38-6475-4F77-B056-6F2DA33BD612@oracle.com> Looks good to me. -- Igor > On Sep 28, 2018, at 3:03 PM, Mikael Vidstedt wrote: > > > Backout of JDK-8210842 since it seems to cause some build issues on Windows and Solaris: > > bug: https://bugs.openjdk.java.net/browse/JDK-8211291 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211291/webrev.00/open/webrev/ > > Produced using: > > hg backout -r 2712735bc434 > > Running a job to make sure it resolves the build issues. > > Cheers, > Mikael > From jcbeyler at google.com Fri Sep 28 22:19:37 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 28 Sep 2018 15:19:37 -0700 Subject: 8211291: Backout JDK-8210842 Handle JNIGlobalRefLocker.cpp In-Reply-To: <927FCC38-6475-4F77-B056-6F2DA33BD612@oracle.com> References: <03F0AC3F-3F37-4F95-B06B-75DFDD97CF1A@oracle.com> <927FCC38-6475-4F77-B056-6F2DA33BD612@oracle.com> Message-ID: Also looks good to me; my sincere apologies for breaking things... Jc On Fri, Sep 28, 2018 at 3:02 PM Igor Ignatyev wrote: > Looks good to me. > -- Igor > > > On Sep 28, 2018, at 3:03 PM, Mikael Vidstedt > wrote: > > > > > > Backout of JDK-8210842 since it seems to cause some build issues on > Windows and Solaris: > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8211291 > > webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8211291/webrev.00/open/webrev/ > > > > > > Produced using: > > > > hg backout -r 2712735bc434 > > > > Running a job to make sure it resolves the build issues. > > > > Cheers, > > Mikael > > > > -- Thanks, Jc From glaubitz at physik.fu-berlin.de Fri Sep 28 22:44:57 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Sat, 29 Sep 2018 00:44:57 +0200 Subject: Build broken on linux-sparc64 In-Reply-To: References: <4403fa35-34a5-4edd-1348-d453c531048f@physik.fu-berlin.de> Message-ID: On 9/28/18 4:41 PM, Aleksey Shipilev wrote: > This looks like: > https://bugs.openjdk.java.net/browse/JDK-8211228 > https://bugs.openjdk.java.net/browse/JDK-8211239 I can confirm that JDK-8211239 fixes linux-sparc64 and linux-zero for me. 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 shrutika.ukey4 at gmail.com Thu Sep 27 07:37:36 2018 From: shrutika.ukey4 at gmail.com (shrutika ukey) Date: Thu, 27 Sep 2018 13:07:36 +0530 Subject: JVM architecture video request Message-ID: Hello I want to learn how JVM works, the architecture right from Class loaders. But I do not find any video on "Oracle Developers" you tube channel Kindly share any video, overview will also do -- Best Regards, Shrutika From magnus.ihse.bursie at oracle.com Sat Sep 29 17:13:33 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 29 Sep 2018 19:13:33 +0200 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: References: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> <07a8f2ff-aefb-be70-8002-c12a37d30b90@oracle.com> Message-ID: On 2018-09-27 16:31, David Holmes wrote: > Hi Magnus, > > On 27/09/2018 8:47 AM, Magnus Ihse Bursie wrote: >> Anyone from Hotspot who can review the code changes? > > I had looked at this but it is unclear whether the casts are the right > fix or whether we have a poor type selection in the first place. For > example, > > ./share/opto/node.hpp: enum { NO_HASH = 0 }; > > defines NO_HASH which is implicitly treated as int but then it's used > everywhere as uint - which just seems odd. I agree; I started doing such a fix but it felt more invasive than I felt I could defend, so I reverted back to the simplest possible cast. (Which is basically what the compiler did implicitly without the warning.) > > So I'm unclear whether this needs more indepth examination by the > various code owners. Yes, hotspotters, please do have a look. :-) Do I need to split this up in separate parts for different hotspot areas? /Magnus > > Thanks, > David > >> /Magnus >> >> On 2018-09-24 22:31, Magnus Ihse Bursie wrote: >>> The -Wextra option to gcc enables a bunch of useful warnings.[1] >>> Some of them, but not all, can be individually enabled or disabled. >>> All other libraries in OpenJDK are compiled with -Wextra, but not >>> Hotspot. Enabling -Wextra on Hotspot triggers a couple of warnings >>> for zero that can be individually disabled. >>> >>> However, -Wextra also includes some check that cannot be disabled >>> individually, so to be able to add this, we must at the same time >>> fix those warnings. >>> >>> The warnings that cannot be disabled and which have been triggered >>> in Hotspot is "enumeral and non-enumeral type in conditional >>> expression" and "base class should be explicitly initialized in the >>> copy constructor". The former complains about mixing enums and >>> integers in the tertiary operator (x ? enum_val : int_val). If you >>> think that gcc is a bit too picky here, I agree. It's not obvious >>> per se that the added casts improve the code. However, this is the >>> price we need to pay to be able to enable -Wextra, and *that* is >>> something that is likely to improve the code. >>> >>> The second warning about the copy constructor is, for what I can >>> tell, a highly valid warning and the code it warned on was indeed >>> broken. As far as I can tell, in a derived copy constructor you >>> should always explicitly initialize the base class. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8211073-remove-Wno-extra-from-hotspot/webrev.01 >>> >>> >>> /Magnus >>> >>> [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html >>> >> From magnus.ihse.bursie at oracle.com Sat Sep 29 17:36:13 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Sat, 29 Sep 2018 19:36:13 +0200 Subject: RFR: JDK-8211073 Remove -Wno-extra from Hotspot In-Reply-To: <47ABAD88-9376-45D3-86DB-16A47B81F061@oracle.com> References: <671e162b-5580-2a0b-5115-847b8b26c4aa@oracle.com> <47ABAD88-9376-45D3-86DB-16A47B81F061@oracle.com> Message-ID: On 2018-09-28 23:22, Kim Barrett wrote: >> On Sep 24, 2018, at 4:31 PM, Magnus Ihse Bursie wrote: >> The second warning about the copy constructor is, for what I can tell, a highly valid warning and the code it warned on was indeed broken. As far as I can tell, in a derived copy constructor you should always explicitly initialize the base class. > I agree the copy constructor warnings are correct and indicate potentially serious bugs. > These copy constructor changes look correct to me. > > The code that is being missed because of this bug is debug-only usage verification. I think > bad things might happen if we C-heap allocated a ResourceObj and then copied that object. > Maybe we fortuitously don?t ever do that? If we had triggered problems we'd probably found out the issue by now, so its likely we're not doing anything that causes this to happen currently. But latent bugs like these are scary, and unnecessary, especially if we can get the compiler's help to avoid them. > It?s unfortunate that the only way to get these warnings from gcc seems to be via -Wextra. I agree, it's unfortunate. -Wextra in gcc actually means two things: a bunch of "extra" warnings, that you can turn on or off as a group only by enabling or disabling -Wextra, and a set of separate warnings that this option also turns on by default. The latter is more of a convenience to get a set of warnings that the gcc authors recommend for more in-depth warnings. Since they can be individually disabled, we don't need to care much about them. In regard to your previous mail, there has not been much change in the scope of -Wextra. Between gcc 4.8 and 7.3, no changes were made in the first part (the "extra" warnings), and only four more warnings were added to the second part (-Wcast-function-type, -Wimplicit-fallthrough=3, -Wredundant-move and -Wshift-negative-value), all of which can be turned off if we don't want them. In general, we try to make the product compile without warnings on common platforms, but as you say, unless you use one of the compilers that are regularly used (at Oracle or elsewhere), there's a risk of triggering new warnings. However, using configure --disable-warnings-as-errors makes the build pass anyway, and is already commonly in use by those building on more exotic platforms or compiler versions. I would have preferred to have individual warnings to enable, but gcc has not moved all warnings from -Wextra to individual warnings (new warnings, though, have all been given individual names). Since the warnings, as you agree, can find actual bugs, I think it's worth the hassle to enable -Wextra. (We already do that for all native code in OpenJDK, except hotspot, btw.) /Magnus > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211073 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8211073-remove-Wno-extra-from-hotspot/webrev.01 >> >> /Magnus >> >> [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html > From kim.barrett at oracle.com Sun Sep 30 01:23:41 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 29 Sep 2018 21:23:41 -0400 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang Message-ID: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> Please review this change to HotSpot build options and code to eliminate the suppression of deprecation warnings when building with clang. There are two code changes: (1) Replace calls to finite() with C99 isfinite(). This also affects gcc-based builds, but isfinite has been supported there for a long time too. (2) Remove call to _dyld_bind_fully_image_containing_address, which seems to have been deprecated since MacOSX 10.5. Instead use the recommended replacement "dlopen(RTLD_NOW)". However, it might be we don't need to do anything here anymore. I ran tier1-5 test without the dlopen without any problems. But I'm not familiar with the original problem, so not sure that's convincing. Perhaps another RFE to determine whether this code can be deleted? CR: https://bugs.openjdk.java.net/browse/JDK-8211296 Webrev: http://cr.openjdk.java.net/~kbarrett/8211296/open.00/ Testing: Mach5 tier1, tier1-5 on MacOSX. From david.holmes at oracle.com Sun Sep 30 20:51:16 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Oct 2018 06:51:16 +1000 Subject: RFR: 8211296: Remove HotSpot deprecation warning suppression for Mac/clang In-Reply-To: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> References: <050B2C90-F236-4C15-8C32-E54B63C152C6@oracle.com> Message-ID: Hi Kim, On 30/09/2018 11:23 AM, Kim Barrett wrote: > Please review this change to HotSpot build options and code to > eliminate the suppression of deprecation warnings when building with > clang. Just as a historical note the no-deprecation-warning was only applied to os_bsd.cpp in the distant past. No idea when it became global. > There are two code changes: > > (1) Replace calls to finite() with C99 isfinite(). This also affects > gcc-based builds, but isfinite has been supported there for a long > time too. Ok. > (2) Remove call to _dyld_bind_fully_image_containing_address, which > seems to have been deprecated since MacOSX 10.5. Instead use the > recommended replacement "dlopen(RTLD_NOW)". However, it might be we > don't need to do anything here anymore. I ran tier1-5 test without > the dlopen without any problems. But I'm not familiar with the > original problem, so not sure that's convincing. Perhaps another RFE > to determine whether this code can be deleted? The use of _dyld_bind_fully_image_containing_address, as per the comment is a workaround to force full binding of symbols in the library. I don't know where the "callbacks" referred to in the comment come from or why they may be unaligned - this seems to be day 1 code for the OS X port from 2008: http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/be94a5de4d32#l75.4001 I've cc'd the macosx-port-dev mailing list in case someone still subscribed there might know the answer. If you don't have unaligned symbols then the workaround is not needed. In that case the replacement dlopen is also not needed (and it isn't needed to actually dlopen anything as you are opening the current library!). So it is not surprising that removing the dlopen causes no problem. With the dlopen in place however the code looks very strange and there's no guarantee it actually engages the workaround of the original function. So I'd say this either has to be removed completely or else left alone. Thanks, David > CR: > https://bugs.openjdk.java.net/browse/JDK-8211296 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8211296/open.00/ > > Testing: > Mach5 tier1, tier1-5 on MacOSX. > >