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 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 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 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 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 Ningsheng.Jian at arm.com Fri Sep 14 04:19:20 2018 From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China)) Date: Fri, 14 Sep 2018 04:19:20 -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