From HORIE at jp.ibm.com Sun Sep 2 23:28:28 2018 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Mon, 3 Sep 2018 08:28:28 +0900 Subject: RFR: 8208171: PPC64: Enrich SLP support In-Reply-To: <1390fbbb7b6147ce8570ab977a670f05@sap.com> References:

<346da54af45243c4bdaf475f118a450d@sap.com> <1390fbbb7b6147ce8570ab977a670f05@sap.com> Message-ID: Thanks a lot, Martin! Best regards, -- Michihiro, IBM Research - Tokyo From: "Doerr, Martin" To: Michihiro Horie Cc: "Lindenmaier, Goetz" , Gustavo Romero , "hotspot-dev at openjdk.java.net" , "ppc-aix-port-dev at openjdk.java.net" , "Simonis, Volker" Date: 2018/09/01 00:28 Subject: RE: RFR: 8208171: PPC64: Enrich SLP support Hi Michihiro, thanks for the update. Looks correct, now. I can also sponsor this change. Does anybody else want to review it? Best regards, Martin From: Michihiro Horie Sent: Freitag, 31. August 2018 15:16 To: Doerr, Martin Cc: Lindenmaier, Goetz ; Gustavo Romero ; 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 Martin, Thank you so much for giving comments! I fixed version checks and indentation. New webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.02/ Best regards, -- Michihiro, IBM Research - Tokyo Inactive hide details for "Doerr, Martin" ---2018/08/29 02:35:05---Hi Michihiro, thank you for implementing it. I have just tak"Doerr, Martin" ---2018/08/29 02:35:05---Hi Michihiro, thank you for implementing it. I have just taken a first look at your webrev.01. From: "Doerr, Martin" To: Gustavo Romero , Michihiro Horie < HORIE at jp.ibm.com> Cc: "Lindenmaier, Goetz" , " hotspot-dev at openjdk.java.net" , " ppc-aix-port-dev at openjdk.java.net" , "Simonis, Volker" Date: 2018/08/29 02:35 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" < martin.doerr at sap.com> > 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 > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From thomas.stuefe at gmail.com Mon Sep 3 09:45:39 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 3 Sep 2018 11:45:39 +0200 Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory type Message-ID: Hi all, may I please have reviews for this small, AIX-only change. cr: http://cr.openjdk.java.net/~stuefe/webrevs/8210314-aix-NMT-does-not-show-safepoint-memory/webrev.00/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8210314 On AIX, we have our own initialization for the safepoint mechanism. We missed registering the polling page with NMT, which the generic code path did. This patch adds that. Side note: We are different for two reasons. One, on ppc we use per default SIGTRAP for safepoint signalling, which can be switched off though. Second, on AIX, we cannot use os::reserve_memory() to obtain a polling page since that memory may not protectable (if it uses sysV shmat). Hence, the AIX specific coding. Best Regards, Thomas From goetz.lindenmaier at sap.com Mon Sep 3 10:08:21 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 3 Sep 2018 10:08:21 +0000 Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory type In-Reply-To: References: Message-ID: <10f7f6830045418d9bc2d7e16c3a711b@sap.com> Hi Thomas, Thanks for fixing this! I had given this a try before, but only managed to fix the linux ppc platforms :) Looks good. Best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Thomas St?fe > Sent: Montag, 3. September 2018 11:46 > To: Hotspot dev runtime ; ppc- > aix-port-dev at openjdk.java.net > Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory > type > > Hi all, > > may I please have reviews for this small, AIX-only change. > > cr: http://cr.openjdk.java.net/~stuefe/webrevs/8210314-aix-NMT-does- > not-show-safepoint-memory/webrev.00/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8210314 > > On AIX, we have our own initialization for the safepoint mechanism. We > missed registering the polling page with NMT, which the generic code > path did. This patch adds that. > > Side note: > > We are different for two reasons. One, on ppc we use per default > SIGTRAP for safepoint signalling, which can be switched off though. > Second, on AIX, we cannot use os::reserve_memory() to obtain a polling > page since that memory may not protectable (if it uses sysV shmat). > Hence, the AIX specific coding. > > Best Regards, Thomas From matthias.baesken at sap.com Mon Sep 3 10:29:51 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 3 Sep 2018 10:29:51 +0000 Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory type In-Reply-To: References: Message-ID: <01cf43403683423184ef22dab760923c@sap.com> Hi Thomas, looks good to me ( not a Reviewer however). One other small difference I noticed when comparing AIX to other UNIX implementations (e.g. linux / bsd ) : In perfMemory_aix.cpp / mmap_create_shared and mmap_attach_shared we call MemTracker::record_virtual_memory_reserve(...) While in perfMemory_linux.cpp (bsd and solaris as well) we call MemTracker::record_virtual_memory_reserve_and_commit(...) Is there really a need for different call on AIX ? And the z GC code base ( jdk/src/hotspot/os_cpu/linux_x86/gc/z/) contains also a couple of mmap calls , wonder where those are recorded . Best regards, Matthias > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Thomas St?fe > Sent: Montag, 3. September 2018 11:46 > To: Hotspot dev runtime ; ppc- > aix-port-dev at openjdk.java.net > Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory > type > > Hi all, > > may I please have reviews for this small, AIX-only change. > > cr: http://cr.openjdk.java.net/~stuefe/webrevs/8210314-aix-NMT-does- > not-show-safepoint-memory/webrev.00/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8210314 > > On AIX, we have our own initialization for the safepoint mechanism. We > missed registering the polling page with NMT, which the generic code > path did. This patch adds that. > > Side note: > > We are different for two reasons. One, on ppc we use per default > SIGTRAP for safepoint signalling, which can be switched off though. > Second, on AIX, we cannot use os::reserve_memory() to obtain a polling > page since that memory may not protectable (if it uses sysV shmat). > Hence, the AIX specific coding. > > Best Regards, Thomas From thomas.stuefe at gmail.com Mon Sep 3 11:26:40 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 3 Sep 2018 13:26:40 +0200 Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory type In-Reply-To: <01cf43403683423184ef22dab760923c@sap.com> References: <01cf43403683423184ef22dab760923c@sap.com> Message-ID: Hi Matthias, thanks for the review. On Mon, Sep 3, 2018 at 12:29 PM, Baesken, Matthias wrote: > Hi Thomas, looks good to me ( not a Reviewer however). > > > One other small difference I noticed when comparing AIX to other UNIX implementations (e.g. linux / bsd ) : > > In perfMemory_aix.cpp / mmap_create_shared and mmap_attach_shared we call > > MemTracker::record_virtual_memory_reserve(...) > > While in perfMemory_linux.cpp (bsd and solaris as well) we call > > MemTracker::record_virtual_memory_reserve_and_commit(...) > > > Is there really a need for different call on AIX ? > > In short, record_virtual_memory_reserve() should only be used whereever mmap( ... MAP_NORESERVE ...) is used. So, MemTracker::record_virtual_memory_reserve_and_commit(...) would be more correct. However, on AIX we have no explicit commit (os::commit()) is a noop, and there is no MAP_NORESERVE - the system just provides swapping space by default as needed. So, this aspect of NMT - the "committed" numbers for virtual memory - is right now broken, just a rough estimate, and right now I have absolutely no clue how to fix it. Best Regards, Thomas > > And the z GC code base ( jdk/src/hotspot/os_cpu/linux_x86/gc/z/) contains also a couple of mmap calls , wonder where those are recorded . > > > Best regards, Matthias > > >> -----Original Message----- >> From: ppc-aix-port-dev On >> Behalf Of Thomas St?fe >> Sent: Montag, 3. September 2018 11:46 >> To: Hotspot dev runtime ; ppc- >> aix-port-dev at openjdk.java.net >> Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory >> type >> >> Hi all, >> >> may I please have reviews for this small, AIX-only change. >> >> cr: http://cr.openjdk.java.net/~stuefe/webrevs/8210314-aix-NMT-does- >> not-show-safepoint-memory/webrev.00/webrev/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8210314 >> >> On AIX, we have our own initialization for the safepoint mechanism. We >> missed registering the polling page with NMT, which the generic code >> path did. This patch adds that. >> >> Side note: >> >> We are different for two reasons. One, on ppc we use per default >> SIGTRAP for safepoint signalling, which can be switched off though. >> Second, on AIX, we cannot use os::reserve_memory() to obtain a polling >> page since that memory may not protectable (if it uses sysV shmat). >> Hence, the AIX specific coding. >> >> Best Regards, Thomas From thomas.stuefe at gmail.com Mon Sep 3 11:26:49 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 3 Sep 2018 13:26:49 +0200 Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory type In-Reply-To: <10f7f6830045418d9bc2d7e16c3a711b@sap.com> References: <10f7f6830045418d9bc2d7e16c3a711b@sap.com> Message-ID: Thanks :) ..Thomas On Mon, Sep 3, 2018 at 12:08 PM, Lindenmaier, Goetz wrote: > Hi Thomas, > > Thanks for fixing this! > I had given this a try before, but only managed to fix the linux ppc platforms :) > > Looks good. > > Best regards, > Goetz. > >> -----Original Message----- >> From: ppc-aix-port-dev On >> Behalf Of Thomas St?fe >> Sent: Montag, 3. September 2018 11:46 >> To: Hotspot dev runtime ; ppc- >> aix-port-dev at openjdk.java.net >> Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory >> type >> >> Hi all, >> >> may I please have reviews for this small, AIX-only change. >> >> cr: http://cr.openjdk.java.net/~stuefe/webrevs/8210314-aix-NMT-does- >> not-show-safepoint-memory/webrev.00/webrev/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8210314 >> >> On AIX, we have our own initialization for the safepoint mechanism. We >> missed registering the polling page with NMT, which the generic code >> path did. This patch adds that. >> >> Side note: >> >> We are different for two reasons. One, on ppc we use per default >> SIGTRAP for safepoint signalling, which can be switched off though. >> Second, on AIX, we cannot use os::reserve_memory() to obtain a polling >> page since that memory may not protectable (if it uses sysV shmat). >> Hence, the AIX specific coding. >> >> Best Regards, Thomas From martin.doerr at sap.com Mon Sep 3 12:36:59 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 3 Sep 2018 12:36:59 +0000 Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory type In-Reply-To: References: <01cf43403683423184ef22dab760923c@sap.com> Message-ID: <8205cd9de39c413d9f57ea85d3e4758f@sap.com> Hi Thomas, thanks for explaining. I think using "record_virtual_memory_reserve_and_commit" makes sense because it combines "reserve" and "commit" which matches what the implementation does. The change looks good to me. Thanks, Martin -----Original Message----- From: ppc-aix-port-dev On Behalf Of Thomas St?fe Sent: Montag, 3. September 2018 13:27 To: Baesken, Matthias Cc: ppc-aix-port-dev at openjdk.java.net; Hotspot dev runtime Subject: Re: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory type Hi Matthias, thanks for the review. On Mon, Sep 3, 2018 at 12:29 PM, Baesken, Matthias wrote: > Hi Thomas, looks good to me ( not a Reviewer however). > > > One other small difference I noticed when comparing AIX to other UNIX implementations (e.g. linux / bsd ) : > > In perfMemory_aix.cpp / mmap_create_shared and mmap_attach_shared we call > > MemTracker::record_virtual_memory_reserve(...) > > While in perfMemory_linux.cpp (bsd and solaris as well) we call > > MemTracker::record_virtual_memory_reserve_and_commit(...) > > > Is there really a need for different call on AIX ? > > In short, record_virtual_memory_reserve() should only be used whereever mmap( ... MAP_NORESERVE ...) is used. So, MemTracker::record_virtual_memory_reserve_and_commit(...) would be more correct. However, on AIX we have no explicit commit (os::commit()) is a noop, and there is no MAP_NORESERVE - the system just provides swapping space by default as needed. So, this aspect of NMT - the "committed" numbers for virtual memory - is right now broken, just a rough estimate, and right now I have absolutely no clue how to fix it. Best Regards, Thomas > > And the z GC code base ( jdk/src/hotspot/os_cpu/linux_x86/gc/z/) contains also a couple of mmap calls , wonder where those are recorded . > > > Best regards, Matthias > > >> -----Original Message----- >> From: ppc-aix-port-dev On >> Behalf Of Thomas St?fe >> Sent: Montag, 3. September 2018 11:46 >> To: Hotspot dev runtime ; ppc- >> aix-port-dev at openjdk.java.net >> Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory >> type >> >> Hi all, >> >> may I please have reviews for this small, AIX-only change. >> >> cr: http://cr.openjdk.java.net/~stuefe/webrevs/8210314-aix-NMT-does- >> not-show-safepoint-memory/webrev.00/webrev/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8210314 >> >> On AIX, we have our own initialization for the safepoint mechanism. We >> missed registering the polling page with NMT, which the generic code >> path did. This patch adds that. >> >> Side note: >> >> We are different for two reasons. One, on ppc we use per default >> SIGTRAP for safepoint signalling, which can be switched off though. >> Second, on AIX, we cannot use os::reserve_memory() to obtain a polling >> page since that memory may not protectable (if it uses sysV shmat). >> Hence, the AIX specific coding. >> >> Best Regards, Thomas From thomas.stuefe at gmail.com Mon Sep 3 12:39:54 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 3 Sep 2018 14:39:54 +0200 Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory type In-Reply-To: <8205cd9de39c413d9f57ea85d3e4758f@sap.com> References: <01cf43403683423184ef22dab760923c@sap.com> <8205cd9de39c413d9f57ea85d3e4758f@sap.com> Message-ID: Hi Martin, On Mon, Sep 3, 2018 at 2:36 PM, Doerr, Martin wrote: > Hi Thomas, > > thanks for explaining. I think using "record_virtual_memory_reserve_and_commit" makes sense because it combines "reserve" and "commit" which matches what the implementation does. > Yes, that was what I was thinking. Save that we do not really commit on AIX, we just think we do. But still slightly more correct than the no-commit version. > The change looks good to me. Thanks. I already pushed, so I cannot add your name to the reviewers list, sorry. ..Thomas > > Thanks, > Martin > > > -----Original Message----- > From: ppc-aix-port-dev On Behalf Of Thomas St?fe > Sent: Montag, 3. September 2018 13:27 > To: Baesken, Matthias > Cc: ppc-aix-port-dev at openjdk.java.net; Hotspot dev runtime > Subject: Re: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory type > > Hi Matthias, > > thanks for the review. > > > On Mon, Sep 3, 2018 at 12:29 PM, Baesken, Matthias > wrote: >> Hi Thomas, looks good to me ( not a Reviewer however). >> >> >> One other small difference I noticed when comparing AIX to other UNIX implementations (e.g. linux / bsd ) : >> >> In perfMemory_aix.cpp / mmap_create_shared and mmap_attach_shared we call >> >> MemTracker::record_virtual_memory_reserve(...) >> >> While in perfMemory_linux.cpp (bsd and solaris as well) we call >> >> MemTracker::record_virtual_memory_reserve_and_commit(...) >> >> >> Is there really a need for different call on AIX ? >> >> > > In short, record_virtual_memory_reserve() should only be used > whereever mmap( ... MAP_NORESERVE ...) is used. So, > MemTracker::record_virtual_memory_reserve_and_commit(...) would be > more correct. > > However, on AIX we have no explicit commit (os::commit()) is a noop, > and there is no MAP_NORESERVE - the system just provides swapping > space by default as needed. So, this aspect of NMT - the "committed" > numbers for virtual memory - is right now broken, just a rough > estimate, and right now I have absolutely no clue how to fix it. > > Best Regards, Thomas > >> >> And the z GC code base ( jdk/src/hotspot/os_cpu/linux_x86/gc/z/) contains also a couple of mmap calls , wonder where those are recorded . >> >> >> Best regards, Matthias >> >> >>> -----Original Message----- >>> From: ppc-aix-port-dev On >>> Behalf Of Thomas St?fe >>> Sent: Montag, 3. September 2018 11:46 >>> To: Hotspot dev runtime ; ppc- >>> aix-port-dev at openjdk.java.net >>> Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory >>> type >>> >>> Hi all, >>> >>> may I please have reviews for this small, AIX-only change. >>> >>> cr: http://cr.openjdk.java.net/~stuefe/webrevs/8210314-aix-NMT-does- >>> not-show-safepoint-memory/webrev.00/webrev/ >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8210314 >>> >>> On AIX, we have our own initialization for the safepoint mechanism. We >>> missed registering the polling page with NMT, which the generic code >>> path did. This patch adds that. >>> >>> Side note: >>> >>> We are different for two reasons. One, on ppc we use per default >>> SIGTRAP for safepoint signalling, which can be switched off though. >>> Second, on AIX, we cannot use os::reserve_memory() to obtain a polling >>> page since that memory may not protectable (if it uses sysV shmat). >>> Hence, the AIX specific coding. >>> >>> Best Regards, Thomas From gromero at linux.vnet.ibm.com Tue Sep 4 13:42:02 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 4 Sep 2018 10:42:02 -0300 Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code Message-ID: Hi, May I please request reviews for this tiny change that fixes two uninitialized variables in PPC64 C1 LIR code? Bug : https://bugs.openjdk.java.net/browse/JDK-8210320 Webrev: http://cr.openjdk.java.net/~gromero/8210320/v1/ GCC 4.8 does not complain about these two uninitialized pointers ('data' and 'md') but more recent versions, like 5.4.0 and 7.3.1, complain about it: In file included from /home/gromero/hg/jdk/jdk/src/hotspot/share/c1/c1_Compilation.hpp:29:0, from /home/gromero/hg/jdk/jdk/src/hotspot/share/precompiled/precompiled.hpp:286: /home/gromero/hg/jdk/jdk/src/hotspot/share/ci/ciMethodData.hpp: In member function ?void LIR_Assembler::emit_typecheck_helper(LIR_OpTypeCheck*, Label*, Label*, Label*)?: /home/gromero/hg/jdk/jdk/src/hotspot/share/ci/ciMethodData.hpp:595:100: warning: ?data? may be used uninitialized in this function [-Wmaybe-uninitialized] int byte_offset_of_slot(ciProfileData* data, ByteSize slot_offset_in_data) { return in_bytes(offset_of_slot(data, slot_offset_in_data)); } ^ /home/gromero/hg/jdk/jdk/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp:2400:18: note: ?data? was declared here ciProfileData* data; ^ /home/gromero/hg/jdk/jdk/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp:2483:78: warning: ?md? may be used uninitialized in this function [-Wmaybe-uninitialized] type_profile_helper(mdo, mdo_offset_bias, md, data, recv, Rtmp1, success); ^ Thank you. Best regards, Gustavo From matthias.baesken at sap.com Tue Sep 4 13:48:54 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 4 Sep 2018 13:48:54 +0000 Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code In-Reply-To: References: Message-ID: <4ca7e1f4303a44df8c0ada10cb402718@sap.com> Hi Gustavo , looks good (not a reviewer however). It might not hurt to initialize md and data as well in the same file in emit_opTypeCheck as well ( even without gcc complaints ) : void LIR_Assembler::emit_opTypeCheck(LIR_OpTypeCheck* op) { LIR_Code code = op->code(); if (code == lir_store_check) { Register value = op->object()->as_register(); Register array = op->array()->as_register(); Register k_RInfo = op->tmp1()->as_register(); Register klass_RInfo = op->tmp2()->as_register(); Register Rtmp1 = op->tmp3()->as_register(); bool should_profile = op->should_profile(); __ verify_oop(value); CodeStub* stub = op->stub(); // Check if it needs to be profiled. ciMethodData* md; ciProfileData* data; ... Best regards, Matthias > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Gustavo Romero > Sent: Dienstag, 4. September 2018 15:42 > To: hotspot-compiler-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler > code > Importance: High > > Hi, > > May I please request reviews for this tiny change that fixes two > uninitialized variables in PPC64 C1 LIR code? > > Bug : https://bugs.openjdk.java.net/browse/JDK-8210320 > Webrev: http://cr.openjdk.java.net/~gromero/8210320/v1/ > > GCC 4.8 does not complain about these two uninitialized pointers ('data' > and 'md') but more recent versions, like 5.4.0 and 7.3.1, complain about > it: > > In file included from > /home/gromero/hg/jdk/jdk/src/hotspot/share/c1/c1_Compilation.hpp:29:0, > from > /home/gromero/hg/jdk/jdk/src/hotspot/share/precompiled/precompiled.h > pp:286: > /home/gromero/hg/jdk/jdk/src/hotspot/share/ci/ciMethodData.hpp: In > member function ?void > LIR_Assembler::emit_typecheck_helper(LIR_OpTypeCheck*, Label*, Label*, > Label*)?: > /home/gromero/hg/jdk/jdk/src/hotspot/share/ci/ciMethodData.hpp:595:10 > 0: warning: ?data? may be used uninitialized in this function [-Wmaybe- > uninitialized] > int byte_offset_of_slot(ciProfileData* data, ByteSize > slot_offset_in_data) { return in_bytes(offset_of_slot(data, > slot_offset_in_data)); } > ^ > /home/gromero/hg/jdk/jdk/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cp > p:2400:18: note: ?data? was declared here > ciProfileData* data; > ^ > /home/gromero/hg/jdk/jdk/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cp > p:2483:78: warning: ?md? may be used uninitialized in this function [- > Wmaybe-uninitialized] > type_profile_helper(mdo, mdo_offset_bias, md, data, recv, Rtmp1, > success); > ^ > > Thank you. > > Best regards, > Gustavo From shade at redhat.com Tue Sep 4 13:49:12 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Sep 2018 15:49:12 +0200 Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code In-Reply-To: References: Message-ID: <36d840d7-1050-80a4-5e78-fdb36a734702@redhat.com> On 09/04/2018 03:42 PM, Gustavo Romero wrote: > May I please request reviews for this tiny change that fixes two > uninitialized variables in PPC64 C1 LIR code? > > Bug?? : https://bugs.openjdk.java.net/browse/JDK-8210320 > Webrev: http://cr.openjdk.java.net/~gromero/8210320/v1/ Looks good and trivial to me. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gromero at linux.vnet.ibm.com Tue Sep 4 14:11:05 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 4 Sep 2018 11:11:05 -0300 Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code In-Reply-To: <36d840d7-1050-80a4-5e78-fdb36a734702@redhat.com> References: <36d840d7-1050-80a4-5e78-fdb36a734702@redhat.com> Message-ID: <96db713b-a1af-d0f6-55fe-053f4780dab8@linux.vnet.ibm.com> Hi Matthias and Aleksey, Thanks for reviewing it. On 09/04/2018 10:49 AM, Aleksey Shipilev wrote: > On 09/04/2018 03:42 PM, Gustavo Romero wrote: >> May I please request reviews for this tiny change that fixes two >> uninitialized variables in PPC64 C1 LIR code? >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8210320 >> Webrev: http://cr.openjdk.java.net/~gromero/8210320/v1/ > > Looks good and trivial to me. Aleksey, I've updated that change to include another case pointed out by Matthias: http://cr.openjdk.java.net/~gromero/8210320/v2/ I think it's still trivial as before? If so it means I can push it once I receive a second OK from you? I also think I don't need to push it first to the 'submit' repo since it's a PPC64-only change. Is that correct? Thank you. Best regards, Gustavo From martin.doerr at sap.com Tue Sep 4 14:12:09 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 4 Sep 2018 14:12:09 +0000 Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code In-Reply-To: References: Message-ID: Hi Gustavo, it's not a real bug, just a build warning. But it needs to get fixed. Thanks for doing it. Reviewed. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev On Behalf Of Gustavo Romero Sent: Dienstag, 4. September 2018 15:42 To: hotspot-compiler-dev at openjdk.java.net Cc: ppc-aix-port-dev at openjdk.java.net Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code Importance: High Hi, May I please request reviews for this tiny change that fixes two uninitialized variables in PPC64 C1 LIR code? Bug : https://bugs.openjdk.java.net/browse/JDK-8210320 Webrev: http://cr.openjdk.java.net/~gromero/8210320/v1/ GCC 4.8 does not complain about these two uninitialized pointers ('data' and 'md') but more recent versions, like 5.4.0 and 7.3.1, complain about it: In file included from /home/gromero/hg/jdk/jdk/src/hotspot/share/c1/c1_Compilation.hpp:29:0, from /home/gromero/hg/jdk/jdk/src/hotspot/share/precompiled/precompiled.hpp:286: /home/gromero/hg/jdk/jdk/src/hotspot/share/ci/ciMethodData.hpp: In member function ?void LIR_Assembler::emit_typecheck_helper(LIR_OpTypeCheck*, Label*, Label*, Label*)?: /home/gromero/hg/jdk/jdk/src/hotspot/share/ci/ciMethodData.hpp:595:100: warning: ?data? may be used uninitialized in this function [-Wmaybe-uninitialized] int byte_offset_of_slot(ciProfileData* data, ByteSize slot_offset_in_data) { return in_bytes(offset_of_slot(data, slot_offset_in_data)); } ^ /home/gromero/hg/jdk/jdk/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp:2400:18: note: ?data? was declared here ciProfileData* data; ^ /home/gromero/hg/jdk/jdk/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp:2483:78: warning: ?md? may be used uninitialized in this function [-Wmaybe-uninitialized] type_profile_helper(mdo, mdo_offset_bias, md, data, recv, Rtmp1, success); ^ Thank you. Best regards, Gustavo From martin.doerr at sap.com Tue Sep 4 14:15:29 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 4 Sep 2018 14:15:29 +0000 Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code In-Reply-To: <96db713b-a1af-d0f6-55fe-053f4780dab8@linux.vnet.ibm.com> References: <36d840d7-1050-80a4-5e78-fdb36a734702@redhat.com> <96db713b-a1af-d0f6-55fe-053f4780dab8@linux.vnet.ibm.com> Message-ID: Hi Gustavo, > I think it's still trivial as before? Yes. > If so it means I can push it once I receive a second OK from you? > > I also think I don't need to push it first to the 'submit' repo since it's > a PPC64-only change. Is that correct? That's fine (assuming you have run a local build). Best regards, Martin -----Original Message----- From: hotspot-compiler-dev On Behalf Of Gustavo Romero Sent: Dienstag, 4. September 2018 16:11 To: Aleksey Shipilev ; hotspot-compiler-dev at openjdk.java.net; Baesken, Matthias Cc: ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code Hi Matthias and Aleksey, Thanks for reviewing it. On 09/04/2018 10:49 AM, Aleksey Shipilev wrote: > On 09/04/2018 03:42 PM, Gustavo Romero wrote: >> May I please request reviews for this tiny change that fixes two >> uninitialized variables in PPC64 C1 LIR code? >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8210320 >> Webrev: http://cr.openjdk.java.net/~gromero/8210320/v1/ > > Looks good and trivial to me. Aleksey, I've updated that change to include another case pointed out by Matthias: http://cr.openjdk.java.net/~gromero/8210320/v2/ I think it's still trivial as before? If so it means I can push it once I receive a second OK from you? I also think I don't need to push it first to the 'submit' repo since it's a PPC64-only change. Is that correct? Thank you. Best regards, Gustavo From shade at redhat.com Tue Sep 4 14:15:32 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Sep 2018 16:15:32 +0200 Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code In-Reply-To: <96db713b-a1af-d0f6-55fe-053f4780dab8@linux.vnet.ibm.com> References: <36d840d7-1050-80a4-5e78-fdb36a734702@redhat.com> <96db713b-a1af-d0f6-55fe-053f4780dab8@linux.vnet.ibm.com> Message-ID: On 09/04/2018 04:11 PM, Gustavo Romero wrote: > http://cr.openjdk.java.net/~gromero/8210320/v2/ > > I think it's still trivial as before? Yes. > If so it means I can push it once I receive a second OK from you? Yes, this is trivial, and AFAIU only one Reviewer is required for trivial issues. > I also think I don't need to push it first to the 'submit' repo since it's > a PPC64-only change. Is that correct? Yes, I don't see the need to test trivial patches like this with submit repo. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gromero at linux.vnet.ibm.com Tue Sep 4 14:47:54 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 4 Sep 2018 11:47:54 -0300 Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code In-Reply-To: References: Message-ID: <9accaa5c-5bd5-b07f-e246-c3956bff5643@linux.vnet.ibm.com> Hi Martin! On 09/04/2018 11:12 AM, Doerr, Martin wrote: > Hi Gustavo, > > it's not a real bug, just a build warning. But it needs to get fixed. Thanks for doing it. Reviewed. Thanks for reviewing it. Yes, I agree. Btw, I tried to precisely determine which change was introduced in gcc 7.3 (for instance) hoping it was only a matter of an additional -Wextra or -Wall in a gcc spec but it turned out that that was not the case apparently... I could not find a reasonable change in gcc flags or source code that might cause such a warnings when gcc 7.3 is used. I've create a "test case" from JVM code for that [1] (which is still 4.4 MiB since I didn't have the change to prune it further). But curious enough although the following simple code really triggers the same warning _both_ on gcc 4.8 and 7.3 when compiled with: $ g++ -Wuninitialized -O3 mu.cpp -c -o mu mu.cpp: void foo(int x) { printf("%d\n", x+1); } int main(int argc, char** argv) { int x; switch (argc) { case 1: x = 1; break; case 2: x = 4; break; case 3: x = 5; } foo(x); } code [1] only triggers the warning in question when gcc 7.3 is used (using the exact same flags): $ g++ -Wuninitialized -O3 ok.cpp -c -o ok.o Passing '-v' to gcc to check the flags from spec didnt show any clue. Toolchain folks also were not able to tell any differences that could account for that behavior on gcc 7.3 without a detailed look... Anyway, it's only a note :) Thanks. Best regards, Gustavo [1] http://cr.openjdk.java.net/~gromero/misc/ok.cpp > Best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev On Behalf Of Gustavo Romero > Sent: Dienstag, 4. September 2018 15:42 > To: hotspot-compiler-dev at openjdk.java.net > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code > Importance: High > > Hi, > > May I please request reviews for this tiny change that fixes two > uninitialized variables in PPC64 C1 LIR code? > > Bug : https://bugs.openjdk.java.net/browse/JDK-8210320 > Webrev: http://cr.openjdk.java.net/~gromero/8210320/v1/ > > GCC 4.8 does not complain about these two uninitialized pointers ('data' > and 'md') but more recent versions, like 5.4.0 and 7.3.1, complain about > it: > > In file included from /home/gromero/hg/jdk/jdk/src/hotspot/share/c1/c1_Compilation.hpp:29:0, > from /home/gromero/hg/jdk/jdk/src/hotspot/share/precompiled/precompiled.hpp:286: > /home/gromero/hg/jdk/jdk/src/hotspot/share/ci/ciMethodData.hpp: In member function ?void LIR_Assembler::emit_typecheck_helper(LIR_OpTypeCheck*, Label*, Label*, Label*)?: > /home/gromero/hg/jdk/jdk/src/hotspot/share/ci/ciMethodData.hpp:595:100: warning: ?data? may be used uninitialized in this function [-Wmaybe-uninitialized] > int byte_offset_of_slot(ciProfileData* data, ByteSize slot_offset_in_data) { return in_bytes(offset_of_slot(data, slot_offset_in_data)); } > ^ > /home/gromero/hg/jdk/jdk/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp:2400:18: note: ?data? was declared here > ciProfileData* data; > ^ > /home/gromero/hg/jdk/jdk/src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp:2483:78: warning: ?md? may be used uninitialized in this function [-Wmaybe-uninitialized] > type_profile_helper(mdo, mdo_offset_bias, md, data, recv, Rtmp1, success); > ^ > > Thank you. > > Best regards, > Gustavo > From gromero at linux.vnet.ibm.com Tue Sep 4 14:49:36 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 4 Sep 2018 11:49:36 -0300 Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code In-Reply-To: References: <36d840d7-1050-80a4-5e78-fdb36a734702@redhat.com> <96db713b-a1af-d0f6-55fe-053f4780dab8@linux.vnet.ibm.com> Message-ID: <04bb4c95-6252-1837-e7bf-4ad2d2e411c0@linux.vnet.ibm.com> On 09/04/2018 11:15 AM, Doerr, Martin wrote: > Hi Gustavo, > >> I think it's still trivial as before? > Yes. > >> If so it means I can push it once I receive a second OK from you? >> >> I also think I don't need to push it first to the 'submit' repo since it's >> a PPC64-only change. Is that correct? > That's fine (assuming you have run a local build). Sure :) Regards, Gustavo > Best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev On Behalf Of Gustavo Romero > Sent: Dienstag, 4. September 2018 16:11 > To: Aleksey Shipilev ; hotspot-compiler-dev at openjdk.java.net; Baesken, Matthias > Cc: ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code > > Hi Matthias and Aleksey, > > Thanks for reviewing it. > > On 09/04/2018 10:49 AM, Aleksey Shipilev wrote: >> On 09/04/2018 03:42 PM, Gustavo Romero wrote: >>> May I please request reviews for this tiny change that fixes two >>> uninitialized variables in PPC64 C1 LIR code? >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8210320 >>> Webrev: http://cr.openjdk.java.net/~gromero/8210320/v1/ >> >> Looks good and trivial to me. > > Aleksey, I've updated that change to include another case pointed out by Matthias: > > http://cr.openjdk.java.net/~gromero/8210320/v2/ > > I think it's still trivial as before? > > If so it means I can push it once I receive a second OK from you? > > I also think I don't need to push it first to the 'submit' repo since it's > a PPC64-only change. Is that correct? > > Thank you. > > Best regards, > Gustavo > From gromero at linux.vnet.ibm.com Tue Sep 4 14:52:35 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 4 Sep 2018 11:52:35 -0300 Subject: RFR(xs): 8210320: PPC64: Fix uninitialized variable in C1 LIR assembler code In-Reply-To: References: <36d840d7-1050-80a4-5e78-fdb36a734702@redhat.com> <96db713b-a1af-d0f6-55fe-053f4780dab8@linux.vnet.ibm.com> Message-ID: On 09/04/2018 11:15 AM, Aleksey Shipilev wrote: > On 09/04/2018 04:11 PM, Gustavo Romero wrote: >> http://cr.openjdk.java.net/~gromero/8210320/v2/ >> >> I think it's still trivial as before? > > Yes. > >> If so it means I can push it once I receive a second OK from you? > > Yes, this is trivial, and AFAIU only one Reviewer is required for trivial issues. Got it. Thanks for confirming it. Either way Martin reviewed it also by now. >> I also think I don't need to push it first to the 'submit' repo since it's >> a PPC64-only change. Is that correct? > > Yes, I don't see the need to test trivial patches like this with submit repo. OK. Thanks! Best regards, Gustavo > Thanks, > -Aleksey > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: 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 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 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 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 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: 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 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 gromero at linux.vnet.ibm.com Wed Sep 12 03:51:08 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 12 Sep 2018 00:51:08 -0300 Subject: RFR: 8210416: [linux] Poor StrictMath performance due to non-optimized compilation In-Reply-To: <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com> References:

<4173234da6f0b49a210f199c640bbf92cf9f9e61.camel@redhat.com> <8f144dd7830dff515d636408d18e6fa3dcda311c.camel@redhat.com> <2c91fac3-3514-826b-4513-3da7502311b3@oracle.com> <7c4e6e43-d2b5-d670-8d0f-5a39e1ac572b@oracle.com> <235587f0-920d-0dc7-5235-ef5a066a5ad9@oracle.com> <6a51a8a430b7970bd83dd5b489edd23b514e9463.camel@redhat.com> <783996c2-2beb-db46-d1f4-279e3d15153f@oracle.com> <05284dfa81882ba8a429a875105d3546b4a11331.camel@redhat.com> <47e56a18-a5f7-3583-9f5e-ede471586b8e@linux.vnet.ibm.com> Message-ID: Hi Andrew, On 09/12/2018 12:51 AM, Gustavo Romero wrote: > > Maybe Andrew can enlight us. I was not sure if 'enlight us' was the correct form here, so I did some search and I found with horror today that 'enlighten us' can also be considered an insult (!?). That's really not the case here. So if it's really possible to interpret it in a non-positive / non-cordial way I sincerely apologize for the wrong use. I was really only asking for an advice. :) Regards, Gustavo 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 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 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: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 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 gromero at linux.vnet.ibm.com Tue Sep 25 18:29:04 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 25 Sep 2018 15:29:04 -0300 Subject: [8u] RFR for backport of JDK-8164920: ppc: enhancement of CRC32 intrinsic to jdk8u-dev (v2) In-Reply-To: <31e036a0-a7b7-70f2-422f-addd4049436f@linux.vnet.ibm.com> References: <31e036a0-a7b7-70f2-422f-addd4049436f@linux.vnet.ibm.com> Message-ID: <5d059529-6048-ea79-f661-aae05b754dcc@linux.vnet.ibm.com> Hi, Maybe I please get reviews for the following changes (v2)? http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v2/8131048/ http://cr.openjdk.java.net/~gromero/crc32_jdk8u/v2/8164920/ Change JDK-8131048 is a dependency to backport JDK-8164920 to 8u. Goetz reviewed the first version of this backport and pointed out necessary changes and fixes that are present in this v2. Thank you, Goetz. There is no code change except to adapt the file paths, to add has_vpmsumb() feature detection, and to adapt the signature before doing the runtime call to CRC32 intrinsic by casting T_INTs as T_LONGs, because PPC64 c_calling_convention() requires T_LONGs on 8u, otherwise a proper assert() for that is hit. Change JDK-8131048 touches shared code but, since it checks for 'CCallingConventionRequiresIntsAsLongs' flag that is only currently set on PPC64, that change is in effect PPC64-only. JDK-8164920 is important for PPC64 because it helps a lot some Apache Cassandra workloads on Power. Thank you. Best regards, Gustavo 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 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 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 > > > >