From david.holmes at oracle.com Tue Jun 5 04:24:30 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Jun 2018 14:24:30 +1000 Subject: ARM port consolidation In-Reply-To: References: Message-ID: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> Hi Bob, Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. I think this is a good idea. Thanks, David On 5/06/2018 6:34 AM, Bob Vandette wrote: > During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit > ARM ports and contributed them to OpenJDK. These ports have been used for > years in the embedded and mobile market, making them very stable and > having the benefit of a single source base which can produce both 32 and > 64-bit binaries. The downside of this contribution is that it resulted > in two 64-bit ARM implementations being available in OpenJDK. > > I'd like to propose that we eliminate one of the 64-bit ARM ports and > encourage everyone to enhance and support the remaining 32 and 64 bit > ARM ports. This would avoid the creation of yet another port for these chip > architectures. The reduction of competing ports will allow everyone > to focus their attention on a single 64-bit port rather than diluting > our efforts. This will result in a higher quality and a more performant > implementation. > > The community at large (especially RedHat, BellSoft, Linaro and Cavium) > have done a great job of enhancing and keeping the AArch64 port up to > date with current and new Hotspot features. As a result, I propose that > we standardize the 64-bit ARM implementation on this port. > > If there are no objections, I will file a JEP to remove the 64-bit ARM > port sources that reside in jdk/open/src/hotspot/src/cpu/arm > along with any build logic. This will leave the Oracle contributed > 32-bit ARM port and the AArch64 64-bit ARM port. > > Let me know what you all think, > Bob Vandette > > From gil at azul.com Thu Jun 7 04:23:29 2018 From: gil at azul.com (Gil Tene) Date: Thu, 7 Jun 2018 04:23:29 +0000 Subject: ARM port consolidation In-Reply-To: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> References: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> Message-ID: This makes sense to me on the Aarch64 side. However, on the ARM32 side, I don't think the situation is as straightforward as what is being presented below, and I think more discussion and exploration of alternatives is needed. Much like with AArch64, there is an existing, active, community-developed and community-supported AArch32 port in OpenJDK that predates Oracle's open sourcing of their ARM32 version. That port is being used by multiple downstream builds and, at least for the past year+, it seems to have had more attention and ongoing engineering commitment around it than the Oracle variant. Before making a choice of one AArch32 port vs the other (if such a choice even needs to be made), I would like to hear more about the resources being committed towards maintaining each, keeping each up to date, testing them on various platforms (e.g. including building, testing, and supporting the popular softfloat ABI variants imposed by some OS packages) and working on bug fixes as needs appear. ? Gil. > On Jun 4, 2018, at 6:24 PM, David Holmes wrote: > > Hi Bob, > > Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. > > I think this is a good idea. > > Thanks, > David > > On 5/06/2018 6:34 AM, Bob Vandette wrote: >> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit >> ARM ports and contributed them to OpenJDK. These ports have been used for >> years in the embedded and mobile market, making them very stable and >> having the benefit of a single source base which can produce both 32 and >> 64-bit binaries. The downside of this contribution is that it resulted >> in two 64-bit ARM implementations being available in OpenJDK. >> I'd like to propose that we eliminate one of the 64-bit ARM ports and >> encourage everyone to enhance and support the remaining 32 and 64 bit >> ARM ports. This would avoid the creation of yet another port for these chip >> architectures. The reduction of competing ports will allow everyone >> to focus their attention on a single 64-bit port rather than diluting >> our efforts. This will result in a higher quality and a more performant >> implementation. >> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >> have done a great job of enhancing and keeping the AArch64 port up to >> date with current and new Hotspot features. As a result, I propose that >> we standardize the 64-bit ARM implementation on this port. >> If there are no objections, I will file a JEP to remove the 64-bit ARM >> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >> along with any build logic. This will leave the Oracle contributed >> 32-bit ARM port and the AArch64 64-bit ARM port. >> Let me know what you all think, >> Bob Vandette From david.holmes at oracle.com Thu Jun 7 04:56:08 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Jun 2018 14:56:08 +1000 Subject: ARM port consolidation In-Reply-To: References: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> Message-ID: <290c14ed-f7c7-00d5-41ff-a335b1c7bac3@oracle.com> Hi Gil, On 7/06/2018 2:23 PM, Gil Tene wrote: > This makes sense to me on the Aarch64 side. > > However, on the ARM32 side, I don't think the situation is as straightforward as > what is being presented below, and I think more discussion and exploration of > alternatives is needed. > > Much like with AArch64, there is an existing, active, community-developed and > community-supported AArch32 port in OpenJDK that predates Oracle's open > sourcing of their ARM32 version. That port is being used by multiple downstream > builds and, at least for the past year+, it seems to have had more attention and > ongoing engineering commitment around it than the Oracle variant. To clarify: "AArch32 is the 32-bit sub-architecture within the ARMv8 architecture. The port will be fully compatible with ARMv7 and may support ARMv6 depending on community interest." [1] whereas the 32-bit ARM port that Oracle contributed is for ARMv5, v6 and v7. There's obviously some overlap. If the Aarch32 project reaches a point (like Aarch64) where it is desirable to bring it into the mainline OpenJDK then that would seem like the opportune time to reevaluate the co-existence (or not) of the two ports. David [1] http://openjdk.java.net/projects/aarch32-port/ > Before making a choice of one AArch32 port vs the other (if such a choice > even needs to be made), I would like to hear more about the resources being > committed towards maintaining each, keeping each up to date, testing them on > various platforms (e.g. including building, testing, and supporting the popular > softfloat ABI variants imposed by some OS packages) and working on bug > fixes as needs appear. > ? Gil. > >> On Jun 4, 2018, at 6:24 PM, David Holmes wrote: >> >> Hi Bob, >> >> Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. >> >> I think this is a good idea. >> >> Thanks, >> David >> >> On 5/06/2018 6:34 AM, Bob Vandette wrote: >>> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit >>> ARM ports and contributed them to OpenJDK. These ports have been used for >>> years in the embedded and mobile market, making them very stable and >>> having the benefit of a single source base which can produce both 32 and >>> 64-bit binaries. The downside of this contribution is that it resulted >>> in two 64-bit ARM implementations being available in OpenJDK. >>> I'd like to propose that we eliminate one of the 64-bit ARM ports and >>> encourage everyone to enhance and support the remaining 32 and 64 bit >>> ARM ports. This would avoid the creation of yet another port for these chip >>> architectures. The reduction of competing ports will allow everyone >>> to focus their attention on a single 64-bit port rather than diluting >>> our efforts. This will result in a higher quality and a more performant >>> implementation. >>> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >>> have done a great job of enhancing and keeping the AArch64 port up to >>> date with current and new Hotspot features. As a result, I propose that >>> we standardize the 64-bit ARM implementation on this port. >>> If there are no objections, I will file a JEP to remove the 64-bit ARM >>> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >>> along with any build logic. This will leave the Oracle contributed >>> 32-bit ARM port and the AArch64 64-bit ARM port. >>> Let me know what you all think, >>> Bob Vandette > From magnus.ihse.bursie at oracle.com Thu Jun 7 09:41:41 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 7 Jun 2018 11:41:41 +0200 Subject: ARM port consolidation In-Reply-To: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> References: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> Message-ID: From a build perspective, it would certainly simplify things if we have just a single port, so I'm in favour of this proposal. /Magnus On 2018-06-05 06:24, David Holmes wrote: > Hi Bob, > > Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. > > I think this is a good idea. > > Thanks, > David > > On 5/06/2018 6:34 AM, Bob Vandette wrote: >> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit >> ARM ports and contributed them to OpenJDK.? These ports have been >> used for >> years in the embedded and mobile market, making them very stable and >> having the benefit of a single source base which can produce both 32 and >> 64-bit binaries.? The downside of this contribution is that it resulted >> in two 64-bit ARM implementations being available in OpenJDK. >> >> I'd like to propose that we eliminate one of the 64-bit ARM ports and >> encourage everyone to enhance and support the remaining 32 and 64 bit >> ARM ports. This would avoid the creation of yet another port for >> these chip >> architectures.? The reduction of competing ports will allow everyone >> to focus their attention on a single 64-bit port rather than diluting >> our efforts.? This will result in a higher quality and a more performant >> implementation. >> >> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >> have done a great job of enhancing and keeping the AArch64 port up to >> date with current and new Hotspot features.? As a result, I propose that >> we standardize the 64-bit ARM implementation on this port. >> >> If there are no objections, I will file a JEP to remove the 64-bit ARM >> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >> along with any build logic.? This will leave the Oracle contributed >> 32-bit ARM port and the AArch64 64-bit ARM port. >> >> Let me know what you all think, >> Bob Vandette >> >> From bob.vandette at oracle.com Thu Jun 7 14:48:16 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 7 Jun 2018 10:48:16 -0400 Subject: ARM port consolidation In-Reply-To: <290c14ed-f7c7-00d5-41ff-a335b1c7bac3@oracle.com> References: <247c1b0c-a3f6-57e3-f00b-2d9a1488213e@oracle.com> <290c14ed-f7c7-00d5-41ff-a335b1c7bac3@oracle.com> Message-ID: <794BFAA0-6FCB-4730-9A89-B6B3F3D728BF@oracle.com> I agree with David. I do know that our implementation does run in AArch32 mode and it should be very easy to add dynamic AArch32 detection in order to make use of the few new AArch32 specific instructions such as the memory barrier instructions (LDAR/STLR). Since our current port already contains ARMv8 instruction pneumonics, we are already 1/2 way there. Bob. > On Jun 7, 2018, at 12:56 AM, David Holmes wrote: > > Hi Gil, > > On 7/06/2018 2:23 PM, Gil Tene wrote: >> This makes sense to me on the Aarch64 side. >> However, on the ARM32 side, I don't think the situation is as straightforward as >> what is being presented below, and I think more discussion and exploration of >> alternatives is needed. >> Much like with AArch64, there is an existing, active, community-developed and >> community-supported AArch32 port in OpenJDK that predates Oracle's open >> sourcing of their ARM32 version. That port is being used by multiple downstream >> builds and, at least for the past year+, it seems to have had more attention and >> ongoing engineering commitment around it than the Oracle variant. > > To clarify: > > "AArch32 is the 32-bit sub-architecture within the ARMv8 architecture. The port will be fully compatible with ARMv7 and may support ARMv6 depending on community interest." [1] > > whereas the 32-bit ARM port that Oracle contributed is for ARMv5, v6 and v7. There's obviously some overlap. If the Aarch32 project reaches a point (like Aarch64) where it is desirable to bring it into the mainline OpenJDK then that would seem like the opportune time to reevaluate the co-existence (or not) of the two ports. > > David > > [1] http://openjdk.java.net/projects/aarch32-port/ > >> Before making a choice of one AArch32 port vs the other (if such a choice >> even needs to be made), I would like to hear more about the resources being >> committed towards maintaining each, keeping each up to date, testing them on >> various platforms (e.g. including building, testing, and supporting the popular >> softfloat ABI variants imposed by some OS packages) and working on bug >> fixes as needs appear. >> ? Gil. >>> On Jun 4, 2018, at 6:24 PM, David Holmes wrote: >>> >>> Hi Bob, >>> >>> Looping in porters-dev, aarch32-port-dev and aarch64-port-dev. >>> >>> I think this is a good idea. >>> >>> Thanks, >>> David >>> >>> On 5/06/2018 6:34 AM, Bob Vandette wrote: >>>> During the JDK 9 time frame, Oracle open sourced its 32-bit and 64-bit >>>> ARM ports and contributed them to OpenJDK. These ports have been used for >>>> years in the embedded and mobile market, making them very stable and >>>> having the benefit of a single source base which can produce both 32 and >>>> 64-bit binaries. The downside of this contribution is that it resulted >>>> in two 64-bit ARM implementations being available in OpenJDK. >>>> I'd like to propose that we eliminate one of the 64-bit ARM ports and >>>> encourage everyone to enhance and support the remaining 32 and 64 bit >>>> ARM ports. This would avoid the creation of yet another port for these chip >>>> architectures. The reduction of competing ports will allow everyone >>>> to focus their attention on a single 64-bit port rather than diluting >>>> our efforts. This will result in a higher quality and a more performant >>>> implementation. >>>> The community at large (especially RedHat, BellSoft, Linaro and Cavium) >>>> have done a great job of enhancing and keeping the AArch64 port up to >>>> date with current and new Hotspot features. As a result, I propose that >>>> we standardize the 64-bit ARM implementation on this port. >>>> If there are no objections, I will file a JEP to remove the 64-bit ARM >>>> port sources that reside in jdk/open/src/hotspot/src/cpu/arm >>>> along with any build logic. This will leave the Oracle contributed >>>> 32-bit ARM port and the AArch64 64-bit ARM port. >>>> Let me know what you all think, >>>> Bob Vandette From andrey.petushkov at gmail.com Sat Jun 9 14:46:59 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Sat, 9 Jun 2018 17:46:59 +0300 Subject: RFR: aarch32-jdk10 Message-ID: <5AF822A5-C8AC-4EE7-AD28-E8378C96FA9B@gmail.com> Dear Ed, All, As promised, jdk10 version of aarch32 port. http://cr.openjdk.java.net/~apetushkov/aarch32-jdk10u/ Nothing specific to say, basically everything in jdk9 aarch32 patch merged with latest jdk10u. Thread Local Handshakes implemented (not sure anybody needs that on 32-bit Arm) Verified with hotspot jtreg. A few test fixes are part of this review. More serous testing is in progress Regards, Andrey From edward.nevill at gmail.com Sun Jun 10 20:48:19 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Sun, 10 Jun 2018 21:48:19 +0100 Subject: [RFR] jdk9.0.4+12 + functionality In-Reply-To: <1D8BABDB-A232-4D10-9C9A-087D1F2FCCD0@gmail.com> References: <83D551E9-1EBF-4F1E-A15D-C87E6FCCBFA9@gmail.com> <1523306527.16246.3.camel@gmail.com> <1523350531.2440.6.camel@gmail.com> <1523360339.2440.22.camel@gmail.com> <1C2B1668-E0BB-4A9D-B391-10E4E551D010@gmail.com> <040F8DA9-5367-4DF5-967B-584268D399AC@gmail.com> <1523389350.2440.39.camel@gmail.com> <68333229-613D-4D20-A8BC-BE0FF522E215@gmail.com> <1523448323.6342.16.camel@gmail.com> <56BCFB51-258E-4677-A136-937706761E82@gmail.com> <1523461579.6342.30.camel@gmail.com> <1523470275.6342.53.camel@gmail.com> <1527680723.2904.13.camel@gmail.com> <89D85279-6ED1-4126-AC2E-7DB32F26662F@gmail.com> <1527683902.2904.17.camel@gmail.com> <06847DB6-B8F7-4EC6-A19C-7B6D688EB1CB@gmail.com> <1527698512.2904.20.camel@gmail.com> <1D8BABDB-A232-4D10-9C9A-087D1F2FCCD0@gmail.com> Message-ID: <1528663699.2998.13.camel@gmail.com> Hi Andrey, Thanks for that. Sorry for the delay. I have build aarch32 versions of server, client and core and arm versions of server and client. I had to make a minor change to Copy-java.base.gmk in order to get the 'core' build working again (patch below) I also did some sanity checks with jtreg/hotspot and jcstress - m quick hotspot (aarch32 client) Test results: passed: 1,224; failed: 34; error: 53 hotspot (aarch32 server) Test results: passed: 1,259; failed: 37; error: 43 jcstress (aarch32 server) (ETA: 00:00:18) (Rate: 2.66E+06 samples/sec) (Tests: 11560 of 11560) (Forks: 69360 of 69360) (Iterations: 416000 of 416160; 414573 passed, 1427 failed, 0 soft errs, 0 hard errs) The large number of failure on jcstress is a bit disconcerting. Nonetheless, I propose pushing this within the next few days. The issues above can be addressed later and there is no point holding off pushing until all issues are addressed. Can you give me a list of people (names and email addresses) of people who contributed to this for inclusion in the commit. Many thanks, Ed. Patch to enable 'core' build again. --- CUT HERE --- diff -r d54486c189e5 make/copy/Copy-java.base.gmk --- a/make/copy/Copy-java.base.gmk Wed Feb 14 07:32:50 2018 -0800 +++ b/make/copy/Copy-java.base.gmk Sun Jun 10 21:47:02 2018 +0100 @@ -152,6 +152,11 @@ $(PRINTF) "-minimal KNOWN\n">>$(@) $(PRINTF) "-server ALIASED_TO -minimal\n">>$(@) $(PRINTF) "-client ALIASED_TO -minimal\n">>$(@) + else + ifeq ($(call check-jvm-variant, core), true) + $(PRINTF) "-server KNOWN\n">>$(@) + $(PRINTF) "-client ALIASED_TO -server\n">>$(@) + endif endif endif endif --- CUT HERE --- On Thu, 2018-05-31 at 14:23 +0300, Andrey Petushkov wrote: > Oops, glitch on my side. Sorry. Fixed, webrev updated > > Thanks, > Andrey > > > On 30 May 2018, at 21:32, Andrey Petushkov wrote: > > > > Hmm, I've really removed this file since the functionality is not relevant for aarch32, and that did not cause any problems on my side.. Please let me doublecheck > > > > Thank you, > > Andrey > > > > On Wed, May 30, 2018 at 7:41 PM Edward Nevill wrote: > > > OK. So I applied both sets of patches and I get > > > > > > /work/ed/openjdk/jdk9u-aarch32/hotspot/src/share/vm/c1/c1_FpuStackSim.hpp:36:36: fatal error: c1_FpuStackSim_aarch32.hpp: No such file or directory > > > #include CPU_HEADER(c1_FpuStackSim) > > > > > > My build command is > > > > > > bash ./configure --with-jobs=2 --disable-warnings-as-errors --with-boot-jdk=/work/ed/images/jdk9u --with-jvm-variants=server > > > make images > > > > > > All the best, > > > Ed. > > > > > > > > > On Wed, 2018-05-30 at 16:52 +0300, Andrey Petushkov wrote: > > > > Would it be ok if you just check the final state? > > > > > > > > Andrey > > > > > > From andrey.petushkov at gmail.com Wed Jun 13 10:33:45 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Wed, 13 Jun 2018 13:33:45 +0300 Subject: [RFR] jdk9.0.4+12 + functionality In-Reply-To: <1528663699.2998.13.camel@gmail.com> References: <83D551E9-1EBF-4F1E-A15D-C87E6FCCBFA9@gmail.com> <1523306527.16246.3.camel@gmail.com> <1523350531.2440.6.camel@gmail.com> <1523360339.2440.22.camel@gmail.com> <1C2B1668-E0BB-4A9D-B391-10E4E551D010@gmail.com> <040F8DA9-5367-4DF5-967B-584268D399AC@gmail.com> <1523389350.2440.39.camel@gmail.com> <68333229-613D-4D20-A8BC-BE0FF522E215@gmail.com> <1523448323.6342.16.camel@gmail.com> <56BCFB51-258E-4677-A136-937706761E82@gmail.com> <1523461579.6342.30.camel@gmail.com> <1523470275.6342.53.camel@gmail.com> <1527680723.2904.13.camel@gmail.com> <89D85279-6ED1-4126-AC2E-7DB32F26662F@gmail.com> <1527683902.2904.17.camel@gmail.com> <06847DB6-B8F7-4EC6-A19C-7B6D688EB1CB@gmail.com> <1527698512.2904.20.camel@gmail.com> <1D8BABDB-A232-4D10-9C9A-087D1F2FCCD0@gmail.com> <1528663699.2998.13.camel@gmail.com> Message-ID: <773A480B-8AD9-41D1-ACC4-7F11E413C397@gmail.com> Dear Ed, Thank you so much a try! In fact there are two synchronization bugs found and fixed during updating to Java 10. So could I ask you to check out the jdk10 webrev I?ve sent last week. Hopefully some of the problems should go away. Unfortunately I did not yet run jcstress myself, shame on me? The people participated are Fedor Burdun and myself, Andrey Petushkov Thanks again, Andrey > On 10 Jun 2018, at 23:48, Edward Nevill wrote: > > Hi Andrey, > > Thanks for that. Sorry for the delay. > > I have build aarch32 versions of server, client and core and arm versions of server and client. > > I had to make a minor change to Copy-java.base.gmk in order to get the 'core' build working again (patch below) > > I also did some sanity checks with jtreg/hotspot and jcstress - m quick > > hotspot (aarch32 client) > > Test results: passed: 1,224; failed: 34; error: 53 > > hotspot (aarch32 server) > > Test results: passed: 1,259; failed: 37; error: 43 > > jcstress (aarch32 server) > > (ETA: 00:00:18) (Rate: 2.66E+06 samples/sec) (Tests: 11560 of 11560) (Forks: 69360 of 69360) (Iterations: 416000 of 416160; 414573 passed, 1427 failed, 0 soft errs, 0 hard errs) > > The large number of failure on jcstress is a bit disconcerting. > > Nonetheless, I propose pushing this within the next few days. The issues above can be addressed later and there is no point holding off pushing until all issues are addressed. > > Can you give me a list of people (names and email addresses) of people who contributed to this for inclusion in the commit. > > Many thanks, > Ed. > > Patch to enable 'core' build again. > > --- CUT HERE --- > diff -r d54486c189e5 make/copy/Copy-java.base.gmk > --- a/make/copy/Copy-java.base.gmk Wed Feb 14 07:32:50 2018 -0800 > +++ b/make/copy/Copy-java.base.gmk Sun Jun 10 21:47:02 2018 +0100 > @@ -152,6 +152,11 @@ > $(PRINTF) "-minimal KNOWN\n">>$(@) > $(PRINTF) "-server ALIASED_TO -minimal\n">>$(@) > $(PRINTF) "-client ALIASED_TO -minimal\n">>$(@) > + else > + ifeq ($(call check-jvm-variant, core), true) > + $(PRINTF) "-server KNOWN\n">>$(@) > + $(PRINTF) "-client ALIASED_TO -server\n">>$(@) > + endif > endif > endif > endif > > --- CUT HERE --- > > On Thu, 2018-05-31 at 14:23 +0300, Andrey Petushkov wrote: >> Oops, glitch on my side. Sorry. Fixed, webrev updated >> >> Thanks, >> Andrey >> >>> On 30 May 2018, at 21:32, Andrey Petushkov wrote: >>> >>> Hmm, I've really removed this file since the functionality is not relevant for aarch32, and that did not cause any problems on my side.. Please let me doublecheck >>> >>> Thank you, >>> Andrey >>> >>> On Wed, May 30, 2018 at 7:41 PM Edward Nevill wrote: >>>> OK. So I applied both sets of patches and I get >>>> >>>> /work/ed/openjdk/jdk9u-aarch32/hotspot/src/share/vm/c1/c1_FpuStackSim.hpp:36:36: fatal error: c1_FpuStackSim_aarch32.hpp: No such file or directory >>>> #include CPU_HEADER(c1_FpuStackSim) >>>> >>>> My build command is >>>> >>>> bash ./configure --with-jobs=2 --disable-warnings-as-errors --with-boot-jdk=/work/ed/images/jdk9u --with-jvm-variants=server >>>> make images >>>> >>>> All the best, >>>> Ed. >>>> >>>> >>>> On Wed, 2018-05-30 at 16:52 +0300, Andrey Petushkov wrote: >>>>> Would it be ok if you just check the final state? >>>>> >>>>> Andrey >>>>> >> >> From andrey.petushkov at gmail.com Wed Jun 13 12:40:38 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Wed, 13 Jun 2018 15:40:38 +0300 Subject: 8153107: Unbalanced recursive locking Message-ID: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Dear Hotspot developers, It looks like the cause of the https://bugs.openjdk.java.net/browse/JDK-8153107 problem is that ObjectSynchronizer::quick_enter implementation leaves the BasicLock marked as recursive (DHW==0) in case that the lock is inflated and already taken. As such the routines which first check the recursive stack locking (e.g. fast_exit) consider this lock as non-inflated recursive and hence do not decrement _recursions field of ObjectMonitor, leaving the monitor locked forever. In contrary the slow path does work the right way: ObjectSynchronizer::slow_enter first marks stack lock as non-locked and non-recursive (DHW==3) and then delegates to ObjectMonitor::enter to increment _recursions. So from the source code prospective this bug looks like platform-independent, contrary to what?s was found under https://bugs.openjdk.java.net/browse/JDK-8131715 . Unfortunately I cannot prove it with an example. The only case it fails for me is runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test on aarch32 openjdk port. The following changes fix the problem: diff --git a/src/hotspot/share/runtime/sharedRuntime.cpp b/src/hotspot/share/runtime/sharedRuntime.cpp --- a/src/hotspot/share/runtime/sharedRuntime.cpp +++ b/src/hotspot/share/runtime/sharedRuntime.cpp @@ -1985,9 +1985,7 @@ JRT_BLOCK_ENTRY(void, SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* lock, JavaThread* thread)) // Disable ObjectSynchronizer::quick_enter() in default config // on AARCH64 and ARM until JDK-8153107 is resolved. - if (ARM_ONLY((SyncFlags & 256) != 0 &&) - AARCH64_ONLY((SyncFlags & 256) != 0 &&) - !SafepointSynchronize::is_synchronizing()) { + if (!SafepointSynchronize::is_synchronizing()) { // Only try quick_enter() if we're not trying to reach a safepoint // so that the calling thread reaches the safepoint more quickly. if (ObjectSynchronizer::quick_enter(_obj, thread, lock)) return; diff --git a/src/hotspot/share/runtime/synchronizer.cpp b/src/hotspot/share/runtime/synchronizer.cpp --- a/src/hotspot/share/runtime/synchronizer.cpp +++ b/src/hotspot/share/runtime/synchronizer.cpp @@ -220,11 +220,6 @@ // Case: light contention possibly amenable to TLE // Case: TLE inimical operations such as nested/recursive synchronization - if (owner == Self) { - m->_recursions++; - return true; - } - // This Java Monitor is inflated so obj's header will never be // displaced to this thread's BasicLock. Make the displaced header // non-NULL so this BasicLock is not seen as recursive nor as @@ -237,6 +232,11 @@ // and last are the inflated Java Monitor (ObjectMonitor) checks. lock->set_displaced_header(markOopDesc::unused_mark()); + if (owner == Self) { + m->_recursions++; + return true; + } + if (owner == NULL && Atomic::replace_if_null(Self, &(m->_owner))) { assert(m->_recursions == 0, "invariant"); assert(m->_owner == Self, "invariant"); Regards, Andrey From aph at redhat.com Wed Jun 13 13:37:54 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jun 2018 14:37:54 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Message-ID: On 06/13/2018 01:40 PM, Andrey Petushkov wrote: > It looks like the cause of the > https://bugs.openjdk.java.net/browse/JDK-8153107 > problem is that > ObjectSynchronizer::quick_enter implementation leaves the BasicLock > marked as recursive (DHW==0) in case that the lock is inflated and > already taken. As such the routines which first check the recursive > stack locking (e.g. fast_exit) consider this lock as non-inflated > recursive and hence do not decrement _recursions field of > ObjectMonitor, leaving the monitor locked forever. In contrary the > slow path does work the right way: ObjectSynchronizer::slow_enter > first marks stack lock as non-locked and non-recursive (DHW==3) and > then delegates to ObjectMonitor::enter to increment _recursions. > So from the source code prospective this bug looks like > platform-independent, contrary to what?s was found under > https://bugs.openjdk.java.net/browse/JDK-8131715 > . Unfortunately I > cannot prove it with an example. The only case it fails for me is > runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test on > aarch32 openjdk port. The following changes fix the problem: Ouch. The code is due to 8167501, which was a bug in the Oracle ARM64 and ARM32 ports. This bug was never seen in the AARCH64 open port, so the workaround shouldn't be enabled for it. 8167501: ARMv7 Linux C2 compiler crashes running jtreg harness on MP systems Reviewed-by: dcubed diff -r afd6ae4fec81 -r 71d7ced6c439 hotspot/src/share/vm/runtime/sharedRuntime.cpp --- a/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 11:53:20 2016 +0530 +++ b/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 10:44:17 2016 -0400 @@ -1983,8 +1983,10 @@ // Handles the uncommon case in locking, i.e., contention or an inflated lock. JRT_BLOCK_ENTRY(void, SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* lock, JavaThread* thread)) // Disable ObjectSynchronizer::quick_enter() in default config - // on AARCH64 until JDK-8153107 is resolved. - if (AARCH64_ONLY((SyncFlags & 256) != 0 &&) !SafepointSynchronize::is_synchronizing()) { + // on AARCH64 and ARM until JDK-8153107 is resolved. + if (ARM_ONLY((SyncFlags & 256) != 0 &&) + AARCH64_ONLY((SyncFlags & 256) != 0 &&) + !SafepointSynchronize::is_synchronizing()) { // Only try quick_enter() if we're not trying to reach a safepoint Why did you move the code which handles recursive locking counts? Do you believe that it's incorrect where it is, and if so, why? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey.petushkov at gmail.com Wed Jun 13 14:00:26 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Wed, 13 Jun 2018 17:00:26 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Message-ID: > On 13 Jun 2018, at 16:37, Andrew Haley wrote: > > On 06/13/2018 01:40 PM, Andrey Petushkov wrote: > >> It looks like the cause of the >> https://bugs.openjdk.java.net/browse/JDK-8153107 >> problem is that >> ObjectSynchronizer::quick_enter implementation leaves the BasicLock >> marked as recursive (DHW==0) in case that the lock is inflated and >> already taken. As such the routines which first check the recursive >> stack locking (e.g. fast_exit) consider this lock as non-inflated >> recursive and hence do not decrement _recursions field of >> ObjectMonitor, leaving the monitor locked forever. In contrary the >> slow path does work the right way: ObjectSynchronizer::slow_enter >> first marks stack lock as non-locked and non-recursive (DHW==3) and >> then delegates to ObjectMonitor::enter to increment _recursions. > >> So from the source code prospective this bug looks like >> platform-independent, contrary to what?s was found under >> https://bugs.openjdk.java.net/browse/JDK-8131715 >> . Unfortunately I >> cannot prove it with an example. The only case it fails for me is >> runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test on >> aarch32 openjdk port. The following changes fix the problem: > > Ouch. The code is due to 8167501, which was a bug in the Oracle ARM64 > and ARM32 ports. This bug was never seen in the AARCH64 open port, > so the workaround shouldn't be enabled for it. > > 8167501: ARMv7 Linux C2 compiler crashes running jtreg harness on MP systems > Reviewed-by: dcubed > diff -r afd6ae4fec81 -r 71d7ced6c439 hotspot/src/share/vm/runtime/sharedRuntime.cpp > --- a/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 11:53:20 2016 +0530 > +++ b/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 10:44:17 2016 -0400 > @@ -1983,8 +1983,10 @@ > // Handles the uncommon case in locking, i.e., contention or an inflated lock. > JRT_BLOCK_ENTRY(void, SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* lock, JavaThread* thread)) > // Disable ObjectSynchronizer::quick_enter() in default config > - // on AARCH64 until JDK-8153107 is resolved. > - if (AARCH64_ONLY((SyncFlags & 256) != 0 &&) !SafepointSynchronize::is_synchronizing()) { > + // on AARCH64 and ARM until JDK-8153107 is resolved. > + if (ARM_ONLY((SyncFlags & 256) != 0 &&) > + AARCH64_ONLY((SyncFlags & 256) != 0 &&) > + !SafepointSynchronize::is_synchronizing()) { > // Only try quick_enter() if we're not trying to reach a safepoint > > Why did you move the code which handles recursive locking counts? Do > you believe that it's incorrect where it is, and if so, why? That?s exactly what I?ve been trying to describe. The displaced header shall be assigned 3 when recursive locking happens on inflated lock. At least with the current design of the exit code which uses it as an indicator that inflated lock is present. So it seems to me that currently the number of recursive locks on an object is the count of relevant stack lock structures with mark(DHW)!=3 (i.e. first lock + any stack locks prior to inflation) + _recursions field value of the inflated lock structure. The sequence of operations under review was breaking this assumption: any recursion via quick_enter was increasing both number of stack locks with DHW==0 and value of _recursions. While the slow_enter only increased _recursions The above is idea I got from reading the code, I hope someone more experienced (@Daniel Daugherty?) can chime in and prove me right or wrong Andrey > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniel.daugherty at oracle.com Wed Jun 13 14:54:10 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 13 Jun 2018 10:54:10 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Message-ID: Andrey and Andrew, I've copied the three previous emails on this thread to: https://bugs.openjdk.java.net/browse/JDK-8153107 This particular hang was never seen on any of Oracle's other supported platforms so I'm a bit hesitant on making a change to shared code without a better understand of why. Dan On 6/13/18 10:00 AM, Andrey Petushkov wrote: >> On 13 Jun 2018, at 16:37, Andrew Haley wrote: >> >> On 06/13/2018 01:40 PM, Andrey Petushkov wrote: >> >>> It looks like the cause of the >>> https://bugs.openjdk.java.net/browse/JDK-8153107 >>> problem is that >>> ObjectSynchronizer::quick_enter implementation leaves the BasicLock >>> marked as recursive (DHW==0) in case that the lock is inflated and >>> already taken. As such the routines which first check the recursive >>> stack locking (e.g. fast_exit) consider this lock as non-inflated >>> recursive and hence do not decrement _recursions field of >>> ObjectMonitor, leaving the monitor locked forever. In contrary the >>> slow path does work the right way: ObjectSynchronizer::slow_enter >>> first marks stack lock as non-locked and non-recursive (DHW==3) and >>> then delegates to ObjectMonitor::enter to increment _recursions. >>> So from the source code prospective this bug looks like >>> platform-independent, contrary to what?s was found under >>> https://bugs.openjdk.java.net/browse/JDK-8131715 >>> . Unfortunately I >>> cannot prove it with an example. The only case it fails for me is >>> runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test on >>> aarch32 openjdk port. The following changes fix the problem: >> Ouch. The code is due to 8167501, which was a bug in the Oracle ARM64 >> and ARM32 ports. This bug was never seen in the AARCH64 open port, >> so the workaround shouldn't be enabled for it. >> >> 8167501: ARMv7 Linux C2 compiler crashes running jtreg harness on MP systems >> Reviewed-by: dcubed >> diff -r afd6ae4fec81 -r 71d7ced6c439 hotspot/src/share/vm/runtime/sharedRuntime.cpp >> --- a/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 11:53:20 2016 +0530 >> +++ b/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 10:44:17 2016 -0400 >> @@ -1983,8 +1983,10 @@ >> // Handles the uncommon case in locking, i.e., contention or an inflated lock. >> JRT_BLOCK_ENTRY(void, SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* lock, JavaThread* thread)) >> // Disable ObjectSynchronizer::quick_enter() in default config >> - // on AARCH64 until JDK-8153107 is resolved. >> - if (AARCH64_ONLY((SyncFlags & 256) != 0 &&) !SafepointSynchronize::is_synchronizing()) { >> + // on AARCH64 and ARM until JDK-8153107 is resolved. >> + if (ARM_ONLY((SyncFlags & 256) != 0 &&) >> + AARCH64_ONLY((SyncFlags & 256) != 0 &&) >> + !SafepointSynchronize::is_synchronizing()) { >> // Only try quick_enter() if we're not trying to reach a safepoint >> >> Why did you move the code which handles recursive locking counts? Do >> you believe that it's incorrect where it is, and if so, why? > That?s exactly what I?ve been trying to describe. The displaced header shall be assigned 3 when recursive locking happens on inflated lock. At least with the current design of the exit code which uses it as an indicator that inflated lock is present. > So it seems to me that currently the number of recursive locks on an object is the count of relevant stack lock structures with mark(DHW)!=3 (i.e. first lock + any stack locks prior to inflation) + _recursions field value of the inflated lock structure. The sequence of operations under review was breaking this assumption: any recursion via quick_enter was increasing both number of stack locks with DHW==0 and value of _recursions. While the slow_enter only increased _recursions > The above is idea I got from reading the code, I hope someone more experienced (@Daniel Daugherty?) can chime in and prove me right or wrong > > Andrey >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Jun 13 15:04:06 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jun 2018 16:04:06 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Message-ID: <163d3328-6cc9-1e3e-3a6b-72543b0204db@redhat.com> On 06/13/2018 03:54 PM, Daniel D. Daugherty wrote: > This particular hang was never seen on any of Oracle's other supported > platforms so I'm a bit hesitant on making a change to shared code > without a better understand of why. Yeah, my thoughts exactly. It doesn't help that the platform- specific variants of quick_enter() are all subtly different. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Jun 13 15:14:58 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 13 Jun 2018 16:14:58 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Message-ID: <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> Hi Dan, Have you got any torture tests for recursive locking? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniel.daugherty at oracle.com Wed Jun 13 15:17:10 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 13 Jun 2018 11:17:10 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> Message-ID: Not at my fingertips, but I will look thru my archives. Dan On 6/13/18 11:14 AM, Andrew Haley wrote: > Hi Dan, > > Have you got any torture tests for recursive locking? > From Derek.White at cavium.com Wed Jun 13 15:04:15 2018 From: Derek.White at cavium.com (White, Derek) Date: Wed, 13 Jun 2018 15:04:15 +0000 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> Message-ID: Hi Andrey, Andrew, > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Andrew Haley > On 06/13/2018 01:40 PM, Andrey Petushkov wrote: > > > It looks like the cause of the > > https://bugs.openjdk.java.net/browse/JDK-8153107 > > problem is that > > ObjectSynchronizer::quick_enter implementation leaves the BasicLock > > marked as recursive (DHW==0) in case that the lock is inflated and > > already taken. As such the routines which first check the recursive > > stack locking (e.g. fast_exit) consider this lock as non-inflated > > recursive and hence do not decrement _recursions field of > > ObjectMonitor, leaving the monitor locked forever. In contrary the > > slow path does work the right way: ObjectSynchronizer::slow_enter > > first marks stack lock as non-locked and non-recursive (DHW==3) and > > then delegates to ObjectMonitor::enter to increment _recursions. > > > So from the source code prospective this bug looks like > > platform-independent, contrary to what?s was found under > > https://bugs.openjdk.java.net/browse/JDK-8131715 > > . Unfortunately I > > cannot prove it with an example. The only case it fails for me is > > runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test on > > aarch32 openjdk port. The following changes fix the problem: > > Ouch. The code is due to 8167501, which was a bug in the Oracle ARM64 > and ARM32 ports. This bug was never seen in the AARCH64 open port, so > the workaround shouldn't be enabled for it. Yes, I've been testing this last week myself (e.g. setting SyncFlags). It's responsible for about a 2% drop in SPECjbb on aarch64 when they added it. > 8167501: ARMv7 Linux C2 compiler crashes running jtreg harness on MP > systems > Reviewed-by: dcubed > diff -r afd6ae4fec81 -r 71d7ced6c439 > hotspot/src/share/vm/runtime/sharedRuntime.cpp > --- a/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 > 11:53:20 2016 +0530 > +++ b/hotspot/src/share/vm/runtime/sharedRuntime.cpp Thu Nov 03 > 10:44:17 2016 -0400 > @@ -1983,8 +1983,10 @@ > // Handles the uncommon case in locking, i.e., contention or an inflated > lock. > JRT_BLOCK_ENTRY(void, > SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* > lock, JavaThread* thread)) > // Disable ObjectSynchronizer::quick_enter() in default config > - // on AARCH64 until JDK-8153107 is resolved. > - if (AARCH64_ONLY((SyncFlags & 256) != 0 &&) > !SafepointSynchronize::is_synchronizing()) { > + // on AARCH64 and ARM until JDK-8153107 is resolved. > + if (ARM_ONLY((SyncFlags & 256) != 0 &&) > + AARCH64_ONLY((SyncFlags & 256) != 0 &&) > + !SafepointSynchronize::is_synchronizing()) { > // Only try quick_enter() if we're not trying to reach a safepoint > > Why did you move the code which handles recursive locking counts? Do you > believe that it's incorrect where it is, and if so, why? I'm similarly suspicious of pointing the blame at the shared code. I'll look some more also. - Derek From andrey.petushkov at gmail.com Wed Jun 13 17:26:08 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Wed, 13 Jun 2018 20:26:08 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> Message-ID: <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> Ok, I shall I admit I did not dig deep enough. Yes, there is platform specifics which plays a role here. That is: all platforms except Oracle ARM (all bitness) and aarch32 fill-in stack lock?s DHW with result of same-stack-page-lock probe result. Which is always !=0 when failed. Oracle?s ARM and aarch32 do that conditionally, based on whether this test actually passes. Hence for the latter platforms the DHW in the stack lock really contains random value which occasionally can be 0, and being not rewritten (e.g. with markOopDesc::unused_mark(), aka 3) will indicate recursive stack lock for ::fast_unlock(). Not sure about those stack walkers mentioned in the comment in ::quick_enter(). So, right, it?s possible to fix the problem in the platform-specific code only. Leaving up to you to decide whether it?s proper design :) Regards, Andrey > On 13 Jun 2018, at 18:17, Daniel D. Daugherty wrote: > > Not at my fingertips, but I will look thru my archives. > > Dan > > > On 6/13/18 11:14 AM, Andrew Haley wrote: >> Hi Dan, >> >> Have you got any torture tests for recursive locking? >> > From andrey.petushkov at gmail.com Thu Jun 14 11:59:11 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Thu, 14 Jun 2018 14:59:11 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> Message-ID: So then if you prefer to leave the different logic in shared code between quick and slow paths I believe the fix for cpu/arm implementation (and removal of unnecessary workaround for cpu/aarch64) should look like this: --- CUT --- diff -r db65921e9a9b src/hotspot/cpu/arm/macroAssembler_arm.cpp --- a/src/hotspot/cpu/arm/macroAssembler_arm.cpp Thu Jun 07 06:27:09 2018 -0400 +++ b/src/hotspot/cpu/arm/macroAssembler_arm.cpp Thu Jun 14 14:56:38 2018 +0300 @@ -3014,8 +3014,8 @@ mov(Rscratch, SP); sub(Rscratch, Rmark, Rscratch); ands(Rscratch, Rscratch, imm); - b(done, ne); // exit with failure - str(Rscratch, Address(Rbox, BasicLock::displaced_header_offset_in_bytes())); // set to zero + // set to zero if recursive lock, set to non zero otherwise (see discussion in JDK-8153107) + str(Rscratch, Address(Rbox, BasicLock::displaced_header_offset_in_bytes())); b(done); #else @@ -3025,7 +3025,8 @@ sub(Rscratch, Rmark, SP, eq); movs(Rscratch, AsmOperand(Rscratch, lsr, exact_log2(os::vm_page_size())), eq); // If still 'eq' then recursive locking OK - str(Rscratch, Address(Rbox, BasicLock::displaced_header_offset_in_bytes()), eq); // set to zero + // set to zero if recursive lock, set to non zero otherwise (see discussion in JDK-8153107) + str(Rscratch, Address(Rbox, BasicLock::displaced_header_offset_in_bytes())); b(done); #endif diff -r db65921e9a9b src/hotspot/share/runtime/sharedRuntime.cpp --- a/src/hotspot/share/runtime/sharedRuntime.cpp Thu Jun 07 06:27:09 2018 -0400 +++ b/src/hotspot/share/runtime/sharedRuntime.cpp Thu Jun 14 14:56:38 2018 +0300 @@ -1983,11 +1983,7 @@ // Handles the uncommon case in locking, i.e., contention or an inflated lock. JRT_BLOCK_ENTRY(void, SharedRuntime::complete_monitor_locking_C(oopDesc* _obj, BasicLock* lock, JavaThread* thread)) - // Disable ObjectSynchronizer::quick_enter() in default config - // on AARCH64 and ARM until JDK-8153107 is resolved. - if (ARM_ONLY((SyncFlags & 256) != 0 &&) - AARCH64_ONLY((SyncFlags & 256) != 0 &&) - !SafepointSynchronize::is_synchronizing()) { + if (!SafepointSynchronize::is_synchronizing()) { // Only try quick_enter() if we're not trying to reach a safepoint // so that the calling thread reaches the safepoint more quickly. if (ObjectSynchronizer::quick_enter(_obj, thread, lock)) return; --- END CUT --- Tested on jdk10/port-aarch32 codebase Regards, Andrey On Wed, Jun 13, 2018 at 8:26 PM Andrey Petushkov wrote: > Ok, I shall I admit I did not dig deep enough. Yes, there is platform > specifics which plays a role here. That is: all platforms except Oracle ARM > (all bitness) and aarch32 fill-in stack lock?s DHW with result of > same-stack-page-lock probe result. Which is always !=0 when failed. > Oracle?s ARM and aarch32 do that conditionally, based on whether this test > actually passes. Hence for the latter platforms the DHW in the stack lock > really contains random value which occasionally can be 0, and being not > rewritten (e.g. with markOopDesc::unused_mark(), aka 3) will indicate > recursive stack lock for ::fast_unlock(). Not sure about those stack > walkers mentioned in the comment in ::quick_enter(). So, right, it?s > possible to fix the problem in the platform-specific code only. Leaving up > to you to decide whether it?s proper design :) > > Regards, > Andrey > > > On 13 Jun 2018, at 18:17, Daniel D. Daugherty < > daniel.daugherty at oracle.com> wrote: > > > > Not at my fingertips, but I will look thru my archives. > > > > Dan > > > > > > On 6/13/18 11:14 AM, Andrew Haley wrote: > >> Hi Dan, > >> > >> Have you got any torture tests for recursive locking? > >> > > > > From aph at redhat.com Thu Jun 14 12:14:58 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Jun 2018 13:14:58 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> Message-ID: <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > So then if you prefer to leave the different logic in shared code between > quick and slow paths I believe the fix for cpu/arm implementation (and > removal of unnecessary workaround for cpu/aarch64) should look like this: Something awful happened to the formatting of your mail. Can you put it up somewhere we can see the patch? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey.petushkov at gmail.com Thu Jun 14 12:25:01 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Thu, 14 Jun 2018 15:25:01 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> Message-ID: Hm, strange. It displays well for me in the archives page. Anyway, I've put the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley wrote: > On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > > So then if you prefer to leave the different logic in shared code between > > quick and slow paths I believe the fix for cpu/arm implementation (and > > removal of unnecessary workaround for cpu/aarch64) should look like this: > > Something awful happened to the formatting of your mail. Can you put > it up somewhere we can see the patch? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 > F A671 > From Derek.White at cavium.com Thu Jun 14 18:12:57 2018 From: Derek.White at cavium.com (White, Derek) Date: Thu, 14 Jun 2018 18:12:57 +0000 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> Message-ID: Hi Andrey, I like this version. My only suggestion is minor - the "ands" at line 3016 could be a simple "and". It causes no harm but could be confusing to a reader: 3016 ands(Rscratch, Rscratch, imm); No need to see a new webrev. - Derek > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Andrey Petushkov > Sent: Thursday, June 14, 2018 8:25 AM > To: Andrew Haley > Cc: hotspot-runtime-dev at openjdk.java.net; aarch64-port- > dev at openjdk.java.net; AArch32 Port Project dev at openjdk.java.net> > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > > External Email > > Hm, strange. It displays well for me in the archives page. Anyway, I've put > the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ > > On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley wrote: > > > On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > > > So then if you prefer to leave the different logic in shared code > > > between quick and slow paths I believe the fix for cpu/arm > > > implementation (and removal of unnecessary workaround for > cpu/aarch64) should look like this: > > > > Something awful happened to the formatting of your mail. Can you put > > it up somewhere we can see the patch? > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 > > F A671 > > From andrey.petushkov at gmail.com Thu Jun 14 20:54:47 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Thu, 14 Jun 2018 23:54:47 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> Message-ID: Hi Derek, that shall be ands since it expected to leave the result in the flags register, see the cmpFastLock instruct in aarch64.ad to my taste this version is error-prone, since it's quite hard to deduce that contract FastLock node involves writing of non 0 value into DHW of stack lock when it has failed. however I don't insist. so if everyone agrees could someone please commit. sorry, I don't have necessary status Regards, Andrey On Thu, Jun 14, 2018 at 9:13 PM White, Derek wrote: > Hi Andrey, > > I like this version. > > My only suggestion is minor - the "ands" at line 3016 could be a simple > "and". It causes no harm but could be confusing to a reader: > > 3016 ands(Rscratch, Rscratch, imm); > > No need to see a new webrev. > - Derek > > > -----Original Message----- > > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > > bounces at openjdk.java.net] On Behalf Of Andrey Petushkov > > Sent: Thursday, June 14, 2018 8:25 AM > > To: Andrew Haley > > Cc: hotspot-runtime-dev at openjdk.java.net; aarch64-port- > > dev at openjdk.java.net; AArch32 Port Project > dev at openjdk.java.net> > > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > > > > External Email > > > > Hm, strange. It displays well for me in the archives page. Anyway, I've > put > > the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ > > > > On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley wrote: > > > > > On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > > > > So then if you prefer to leave the different logic in shared code > > > > between quick and slow paths I believe the fix for cpu/arm > > > > implementation (and removal of unnecessary workaround for > > cpu/aarch64) should look like this: > > > > > > Something awful happened to the formatting of your mail. Can you put > > > it up somewhere we can see the patch? > > > > > > -- > > > Andrew Haley > > > Java Platform Lead Engineer > > > Red Hat UK Ltd. > > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 > > > F A671 > > > > From Derek.White at cavium.com Thu Jun 14 22:08:36 2018 From: Derek.White at cavium.com (White, Derek) Date: Thu, 14 Jun 2018 22:08:36 +0000 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> Message-ID: Hi Andrey, It took me looking at the code three times, but I finally saw what you mean about condition code register. OK, looks fine to me. You still need a (R)eviewer?s OK and then a sponsor. * Derek From: Andrey Petushkov [mailto:andrey.petushkov at gmail.com] Sent: Thursday, June 14, 2018 4:55 PM To: White, Derek Cc: Andrew Haley ; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; AArch32 Port Project Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking External Email Hi Derek, that shall be ands since it expected to leave the result in the flags register, see the cmpFastLock instruct in aarch64.ad to my taste this version is error-prone, since it's quite hard to deduce that contract FastLock node involves writing of non 0 value into DHW of stack lock when it has failed. however I don't insist. so if everyone agrees could someone please commit. sorry, I don't have necessary status Regards, Andrey On Thu, Jun 14, 2018 at 9:13 PM White, Derek > wrote: Hi Andrey, I like this version. My only suggestion is minor - the "ands" at line 3016 could be a simple "and". It causes no harm but could be confusing to a reader: 3016 ands(Rscratch, Rscratch, imm); No need to see a new webrev. - Derek > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Andrey Petushkov > Sent: Thursday, June 14, 2018 8:25 AM > To: Andrew Haley > > Cc: hotspot-runtime-dev at openjdk.java.net; aarch64-port- > dev at openjdk.java.net; AArch32 Port Project dev at openjdk.java.net> > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > > External Email > > Hm, strange. It displays well for me in the archives page. Anyway, I've put > the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ > > On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley > wrote: > > > On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > > > So then if you prefer to leave the different logic in shared code > > > between quick and slow paths I believe the fix for cpu/arm > > > implementation (and removal of unnecessary workaround for > cpu/aarch64) should look like this: > > > > Something awful happened to the formatting of your mail. Can you put > > it up somewhere we can see the patch? > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 > > F A671 > > From daniel.daugherty at oracle.com Fri Jun 15 17:29:57 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Jun 2018 13:29:57 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> Message-ID: <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> > http://cr.openjdk.java.net/~apetushkov/8153107/ src/hotspot/share/runtime/sharedRuntime.cpp ??? No comments. src/hotspot/cpu/arm/macroAssembler_arm.cpp ??? Looks correct. Here's my analysis: ??? The X64 version of this code does this: ??? src/hotspot/cpu/x86/macroAssembler_x86.cpp: ?? ?? // Recursive locking. ? ? ? // The object is stack-locked: markword contains stack pointer to BasicLock. ? ? ? // Locked by current thread if difference with current SP is less than one page. ? ? ? subptr(tmpReg, rsp); ? ? ? // Next instruction set ZFlag == 1 (Success) if difference is less then one page. ? ? ? andptr(tmpReg, (int32_t) (NOT_LP64(0xFFFFF003) LP64_ONLY(7 - os::vm_page_size())) ); ? ? ? movptr(Address(boxReg, 0), tmpReg); ? ? ? if (counters != NULL) { ?? ???? cond_inc32(Assembler::equal, ExternalAddress((address)counters->fast_path_entry_count_addr())); ?? ?? } ?? ?? jmp(DONE_LABEL); ??? This code path always updates "Address(boxReg, 0)" with the ??? "tmpReg" value so the markword always gets updated with a zero ??? or non-zero value. ??? The previous AMD64 code did this: ????? L3011: #ifdef AARCH64 ????? L3012: ? intptr_t mask = ((intptr_t)3) - ((intptr_t)os::vm_page_size()); ????? L3013: ? Assembler::LogicalImmediate imm(mask, false); ????? L3014: ? mov(Rscratch, SP); ????? L3015: ? sub(Rscratch, Rmark, Rscratch); ????? L3016: ? ands(Rscratch, Rscratch, imm); ????? L3017: ? b(done, ne); // exit with failure ????? L3018: ? str(Rscratch, Address(Rbox, BasicLock::displaced_header_offset_in_bytes())); // set to zero ????? L3019: ? b(done); ????? L3020: ????? L3021: #else ????? L3022: ? // -1- test low 2 bits ????? L3023: ? movs(Rscratch, AsmOperand(Rmark, lsl, 30)); ????? L3024: ? // -2- test (hdr - SP) if the low two bits are 0 ????? L3025: ? sub(Rscratch, Rmark, SP, eq); ????? L3026: ? movs(Rscratch, AsmOperand(Rscratch, lsr, exact_log2(os::vm_page_size())), eq); ????? L3027: ? // If still 'eq' then recursive locking OK ????? L3028: ? str(Rscratch, Address(Rbox, BasicLock::displaced_header_offset_in_bytes()), eq); // set to zero ????? L3029: ? b(done); ????? L3030: #endif ??? For the AARCH64 version, the key bug is the "b(done, ne); // exit with failure" ??? which results in the markword not getting set to a specific value. ??? Someone mentioned that we're getting a random value here and that ??? contributes to the intermittent nature of the hang. Removing L3017 ??? so that we always set the markword makes perfect sense. ??? For the non-AARCH64 version, the key bug is a little more obscure ??? (at least to me): "str(Rscratch, Address(Rbox, ...), eq); // set to zero". ??? I don't really know ARM assembly, but I'm guessing that the 'eq' parameter ??? controls whether the store of Rscratch into "Address(Rbox, ...)" occurs or ??? not. Removing the "eq" parameter in the fix so that we always set the ??? markword makes perfect sense. So thumbs up on the fix and I can sponsor it. Please provide me with an importable changeset and I'll take care of that after confirmation that the ARM folks have tested the fix and are happy with it. Dan On 6/14/18 6:08 PM, White, Derek wrote: > Hi Andrey, > > It took me looking at the code three times, but I finally saw what you mean about condition code register. OK, looks fine to me. > > You still need a (R)eviewer?s OK and then a sponsor. > > > * Derek > > From: Andrey Petushkov [mailto:andrey.petushkov at gmail.com] > Sent: Thursday, June 14, 2018 4:55 PM > To: White, Derek > Cc: Andrew Haley ; hotspot-runtime-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; AArch32 Port Project > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > > > External Email > Hi Derek, > > that shall be ands since it expected to leave the result in the flags register, see the cmpFastLock instruct in aarch64.ad > to my taste this version is error-prone, since it's quite hard to deduce that contract FastLock node involves writing of non 0 value into DHW of stack lock when it has failed. however I don't insist. so if everyone agrees could someone please commit. sorry, I don't have necessary status > > > Regards, > Andrey > > On Thu, Jun 14, 2018 at 9:13 PM White, Derek > wrote: > Hi Andrey, > > I like this version. > > My only suggestion is minor - the "ands" at line 3016 could be a simple "and". It causes no harm but could be confusing to a reader: > > 3016 ands(Rscratch, Rscratch, imm); > > No need to see a new webrev. > - Derek > >> -----Original Message----- >> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- >> bounces at openjdk.java.net] On Behalf Of Andrey Petushkov >> Sent: Thursday, June 14, 2018 8:25 AM >> To: Andrew Haley > >> Cc: hotspot-runtime-dev at openjdk.java.net; aarch64-port- >> dev at openjdk.java.net; AArch32 Port Project > dev at openjdk.java.net> >> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >> >> External Email >> >> Hm, strange. It displays well for me in the archives page. Anyway, I've put >> the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ >> >> On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley > wrote: >> >>> On 06/14/2018 12:59 PM, Andrey Petushkov wrote: >>>> So then if you prefer to leave the different logic in shared code >>>> between quick and slow paths I believe the fix for cpu/arm >>>> implementation (and removal of unnecessary workaround for >> cpu/aarch64) should look like this: >>> Something awful happened to the formatting of your mail. Can you put >>> it up somewhere we can see the patch? >>> >>> -- >>> Andrew Haley >>> Java Platform Lead Engineer >>> Red Hat UK Ltd. >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 >>> F A671 >>> From daniel.daugherty at oracle.com Fri Jun 15 17:59:48 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Jun 2018 13:59:48 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> Message-ID: <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> Andrey, I'm about to send the following changeset thru Mach5 testing: $ hg log -v -r tip changeset:?? 50592:dc9e3b56c8ab tag:???????? tip user:??????? apetushkov date:??????? Fri Jun 15 13:57:32 2018 -0400 files:?????? src/hotspot/cpu/arm/macroAssembler_arm.cpp src/hotspot/share/runtime/sharedRuntime.cpp description: 8153107: enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs Summary: Always set the markword for recursive monitors in MacroAssembler::fast_lock(). Reviewed-by: aph, drwhite, dcubed I don't expect any problems, but I'm paranoid so... Dan On 6/15/18 1:29 PM, Daniel D. Daugherty wrote: > > http://cr.openjdk.java.net/~apetushkov/8153107/ > > src/hotspot/share/runtime/sharedRuntime.cpp > ??? No comments. > > src/hotspot/cpu/arm/macroAssembler_arm.cpp > ??? Looks correct. Here's my analysis: > > ??? The X64 version of this code does this: > > ??? src/hotspot/cpu/x86/macroAssembler_x86.cpp: > > ?? ?? // Recursive locking. > ? ? ? // The object is stack-locked: markword contains stack pointer > to BasicLock. > ? ? ? // Locked by current thread if difference with current SP is > less than one page. > ? ? ? subptr(tmpReg, rsp); > ? ? ? // Next instruction set ZFlag == 1 (Success) if difference is > less then one page. > ? ? ? andptr(tmpReg, (int32_t) (NOT_LP64(0xFFFFF003) LP64_ONLY(7 - > os::vm_page_size())) ); > ? ? ? movptr(Address(boxReg, 0), tmpReg); > ? ? ? if (counters != NULL) { > ?? ???? cond_inc32(Assembler::equal, > ExternalAddress((address)counters->fast_path_entry_count_addr())); > ?? ?? } > ?? ?? jmp(DONE_LABEL); > > ??? This code path always updates "Address(boxReg, 0)" with the > ??? "tmpReg" value so the markword always gets updated with a zero > ??? or non-zero value. > > ??? The previous AMD64 code did this: > > ????? L3011: #ifdef AARCH64 > ????? L3012: ? intptr_t mask = ((intptr_t)3) - > ((intptr_t)os::vm_page_size()); > ????? L3013: ? Assembler::LogicalImmediate imm(mask, false); > ????? L3014: ? mov(Rscratch, SP); > ????? L3015: ? sub(Rscratch, Rmark, Rscratch); > ????? L3016: ? ands(Rscratch, Rscratch, imm); > ????? L3017: ? b(done, ne); // exit with failure > ????? L3018: ? str(Rscratch, Address(Rbox, > BasicLock::displaced_header_offset_in_bytes())); // set to zero > ????? L3019: ? b(done); > ????? L3020: > ????? L3021: #else > ????? L3022: ? // -1- test low 2 bits > ????? L3023: ? movs(Rscratch, AsmOperand(Rmark, lsl, 30)); > ????? L3024: ? // -2- test (hdr - SP) if the low two bits are 0 > ????? L3025: ? sub(Rscratch, Rmark, SP, eq); > ????? L3026: ? movs(Rscratch, AsmOperand(Rscratch, lsr, > exact_log2(os::vm_page_size())), eq); > ????? L3027: ? // If still 'eq' then recursive locking OK > ????? L3028: ? str(Rscratch, Address(Rbox, > BasicLock::displaced_header_offset_in_bytes()), eq); // set to zero > ????? L3029: ? b(done); > ????? L3030: #endif > > ??? For the AARCH64 version, the key bug is the "b(done, ne); // exit > with failure" > ??? which results in the markword not getting set to a specific value. > ??? Someone mentioned that we're getting a random value here and that > ??? contributes to the intermittent nature of the hang. Removing L3017 > ??? so that we always set the markword makes perfect sense. > > ??? For the non-AARCH64 version, the key bug is a little more obscure > ??? (at least to me): "str(Rscratch, Address(Rbox, ...), eq); // set > to zero". > ??? I don't really know ARM assembly, but I'm guessing that the 'eq' > parameter > ??? controls whether the store of Rscratch into "Address(Rbox, ...)" > occurs or > ??? not. Removing the "eq" parameter in the fix so that we always set the > ??? markword makes perfect sense. > > > So thumbs up on the fix and I can sponsor it. Please provide me with an > importable changeset and I'll take care of that after confirmation that > the ARM folks have tested the fix and are happy with it. > > Dan > > > On 6/14/18 6:08 PM, White, Derek wrote: >> Hi Andrey, >> >> It took me looking at the code three times, but I finally saw what >> you mean about condition code register. OK, looks fine to me. >> >> You still need a (R)eviewer?s OK and then a sponsor. >> >> >> ?? *?? Derek >> >> From: Andrey Petushkov [mailto:andrey.petushkov at gmail.com] >> Sent: Thursday, June 14, 2018 4:55 PM >> To: White, Derek >> Cc: Andrew Haley ; >> hotspot-runtime-dev at openjdk.java.net; >> aarch64-port-dev at openjdk.java.net; AArch32 Port Project >> >> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >> >> >> External Email >> Hi Derek, >> >> that shall be ands since it expected to leave the result in the flags >> register, see the cmpFastLock instruct in aarch64.ad >> to my taste this version is error-prone, since it's quite hard to >> deduce that contract FastLock node involves writing of non 0 value >> into DHW of stack lock when it has failed. however I don't insist. so >> if everyone agrees could someone please commit. sorry, I don't have >> necessary status >> >> >> Regards, >> Andrey >> >> On Thu, Jun 14, 2018 at 9:13 PM White, Derek >> > wrote: >> Hi Andrey, >> >> I like this version. >> >> My only suggestion is minor - the "ands" at line 3016 could be a >> simple "and". It causes no harm but could be confusing to a reader: >> >> 3016?? ands(Rscratch, Rscratch, imm); >> >> No need to see a new webrev. >> - Derek >> >>> -----Original Message----- >>> From: hotspot-runtime-dev >>> [mailto:hotspot-runtime-dev- >>> bounces at openjdk.java.net] On Behalf >>> Of Andrey Petushkov >>> Sent: Thursday, June 14, 2018 8:25 AM >>> To: Andrew Haley > >>> Cc: >>> hotspot-runtime-dev at openjdk.java.net; >>> aarch64-port- >>> dev at openjdk.java.net; AArch32 Port >>> Project >> dev at openjdk.java.net> >>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >>> >>> External Email >>> >>> Hm, strange. It displays well for me in the archives page. Anyway, >>> I've put >>> the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ >>> >>> On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley >>> > wrote: >>> >>>> On 06/14/2018 12:59 PM, Andrey Petushkov wrote: >>>>> So then if you prefer to leave the different logic in shared code >>>>> between quick and slow paths I believe the fix for cpu/arm >>>>> implementation (and removal of unnecessary workaround for >>> cpu/aarch64) should look like this: >>>> Something awful happened to the formatting of your mail.? Can you put >>>> it up somewhere we can see the patch? >>>> >>>> -- >>>> Andrew Haley >>>> Java Platform Lead Engineer >>>> Red Hat UK Ltd. >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 >>>> F A671 >>>> > > From edward.nevill at gmail.com Fri Jun 15 21:28:06 2018 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Jun 2018 21:28:06 +0000 Subject: hg: aarch32-port/jdk9u: 4 new changesets Message-ID: <201806152128.w5FLS6rG024649@aojmv0008.oracle.com> Changeset: 7d0b08fd5abb Author: enevill Date: 2015-12-07 21:25 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/rev/7d0b08fd5abb 8139303: aarch32: add support for ARM aarch32 Summary: Initial port of template interpreter to aarch32 Reviewed-by: duke Contributed-by: joseph.joyce at linaro.org ! common/autoconf/build-aux/config.sub ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! make/common/NativeCompilation.gmk Changeset: efb9022f220f Author: enevill Date: 2015-12-08 09:21 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/rev/efb9022f220f 8144905: aarch32: fails to build due to reliance on autoconf-config.sub Reviewed-by: duke ! common/autoconf/build-aux/config.sub Changeset: a3304a423297 Author: enevill Date: 2016-10-12 19:58 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/rev/a3304a423297 8167584: aarch32: use "arm" for os.arch system property Reviewed-by: enevill Contributed-by: akashche at redhat.com ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 Changeset: 5413e7cc4fbe Author: enevill Date: 2018-06-15 21:19 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/rev/5413e7cc4fbe 8205123: aarch32: add C2 plus additional functionality Reviewed-by: enevill Contributed-by: andrey.petushkov at gmail.com, fedor.burdun at azulsystems.com ! common/autoconf/flags.m4 ! common/autoconf/generated-configure.sh ! common/autoconf/hotspot.m4 ! common/autoconf/platform.m4 ! common/conf/jib-profiles.js From edward.nevill at gmail.com Fri Jun 15 21:28:35 2018 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Jun 2018 21:28:35 +0000 Subject: hg: aarch32-port/jdk9u/jdk: 3 new changesets Message-ID: <201806152128.w5FLSZjm025063@aojmv0008.oracle.com> Changeset: c1b052eebb2a Author: enevill Date: 2015-12-07 21:26 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/jdk/rev/c1b052eebb2a 8139303: aarch32: add support for ARM aarch32 Summary: Initial port of template interpreter to aarch32 Reviewed-by: duke Contributed-by: joseph.joyce at linaro.org ! make/copy/Copy-java.base.gmk + src/java.base/unix/conf/aarch32/jvm.cfg Changeset: 2f3b5fbdc74f Author: enevill Date: 2018-06-15 21:18 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/jdk/rev/2f3b5fbdc74f 8205123: aarch32: add C2 plus additional functionality Reviewed-by: enevill Contributed-by: andrey.petushkov at gmail.com, fedor.burdun at azulsystems.com ! make/copy/Copy-java.base.gmk ! src/java.base/unix/conf/aarch32/jvm.cfg Changeset: f8e75da258cd Author: enevill Date: 2018-06-15 21:24 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/jdk/rev/f8e75da258cd 8205124: aarch32: make build work again with jvm-variant=core Reviewed-by: duke ! make/copy/Copy-java.base.gmk From edward.nevill at gmail.com Fri Jun 15 21:29:47 2018 From: edward.nevill at gmail.com (edward.nevill at gmail.com) Date: Fri, 15 Jun 2018 21:29:47 +0000 Subject: hg: aarch32-port/jdk9u/hotspot: 45 new changesets Message-ID: <201806152129.w5FLTmoM025373@aojmv0008.oracle.com> Changeset: b4ddb5c23551 Author: enevill Date: 2015-12-07 21:48 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/b4ddb5c23551 8139303: aarch32: add support for ARM aarch32 Summary: Initial port of template interpreter to aarch32 Reviewed-by: duke Contributed-by: joseph.joyce at linaro.org + src/cpu/aarch32/vm/aarch32Test.cpp + src/cpu/aarch32/vm/assembler_aarch32.cpp + src/cpu/aarch32/vm/assembler_aarch32.hpp + src/cpu/aarch32/vm/assembler_aarch32.inline.hpp + src/cpu/aarch32/vm/bytecodeInterpreter_aarch32.cpp + src/cpu/aarch32/vm/bytecodeInterpreter_aarch32.hpp + src/cpu/aarch32/vm/bytecodeInterpreter_aarch32.inline.hpp + src/cpu/aarch32/vm/bytecodes_aarch32.cpp + src/cpu/aarch32/vm/bytecodes_aarch32.hpp + src/cpu/aarch32/vm/bytes_aarch32.hpp + src/cpu/aarch32/vm/codeBuffer_aarch32.hpp + src/cpu/aarch32/vm/compiledIC_aarch32.cpp + src/cpu/aarch32/vm/copy_aarch32.hpp + src/cpu/aarch32/vm/cpustate_aarch32.hpp + src/cpu/aarch32/vm/debug_aarch32.cpp + src/cpu/aarch32/vm/decode_aarch32.hpp + src/cpu/aarch32/vm/depChecker_aarch32.cpp + src/cpu/aarch32/vm/depChecker_aarch32.hpp + src/cpu/aarch32/vm/disassembler_aarch32.hpp + src/cpu/aarch32/vm/frame_aarch32.cpp + src/cpu/aarch32/vm/frame_aarch32.hpp + src/cpu/aarch32/vm/frame_aarch32.inline.hpp + src/cpu/aarch32/vm/globalDefinitions_aarch32.hpp + src/cpu/aarch32/vm/globals_aarch32.hpp + src/cpu/aarch32/vm/icBuffer_aarch32.cpp + src/cpu/aarch32/vm/icache_aarch32.cpp + src/cpu/aarch32/vm/icache_aarch32.hpp + src/cpu/aarch32/vm/immediate_aarch32.cpp + src/cpu/aarch32/vm/immediate_aarch32.hpp + src/cpu/aarch32/vm/interp_masm_aarch32.cpp + src/cpu/aarch32/vm/interp_masm_aarch32.hpp + src/cpu/aarch32/vm/interpreterRT_aarch32.cpp + src/cpu/aarch32/vm/interpreterRT_aarch32.hpp + src/cpu/aarch32/vm/interpreter_aarch32.cpp + src/cpu/aarch32/vm/interpreter_aarch32.hpp + src/cpu/aarch32/vm/javaFrameAnchor_aarch32.hpp + src/cpu/aarch32/vm/jniFastGetField_aarch32.cpp + src/cpu/aarch32/vm/jniTypes_aarch32.hpp + src/cpu/aarch32/vm/jni_aarch32.h + src/cpu/aarch32/vm/macroAssembler_aarch32.cpp + src/cpu/aarch32/vm/macroAssembler_aarch32.hpp + src/cpu/aarch32/vm/macroAssembler_aarch32.inline.hpp + src/cpu/aarch32/vm/metaspaceShared_aarch32.cpp + src/cpu/aarch32/vm/methodHandles_aarch32.cpp + src/cpu/aarch32/vm/methodHandles_aarch32.hpp + src/cpu/aarch32/vm/nativeInst_aarch32.cpp + src/cpu/aarch32/vm/nativeInst_aarch32.hpp + src/cpu/aarch32/vm/registerMap_aarch32.hpp + src/cpu/aarch32/vm/register_aarch32.cpp + src/cpu/aarch32/vm/register_aarch32.hpp + src/cpu/aarch32/vm/register_definitions_aarch32.cpp + src/cpu/aarch32/vm/relocInfo_aarch32.cpp + src/cpu/aarch32/vm/relocInfo_aarch32.hpp + src/cpu/aarch32/vm/runtime_aarch32.cpp + src/cpu/aarch32/vm/sharedRuntime_aarch32.cpp + src/cpu/aarch32/vm/stubGenerator_aarch32.cpp + src/cpu/aarch32/vm/stubRoutines_aarch32.cpp + src/cpu/aarch32/vm/stubRoutines_aarch32.hpp + src/cpu/aarch32/vm/templateInterpreterGenerator_aarch32.hpp + src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp + src/cpu/aarch32/vm/templateInterpreter_aarch32.hpp + src/cpu/aarch32/vm/templateTable_aarch32.cpp + src/cpu/aarch32/vm/templateTable_aarch32.hpp + src/cpu/aarch32/vm/vmStructs_aarch32.hpp + src/cpu/aarch32/vm/vm_version_aarch32.cpp + src/cpu/aarch32/vm/vm_version_aarch32.hpp + src/cpu/aarch32/vm/vmreg_aarch32.cpp + src/cpu/aarch32/vm/vmreg_aarch32.hpp + src/cpu/aarch32/vm/vmreg_aarch32.inline.hpp + src/cpu/aarch32/vm/vtableStubs_aarch32.cpp ! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.c ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h + src/os_cpu/linux_aarch32/vm/assembler_linux_aarch32.cpp + src/os_cpu/linux_aarch32/vm/atomic_linux_aarch32.inline.hpp + src/os_cpu/linux_aarch32/vm/bytes_linux_aarch32.inline.hpp + src/os_cpu/linux_aarch32/vm/copy_linux_aarch32.inline.hpp + src/os_cpu/linux_aarch32/vm/globals_linux_aarch32.hpp + src/os_cpu/linux_aarch32/vm/linux_aarch32.S + src/os_cpu/linux_aarch32/vm/orderAccess_linux_aarch32.inline.hpp + src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp + src/os_cpu/linux_aarch32/vm/os_linux_aarch32.hpp + src/os_cpu/linux_aarch32/vm/os_linux_aarch32.inline.hpp + src/os_cpu/linux_aarch32/vm/prefetch_linux_aarch32.inline.hpp + src/os_cpu/linux_aarch32/vm/threadLS_linux_aarch32.cpp + src/os_cpu/linux_aarch32/vm/threadLS_linux_aarch32.hpp + src/os_cpu/linux_aarch32/vm/thread_linux_aarch32.cpp + src/os_cpu/linux_aarch32/vm/thread_linux_aarch32.hpp + src/os_cpu/linux_aarch32/vm/vmStructs_linux_aarch32.hpp + src/os_cpu/linux_aarch32/vm/vm_version_linux_aarch32.cpp ! src/share/tools/hsdis/hsdis.c ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/macros.hpp Changeset: be8d48e0370e Author: enevill Date: 2015-12-23 12:21 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/be8d48e0370e 8146094: aarch32: exception handling in putfield corrupts dispatch register Summary: Use rscratch2 instead of rdispatch Reviewed-by: duke Contributed-by: triple.yang at linaro.org ! src/cpu/aarch32/vm/templateTable_aarch32.cpp Changeset: 35a7af957b07 Author: jjoyce Date: 2015-12-26 22:30 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/35a7af957b07 8146193: Bad marshalling of single precision floats Summary: Switched action of fp_rencode_real for 32/64 bit floats. Fixed variable names in assertions. Reviewed-by: enevill ! src/cpu/aarch32/vm/assembler_aarch32.hpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp Changeset: 46d0ef8405d8 Author: enevill Date: 2015-12-29 16:18 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/46d0ef8405d8 8146284: integer shifts not correctly masked Summary: and shift quantity with 0x1f as required by hava spec Reviewed-by: duke Contributed-by: xiang.yuan at linaro.org ! src/cpu/aarch32/vm/templateTable_aarch32.cpp Changeset: 78111b410520 Author: enevill Date: 2015-12-29 16:25 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/78111b410520 8146285: aarch32: NegativeArraySizeException not thrown correctly Summary: Restore correct value of lr in newarray handler Reviewed-by: duke Contributed-by: triple.yang at linaro.org, snazarkin at azul.com ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp Changeset: 389e4f569cc9 Author: enevill Date: 2015-12-30 17:16 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/389e4f569cc9 8146339: aarch32: mov immediate generates incorrect value for some immediate values Summary: Use movw/movt instead of just movt for immediates with bottom 16 bits 0 Reviewed-by: duke Contributed-by: xiang.yuan at linaro.org ! src/cpu/aarch32/vm/assembler_aarch32.cpp Changeset: 86bb7fe73428 Author: enevill Date: 2016-01-05 09:17 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/86bb7fe73428 8146456: aarch32: JVM crashes when run with -Xdebug option Summary: Fix register corruption Reviewed-by: duke Contributed-by: shanyao.chen at linaro.org ! src/cpu/aarch32/vm/templateTable_aarch32.cpp Changeset: 96273945554b Author: jjoyce Date: 2016-01-09 20:42 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/96273945554b 8146308: [aarch32] Debug builds fail Summary: Combine store_check_part_ 1 and 2, fix barrier set assertion. Initialise variables to remove some build warnings. Reviewed-by: enevill ! src/cpu/aarch32/vm/assembler_aarch32.cpp ! src/cpu/aarch32/vm/interpreter_aarch32.cpp ! src/cpu/aarch32/vm/jniFastGetField_aarch32.cpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.hpp ! src/cpu/aarch32/vm/methodHandles_aarch32.cpp Changeset: 815ff972dc01 Author: jjoyce Date: 2016-01-11 14:58 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/815ff972dc01 8146734: SlowSignatureHandler always uses softfloat Summary: Correct ifdefs to use hardfloat if required. Fix softfloat pass_double to call pass_long. Reviewed-by: enevill ! src/cpu/aarch32/vm/interpreterRT_aarch32.cpp Changeset: 344ea8a33362 Author: enevill Date: 2016-01-20 21:28 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/344ea8a33362 8147874: aarch32: JVM crashes with SIGILL when using TraceBytecodes Summary: Fix invalid register range in generate_trace_code Reviewed-by: duke Contributed-by: shanyao.chen at linaro.org ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp Changeset: 9a11237b0e43 Author: enevill Date: 2016-01-27 11:38 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/9a11237b0e43 8148355: aarch32: JVM bugfix for failing to running JTreg test 'hotspot/test/compiler/7116216/StackOverflow.java' Summary: Fix stack pointer adjustment in generate_throw_exception Reviewed-by: duke Contributed-by: mingliang.yi at linaro.org ! src/cpu/aarch32/vm/stubGenerator_aarch32.cpp ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp Changeset: a548b7ecebf2 Author: enevill Date: 2016-02-11 09:43 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/a548b7ecebf2 8149548: aarch32: slowdebug build crashes if -XX:+TraceBytecodes flag is used Reviewed-by: enevill Contributed-by: snazarkin at azul.com ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp ! src/cpu/aarch32/vm/stubGenerator_aarch32.cpp ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp Changeset: d2f0850e4690 Author: enevill Date: 2016-02-11 09:45 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/d2f0850e4690 8149559: aarch32: crash error output is not informative Reviewed-by: enevill Contributed-by: snazarkin at azul.com ! src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp Changeset: 8f286ded727c Author: enevill Date: 2016-02-11 11:34 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/8f286ded727c 8149563: aarch32: os::current_frame() crashes Reviewed-by: enevill Contributed-by: snazarkin at azul.com ! src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp Changeset: c87d78a336a2 Author: enevill Date: 2016-02-16 09:30 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/c87d78a336a2 8149646: aarch32: EventLogBase::print_log_on() is failed to acquire MutexLockerEx Reviewed-by: enevill Contributed-by: snazarkin at azul.com ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp Changeset: a554e5715639 Author: enevill Date: 2016-02-16 14:03 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/a554e5715639 8149654: aarch32: Remove code related to aarch64 simulator Reviewed-by: enevill Contributed-by: snazarkin at azul.com ! src/cpu/aarch32/vm/assembler_aarch32.cpp ! src/cpu/aarch32/vm/metaspaceShared_aarch32.cpp ! src/cpu/aarch32/vm/sharedRuntime_aarch32.cpp ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp ! src/cpu/aarch32/vm/vm_version_aarch32.cpp ! src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp ! src/os_cpu/linux_aarch32/vm/prefetch_linux_aarch32.inline.hpp Changeset: 39164b45c4c2 Author: enevill Date: 2016-02-24 11:13 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/39164b45c4c2 8150520: aarch32: SIGILL when jdwp is enabled Reviewed-by: enevill Contributed-by: snazarkin at azul.com ! src/cpu/aarch32/vm/interp_masm_aarch32.cpp Changeset: 305ca579599f Author: enevill Date: 2016-03-03 14:38 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/305ca579599f 8151180: aarch32: cumulative patch for C1 integration Summary: Non JIT changes to facilitate future synchronization of C1 Reviewed-by: enevill Contributed-by: snazarkin at azul.com ! src/cpu/aarch32/vm/assembler_aarch32.cpp ! src/cpu/aarch32/vm/assembler_aarch32.hpp ! src/cpu/aarch32/vm/compiledIC_aarch32.cpp ! src/cpu/aarch32/vm/frame_aarch32.cpp ! src/cpu/aarch32/vm/frame_aarch32.hpp ! src/cpu/aarch32/vm/frame_aarch32.inline.hpp ! src/cpu/aarch32/vm/globalDefinitions_aarch32.hpp ! src/cpu/aarch32/vm/icBuffer_aarch32.cpp ! src/cpu/aarch32/vm/interp_masm_aarch32.cpp ! src/cpu/aarch32/vm/interp_masm_aarch32.hpp ! src/cpu/aarch32/vm/interpreterRT_aarch32.cpp ! src/cpu/aarch32/vm/interpreterRT_aarch32.hpp ! src/cpu/aarch32/vm/interpreter_aarch32.cpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.hpp ! src/cpu/aarch32/vm/methodHandles_aarch32.cpp ! src/cpu/aarch32/vm/nativeInst_aarch32.cpp ! src/cpu/aarch32/vm/nativeInst_aarch32.hpp ! src/cpu/aarch32/vm/register_aarch32.cpp ! src/cpu/aarch32/vm/register_aarch32.hpp ! src/cpu/aarch32/vm/register_definitions_aarch32.cpp ! src/cpu/aarch32/vm/relocInfo_aarch32.cpp ! src/cpu/aarch32/vm/sharedRuntime_aarch32.cpp ! src/cpu/aarch32/vm/stubGenerator_aarch32.cpp ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp ! src/cpu/aarch32/vm/templateTable_aarch32.cpp ! src/cpu/aarch32/vm/vm_version_aarch32.cpp ! src/cpu/aarch32/vm/vmreg_aarch32.cpp ! src/cpu/aarch32/vm/vmreg_aarch32.hpp ! src/cpu/aarch32/vm/vmreg_aarch32.inline.hpp ! src/cpu/aarch32/vm/vtableStubs_aarch32.cpp ! src/os_cpu/linux_aarch32/vm/assembler_linux_aarch32.cpp ! src/os_cpu/linux_aarch32/vm/globals_linux_aarch32.hpp ! src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp ! src/os_cpu/linux_aarch32/vm/threadLS_linux_aarch32.cpp ! src/os_cpu/linux_aarch32/vm/threadLS_linux_aarch32.hpp Changeset: 09e4eb76b015 Author: enevill Date: 2016-03-10 11:59 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/09e4eb76b015 8151611: array copy stub copies wrong data count Reviewed-by: enevill Contributed-by: akozlov at azul.com ! src/cpu/aarch32/vm/stubGenerator_aarch32.cpp Changeset: 6eb2b555a746 Author: enevill Date: 2016-03-13 14:49 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/6eb2b555a746 8151284: aarch32: on-stack replacement does not work properly when invoked from compiled Reviewed-by: enevill Contributed-by: andrey.petushkov at gmail.com ! src/cpu/aarch32/vm/templateTable_aarch32.cpp Changeset: 2956b60ba247 Author: enevill Date: 2016-03-17 11:43 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/2956b60ba247 8151774: longs may be passed in incorrect register Reviewed-by: enevill Contributed-by: akozlov at azul.com ! src/cpu/aarch32/vm/sharedRuntime_aarch32.cpp Changeset: 23ac705e9361 Author: enevill Date: 2016-03-22 10:41 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/23ac705e9361 8152130: aarch32: remove unused definition of min Summary: remove unused def of min to allow compilation with gcc 6 Reviewed-by: enevill Contributed-by: akashche at redhat.com ! src/cpu/aarch32/vm/sharedRuntime_aarch32.cpp Changeset: 0c5c54d72c99 Author: enevill Date: 2016-03-22 16:11 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/0c5c54d72c99 8152131: aarch32: specify which overloaded variant of fmod to use Summary: cast fmod compile with gcc 6 Reviewed-by: enevill Contributed-by: akashche at redhat.com ! src/cpu/aarch32/vm/templateTable_aarch32.cpp Changeset: f0518c513799 Author: enevill Date: 2016-03-22 16:15 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/f0518c513799 8152297: Macroassmbler:divide has to be able accept the same dividend and divisor Summary: Remove assert which failes becuase divide is called with same dividend and divisor Reviewed-by: enevill Contributed-by: snazarkin at azul.com ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp Changeset: 9808701f9e24 Author: enevill Date: 2016-03-22 16:27 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/9808701f9e24 8152304: aarch32: fix for compiler/7116216/StackOverflow regression test Reviewed-by: enevill Contributed-by: snazarkin at azul.com ! src/cpu/aarch32/vm/stubGenerator_aarch32.cpp ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp Changeset: 57a8aad5aac4 Author: enevill Date: 2016-03-22 16:35 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/57a8aad5aac4 8152408: Remove stop in JVMTI popframe Summary: Remove debug stop and fixe register usage Reviewed-by: enevill Contributed-by: snazarkin at azul.com ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp Changeset: 6d117cbc5590 Author: enevill Date: 2016-03-22 16:53 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/6d117cbc5590 8152442: change in ldrd/strd macrosses required for implicit null check Reviewed-by: enevill Contributed-by: fedor.burdun at azulsystems.com ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.hpp Changeset: ced4dce7eac0 Author: enevill Date: 2016-04-05 09:12 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/ced4dce7eac0 8153493: aarch32: assembler generates non canonical form for mov imm instructions Reviewed-by: enevill Contributed-by: akozlov at azul.com ! src/cpu/aarch32/vm/assembler_aarch32.cpp Changeset: 7da05ab2d62f Author: enevill Date: 2016-04-05 09:18 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/7da05ab2d62f 8153495: aarch32: remove redundant "Not tested this message" Reviewed-by: enevill Contributed-by: akozlov at azul.com ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp Changeset: c9f4e2704328 Author: enevill Date: 2016-04-05 09:27 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/c9f4e2704328 8153496: aarch32: rthread corrupted in method handle dispatch Reviewed-by: enevill Contributed-by: akozlov at azul.com ! src/cpu/aarch32/vm/methodHandles_aarch32.cpp Changeset: a23083918540 Author: enevill Date: 2016-04-05 09:37 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/a23083918540 8153497: aarch32: implement special case of moving +0.0 to double register Reviewed-by: enevill Contributed-by: fedor.burdun at azulsystems.com ! src/cpu/aarch32/vm/assembler_aarch32.cpp ! src/cpu/aarch32/vm/assembler_aarch32.hpp ! src/cpu/aarch32/vm/icache_aarch32.cpp ! src/cpu/aarch32/vm/templateTable_aarch32.cpp ! src/cpu/aarch32/vm/vm_version_aarch32.cpp ! src/cpu/aarch32/vm/vm_version_aarch32.hpp Changeset: 698647e36e96 Author: enevill Date: 2016-04-11 11:56 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/698647e36e96 8153958: aarch32: fix of vtable self-patching routine Reviewed-by: enevill Contributed-by: fedor.burdun at azulsystems.com ! src/cpu/aarch32/vm/metaspaceShared_aarch32.cpp Changeset: ed83d661ab9c Author: enevill Date: 2016-04-28 17:03 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/ed83d661ab9c 8155645: aarch32: Turn off critical JNI Summary: Turn off critical JNI plsu other minor tidy ups Reviewed-by: enevill Contributed-by: fedor.burdun at azulsystems.com ! src/cpu/aarch32/vm/globals_aarch32.hpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.hpp ! src/cpu/aarch32/vm/templateTable_aarch32.cpp ! src/cpu/aarch32/vm/vm_version_aarch32.cpp Changeset: b72a8059290d Author: enevill Date: 2016-05-02 15:15 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/b72a8059290d 8155826: aarch32: java/nio/MappedByteBuffer/Truncate.java fails Summary: fix nextpc calculation in handle_unsafe_access Reviewed-by: enevill Contributed-by: fedor.burdun at azulsystems.com ! src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp Changeset: 7acd79b28164 Author: akasko Date: 2016-06-14 16:02 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/7acd79b28164 8156208: aarch32: Fatal Error Log improvement Summary: print location of addresses stored at the registers Reviewed-by: enevill Contributed-by: snazarkin at azul.com ! src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp Changeset: 1a435735b1a6 Author: akasko Date: 2016-06-14 16:07 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/1a435735b1a6 8156945: aarch32: add verification of Use*Intrinsics cmdline parameters Reviewed-by: enevill Contributed-by: alexey at azul.com ! src/cpu/aarch32/vm/vm_version_aarch32.cpp Changeset: 1da2134e3eef Author: akasko Date: 2016-06-14 16:12 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/1da2134e3eef 8156948: aarch32: Fix wrong message of the ArrayIndexOutOfBoundException Reviewed-by: enevill Contributed-by: alexey at azul.com ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp ! src/cpu/aarch32/vm/templateTable_aarch32.cpp Changeset: 55ab38a89b7a Author: akasko Date: 2016-06-14 16:24 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/55ab38a89b7a 8155618: aarch32: implement CRC32 intrinsics Reviewed-by: enevill Contributed-by: andrey.petushkov at gmail.com ! src/cpu/aarch32/vm/assembler_aarch32.cpp ! src/cpu/aarch32/vm/assembler_aarch32.hpp ! src/cpu/aarch32/vm/globals_aarch32.hpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.hpp ! src/cpu/aarch32/vm/register_aarch32.hpp ! src/cpu/aarch32/vm/register_definitions_aarch32.cpp ! src/cpu/aarch32/vm/stubGenerator_aarch32.cpp ! src/cpu/aarch32/vm/stubRoutines_aarch32.cpp ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp ! src/cpu/aarch32/vm/vm_version_aarch32.cpp ! src/cpu/aarch32/vm/vm_version_aarch32.hpp ! src/cpu/aarch32/vm/vmreg_aarch32.cpp Changeset: afc2bb79ad9c Author: akasko Date: 2016-06-14 16:27 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/afc2bb79ad9c 8158492: aarch32: bogus warning CRC32 Intrinsics not implemented Summary: Remove bogus check Reviewed-by: enevill Contributed-by: andrey at azul.com ! src/cpu/aarch32/vm/vm_version_aarch32.cpp Changeset: 75240821a4f8 Author: akasko Date: 2016-06-14 16:29 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/75240821a4f8 8158386: aarch32: jlong value corrupt when returned from method being deoptimized Summary: Save/restore high half of jlongs in r1 Reviewed-by: enevill Contributed-by: andrey at azul.com ! src/cpu/aarch32/vm/sharedRuntime_aarch32.cpp Changeset: 50bdf9fdc08f Author: akasko Date: 2016-06-14 16:32 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/50bdf9fdc08f 8158498: aarch32: os::current_stack_pointer may return unaligned sp Summary: Use external asm function to set sp correctly Reviewed-by: enevill Contributed-by: akozlov at azul.com, akashche at redhat.com + src/os_cpu/linux_aarch32/vm/asm_os_linux_aarch32.s ! src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp Changeset: 64e067f79555 Author: akasko Date: 2016-06-14 16:34 +0000 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/64e067f79555 8158500: aarch32: regression test com/sun/jdi/PopAsynchronousTest.java crashes VM Summary: restore dispatch register in remove_activation Reviewed-by: enevill Contributed-by: fedor.burdun at azulsystems.com ! src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp Changeset: 222712e5cfe8 Author: enevill Date: 2016-06-25 19:32 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/222712e5cfe8 8160298: missing HARD_FLOAT_CC conditionalisation in generate_slow_signature_handler Reviewed-by: enevill Contributed-by: mingliang.yi at linaro.org ! src/cpu/aarch32/vm/interpreter_aarch32.cpp Changeset: b7a9aef30a0a Author: snazarki Date: 2016-10-04 13:21 +0300 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/b7a9aef30a0a 8167027: Scala HelloWord crash Reviewed-by: enevill ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp Changeset: e11b6a559b8d Author: enevill Date: 2018-06-15 21:20 +0100 URL: http://hg.openjdk.java.net/aarch32-port/jdk9u/hotspot/rev/e11b6a559b8d 8205123: aarch32: add C2 plus additional functionality Reviewed-by: enevill Contributed-by: andrey.petushkov at gmail.com, fedor.burdun at azulsystems.com ! make/lib/JvmOverrideFiles.gmk ! make/lib/Lib-jdk.hotspot.agent.gmk + make/linux/makefiles/aarch32.make + make/linux/platform_aarch32 + src/cpu/aarch32/vm/aarch32.ad + src/cpu/aarch32/vm/abstractInterpreter_aarch32.cpp ! src/cpu/aarch32/vm/assembler_aarch32.cpp ! src/cpu/aarch32/vm/assembler_aarch32.hpp - src/cpu/aarch32/vm/bytecodeInterpreter_aarch32.cpp - src/cpu/aarch32/vm/bytecodeInterpreter_aarch32.hpp - src/cpu/aarch32/vm/bytecodeInterpreter_aarch32.inline.hpp ! src/cpu/aarch32/vm/bytecodes_aarch32.hpp ! src/cpu/aarch32/vm/bytes_aarch32.hpp + src/cpu/aarch32/vm/c1_CodeStubs_aarch32.cpp + src/cpu/aarch32/vm/c1_Defs_aarch32.hpp + src/cpu/aarch32/vm/c1_FpuStackSim_aarch32.cpp + src/cpu/aarch32/vm/c1_FpuStackSim_aarch32.hpp + src/cpu/aarch32/vm/c1_FrameMap_aarch32.cpp + src/cpu/aarch32/vm/c1_FrameMap_aarch32.hpp + src/cpu/aarch32/vm/c1_LIRAssembler_aarch32.cpp + src/cpu/aarch32/vm/c1_LIRAssembler_aarch32.hpp + src/cpu/aarch32/vm/c1_LIRGenerator_aarch32.cpp + src/cpu/aarch32/vm/c1_LIR_aarch32.cpp + src/cpu/aarch32/vm/c1_LinearScan_aarch32.cpp + src/cpu/aarch32/vm/c1_LinearScan_aarch32.hpp + src/cpu/aarch32/vm/c1_MacroAssembler_aarch32.cpp + src/cpu/aarch32/vm/c1_MacroAssembler_aarch32.hpp + src/cpu/aarch32/vm/c1_Runtime1_aarch32.cpp + src/cpu/aarch32/vm/c1_globals_aarch32.hpp + src/cpu/aarch32/vm/c2_globals_aarch32.hpp ! src/cpu/aarch32/vm/compiledIC_aarch32.cpp ! src/cpu/aarch32/vm/copy_aarch32.hpp - src/cpu/aarch32/vm/debug_aarch32.cpp ! src/cpu/aarch32/vm/frame_aarch32.cpp ! src/cpu/aarch32/vm/frame_aarch32.hpp ! src/cpu/aarch32/vm/frame_aarch32.inline.hpp ! src/cpu/aarch32/vm/globalDefinitions_aarch32.hpp ! src/cpu/aarch32/vm/globals_aarch32.hpp ! src/cpu/aarch32/vm/icBuffer_aarch32.cpp - src/cpu/aarch32/vm/immediate_aarch32.cpp - src/cpu/aarch32/vm/immediate_aarch32.hpp ! src/cpu/aarch32/vm/interp_masm_aarch32.cpp ! src/cpu/aarch32/vm/interp_masm_aarch32.hpp - src/cpu/aarch32/vm/interpreter_aarch32.cpp - src/cpu/aarch32/vm/interpreter_aarch32.hpp ! src/cpu/aarch32/vm/javaFrameAnchor_aarch32.hpp ! src/cpu/aarch32/vm/jniFastGetField_aarch32.cpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.cpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.hpp ! src/cpu/aarch32/vm/macroAssembler_aarch32.inline.hpp ! src/cpu/aarch32/vm/methodHandles_aarch32.cpp ! src/cpu/aarch32/vm/nativeInst_aarch32.cpp ! src/cpu/aarch32/vm/nativeInst_aarch32.hpp ! src/cpu/aarch32/vm/registerMap_aarch32.hpp ! src/cpu/aarch32/vm/register_aarch32.hpp ! src/cpu/aarch32/vm/register_definitions_aarch32.cpp ! src/cpu/aarch32/vm/relocInfo_aarch32.cpp ! src/cpu/aarch32/vm/sharedRuntime_aarch32.cpp ! src/cpu/aarch32/vm/stubGenerator_aarch32.cpp ! src/cpu/aarch32/vm/stubRoutines_aarch32.cpp ! src/cpu/aarch32/vm/stubRoutines_aarch32.hpp + src/cpu/aarch32/vm/templateInterpreterGenerator_aarch32.cpp - src/cpu/aarch32/vm/templateInterpreterGenerator_aarch32.hpp - src/cpu/aarch32/vm/templateInterpreter_aarch32.cpp - src/cpu/aarch32/vm/templateInterpreter_aarch32.hpp ! src/cpu/aarch32/vm/templateTable_aarch32.cpp ! src/cpu/aarch32/vm/vm_version_aarch32.cpp ! src/cpu/aarch32/vm/vm_version_aarch32.hpp + src/cpu/aarch32/vm/vm_version_aarch32_2.cpp ! src/cpu/aarch32/vm/vmreg_aarch32.hpp ! src/cpu/aarch32/vm/vmreg_aarch32.inline.hpp ! src/cpu/aarch32/vm/vtableStubs_aarch32.cpp ! src/cpu/arm/vm/c1_LIRGenerator_arm.cpp ! src/jdk.hotspot.agent/linux/native/libsaproc/libproc.h ! src/os/linux/vm/os_linux.cpp ! src/os_cpu/linux_aarch32/vm/asm_os_linux_aarch32.s ! src/os_cpu/linux_aarch32/vm/assembler_linux_aarch32.cpp + src/os_cpu/linux_aarch32/vm/atomic_linux_aarch32.hpp ! src/os_cpu/linux_aarch32/vm/atomic_linux_aarch32.inline.hpp ! src/os_cpu/linux_aarch32/vm/globals_linux_aarch32.hpp ! src/os_cpu/linux_aarch32/vm/linux_aarch32.S ! src/os_cpu/linux_aarch32/vm/orderAccess_linux_aarch32.inline.hpp ! src/os_cpu/linux_aarch32/vm/os_linux_aarch32.cpp - src/os_cpu/linux_aarch32/vm/threadLS_linux_aarch32.cpp - src/os_cpu/linux_aarch32/vm/threadLS_linux_aarch32.hpp ! src/os_cpu/linux_aarch32/vm/thread_linux_aarch32.cpp ! src/os_cpu/linux_aarch32/vm/thread_linux_aarch32.hpp ! src/share/vm/c1/c1_Compiler.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/interpreter/abstractInterpreter.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.cpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/macros.hpp ! test/compiler/testlibrary/sha/predicate/IntrinsicPredicates.java From andrey.petushkov at gmail.com Sat Jun 16 16:11:47 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Sat, 16 Jun 2018 19:11:47 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> Message-ID: Hi Dan, Thank you for sponsorship and yes, > I don't really know ARM assembly, but I'm guessing that the 'eq' > parameter > controls whether the store of Rscratch into "Address(Rbox, ...)" > occurs or > not You guess is perfectly correct! Thanks again, Andrey On Fri, Jun 15, 2018 at 9:00 PM Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > Andrey, > > I'm about to send the following changeset thru Mach5 testing: > > $ hg log -v -r tip > changeset: 50592:dc9e3b56c8ab > tag: tip > user: apetushkov > date: Fri Jun 15 13:57:32 2018 -0400 > files: src/hotspot/cpu/arm/macroAssembler_arm.cpp > src/hotspot/share/runtime/sharedRuntime.cpp > description: > 8153107: enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs > Summary: Always set the markword for recursive monitors in > MacroAssembler::fast_lock(). > Reviewed-by: aph, drwhite, dcubed > > > I don't expect any problems, but I'm paranoid so... > > Dan > > > On 6/15/18 1:29 PM, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~apetushkov/8153107/ > > > > src/hotspot/share/runtime/sharedRuntime.cpp > > No comments. > > > > src/hotspot/cpu/arm/macroAssembler_arm.cpp > > Looks correct. Here's my analysis: > > > > The X64 version of this code does this: > > > > src/hotspot/cpu/x86/macroAssembler_x86.cpp: > > > > // Recursive locking. > > // The object is stack-locked: markword contains stack pointer > > to BasicLock. > > // Locked by current thread if difference with current SP is > > less than one page. > > subptr(tmpReg, rsp); > > // Next instruction set ZFlag == 1 (Success) if difference is > > less then one page. > > andptr(tmpReg, (int32_t) (NOT_LP64(0xFFFFF003) LP64_ONLY(7 - > > os::vm_page_size())) ); > > movptr(Address(boxReg, 0), tmpReg); > > if (counters != NULL) { > > cond_inc32(Assembler::equal, > > ExternalAddress((address)counters->fast_path_entry_count_addr())); > > } > > jmp(DONE_LABEL); > > > > This code path always updates "Address(boxReg, 0)" with the > > "tmpReg" value so the markword always gets updated with a zero > > or non-zero value. > > > > The previous AMD64 code did this: > > > > L3011: #ifdef AARCH64 > > L3012: intptr_t mask = ((intptr_t)3) - > > ((intptr_t)os::vm_page_size()); > > L3013: Assembler::LogicalImmediate imm(mask, false); > > L3014: mov(Rscratch, SP); > > L3015: sub(Rscratch, Rmark, Rscratch); > > L3016: ands(Rscratch, Rscratch, imm); > > L3017: b(done, ne); // exit with failure > > L3018: str(Rscratch, Address(Rbox, > > BasicLock::displaced_header_offset_in_bytes())); // set to zero > > L3019: b(done); > > L3020: > > L3021: #else > > L3022: // -1- test low 2 bits > > L3023: movs(Rscratch, AsmOperand(Rmark, lsl, 30)); > > L3024: // -2- test (hdr - SP) if the low two bits are 0 > > L3025: sub(Rscratch, Rmark, SP, eq); > > L3026: movs(Rscratch, AsmOperand(Rscratch, lsr, > > exact_log2(os::vm_page_size())), eq); > > L3027: // If still 'eq' then recursive locking OK > > L3028: str(Rscratch, Address(Rbox, > > BasicLock::displaced_header_offset_in_bytes()), eq); // set to zero > > L3029: b(done); > > L3030: #endif > > > > For the AARCH64 version, the key bug is the "b(done, ne); // exit > > with failure" > > which results in the markword not getting set to a specific value. > > Someone mentioned that we're getting a random value here and that > > contributes to the intermittent nature of the hang. Removing L3017 > > so that we always set the markword makes perfect sense. > > > > For the non-AARCH64 version, the key bug is a little more obscure > > (at least to me): "str(Rscratch, Address(Rbox, ...), eq); // set > > to zero". > > I don't really know ARM assembly, but I'm guessing that the 'eq' > > parameter > > controls whether the store of Rscratch into "Address(Rbox, ...)" > > occurs or > > not. Removing the "eq" parameter in the fix so that we always set the > > markword makes perfect sense. > > > > > > So thumbs up on the fix and I can sponsor it. Please provide me with an > > importable changeset and I'll take care of that after confirmation that > > the ARM folks have tested the fix and are happy with it. > > > > Dan > > > > > > On 6/14/18 6:08 PM, White, Derek wrote: > >> Hi Andrey, > >> > >> It took me looking at the code three times, but I finally saw what > >> you mean about condition code register. OK, looks fine to me. > >> > >> You still need a (R)eviewer?s OK and then a sponsor. > >> > >> > >> * Derek > >> > >> From: Andrey Petushkov [mailto:andrey.petushkov at gmail.com] > >> Sent: Thursday, June 14, 2018 4:55 PM > >> To: White, Derek > >> Cc: Andrew Haley ; > >> hotspot-runtime-dev at openjdk.java.net; > >> aarch64-port-dev at openjdk.java.net; AArch32 Port Project > >> > >> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > >> > >> > >> External Email > >> Hi Derek, > >> > >> that shall be ands since it expected to leave the result in the flags > >> register, see the cmpFastLock instruct in aarch64.ad > >> to my taste this version is error-prone, since it's quite hard to > >> deduce that contract FastLock node involves writing of non 0 value > >> into DHW of stack lock when it has failed. however I don't insist. so > >> if everyone agrees could someone please commit. sorry, I don't have > >> necessary status > >> > >> > >> Regards, > >> Andrey > >> > >> On Thu, Jun 14, 2018 at 9:13 PM White, Derek > >> > wrote: > >> Hi Andrey, > >> > >> I like this version. > >> > >> My only suggestion is minor - the "ands" at line 3016 could be a > >> simple "and". It causes no harm but could be confusing to a reader: > >> > >> 3016 ands(Rscratch, Rscratch, imm); > >> > >> No need to see a new webrev. > >> - Derek > >> > >>> -----Original Message----- > >>> From: hotspot-runtime-dev > >>> [mailto:hotspot-runtime-dev- > >>> bounces at openjdk.java.net] On Behalf > >>> Of Andrey Petushkov > >>> Sent: Thursday, June 14, 2018 8:25 AM > >>> To: Andrew Haley > > >>> Cc: > >>> hotspot-runtime-dev at openjdk.java.net hotspot-runtime-dev at openjdk.java.net>; > >>> aarch64-port- > >>> dev at openjdk.java.net; AArch32 Port > >>> Project >>> dev at openjdk.java.net> > >>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > >>> > >>> External Email > >>> > >>> Hm, strange. It displays well for me in the archives page. Anyway, > >>> I've put > >>> the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ > >>> > >>> On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley > >>> > wrote: > >>> > >>>> On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > >>>>> So then if you prefer to leave the different logic in shared code > >>>>> between quick and slow paths I believe the fix for cpu/arm > >>>>> implementation (and removal of unnecessary workaround for > >>> cpu/aarch64) should look like this: > >>>> Something awful happened to the formatting of your mail. Can you put > >>>> it up somewhere we can see the patch? > >>>> > >>>> -- > >>>> Andrew Haley > >>>> Java Platform Lead Engineer > >>>> Red Hat UK Ltd. > >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 > >>>> F A671 > >>>> > > > > > > From daniel.daugherty at oracle.com Sat Jun 16 20:08:49 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 16 Jun 2018 16:08:49 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> Message-ID: <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> Hi Andrey, I updated the bug report with the Mach5 results so the only thing I need now is confirmation that ARM testing went fine. So whenever you or aph or both have some ARM test results we should be good to go. In particular it would be good to verify that your test that reproduces this hang no longer reproduces the hang in some relatively high number of iterations. So if your test repros the hang in 5/100 runs, I would be happy if the hang didn't repro in a 1000 runs. Dan On 6/16/18 12:11 PM, Andrey Petushkov wrote: > Hi Dan, > > Thank you for sponsorship and yes, > > I don't really know ARM assembly, but I'm guessing that the 'eq' > > parameter > > ??? controls whether the store of Rscratch into "Address(Rbox, ...)" > > occurs or > > ??? not > You guess is perfectly correct! > > Thanks again, > Andrey > > > On Fri, Jun 15, 2018 at 9:00 PM Daniel D. Daugherty > > wrote: > > Andrey, > > I'm about to send the following changeset thru Mach5 testing: > > $ hg log -v -r tip > changeset:?? 50592:dc9e3b56c8ab > tag:???????? tip > user:??????? apetushkov > date:??????? Fri Jun 15 13:57:32 2018 -0400 > files:?????? src/hotspot/cpu/arm/macroAssembler_arm.cpp > src/hotspot/share/runtime/sharedRuntime.cpp > description: > 8153107: enabling ObjectSynchronizer::quick_enter() on ARM64 > causes hangs > Summary: Always set the markword for recursive monitors in > MacroAssembler::fast_lock(). > Reviewed-by: aph, drwhite, dcubed > > > I don't expect any problems, but I'm paranoid so... > > Dan > > > On 6/15/18 1:29 PM, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~apetushkov/8153107/ > > > > > src/hotspot/share/runtime/sharedRuntime.cpp > > ??? No comments. > > > > src/hotspot/cpu/arm/macroAssembler_arm.cpp > > ??? Looks correct. Here's my analysis: > > > > ??? The X64 version of this code does this: > > > > ??? src/hotspot/cpu/x86/macroAssembler_x86.cpp: > > > > ?? ?? // Recursive locking. > > ? ? ? // The object is stack-locked: markword contains stack > pointer > > to BasicLock. > > ? ? ? // Locked by current thread if difference with current SP is > > less than one page. > > ? ? ? subptr(tmpReg, rsp); > > ? ? ? // Next instruction set ZFlag == 1 (Success) if difference is > > less then one page. > > ? ? ? andptr(tmpReg, (int32_t) (NOT_LP64(0xFFFFF003) LP64_ONLY(7 - > > os::vm_page_size())) ); > > ? ? ? movptr(Address(boxReg, 0), tmpReg); > > ? ? ? if (counters != NULL) { > > ?? ???? cond_inc32(Assembler::equal, > > ExternalAddress((address)counters->fast_path_entry_count_addr())); > > ?? ?? } > > ?? ?? jmp(DONE_LABEL); > > > > ??? This code path always updates "Address(boxReg, 0)" with the > > ??? "tmpReg" value so the markword always gets updated with a zero > > ??? or non-zero value. > > > > ??? The previous AMD64 code did this: > > > > ????? L3011: #ifdef AARCH64 > > ????? L3012: ? intptr_t mask = ((intptr_t)3) - > > ((intptr_t)os::vm_page_size()); > > ????? L3013: ? Assembler::LogicalImmediate imm(mask, false); > > ????? L3014: ? mov(Rscratch, SP); > > ????? L3015: ? sub(Rscratch, Rmark, Rscratch); > > ????? L3016: ? ands(Rscratch, Rscratch, imm); > > ????? L3017: ? b(done, ne); // exit with failure > > ????? L3018: ? str(Rscratch, Address(Rbox, > > BasicLock::displaced_header_offset_in_bytes())); // set to zero > > ????? L3019: ? b(done); > > ????? L3020: > > ????? L3021: #else > > ????? L3022: ? // -1- test low 2 bits > > ????? L3023: ? movs(Rscratch, AsmOperand(Rmark, lsl, 30)); > > ????? L3024: ? // -2- test (hdr - SP) if the low two bits are 0 > > ????? L3025: ? sub(Rscratch, Rmark, SP, eq); > > ????? L3026: ? movs(Rscratch, AsmOperand(Rscratch, lsr, > > exact_log2(os::vm_page_size())), eq); > > ????? L3027: ? // If still 'eq' then recursive locking OK > > ????? L3028: ? str(Rscratch, Address(Rbox, > > BasicLock::displaced_header_offset_in_bytes()), eq); // set to zero > > ????? L3029: ? b(done); > > ????? L3030: #endif > > > > ??? For the AARCH64 version, the key bug is the "b(done, ne); // > exit > > with failure" > > ??? which results in the markword not getting set to a specific > value. > > ??? Someone mentioned that we're getting a random value here and > that > > ??? contributes to the intermittent nature of the hang. Removing > L3017 > > ??? so that we always set the markword makes perfect sense. > > > > ??? For the non-AARCH64 version, the key bug is a little more > obscure > > ??? (at least to me): "str(Rscratch, Address(Rbox, ...), eq); // > set > > to zero". > > ??? I don't really know ARM assembly, but I'm guessing that the > 'eq' > > parameter > > ??? controls whether the store of Rscratch into "Address(Rbox, > ...)" > > occurs or > > ??? not. Removing the "eq" parameter in the fix so that we > always set the > > ??? markword makes perfect sense. > > > > > > So thumbs up on the fix and I can sponsor it. Please provide me > with an > > importable changeset and I'll take care of that after > confirmation that > > the ARM folks have tested the fix and are happy with it. > > > > Dan > > > > > > On 6/14/18 6:08 PM, White, Derek wrote: > >> Hi Andrey, > >> > >> It took me looking at the code three times, but I finally saw what > >> you mean about condition code register. OK, looks fine to me. > >> > >> You still need a (R)eviewer?s OK and then a sponsor. > >> > >> > >> ?? *?? Derek > >> > >> From: Andrey Petushkov [mailto:andrey.petushkov at gmail.com > ] > >> Sent: Thursday, June 14, 2018 4:55 PM > >> To: White, Derek > > >> Cc: Andrew Haley >; > >> hotspot-runtime-dev at openjdk.java.net > ; > >> aarch64-port-dev at openjdk.java.net > ; AArch32 Port Project > >> > > >> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive > locking > >> > >> > >> External Email > >> Hi Derek, > >> > >> that shall be ands since it expected to leave the result in the > flags > >> register, see the cmpFastLock instruct in aarch64.ad > > >> to my taste this version is error-prone, since it's quite hard to > >> deduce that contract FastLock node involves writing of non 0 value > >> into DHW of stack lock when it has failed. however I don't > insist. so > >> if everyone agrees could someone please commit. sorry, I don't > have > >> necessary status > >> > >> > >> Regards, > >> Andrey > >> > >> On Thu, Jun 14, 2018 at 9:13 PM White, Derek > >> >> wrote: > >> Hi Andrey, > >> > >> I like this version. > >> > >> My only suggestion is minor - the "ands" at line 3016 could be a > >> simple "and". It causes no harm but could be confusing to a reader: > >> > >> 3016?? ands(Rscratch, Rscratch, imm); > >> > >> No need to see a new webrev. > >> - Derek > >> > >>> -----Original Message----- > >>> From: hotspot-runtime-dev > >>> [mailto:hotspot-runtime-dev- > > > >>> bounces at openjdk.java.net > >] On Behalf > >>> Of Andrey Petushkov > >>> Sent: Thursday, June 14, 2018 8:25 AM > >>> To: Andrew Haley >> > >>> Cc: > >>> hotspot-runtime-dev at openjdk.java.net > >; > >>> aarch64-port- > >>> dev at openjdk.java.net > >; AArch32 Port > >>> Project >>> dev at openjdk.java.net > >> > >>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive > locking > >>> > >>> External Email > >>> > >>> Hm, strange. It displays well for me in the archives page. > Anyway, > >>> I've put > >>> the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ > > >>> > >>> On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley > >>> >> wrote: > >>> > >>>> On 06/14/2018 12:59 PM, Andrey Petushkov wrote: > >>>>> So then if you prefer to leave the different logic in shared > code > >>>>> between quick and slow paths I believe the fix for cpu/arm > >>>>> implementation (and removal of unnecessary workaround for > >>> cpu/aarch64) should look like this: > >>>> Something awful happened to the formatting of your mail.? Can > you put > >>>> it up somewhere we can see the patch? > >>>> > >>>> -- > >>>> Andrew Haley > >>>> Java Platform Lead Engineer > >>>> Red Hat UK Ltd. > >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 > >>>> F A671 > >>>> > > > > > From andrey.petushkov at gmail.com Mon Jun 18 13:29:16 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Mon, 18 Jun 2018 16:29:16 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> Message-ID: <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> Hi Dan, The problem is that I?m not aware of any reproducer for any of the platforms part of main openjdk. Also Andrew Haley as well as Derek cannot help here I think since they are working with cpu/aarch64 port code, which did not have mentioned problem at all. Me myself is dealing with cpu/aarch32 port which is not part of main openjdk and jdk10 version of it is not yet even pushed into project-aarch32 openjdk repos. There is jdk9 version but there is no ready made reproducer there. The jdk10 version (on review now) has 100% reproducer for this problem, the runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test, however I?m not sure anyone wants to try that out. Maybe Ed Nevill could help as a more or less independent party. Ed? Thank you, Andrey > On 16 Jun 2018, at 23:08, Daniel D. Daugherty wrote: > > Hi Andrey, > > I updated the bug report with the Mach5 results so the only thing I need > now is confirmation that ARM testing went fine. So whenever you or aph > or both have some ARM test results we should be good to go. > > In particular it would be good to verify that your test that reproduces > this hang no longer reproduces the hang in some relatively high number > of iterations. So if your test repros the hang in 5/100 runs, I would > be happy if the hang didn't repro in a 1000 runs. > > Dan > > > On 6/16/18 12:11 PM, Andrey Petushkov wrote: >> Hi Dan, >> >> Thank you for sponsorship and yes, >> > I don't really know ARM assembly, but I'm guessing that the 'eq' >> > parameter >> > controls whether the store of Rscratch into "Address(Rbox, ...)" >> > occurs or >> > not >> You guess is perfectly correct! >> >> Thanks again, >> Andrey >> >> >> On Fri, Jun 15, 2018 at 9:00 PM Daniel D. Daugherty > wrote: >> Andrey, >> >> I'm about to send the following changeset thru Mach5 testing: >> >> $ hg log -v -r tip >> changeset: 50592:dc9e3b56c8ab >> tag: tip >> user: apetushkov >> date: Fri Jun 15 13:57:32 2018 -0400 >> files: src/hotspot/cpu/arm/macroAssembler_arm.cpp >> src/hotspot/share/runtime/sharedRuntime.cpp >> description: >> 8153107: enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs >> Summary: Always set the markword for recursive monitors in >> MacroAssembler::fast_lock(). >> Reviewed-by: aph, drwhite, dcubed >> >> >> I don't expect any problems, but I'm paranoid so... >> >> Dan >> >> >> On 6/15/18 1:29 PM, Daniel D. Daugherty wrote: >> > > http://cr.openjdk.java.net/~apetushkov/8153107/ >> > >> > src/hotspot/share/runtime/sharedRuntime.cpp >> > No comments. >> > >> > src/hotspot/cpu/arm/macroAssembler_arm.cpp >> > Looks correct. Here's my analysis: >> > >> > The X64 version of this code does this: >> > >> > src/hotspot/cpu/x86/macroAssembler_x86.cpp: >> > >> > // Recursive locking. >> > // The object is stack-locked: markword contains stack pointer >> > to BasicLock. >> > // Locked by current thread if difference with current SP is >> > less than one page. >> > subptr(tmpReg, rsp); >> > // Next instruction set ZFlag == 1 (Success) if difference is >> > less then one page. >> > andptr(tmpReg, (int32_t) (NOT_LP64(0xFFFFF003) LP64_ONLY(7 - >> > os::vm_page_size())) ); >> > movptr(Address(boxReg, 0), tmpReg); >> > if (counters != NULL) { >> > cond_inc32(Assembler::equal, >> > ExternalAddress((address)counters->fast_path_entry_count_addr())); >> > } >> > jmp(DONE_LABEL); >> > >> > This code path always updates "Address(boxReg, 0)" with the >> > "tmpReg" value so the markword always gets updated with a zero >> > or non-zero value. >> > >> > The previous AMD64 code did this: >> > >> > L3011: #ifdef AARCH64 >> > L3012: intptr_t mask = ((intptr_t)3) - >> > ((intptr_t)os::vm_page_size()); >> > L3013: Assembler::LogicalImmediate imm(mask, false); >> > L3014: mov(Rscratch, SP); >> > L3015: sub(Rscratch, Rmark, Rscratch); >> > L3016: ands(Rscratch, Rscratch, imm); >> > L3017: b(done, ne); // exit with failure >> > L3018: str(Rscratch, Address(Rbox, >> > BasicLock::displaced_header_offset_in_bytes())); // set to zero >> > L3019: b(done); >> > L3020: >> > L3021: #else >> > L3022: // -1- test low 2 bits >> > L3023: movs(Rscratch, AsmOperand(Rmark, lsl, 30)); >> > L3024: // -2- test (hdr - SP) if the low two bits are 0 >> > L3025: sub(Rscratch, Rmark, SP, eq); >> > L3026: movs(Rscratch, AsmOperand(Rscratch, lsr, >> > exact_log2(os::vm_page_size())), eq); >> > L3027: // If still 'eq' then recursive locking OK >> > L3028: str(Rscratch, Address(Rbox, >> > BasicLock::displaced_header_offset_in_bytes()), eq); // set to zero >> > L3029: b(done); >> > L3030: #endif >> > >> > For the AARCH64 version, the key bug is the "b(done, ne); // exit >> > with failure" >> > which results in the markword not getting set to a specific value. >> > Someone mentioned that we're getting a random value here and that >> > contributes to the intermittent nature of the hang. Removing L3017 >> > so that we always set the markword makes perfect sense. >> > >> > For the non-AARCH64 version, the key bug is a little more obscure >> > (at least to me): "str(Rscratch, Address(Rbox, ...), eq); // set >> > to zero". >> > I don't really know ARM assembly, but I'm guessing that the 'eq' >> > parameter >> > controls whether the store of Rscratch into "Address(Rbox, ...)" >> > occurs or >> > not. Removing the "eq" parameter in the fix so that we always set the >> > markword makes perfect sense. >> > >> > >> > So thumbs up on the fix and I can sponsor it. Please provide me with an >> > importable changeset and I'll take care of that after confirmation that >> > the ARM folks have tested the fix and are happy with it. >> > >> > Dan >> > >> > >> > On 6/14/18 6:08 PM, White, Derek wrote: >> >> Hi Andrey, >> >> >> >> It took me looking at the code three times, but I finally saw what >> >> you mean about condition code register. OK, looks fine to me. >> >> >> >> You still need a (R)eviewer?s OK and then a sponsor. >> >> >> >> >> >> * Derek >> >> >> >> From: Andrey Petushkov [mailto:andrey.petushkov at gmail.com ] >> >> Sent: Thursday, June 14, 2018 4:55 PM >> >> To: White, Derek > >> >> Cc: Andrew Haley >; >> >> hotspot-runtime-dev at openjdk.java.net ; >> >> aarch64-port-dev at openjdk.java.net ; AArch32 Port Project >> >> > >> >> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >> >> >> >> >> >> External Email >> >> Hi Derek, >> >> >> >> that shall be ands since it expected to leave the result in the flags >> >> register, see the cmpFastLock instruct in aarch64.ad > >> >> to my taste this version is error-prone, since it's quite hard to >> >> deduce that contract FastLock node involves writing of non 0 value >> >> into DHW of stack lock when it has failed. however I don't insist. so >> >> if everyone agrees could someone please commit. sorry, I don't have >> >> necessary status >> >> >> >> >> >> Regards, >> >> Andrey >> >> >> >> On Thu, Jun 14, 2018 at 9:13 PM White, Derek >> >> >> wrote: >> >> Hi Andrey, >> >> >> >> I like this version. >> >> >> >> My only suggestion is minor - the "ands" at line 3016 could be a >> >> simple "and". It causes no harm but could be confusing to a reader: >> >> >> >> 3016 ands(Rscratch, Rscratch, imm); >> >> >> >> No need to see a new webrev. >> >> - Derek >> >> >> >>> -----Original Message----- >> >>> From: hotspot-runtime-dev >> >>> [mailto:hotspot-runtime-dev- > >> >>> bounces at openjdk.java.net >] On Behalf >> >>> Of Andrey Petushkov >> >>> Sent: Thursday, June 14, 2018 8:25 AM >> >>> To: Andrew Haley >> >> >>> Cc: >> >>> hotspot-runtime-dev at openjdk.java.net >; >> >>> aarch64-port- >> >>> dev at openjdk.java.net >; AArch32 Port >> >>> Project > >>> dev at openjdk.java.net >> >> >>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >> >>> >> >>> External Email >> >>> >> >>> Hm, strange. It displays well for me in the archives page. Anyway, >> >>> I've put >> >>> the webrev at http://cr.openjdk.java.net/~apetushkov/8153107/ >> >>> >> >>> On Thu, Jun 14, 2018 at 3:15 PM Andrew Haley >> >>> >> wrote: >> >>> >> >>>> On 06/14/2018 12:59 PM, Andrey Petushkov wrote: >> >>>>> So then if you prefer to leave the different logic in shared code >> >>>>> between quick and slow paths I believe the fix for cpu/arm >> >>>>> implementation (and removal of unnecessary workaround for >> >>> cpu/aarch64) should look like this: >> >>>> Something awful happened to the formatting of your mail. Can you put >> >>>> it up somewhere we can see the patch? >> >>>> >> >>>> -- >> >>>> Andrew Haley >> >>>> Java Platform Lead Engineer >> >>>> Red Hat UK Ltd. > >> >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332 >> >>>> >F A671 >> >>>> >> > >> > >> > From aph at redhat.com Mon Jun 18 13:39:14 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 14:39:14 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> Message-ID: On 06/18/2018 02:29 PM, Andrey Petushkov wrote: > The problem is that I?m not aware of any reproducer for any of the platforms part of main openjdk. > Also Andrew Haley as well as Derek cannot help here I think since they are working with cpu/aarch64 port code, which did not have mentioned problem at all. > Me myself is dealing with cpu/aarch32 port which is not part of main openjdk and jdk10 version of it is not yet even pushed into project-aarch32 openjdk repos. There is jdk9 version but there is no ready made reproducer there. The jdk10 version (on review now) has 100% reproducer for this problem, the runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test, however I?m not sure anyone wants to try that out. Maybe Ed Nevill could help as a more or less independent party. Where is the problem? We're asking you to test it on AArch32. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey.petushkov at gmail.com Mon Jun 18 13:43:21 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Mon, 18 Jun 2018 16:43:21 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> Message-ID: <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> > On 18 Jun 2018, at 16:39, Andrew Haley wrote: > > On 06/18/2018 02:29 PM, Andrey Petushkov wrote: >> The problem is that I?m not aware of any reproducer for any of the platforms part of main openjdk. >> Also Andrew Haley as well as Derek cannot help here I think since they are working with cpu/aarch64 port code, which did not have mentioned problem at all. >> Me myself is dealing with cpu/aarch32 port which is not part of main openjdk and jdk10 version of it is not yet even pushed into project-aarch32 openjdk repos. There is jdk9 version but there is no ready made reproducer there. The jdk10 version (on review now) has 100% reproducer for this problem, the runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test, however I?m not sure anyone wants to try that out. Maybe Ed Nevill could help as a more or less independent party. > > Where is the problem? We're asking you to test it on AArch32. Please elaborate what meaning you put into ?AArch32? term here - The patch under review deals with cpu/arm implementation. I do not have a reproducer for binaries created from this code - I do have a reproducer for the cpu/aarch32 and I?ve tested extremely similar patch numerous times. Does it count as a means of verification of patch under review? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Jun 18 13:47:25 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 14:47:25 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> Message-ID: <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> On 06/18/2018 02:43 PM, Andrey Petushkov wrote: > >> On 18 Jun 2018, at 16:39, Andrew Haley wrote: >> >> On 06/18/2018 02:29 PM, Andrey Petushkov wrote: >>> The problem is that I?m not aware of any reproducer for any of the platforms part of main openjdk. >>> Also Andrew Haley as well as Derek cannot help here I think since they are working with cpu/aarch64 port code, which did not have mentioned problem at all. >>> Me myself is dealing with cpu/aarch32 port which is not part of main openjdk and jdk10 version of it is not yet even pushed into project-aarch32 openjdk repos. There is jdk9 version but there is no ready made reproducer there. The jdk10 version (on review now) has 100% reproducer for this problem, the runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test, however I?m not sure anyone wants to try that out. Maybe Ed Nevill could help as a more or less independent party. >> >> Where is the problem? We're asking you to test it on AArch32. > Please elaborate what meaning you put into ?AArch32? term here > > - The patch under review deals with cpu/arm implementation. I do not have a reproducer for binaries created from this code > - I do have a reproducer for the cpu/aarch32 and I?ve tested extremely similar patch numerous times. Does it count as a means of verification of patch under review? Ah, my mistake. This patch also affects AArch64. So, I take it that your problem is that you don't have AArch64 systems to run the test on? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey.petushkov at gmail.com Mon Jun 18 14:09:47 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Mon, 18 Jun 2018 17:09:47 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <7e38405b-6fc8-2cf7-4833-bed302810d64@redhat.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> Message-ID: <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> I can, but that would only be check for regression, not the fix itself > On 18 Jun 2018, at 16:47, Andrew Haley wrote: > > On 06/18/2018 02:43 PM, Andrey Petushkov wrote: >> >>> On 18 Jun 2018, at 16:39, Andrew Haley wrote: >>> >>> On 06/18/2018 02:29 PM, Andrey Petushkov wrote: >>>> The problem is that I?m not aware of any reproducer for any of the platforms part of main openjdk. >>>> Also Andrew Haley as well as Derek cannot help here I think since they are working with cpu/aarch64 port code, which did not have mentioned problem at all. >>>> Me myself is dealing with cpu/aarch32 port which is not part of main openjdk and jdk10 version of it is not yet even pushed into project-aarch32 openjdk repos. There is jdk9 version but there is no ready made reproducer there. The jdk10 version (on review now) has 100% reproducer for this problem, the runtime/CreateMirror/ArraysNewInstanceBug.java hotspot jtreg test, however I?m not sure anyone wants to try that out. Maybe Ed Nevill could help as a more or less independent party. >>> >>> Where is the problem? We're asking you to test it on AArch32. >> Please elaborate what meaning you put into ?AArch32? term here >> >> - The patch under review deals with cpu/arm implementation. I do not have a reproducer for binaries created from this code >> - I do have a reproducer for the cpu/aarch32 and I?ve tested extremely similar patch numerous times. Does it count as a means of verification of patch under review? > > Ah, my mistake. This patch also affects AArch64. So, I take it that > your problem is that you don't have AArch64 systems to run the test on? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Jun 18 15:46:43 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 16:46:43 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> Message-ID: <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> On 06/18/2018 03:09 PM, Andrey Petushkov wrote: > I can, but that would only be check for regression, not the fix itself I do not understand. Do you mean that out have no reproducer at all? Not even this one? http://cr.openjdk.java.net/~aph/RecursiveLocking.java -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey.petushkov at gmail.com Mon Jun 18 16:02:58 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Mon, 18 Jun 2018 19:02:58 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <6D1DFDB8-142D-4ABF-9196-F14308B8729A@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> Message-ID: > On 18 Jun 2018, at 18:46, Andrew Haley wrote: > > On 06/18/2018 03:09 PM, Andrey Petushkov wrote: >> I can, but that would only be check for regression, not the fix itself > > I do not understand. Do you mean that out have no reproducer > at all? Not even this one? > > http://cr.openjdk.java.net/~aph/RecursiveLocking.java This one does not work for me. In additional it?s quite hard to catch such problem using this code - it does not end any of the threads, hence you cannot rely on deadlock detection mechanism to find out whether any stale locks left. Apparently something should be quite well hand-crafted to put enough 0-s to the stack prior to creation of the stack lock there And as I said, I have a reproducer. It just happen that it only reproduces the problem on port-aarch32 implementation > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Jun 18 16:07:14 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Jun 2018 17:07:14 +0100 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <43c71dda-569e-42a3-51d0-cc0f3e6b45af@redhat.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> Message-ID: <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> On 06/18/2018 05:02 PM, Andrey Petushkov wrote: > And as I said, I have a reproducer. It just happen that it only reproduces the problem on port-aarch32 implementation Well, I'm sure that I can't reproduce the problem either, and I believe that the bug does not exist on AArch64. I'm happy for your patch to be committed. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniel.daugherty at oracle.com Mon Jun 18 18:34:21 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 18 Jun 2018 14:34:21 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> Message-ID: <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> Greetings, OK so I'm not going to get a "go" based on reproducible test results. I'm okay with that as long as I get a "go" from the other folks reviewing and discussing this change: Andrew Haley???? - go (as stated below) Andrey Petushkov - Dan Daugherty??? - go (since Oracle platform testing passed) Derek White????? - Of course, I could have listed Andrey as a go since he is the author of the fix, but I didn't want to assume... :-) Dan On 6/18/18 12:07 PM, Andrew Haley wrote: > On 06/18/2018 05:02 PM, Andrey Petushkov wrote: >> And as I said, I have a reproducer. It just happen that it only reproduces the problem on port-aarch32 implementation > Well, I'm sure that I can't reproduce the problem either, and > I believe that the bug does not exist on AArch64. I'm happy for > your patch to be committed. > From edward.nevill at gmail.com Mon Jun 18 19:42:10 2018 From: edward.nevill at gmail.com (Edward Nevill) Date: Mon, 18 Jun 2018 20:42:10 +0100 Subject: [RFR] jdk9.0.4+12 + functionality In-Reply-To: <773A480B-8AD9-41D1-ACC4-7F11E413C397@gmail.com> References: <83D551E9-1EBF-4F1E-A15D-C87E6FCCBFA9@gmail.com> <1523306527.16246.3.camel@gmail.com> <1523350531.2440.6.camel@gmail.com> <1523360339.2440.22.camel@gmail.com> <1C2B1668-E0BB-4A9D-B391-10E4E551D010@gmail.com> <040F8DA9-5367-4DF5-967B-584268D399AC@gmail.com> <1523389350.2440.39.camel@gmail.com> <68333229-613D-4D20-A8BC-BE0FF522E215@gmail.com> <1523448323.6342.16.camel@gmail.com> <56BCFB51-258E-4677-A136-937706761E82@gmail.com> <1523461579.6342.30.camel@gmail.com> <1523470275.6342.53.camel@gmail.com> <1527680723.2904.13.camel@gmail.com> <89D85279-6ED1-4126-AC2E-7DB32F26662F@gmail.com> <1527683902.2904.17.camel@gmail.com> <06847DB6-B8F7-4EC6-A19C-7B6D688EB1CB@gmail.com> <1527698512.2904.20.camel@gmail.com> <1D8BABDB-A232-4D10-9C9A-087D1F2FCCD0@gmail.com> <1528663699.2998.13.camel@gmail.com> <773A480B-8AD9-41D1-ACC4-7F11E413C397@gmail.com> Message-ID: <552e6df19566f655cd4f817b7559a5a50dccd53b.camel@gmail.com> Hi Andrey, I have updated and pushed your patches. I did the merge myself and then pushed your C2+additional functionality patch as I wanted to preserve the history which otherwise would have been lost. The aarch32 jdk9u tree is now at http://hg.openjdk.java.net/aarch32-port/jdk9u/ I also reran jcstress on your jdk10 patch. I am still seeing 1626 failures. I have uploaded the results to http://www.camswl.com/jcstress-results-2018-06-17-20-37-09.bin.gz All the best, Ed. On Wed, 2018-06-13 at 13:33 +0300, Andrey Petushkov wrote: > Thank you so much a try! > In fact there are two synchronization bugs found and fixed during > updating to Java 10. So could I ask you to check out the jdk10 webrev > I?ve sent last week. Hopefully some of the problems should go away. > Unfortunately I did not yet run jcstress myself, shame on me? > > The people participated are Fedor Burdun m> and myself, Andrey Petushkov > From Derek.White at cavium.com Mon Jun 18 19:53:44 2018 From: Derek.White at cavium.com (White, Derek) Date: Mon, 18 Jun 2018 19:53:44 +0000 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> Message-ID: Yes, It's a go for me on aarch64. - Derek > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty > Sent: Monday, June 18, 2018 2:34 PM > To: Andrew Haley ; Andrey Petushkov > > Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime- > dev at openjdk.java.net; AArch32 Port Project dev at openjdk.java.net> > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > > External Email > > Greetings, > > OK so I'm not going to get a "go" based on reproducible test results. > I'm okay with that as long as I get a "go" from the other folks reviewing and > discussing this change: > > Andrew Haley - go (as stated below) > Andrey Petushkov - > Dan Daugherty - go (since Oracle platform testing passed) > Derek White - > > Of course, I could have listed Andrey as a go since he is the author of the fix, > but I didn't want to assume... :-) > > Dan > > > On 6/18/18 12:07 PM, Andrew Haley wrote: > > On 06/18/2018 05:02 PM, Andrey Petushkov wrote: > >> And as I said, I have a reproducer. It just happen that it only > >> reproduces the problem on port-aarch32 implementation > > Well, I'm sure that I can't reproduce the problem either, and I > > believe that the bug does not exist on AArch64. I'm happy for your > > patch to be committed. > > From andrey.petushkov at gmail.com Mon Jun 18 20:04:09 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Mon, 18 Jun 2018 23:04:09 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> Message-ID: Sure, me too Thank you, Andrey On Mon, Jun 18, 2018, 22:53 White, Derek wrote: > Yes, It's a go for me on aarch64. > > - Derek > > > -----Original Message----- > > From: aarch64-port-dev [mailto:aarch64-port-dev- > > bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty > > Sent: Monday, June 18, 2018 2:34 PM > > To: Andrew Haley ; Andrey Petushkov > > > > Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime- > > dev at openjdk.java.net; AArch32 Port Project > dev at openjdk.java.net> > > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking > > > > External Email > > > > Greetings, > > > > OK so I'm not going to get a "go" based on reproducible test results. > > I'm okay with that as long as I get a "go" from the other folks > reviewing and > > discussing this change: > > > > Andrew Haley - go (as stated below) > > Andrey Petushkov - > > Dan Daugherty - go (since Oracle platform testing passed) > > Derek White - > > > > Of course, I could have listed Andrey as a go since he is the author of > the fix, > > but I didn't want to assume... :-) > > > > Dan > > > > > > On 6/18/18 12:07 PM, Andrew Haley wrote: > > > On 06/18/2018 05:02 PM, Andrey Petushkov wrote: > > >> And as I said, I have a reproducer. It just happen that it only > > >> reproduces the problem on port-aarch32 implementation > > > Well, I'm sure that I can't reproduce the problem either, and I > > > believe that the bug does not exist on AArch64. I'm happy for your > > > patch to be committed. > > > > > From daniel.daugherty at oracle.com Mon Jun 18 20:31:19 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 18 Jun 2018 16:31:19 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> Message-ID: Thanks Derek and Andrey! aleksei.voitylov at bell-sw.com sent me mail letting me know that boris.ulasevich at bell-sw.com is doing some testing on the change on ARM32 and will let me know the results tomorrow. Dan On 6/18/18 4:04 PM, Andrey Petushkov wrote: > Sure, me too > > Thank you, > Andrey > > On Mon, Jun 18, 2018, 22:53 White, Derek > wrote: > > Yes, It's a go for me on aarch64. > > ?- Derek > > > -----Original Message----- > > From: aarch64-port-dev [mailto:aarch64-port-dev- > > > bounces at openjdk.java.net ] On > Behalf Of Daniel D. Daugherty > > Sent: Monday, June 18, 2018 2:34 PM > > To: Andrew Haley >; > Andrey Petushkov > > > > > Cc: aarch64-port-dev at openjdk.java.net > ; hotspot-runtime- > > dev at openjdk.java.net ; AArch32 Port > Project > dev at openjdk.java.net > > > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive > locking > > > > External Email > > > > Greetings, > > > > OK so I'm not going to get a "go" based on reproducible test > results. > > I'm okay with that as long as I get a "go" from the other folks > reviewing and > > discussing this change: > > > > Andrew Haley? ? ?- go (as stated below) > > Andrey Petushkov - > > Dan Daugherty? ? - go (since Oracle platform testing passed) > > Derek White? ? ? - > > > > Of course, I could have listed Andrey as a go since he is the > author of the fix, > > but I didn't want to assume... :-) > > > > Dan > > > > > > On 6/18/18 12:07 PM, Andrew Haley wrote: > > > On 06/18/2018 05:02 PM, Andrey Petushkov wrote: > > >> And as I said, I have a reproducer. It just happen that it only > > >> reproduces the problem on port-aarch32 implementation > > > Well, I'm sure that I can't reproduce the problem either, and I > > > believe that the bug does not exist on AArch64. I'm happy for your > > > patch to be committed. > > > > From andrey.petushkov at gmail.com Tue Jun 19 10:26:48 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Tue, 19 Jun 2018 13:26:48 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> Message-ID: Ah, I see. Looks like Bell-sw is the only company besides Oracle which works with arm(32) port (at least in the open) so it make sense for them to make their testing Thanks for letting me know Regards, Andrey On Mon, Jun 18, 2018 at 11:31 PM Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > Thanks Derek and Andrey! > > aleksei.voitylov at bell-sw.com sent me mail letting me know that > boris.ulasevich at bell-sw.com is doing some testing on the change > on ARM32 and will let me know the results tomorrow. > > Dan > > > On 6/18/18 4:04 PM, Andrey Petushkov wrote: > > Sure, me too > > Thank you, > Andrey > > On Mon, Jun 18, 2018, 22:53 White, Derek wrote: > >> Yes, It's a go for me on aarch64. >> >> - Derek >> >> > -----Original Message----- >> > From: aarch64-port-dev [mailto:aarch64-port-dev- >> > bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty >> > Sent: Monday, June 18, 2018 2:34 PM >> > To: Andrew Haley ; Andrey Petushkov >> > >> > Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime- >> > dev at openjdk.java.net; AArch32 Port Project > > dev at openjdk.java.net> >> > Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >> > >> > External Email >> > >> > Greetings, >> > >> > OK so I'm not going to get a "go" based on reproducible test results. >> > I'm okay with that as long as I get a "go" from the other folks >> reviewing and >> > discussing this change: >> > >> > Andrew Haley - go (as stated below) >> > Andrey Petushkov - >> > Dan Daugherty - go (since Oracle platform testing passed) >> > Derek White - >> > >> > Of course, I could have listed Andrey as a go since he is the author of >> the fix, >> > but I didn't want to assume... :-) >> > >> > Dan >> > >> > >> > On 6/18/18 12:07 PM, Andrew Haley wrote: >> > > On 06/18/2018 05:02 PM, Andrey Petushkov wrote: >> > >> And as I said, I have a reproducer. It just happen that it only >> > >> reproduces the problem on port-aarch32 implementation >> > > Well, I'm sure that I can't reproduce the problem either, and I >> > > believe that the bug does not exist on AArch64. I'm happy for your >> > > patch to be committed. >> > > >> >> > From andrey.petushkov at gmail.com Tue Jun 19 16:18:32 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Tue, 19 Jun 2018 19:18:32 +0300 Subject: [RFR] jdk9.0.4+12 + functionality In-Reply-To: <552e6df19566f655cd4f817b7559a5a50dccd53b.camel@gmail.com> References: <83D551E9-1EBF-4F1E-A15D-C87E6FCCBFA9@gmail.com> <1523306527.16246.3.camel@gmail.com> <1523350531.2440.6.camel@gmail.com> <1523360339.2440.22.camel@gmail.com> <1C2B1668-E0BB-4A9D-B391-10E4E551D010@gmail.com> <040F8DA9-5367-4DF5-967B-584268D399AC@gmail.com> <1523389350.2440.39.camel@gmail.com> <68333229-613D-4D20-A8BC-BE0FF522E215@gmail.com> <1523448323.6342.16.camel@gmail.com> <56BCFB51-258E-4677-A136-937706761E82@gmail.com> <1523461579.6342.30.camel@gmail.com> <1523470275.6342.53.camel@gmail.com> <1527680723.2904.13.camel@gmail.com> <89D85279-6ED1-4126-AC2E-7DB32F26662F@gmail.com> <1527683902.2904.17.camel@gmail.com> <06847DB6-B8F7-4EC6-A19C-7B6D688EB1CB@gmail.com> <1527698512.2904.20.camel@gmail.com> <1D8BABDB-A232-4D10-9C9A-087D1F2FCCD0@gmail.com> <1528663699.2998.13.camel@gmail.com> <773A480B-8AD9-41D1-ACC4-7F11E413C397@gmail.com> <552e6df19566f655cd4f817b7559a5a50dccd53b.camel@gmail.com> Message-ID: <8E99D04E-FC79-478C-9E71-904010F43BD5@gmail.com> Hi Ed, > On 18 Jun 2018, at 22:42, Edward Nevill wrote: > > Hi Andrey, > > I have updated and pushed your patches. I did the merge myself and then > pushed your C2+additional functionality patch as I wanted to preserve > the history which otherwise would have been lost. > > The aarch32 jdk9u tree is now at > > http://hg.openjdk.java.net/aarch32-port/jdk9u/ Thank you so much! > > I also reran jcstress on your jdk10 patch. I am still seeing 1626 > failures. > > I have uploaded the results to > > http://www.camswl.com/jcstress-results-2018-06-17-20-37-09.bin.gz Looking at that. Do you plan to create repos for jdk10 or want me to address stress test results first? Thanks, Andrey > > All the best, > Ed. > > On Wed, 2018-06-13 at 13:33 +0300, Andrey Petushkov wrote: >> Thank you so much a try! >> In fact there are two synchronization bugs found and fixed during >> updating to Java 10. So could I ask you to check out the jdk10 webrev >> I?ve sent last week. Hopefully some of the problems should go away. >> Unfortunately I did not yet run jcstress myself, shame on me? >> >> The people participated are Fedor Burdun > m> and myself, Andrey Petushkov >> From boris.ulasevich at bell-sw.com Tue Jun 19 17:30:45 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Tue, 19 Jun 2018 20:30:45 +0300 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <2e06490f-d61d-c156-acc4-547094b8525f@oracle.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> Message-ID: <0e9fb859-6561-9e5d-44fd-306ac528f6b6@bell-sw.com> Hi all, I ran the test in different modes (single/multiple run, debug/release, Xcomp/mixed), but I can NOT reproduce the issue with current ARM32 jdk-jdk trunk. The test works Ok, as well as other jtreg runtime tests I have run today - both with and without the change. The change itself looks reasonable. Andrey, I think you can commit it, and I will take care of the issue if something will go wrong. best regards, Boris On 19.06.2018 13:26, Andrey Petushkov wrote: > Ah, I see. Looks like Bell-sw is the only company besides Oracle which > works with arm(32) port (at least in the open) so it make sense for them to > make their testing > > Thanks for letting me know > > Regards, > Andrey > > On Mon, Jun 18, 2018 at 11:31 PM Daniel D. Daugherty < > daniel.daugherty at oracle.com> wrote: > >> Thanks Derek and Andrey! >> >> aleksei.voitylov at bell-sw.com sent me mail letting me know that >> boris.ulasevich at bell-sw.com is doing some testing on the change >> on ARM32 and will let me know the results tomorrow. >> >> Dan >> >> >> On 6/18/18 4:04 PM, Andrey Petushkov wrote: >> >> Sure, me too >> >> Thank you, >> Andrey >> >> On Mon, Jun 18, 2018, 22:53 White, Derek wrote: >> >>> Yes, It's a go for me on aarch64. >>> >>> - Derek >>> >>>> -----Original Message----- >>>> From: aarch64-port-dev [mailto:aarch64-port-dev- >>>> bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty >>>> Sent: Monday, June 18, 2018 2:34 PM >>>> To: Andrew Haley ; Andrey Petushkov >>>> >>>> Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime- >>>> dev at openjdk.java.net; AArch32 Port Project >>> dev at openjdk.java.net> >>>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive locking >>>> >>>> External Email >>>> >>>> Greetings, >>>> >>>> OK so I'm not going to get a "go" based on reproducible test results. >>>> I'm okay with that as long as I get a "go" from the other folks >>> reviewing and >>>> discussing this change: >>>> >>>> Andrew Haley - go (as stated below) >>>> Andrey Petushkov - >>>> Dan Daugherty - go (since Oracle platform testing passed) >>>> Derek White - >>>> >>>> Of course, I could have listed Andrey as a go since he is the author of >>> the fix, >>>> but I didn't want to assume... :-) >>>> >>>> Dan >>>> >>>> >>>> On 6/18/18 12:07 PM, Andrew Haley wrote: >>>>> On 06/18/2018 05:02 PM, Andrey Petushkov wrote: >>>>>> And as I said, I have a reproducer. It just happen that it only >>>>>> reproduces the problem on port-aarch32 implementation >>>>> Well, I'm sure that I can't reproduce the problem either, and I >>>>> believe that the bug does not exist on AArch64. I'm happy for your >>>>> patch to be committed. >>>>> >>> >>> >> From daniel.daugherty at oracle.com Tue Jun 19 17:32:43 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Jun 2018 13:32:43 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: <0e9fb859-6561-9e5d-44fd-306ac528f6b6@bell-sw.com> References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <46427c09-66b4-846f-4d5b-8ac29b2ab573@oracle.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> <0e9fb859-6561-9e5d-44fd-306ac528f6b6@bell-sw.com> Message-ID: Boris, Thanks for the testing and, based on what you wrote below, I will add you as a reviewer. I'll take care of pushing the fix shortly. Dan On 6/19/18 1:30 PM, Boris Ulasevich wrote: > Hi all, > > ? I ran the test in different modes (single/multiple run, > debug/release, Xcomp/mixed), but I can NOT reproduce the issue with > current ARM32 jdk-jdk trunk. The test works Ok, as well as other jtreg > runtime tests I have run today - both with and without the change. > > ? The change itself looks reasonable. Andrey, I think you can commit > it, and I will take care of the issue if something will go wrong. > > best regards, > Boris > > > On 19.06.2018 13:26, Andrey Petushkov wrote: >> Ah, I see. Looks like Bell-sw is the only company besides Oracle which >> works with arm(32) port (at least in the open) so it make sense for >> them to >> make their testing >> >> Thanks for letting me know >> >> Regards, >> Andrey >> >> On Mon, Jun 18, 2018 at 11:31 PM Daniel D. Daugherty < >> daniel.daugherty at oracle.com> wrote: >> >>> Thanks Derek and Andrey! >>> >>> aleksei.voitylov at bell-sw.com sent me mail letting me know that >>> boris.ulasevich at bell-sw.com is doing some testing on the change >>> on ARM32 and will let me know the results tomorrow. >>> >>> Dan >>> >>> >>> On 6/18/18 4:04 PM, Andrey Petushkov wrote: >>> >>> Sure,? me too >>> >>> Thank you, >>> Andrey >>> >>> On Mon, Jun 18, 2018, 22:53 White, Derek >>> wrote: >>> >>>> Yes, It's a go for me on aarch64. >>>> >>>> ? - Derek >>>> >>>>> -----Original Message----- >>>>> From: aarch64-port-dev [mailto:aarch64-port-dev- >>>>> bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty >>>>> Sent: Monday, June 18, 2018 2:34 PM >>>>> To: Andrew Haley ; Andrey Petushkov >>>>> >>>>> Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime- >>>>> dev at openjdk.java.net; AArch32 Port Project >>>> dev at openjdk.java.net> >>>>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive >>>>> locking >>>>> >>>>> External Email >>>>> >>>>> Greetings, >>>>> >>>>> OK so I'm not going to get a "go" based on reproducible test results. >>>>> I'm okay with that as long as I get a "go" from the other folks >>>> reviewing and >>>>> discussing this change: >>>>> >>>>> Andrew Haley???? - go (as stated below) >>>>> Andrey Petushkov - >>>>> Dan Daugherty??? - go (since Oracle platform testing passed) >>>>> Derek White????? - >>>>> >>>>> Of course, I could have listed Andrey as a go since he is the >>>>> author of >>>> the fix, >>>>> but I didn't want to assume... :-) >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 6/18/18 12:07 PM, Andrew Haley wrote: >>>>>> On 06/18/2018 05:02 PM, Andrey Petushkov wrote: >>>>>>> And as I said, I have a reproducer. It just happen that it only >>>>>>> reproduces the problem on port-aarch32 implementation >>>>>> Well, I'm sure that I can't reproduce the problem either, and I >>>>>> believe that the bug does not exist on AArch64.? I'm happy for your >>>>>> patch to be committed. >>>>>> >>>> >>>> >>> From daniel.daugherty at oracle.com Tue Jun 19 17:42:08 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Jun 2018 13:42:08 -0400 Subject: [aarch64-port-dev ] 8153107: Unbalanced recursive locking In-Reply-To: References: <28A7EF6C-A1F0-4992-8399-71F65CAC5B5B@gmail.com> <277d0732-dbab-8042-64f9-699d621f3794@oracle.com> <6E20ECAE-EB86-4209-8AA1-1BC95B0BA783@gmail.com> <4B0666C2-AE03-4845-93A3-A1E0B92A8244@gmail.com> <69e92b6b-a286-1388-8fbf-bcf2df814d0b@redhat.com> <84D98DC1-183F-4096-A13E-1964819878D9@gmail.com> <2ace5083-76c1-5b44-a98f-290e9c3a1e78@redhat.com> <2c788187-0171-d6f9-dd64-604312ba3bb4@redhat.com> <684a035e-ff5c-73d4-84ea-b8acce764ccc@oracle.com> <0e9fb859-6561-9e5d-44fd-306ac528f6b6@bell-sw.com> Message-ID: Pushed the following changeset: $ hg log -v -r tip changeset:?? 50666:3e66d204af9b tag:???????? tip user:??????? apetushkov date:??????? Fri Jun 15 13:57:32 2018 -0400 files:?????? src/hotspot/cpu/arm/macroAssembler_arm.cpp src/hotspot/share/runtime/sharedRuntime.cpp description: 8153107: enabling ObjectSynchronizer::quick_enter() on ARM64 causes hangs Summary: Always set the markword for recursive monitors in MacroAssembler::fast_lock(). Reviewed-by: aph, drwhite, dcubed, bulasevich Andrey, thanks for fixing this (longstanding) bug! Dan On 6/19/18 1:32 PM, Daniel D. Daugherty wrote: > Boris, > > Thanks for the testing and, based on what you wrote below, I will add > you as a reviewer. > > I'll take care of pushing the fix shortly. > > Dan > > > On 6/19/18 1:30 PM, Boris Ulasevich wrote: >> Hi all, >> >> ? I ran the test in different modes (single/multiple run, >> debug/release, Xcomp/mixed), but I can NOT reproduce the issue with >> current ARM32 jdk-jdk trunk. The test works Ok, as well as other >> jtreg runtime tests I have run today - both with and without the change. >> >> ? The change itself looks reasonable. Andrey, I think you can commit >> it, and I will take care of the issue if something will go wrong. >> >> best regards, >> Boris >> >> >> On 19.06.2018 13:26, Andrey Petushkov wrote: >>> Ah, I see. Looks like Bell-sw is the only company besides Oracle which >>> works with arm(32) port (at least in the open) so it make sense for >>> them to >>> make their testing >>> >>> Thanks for letting me know >>> >>> Regards, >>> Andrey >>> >>> On Mon, Jun 18, 2018 at 11:31 PM Daniel D. Daugherty < >>> daniel.daugherty at oracle.com> wrote: >>> >>>> Thanks Derek and Andrey! >>>> >>>> aleksei.voitylov at bell-sw.com sent me mail letting me know that >>>> boris.ulasevich at bell-sw.com is doing some testing on the change >>>> on ARM32 and will let me know the results tomorrow. >>>> >>>> Dan >>>> >>>> >>>> On 6/18/18 4:04 PM, Andrey Petushkov wrote: >>>> >>>> Sure,? me too >>>> >>>> Thank you, >>>> Andrey >>>> >>>> On Mon, Jun 18, 2018, 22:53 White, Derek >>>> wrote: >>>> >>>>> Yes, It's a go for me on aarch64. >>>>> >>>>> ? - Derek >>>>> >>>>>> -----Original Message----- >>>>>> From: aarch64-port-dev [mailto:aarch64-port-dev- >>>>>> bounces at openjdk.java.net] On Behalf Of Daniel D. Daugherty >>>>>> Sent: Monday, June 18, 2018 2:34 PM >>>>>> To: Andrew Haley ; Andrey Petushkov >>>>>> >>>>>> Cc: aarch64-port-dev at openjdk.java.net; hotspot-runtime- >>>>>> dev at openjdk.java.net; AArch32 Port Project >>>>> dev at openjdk.java.net> >>>>>> Subject: Re: [aarch64-port-dev ] 8153107: Unbalanced recursive >>>>>> locking >>>>>> >>>>>> External Email >>>>>> >>>>>> Greetings, >>>>>> >>>>>> OK so I'm not going to get a "go" based on reproducible test >>>>>> results. >>>>>> I'm okay with that as long as I get a "go" from the other folks >>>>> reviewing and >>>>>> discussing this change: >>>>>> >>>>>> Andrew Haley???? - go (as stated below) >>>>>> Andrey Petushkov - >>>>>> Dan Daugherty??? - go (since Oracle platform testing passed) >>>>>> Derek White????? - >>>>>> >>>>>> Of course, I could have listed Andrey as a go since he is the >>>>>> author of >>>>> the fix, >>>>>> but I didn't want to assume... :-) >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 6/18/18 12:07 PM, Andrew Haley wrote: >>>>>>> On 06/18/2018 05:02 PM, Andrey Petushkov wrote: >>>>>>>> And as I said, I have a reproducer. It just happen that it only >>>>>>>> reproduces the problem on port-aarch32 implementation >>>>>>> Well, I'm sure that I can't reproduce the problem either, and I >>>>>>> believe that the bug does not exist on AArch64.? I'm happy for your >>>>>>> patch to be committed. >>>>>>> >>>>> >>>>> >>>> > > From andrey.petushkov at gmail.com Wed Jun 20 14:58:54 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Wed, 20 Jun 2018 17:58:54 +0300 Subject: [RFR] jdk9.0.4+12 + functionality In-Reply-To: <8E99D04E-FC79-478C-9E71-904010F43BD5@gmail.com> References: <83D551E9-1EBF-4F1E-A15D-C87E6FCCBFA9@gmail.com> <1523306527.16246.3.camel@gmail.com> <1523350531.2440.6.camel@gmail.com> <1523360339.2440.22.camel@gmail.com> <1C2B1668-E0BB-4A9D-B391-10E4E551D010@gmail.com> <040F8DA9-5367-4DF5-967B-584268D399AC@gmail.com> <1523389350.2440.39.camel@gmail.com> <68333229-613D-4D20-A8BC-BE0FF522E215@gmail.com> <1523448323.6342.16.camel@gmail.com> <56BCFB51-258E-4677-A136-937706761E82@gmail.com> <1523461579.6342.30.camel@gmail.com> <1523470275.6342.53.camel@gmail.com> <1527680723.2904.13.camel@gmail.com> <89D85279-6ED1-4126-AC2E-7DB32F26662F@gmail.com> <1527683902.2904.17.camel@gmail.com> <06847DB6-B8F7-4EC6-A19C-7B6D688EB1CB@gmail.com> <1527698512.2904.20.camel@gmail.com> <1D8BABDB-A232-4D10-9C9A-087D1F2FCCD0@gmail.com> <1528663699.2998.13.camel@gmail.com> <773A480B-8AD9-41D1-ACC4-7F11E413C397@gmail.com> <552e6df19566f655cd4f817b7559a5a50dccd53b.camel@gmail.com> <8E99D04E-FC79-478C-9E71-904010F43BD5@gmail.com> Message-ID: <55EF727B-F8DE-4D17-BEBA-A0F68A6A8BA7@gmail.com> Dear Ed, In fact it looks like vast majority of the tests has failed because they do consider entities of the (non-volatile) long and double types as atomic, while JLS specifically provisions they are not! (and aarch32 port does not make any attempt to implement atomicity for non-volatile 64-bit data types). Tests do not have the necessary checks for partially observed results of long/double writes and hence fail. I?ve checked a few - the failed results all correspond to the case when only low or only high part of 64-bit of newly written value is observed, while the other part remains default (0) There are indeed 2 real problems. The tests: - o.o.j.t.coherence.varHandles.arrays.opaque.ByteTest and o.o.j.t.coherence.varHandles.fields.opaque.*Test have failed as if memory access coherence is really broken. will investigate - o.o.j.t.acqrel.varHandles.byteArray.little.acqrel.ShortStringTest, o.o.j.t.acqrel.varHandles.byteArray.little.plain.IntBooleanTest have crashed the VM. I see that crash dump header mentions use G1 GC there. this might be the reason, we really have never tested it well (although regressions tests have passed successfully) and never have a customer who make benefit from using it. So it might be that support is indeed broken - o.o.j.t.memeffects.basic.atomicupdaters.AtomicLongFieldUpdater.atomic_addAndGet_set_char fails in strange way, might be caused by crash of the VM on the previous test (at least similar to what typically happens in such case) I?ll try to reproduce the above failures and dig into. At the moment my own jcstress run is still in the middle of somewhere, although been running for 2 days.. Regards, Andrey > On 19 Jun 2018, at 19:18, Andrey Petushkov wrote: > > Hi Ed, > >> On 18 Jun 2018, at 22:42, Edward Nevill > wrote: >> >> Hi Andrey, >> >> I have updated and pushed your patches. I did the merge myself and then >> pushed your C2+additional functionality patch as I wanted to preserve >> the history which otherwise would have been lost. >> >> The aarch32 jdk9u tree is now at >> >> http://hg.openjdk.java.net/aarch32-port/jdk9u/ > Thank you so much! >> >> I also reran jcstress on your jdk10 patch. I am still seeing 1626 >> failures. >> >> I have uploaded the results to >> >> http://www.camswl.com/jcstress-results-2018-06-17-20-37-09.bin.gz > Looking at that. Do you plan to create repos for jdk10 or want me to address stress test results first? > > Thanks, > Andrey >> >> All the best, >> Ed. >> >> On Wed, 2018-06-13 at 13:33 +0300, Andrey Petushkov wrote: >>> Thank you so much a try! >>> In fact there are two synchronization bugs found and fixed during >>> updating to Java 10. So could I ask you to check out the jdk10 webrev >>> I?ve sent last week. Hopefully some of the problems should go away. >>> Unfortunately I did not yet run jcstress myself, shame on me? >>> >>> The people participated are Fedor Burdun >>> m> and myself, Andrey Petushkov > >>> >