From david.holmes at oracle.com Mon Jan 2 23:53:44 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 3 Jan 2017 09:53:44 +1000 Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0 In-Reply-To: <58666849.1020700@linux.vnet.ibm.com> References: <58530522.3030102@linux.vnet.ibm.com> <58666849.1020700@linux.vnet.ibm.com> Message-ID: Seems fine. Thanks, David On 30/12/2016 11:59 PM, Gustavo Romero wrote: > Hi, > > That change is already reviewed by Martin on the ppc-aix-port ML [1], but since > I understand that a formal review has to be submitted to the hs ML I resent it. > > Is any thing missing on my side? > > Thank you. > > > Regards, > Gustavo > > [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html > > On 15-12-2016 19:03, Gustavo Romero wrote: >> Hi, >> >> Could the following change be reviewed please? >> >> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/ >> bug : https://bugs.openjdk.java.net/browse/JDK-8171266 >> >> Thank you. >> >> >> Regards, >> Gustavo >> > From volker.simonis at gmail.com Tue Jan 3 18:08:14 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Jan 2017 19:08:14 +0100 Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0 In-Reply-To: References: <58530522.3030102@linux.vnet.ibm.com> <58666849.1020700@linux.vnet.ibm.com> Message-ID: Hi David, thanks for looking at this change. As this is ppc64-only, I'll sponsor it. Regards, Volker On Tue, Jan 3, 2017 at 12:53 AM, David Holmes wrote: > Seems fine. > > Thanks, > David > > > On 30/12/2016 11:59 PM, Gustavo Romero wrote: >> >> Hi, >> >> That change is already reviewed by Martin on the ppc-aix-port ML [1], but >> since >> I understand that a formal review has to be submitted to the hs ML I >> resent it. >> >> Is any thing missing on my side? >> >> Thank you. >> >> >> Regards, >> Gustavo >> >> [1] >> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html >> >> On 15-12-2016 19:03, Gustavo Romero wrote: >>> >>> Hi, >>> >>> Could the following change be reviewed please? >>> >>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/ >>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266 >>> >>> Thank you. >>> >>> >>> Regards, >>> Gustavo >>> >> > From vladimir.kozlov at oracle.com Tue Jan 3 18:53:55 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 3 Jan 2017 10:53:55 -0800 Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now Message-ID: <586BF343.7040608@oracle.com> We are currently in "Rampdown" phase for jdk 9 which allows only P1-P3 bugs fixes. Note for Hotspot it started week ago. http://openjdk.java.net/projects/jdk9/ Please, make sure bugs you are planning to fix have P1-P3 priority and "fix version" is jdk 9. I just updated JDK-8171266 [1] for that. You can rise priority to P3 if you think a bug must be fixed in jdk 9 or defer it to jdk 10 - set "fix version" to 10. I see 3 aarch64 P4-P5 bugs which should be updated accordingly: https://bugs.openjdk.java.net/browse/JDK-8170101 https://bugs.openjdk.java.net/browse/JDK-8170103 https://bugs.openjdk.java.net/browse/JDK-8165058 Thanks, Vladimir [1] https://bugs.openjdk.java.net/browse/JDK-8171266 "PPC64: Add support to -XX:RTMSpinLoopCount=0" From volker.simonis at gmail.com Wed Jan 4 10:23:04 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 4 Jan 2017 11:23:04 +0100 Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now In-Reply-To: <586BF343.7040608@oracle.com> References: <586BF343.7040608@oracle.com> Message-ID: On Tue, Jan 3, 2017 at 7:53 PM, Vladimir Kozlov wrote: > We are currently in "Rampdown" phase for jdk 9 which allows only P1-P3 bugs > fixes. Note for Hotspot it started week ago. > > http://openjdk.java.net/projects/jdk9/ > > Please, make sure bugs you are planning to fix have P1-P3 priority and "fix > version" is jdk 9. I just updated JDK-8171266 [1] for that. > Thanks a lot Vladimir. I'll push it today. Just for clarification: do the "Rampdown phase rules" also apply to non-Oracle platforms like ppc64 or s390x? In the past, we were allowed to push non P1-P3 bugs or enhancements even in later phases as long as they didn't touch shared code. Is this still allowed or do we now have to strictly conform to the process even for ppc64/s390x-only changes? Thanks a lot and best regards, Volker > You can rise priority to P3 if you think a bug must be fixed in jdk 9 or > defer it to jdk 10 - set "fix version" to 10. > > I see 3 aarch64 P4-P5 bugs which should be updated accordingly: > > https://bugs.openjdk.java.net/browse/JDK-8170101 > https://bugs.openjdk.java.net/browse/JDK-8170103 > https://bugs.openjdk.java.net/browse/JDK-8165058 > > Thanks, > Vladimir > > [1] https://bugs.openjdk.java.net/browse/JDK-8171266 > "PPC64: Add support to -XX:RTMSpinLoopCount=0" > From vladimir.kozlov at oracle.com Wed Jan 4 19:30:38 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 4 Jan 2017 11:30:38 -0800 Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now In-Reply-To: References: <586BF343.7040608@oracle.com> Message-ID: <3fa78b65-93cc-1c9c-d39c-e7eafa82ce20@oracle.com> On 1/4/17 2:23 AM, Volker Simonis wrote: > On Tue, Jan 3, 2017 at 7:53 PM, Vladimir Kozlov > wrote: >> We are currently in "Rampdown" phase for jdk 9 which allows only P1-P3 bugs >> fixes. Note for Hotspot it started week ago. >> >> http://openjdk.java.net/projects/jdk9/ >> >> Please, make sure bugs you are planning to fix have P1-P3 priority and "fix >> version" is jdk 9. I just updated JDK-8171266 [1] for that. >> > > Thanks a lot Vladimir. I'll push it today. > > Just for clarification: do the "Rampdown phase rules" also apply to > non-Oracle platforms like ppc64 or s390x? In the past, we were allowed > to push non P1-P3 bugs or enhancements even in later phases as long as > they didn't touch shared code. Is this still allowed or do we now have > to strictly conform to the process even for ppc64/s390x-only changes? JDK 9 schedule was approved by all, including Java Community outside Oracle. I looked on original Mark's email about "JDK 9 Rampdown Phase 1" and there were no exceptions listed: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html But I understand that JDK 9 schedule reflects the process inside Oracle and may not be applied directly to your process. I will try to clarify situation with your ports regarding JDK 9 schedule and inform you. Regards, Vladimir > > Thanks a lot and best regards, > Volker > >> You can rise priority to P3 if you think a bug must be fixed in jdk 9 or >> defer it to jdk 10 - set "fix version" to 10. >> >> I see 3 aarch64 P4-P5 bugs which should be updated accordingly: >> >> https://bugs.openjdk.java.net/browse/JDK-8170101 >> https://bugs.openjdk.java.net/browse/JDK-8170103 >> https://bugs.openjdk.java.net/browse/JDK-8165058 >> >> Thanks, >> Vladimir >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8171266 >> "PPC64: Add support to -XX:RTMSpinLoopCount=0" >> From kim.barrett at oracle.com Wed Jan 4 23:36:23 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 4 Jan 2017 18:36:23 -0500 Subject: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated In-Reply-To: References: Message-ID: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> > On Dec 24, 2016, at 10:04 AM, Alexander Harlap wrote: > > Please review change for JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated > > Change is located at http://cr.openjdk.java.net/~aharlap/8140588/webrev.00/ > > It implements Per Liden fix for rechecking value of marking in progress value inside C1 g1_pre_barrier code. > > Also here is optimization described by Thomas Schatzl - do recheck only if patching involved. I wonder whether it is worth the effort of having distinct stubs for the two cases, or just unconditionally perform the recheck in the existing stub. Thomas said he found no performance issue with the simpler version. ------------------------------------------------------------------------------ Throughout, copyright dates need updating. ------------------------------------------------------------------------------ cpu/aarch64/vm/c1_CodeStubs_aarch64.cpp 373 Runtime1::StubID id = patch_code() == lir_patch_none ? Runtime1::g1_pre_barrier_slow_id : Runtime1::g1_pre_barrier_slow_with_recheck_id; Assuming we stay with the pair of stubs, this ought to be packaged up as a helper function. Other occurrences: src/cpu/arm/vm/c1_CodeStubs_arm.cpp src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp src/cpu/s390/vm/c1_CodeStubs_s390.cpp src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp src/cpu/x86/vm/c1_CodeStubs_x86.cpp ------------------------------------------------------------------------------ From gromero at linux.vnet.ibm.com Thu Jan 5 02:03:04 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 5 Jan 2017 00:03:04 -0200 Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0 In-Reply-To: References: <58530522.3030102@linux.vnet.ibm.com> <58666849.1020700@linux.vnet.ibm.com> Message-ID: <586DA958.3020104@linux.vnet.ibm.com> Hi On 03-01-2017 16:08, Volker Simonis wrote: > Hi David, > > thanks for looking at this change. > As this is ppc64-only, I'll sponsor it. > > Regards, > Volker David, thanks for reviewing the change. Volker, thanks for sponsoring it. Vladimir, thanks for setting the proper priority and fix version tag. Regards, Gustavo > On Tue, Jan 3, 2017 at 12:53 AM, David Holmes wrote: >> Seems fine. >> >> Thanks, >> David >> >> >> On 30/12/2016 11:59 PM, Gustavo Romero wrote: >>> >>> Hi, >>> >>> That change is already reviewed by Martin on the ppc-aix-port ML [1], but >>> since >>> I understand that a formal review has to be submitted to the hs ML I >>> resent it. >>> >>> Is any thing missing on my side? >>> >>> Thank you. >>> >>> >>> Regards, >>> Gustavo >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html >>> >>> On 15-12-2016 19:03, Gustavo Romero wrote: >>>> >>>> Hi, >>>> >>>> Could the following change be reviewed please? >>>> >>>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/ >>>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266 >>>> >>>> Thank you. >>>> >>>> >>>> Regards, >>>> Gustavo >>>> >>> >> > From per.liden at oracle.com Thu Jan 5 12:41:15 2017 From: per.liden at oracle.com (Per Liden) Date: Thu, 5 Jan 2017 13:41:15 +0100 Subject: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated In-Reply-To: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> References: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> Message-ID: <330cdafb-5cd2-c55f-3558-89bfc91e5757@oracle.com> Hi, On 2017-01-05 00:36, Kim Barrett wrote: >> On Dec 24, 2016, at 10:04 AM, Alexander Harlap wrote: >> >> Please review change for JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated >> >> Change is located at http://cr.openjdk.java.net/~aharlap/8140588/webrev.00/ >> >> It implements Per Liden fix for rechecking value of marking in progress value inside C1 g1_pre_barrier code. >> >> Also here is optimization described by Thomas Schatzl - do recheck only if patching involved. > > I wonder whether it is worth the effort of having distinct stubs for > the two cases, or just unconditionally perform the recheck in the > existing stub. Thomas said he found no performance issue with the > simpler version. Agree. If there's no measurable performance gain by having two stubs (given the other things we do in this path I'd be surprised if there were) I'd vote for keeping it simple here and have one stub. That would also "fix" Kim's last comment below. cheers, Per > > ------------------------------------------------------------------------------ > Throughout, copyright dates need updating. > > ------------------------------------------------------------------------------ > cpu/aarch64/vm/c1_CodeStubs_aarch64.cpp > 373 Runtime1::StubID id = patch_code() == lir_patch_none ? Runtime1::g1_pre_barrier_slow_id : Runtime1::g1_pre_barrier_slow_with_recheck_id; > > Assuming we stay with the pair of stubs, this ought to be packaged up > as a helper function. > > Other occurrences: > src/cpu/arm/vm/c1_CodeStubs_arm.cpp > src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp > src/cpu/s390/vm/c1_CodeStubs_s390.cpp > src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp > src/cpu/x86/vm/c1_CodeStubs_x86.cpp > > ------------------------------------------------------------------------------ > From volker.simonis at gmail.com Thu Jan 5 13:18:25 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 5 Jan 2017 14:18:25 +0100 Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0 In-Reply-To: <586DA958.3020104@linux.vnet.ibm.com> References: <58530522.3030102@linux.vnet.ibm.com> <58666849.1020700@linux.vnet.ibm.com> <586DA958.3020104@linux.vnet.ibm.com> Message-ID: Hi Gustavo, I finally got a Power machine which supports RTM. So before pushing this change, I thought I run the RTM jtreg tests. Obviously your change improves the situation by preventing crashes because of RTMSpinLoopCount=0. But I still get 10 failures when running the RTM tests (test/compiler/rtm) on linux/ppc64: compiler/rtm/locking/TestRTMAbortRatio.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0] compiler/rtm/locking/TestRTMAbortThreshold.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected that method with rtm lock elision was deoptimized after 1 lock attempts: expected 10000 to equal 1 compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Two uncommon traps with reason rtm_state_change should be fired.: expected 0 to equal 2 compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get only one deoptimization due to rtm state change: expected 0 to equal 1 compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get only one deoptimization due to rtm state change: expected 0 to equal 1 compiler/rtm/locking/TestRTMLockingCalculationDelay.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: At least one deoptimization due to rtm_state_chage is expected: expected 0 > 0 compiler/rtm/locking/TestRTMLockingThreshold.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: VM output should contain two RTM locking statistics entries.: expected 1 to equal 2 compiler/rtm/locking/TestRTMRetryCount.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: It is expected to get 2 aborts: expected 3 to equal 2 compiler/rtm/locking/TestRTMSpinLoopCount.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Total aborts count (2001) should be less or equal to 1001: expected that 2001 <= 1001 compiler/rtm/locking/TestUseRTMXendForLockBusy.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: VM output should contain exactly one rtm locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1 compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: RTM locking statistics should contain non zero total aborts count: expected 0 > 0 On the other hand, the situation on linux/x86_64 seems similar (with 7-9 failures depending on the run): compiler/rtm/locking/TestRTMAbortThreshold.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected that method with rtm lock elision was deoptimized after 1 lock attempts: expected 10000 to equal 1 compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Two uncommon traps with reason rtm_state_change should be fired.: expected 0 to equal 2 compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get only one deoptimization due to rtm state change: expected 0 to equal 1 compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: After LockThreshold was reached, method should be recompiled with rtm lock eliding.: expected null to not equal null compiler/rtm/locking/TestRTMLockingCalculationDelay.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: At least one deoptimization due to rtm_state_chage is expected: expected 0 > 0 compiler/rtm/locking/TestRTMLockingThreshold.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: VM output should contain two RTM locking statistics entries.: expected 1 to equal 2 compiler/rtm/locking/TestRTMTotalCountIncrRate.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test::lock: expected 0 to equal 1 compiler/rtm/locking/TestUseRTMXendForLockBusy.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: VM output should contain exactly one rtm locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1 compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: RTM locking statistics should contain non zero total aborts count: expected 0 > 0 Are these the same results you are seeing as well? The JDK 9 Early Access Build Test Results site at http://download.java.net/openjdk/testresults/9/testresults.html reports these tests as passed, but I think that may be because they run on hardware which doesn't support RTM? @Vladimir, David: do you regularly run the RTM tests on linux/x86_64 and do they really all pass in your environment? (I've tested with Linux 3.10 on a "Intel(R) Xeon(R) CPU E7-4820 v3" and with Windows 7 on a "Intel(R) Core(TM) i5-4300U" which according to /proc/cpuinfo and coreinfo.exe both support RTM). Thank you and best regards, Volker On Thu, Jan 5, 2017 at 3:03 AM, Gustavo Romero wrote: > Hi > > On 03-01-2017 16:08, Volker Simonis wrote: >> Hi David, >> >> thanks for looking at this change. >> As this is ppc64-only, I'll sponsor it. >> >> Regards, >> Volker > > David, thanks for reviewing the change. > > Volker, thanks for sponsoring it. > > Vladimir, thanks for setting the proper priority and fix version tag. > > > Regards, > Gustavo > >> On Tue, Jan 3, 2017 at 12:53 AM, David Holmes wrote: >>> Seems fine. >>> >>> Thanks, >>> David >>> >>> >>> On 30/12/2016 11:59 PM, Gustavo Romero wrote: >>>> >>>> Hi, >>>> >>>> That change is already reviewed by Martin on the ppc-aix-port ML [1], but >>>> since >>>> I understand that a formal review has to be submitted to the hs ML I >>>> resent it. >>>> >>>> Is any thing missing on my side? >>>> >>>> Thank you. >>>> >>>> >>>> Regards, >>>> Gustavo >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html >>>> >>>> On 15-12-2016 19:03, Gustavo Romero wrote: >>>>> >>>>> Hi, >>>>> >>>>> Could the following change be reviewed please? >>>>> >>>>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/ >>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266 >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> Regards, >>>>> Gustavo >>>>> >>>> >>> >> > From martin.doerr at sap.com Thu Jan 5 13:40:19 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 5 Jan 2017 13:40:19 +0000 Subject: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated In-Reply-To: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> References: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> Message-ID: <74c2d94b37024885b2ec0e15ee510383@dewdfe13de06.global.corp.sap> Hi, it'd be nice if you could apply the following patch to webrev.00 to fix PPC64/s390 build. Thanks, Martin ******** START --- a/src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp Thu Jan 05 14:08:29 2017 +0100 +++ b/src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp Thu Jan 05 14:35:32 2017 +0100 @@ -492,7 +492,7 @@ __ cmpdi(CCR0, pre_val_reg, 0); __ bc_far_optimized(Assembler::bcondCRbiIs1, __ bi0(CCR0, Assembler::equal), _continuation); - Runtime1::StubID id = patch_code() = lir_patch_none ? Runtime1::g1_pre_barrier_slow_id : Runtime1::g1_pre_barrier_slow_with_recheck_id; + Runtime1::StubID id = patch_code() == lir_patch_none ? Runtime1::g1_pre_barrier_slow_id : Runtime1::g1_pre_barrier_slow_with_recheck_id; address stub = Runtime1::entry_for(id); //__ load_const_optimized(R0, stub); __ add_const_optimized(R0, R29_TOC, MacroAssembler::offset_to_global_toc(stub)); diff -r 0f48eb902cfc src/cpu/ppc/vm/c1_Runtime1_ppc.cpp --- a/src/cpu/ppc/vm/c1_Runtime1_ppc.cpp Thu Jan 05 14:08:29 2017 +0100 +++ b/src/cpu/ppc/vm/c1_Runtime1_ppc.cpp Thu Jan 05 14:35:32 2017 +0100 @@ -746,8 +746,8 @@ Register tmp = R14; Register tmp2 = R15; - Label refill, restart, marking_not_active;; - + Label refill, restart, marking_not_active; + int satb_q_active_byte_offset = in_bytes(JavaThread::satb_mark_queue_offset() + SATBMarkQueue::byte_offset_of_active()); diff -r 0f48eb902cfc src/cpu/s390/vm/c1_Runtime1_s390.cpp --- a/src/cpu/s390/vm/c1_Runtime1_s390.cpp Thu Jan 05 14:08:29 2017 +0100 +++ b/src/cpu/s390/vm/c1_Runtime1_s390.cpp Thu Jan 05 14:35:32 2017 +0100 @@ -810,7 +810,7 @@ __ load_and_test_int(tmp, Address(Z_thread, satb_q_active_byte_offset)); } else { guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption"); - __ load_and_test_byte(tmp, Address(Z_thread, satb_q_active_byte_offset`)); + __ load_and_test_byte(tmp, Address(Z_thread, satb_q_active_byte_offset)); } __ z_bre(marking_not_active); // Activity indicator is zero, so there is no marking going on currently. } ******** END -----Original Message----- From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Kim Barrett Sent: Donnerstag, 5. Januar 2017 00:36 To: Alexander Harlap Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: Re: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated > On Dec 24, 2016, at 10:04 AM, Alexander Harlap wrote: > > Please review change for JDK-8140588 - Internal Error: > gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues > are empty when activated > > Change is located at > http://cr.openjdk.java.net/~aharlap/8140588/webrev.00/ > > It implements Per Liden fix for rechecking value of marking in progress value inside C1 g1_pre_barrier code. > > Also here is optimization described by Thomas Schatzl - do recheck only if patching involved. I wonder whether it is worth the effort of having distinct stubs for the two cases, or just unconditionally perform the recheck in the existing stub. Thomas said he found no performance issue with the simpler version. ------------------------------------------------------------------------------ Throughout, copyright dates need updating. ------------------------------------------------------------------------------ cpu/aarch64/vm/c1_CodeStubs_aarch64.cpp 373 Runtime1::StubID id = patch_code() == lir_patch_none ? Runtime1::g1_pre_barrier_slow_id : Runtime1::g1_pre_barrier_slow_with_recheck_id; Assuming we stay with the pair of stubs, this ought to be packaged up as a helper function. Other occurrences: src/cpu/arm/vm/c1_CodeStubs_arm.cpp src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp src/cpu/s390/vm/c1_CodeStubs_s390.cpp src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp src/cpu/x86/vm/c1_CodeStubs_x86.cpp ------------------------------------------------------------------------------ From martin.doerr at sap.com Thu Jan 5 13:48:01 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 5 Jan 2017 13:48:01 +0000 Subject: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated In-Reply-To: <74c2d94b37024885b2ec0e15ee510383@dewdfe13de06.global.corp.sap> References: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> <74c2d94b37024885b2ec0e15ee510383@dewdfe13de06.global.corp.sap> Message-ID: <8695d6e5cf6f476da20e91858835ab65@dewdfe13de06.global.corp.sap> Sorry, pasting patches into emails doesn't work as expected. I've uploaded the patch here: http://cr.openjdk.java.net/~mdoerr/8140588_webrev00_addon.patch Thanks for porting the changes to PPC64/s390. Best regards, Martin -----Original Message----- From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin Sent: Donnerstag, 5. Januar 2017 14:40 To: Kim Barrett ; Alexander Harlap Cc: hotspot-gc-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: RE: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated Hi, it'd be nice if you could apply the following patch to webrev.00 to fix PPC64/s390 build. Thanks, Martin ******** START --- a/src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp Thu Jan 05 14:08:29 2017 +0100 +++ b/src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp Thu Jan 05 14:35:32 2017 +0100 @@ -492,7 +492,7 @@ __ cmpdi(CCR0, pre_val_reg, 0); __ bc_far_optimized(Assembler::bcondCRbiIs1, __ bi0(CCR0, Assembler::equal), _continuation); - Runtime1::StubID id = patch_code() = lir_patch_none ? Runtime1::g1_pre_barrier_slow_id : Runtime1::g1_pre_barrier_slow_with_recheck_id; + Runtime1::StubID id = patch_code() == lir_patch_none ? + Runtime1::g1_pre_barrier_slow_id : + Runtime1::g1_pre_barrier_slow_with_recheck_id; address stub = Runtime1::entry_for(id); //__ load_const_optimized(R0, stub); __ add_const_optimized(R0, R29_TOC, MacroAssembler::offset_to_global_toc(stub)); diff -r 0f48eb902cfc src/cpu/ppc/vm/c1_Runtime1_ppc.cpp --- a/src/cpu/ppc/vm/c1_Runtime1_ppc.cpp Thu Jan 05 14:08:29 2017 +0100 +++ b/src/cpu/ppc/vm/c1_Runtime1_ppc.cpp Thu Jan 05 14:35:32 2017 +0100 @@ -746,8 +746,8 @@ Register tmp = R14; Register tmp2 = R15; - Label refill, restart, marking_not_active;; - + Label refill, restart, marking_not_active; + int satb_q_active_byte_offset = in_bytes(JavaThread::satb_mark_queue_offset() + SATBMarkQueue::byte_offset_of_active()); diff -r 0f48eb902cfc src/cpu/s390/vm/c1_Runtime1_s390.cpp --- a/src/cpu/s390/vm/c1_Runtime1_s390.cpp Thu Jan 05 14:08:29 2017 +0100 +++ b/src/cpu/s390/vm/c1_Runtime1_s390.cpp Thu Jan 05 14:35:32 2017 +0100 @@ -810,7 +810,7 @@ __ load_and_test_int(tmp, Address(Z_thread, satb_q_active_byte_offset)); } else { guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption"); - __ load_and_test_byte(tmp, Address(Z_thread, satb_q_active_byte_offset`)); + __ load_and_test_byte(tmp, Address(Z_thread, + satb_q_active_byte_offset)); } __ z_bre(marking_not_active); // Activity indicator is zero, so there is no marking going on currently. } ******** END -----Original Message----- From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Kim Barrett Sent: Donnerstag, 5. Januar 2017 00:36 To: Alexander Harlap Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: Re: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated > On Dec 24, 2016, at 10:04 AM, Alexander Harlap wrote: > > Please review change for JDK-8140588 - Internal Error: > gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues > are empty when activated > > Change is located at > http://cr.openjdk.java.net/~aharlap/8140588/webrev.00/ > > It implements Per Liden fix for rechecking value of marking in progress value inside C1 g1_pre_barrier code. > > Also here is optimization described by Thomas Schatzl - do recheck only if patching involved. I wonder whether it is worth the effort of having distinct stubs for the two cases, or just unconditionally perform the recheck in the existing stub. Thomas said he found no performance issue with the simpler version. ------------------------------------------------------------------------------ Throughout, copyright dates need updating. ------------------------------------------------------------------------------ cpu/aarch64/vm/c1_CodeStubs_aarch64.cpp 373 Runtime1::StubID id = patch_code() == lir_patch_none ? Runtime1::g1_pre_barrier_slow_id : Runtime1::g1_pre_barrier_slow_with_recheck_id; Assuming we stay with the pair of stubs, this ought to be packaged up as a helper function. Other occurrences: src/cpu/arm/vm/c1_CodeStubs_arm.cpp src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp src/cpu/s390/vm/c1_CodeStubs_s390.cpp src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp src/cpu/x86/vm/c1_CodeStubs_x86.cpp ------------------------------------------------------------------------------ From gromero at linux.vnet.ibm.com Thu Jan 5 20:18:09 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 5 Jan 2017 18:18:09 -0200 Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0 In-Reply-To: References: <58530522.3030102@linux.vnet.ibm.com> <58666849.1020700@linux.vnet.ibm.com> <586DA958.3020104@linux.vnet.ibm.com> Message-ID: <586EAA01.8060207@linux.vnet.ibm.com> Hi Volker, Please see my comments inline. On 05-01-2017 11:18, Volker Simonis wrote: > Hi Gustavo, > > I finally got a Power machine which supports RTM. Good :) > So before pushing this change, I thought I run the RTM jtreg tests. > > Obviously your change improves the situation by preventing crashes > because of RTMSpinLoopCount=0. But I still get 10 failures when > running the RTM tests (test/compiler/rtm) on linux/ppc64: Yes, before my change TestRTMSpinLoopCount.java was just crashing the JVM. But after that the test is not passing yet. It looks like it is expecting fewer abortions and I'm wondering if it's because on Power the transaction is aborted if a signal is caught in the middle (the JVM uses signal quite frequently...), thus an intrinsic property of the JVM on Power. I'll continue the investigation. > > compiler/rtm/locking/TestRTMAbortRatio.java > Failed. Execution failed: `main' > threw exception: java.lang.RuntimeException: Expected to get exit > value of [0] > compiler/rtm/locking/TestRTMAbortThreshold.java > Failed. Execution failed: `main' > threw exception: java.lang.RuntimeException: Expected that method with > rtm lock elision was deoptimized after 1 lock attempts: expected 10000 > to equal 1 > compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java > Failed. Execution failed: `main' > threw exception: java.lang.RuntimeException: Two uncommon traps with > reason rtm_state_change should be fired.: expected 0 to equal 2 > compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java > Failed. Execution failed: `main' > threw exception: java.lang.RuntimeException: Expected to get only one > deoptimization due to rtm state change: expected 0 to equal 1 > compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java > Failed. Execution failed: `main' > threw exception: java.lang.RuntimeException: Expected to get only one > deoptimization due to rtm state change: expected 0 to equal 1 > compiler/rtm/locking/TestRTMLockingCalculationDelay.java > Failed. Execution failed: `main' > threw exception: java.lang.RuntimeException: At least one > deoptimization due to rtm_state_chage is expected: expected 0 > 0 > compiler/rtm/locking/TestRTMLockingThreshold.java > Failed. Execution failed: `main' > threw exception: java.lang.RuntimeException: VM output should contain > two RTM locking statistics entries.: expected 1 to equal 2 > compiler/rtm/locking/TestRTMRetryCount.java > Failed. Execution failed: `main' > threw exception: java.lang.RuntimeException: It is expected to get 2 > aborts: expected 3 to equal 2 > compiler/rtm/locking/TestRTMSpinLoopCount.java > Failed. Execution failed: `main' > threw exception: java.lang.RuntimeException: Total aborts count (2001) > should be less or equal to 1001: expected that 2001 <= 1001 > compiler/rtm/locking/TestUseRTMXendForLockBusy.java > Failed. Execution failed: `main' > threw exception: java.lang.RuntimeException: VM output should contain > exactly one rtm locking statistics entry for method > compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1 > compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java > Failed. Execution failed: `main' > threw exception: java.lang.RuntimeException: RTM locking statistics > should contain non zero total aborts count: expected 0 > 0 > > On the other hand, the situation on linux/x86_64 seems similar (with > 7-9 failures depending on the run): > > compiler/rtm/locking/TestRTMAbortThreshold.java > Failed. Execution failed: > `main' threw exception: java.lang.RuntimeException: Expected that > method with rtm lock elision was deoptimized after 1 lock attempts: > expected 10000 to equal 1 > compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java > Failed. Execution failed: > `main' threw exception: java.lang.RuntimeException: Two uncommon traps > with reason rtm_state_change should be fired.: expected 0 to equal 2 > compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java > Failed. Execution failed: > `main' threw exception: java.lang.RuntimeException: Expected to get > only one deoptimization due to rtm state change: expected 0 to equal 1 > compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java > Failed. Execution failed: > `main' threw exception: java.lang.RuntimeException: After > LockThreshold was reached, method should be recompiled with rtm lock > eliding.: expected null to not equal null > compiler/rtm/locking/TestRTMLockingCalculationDelay.java > Failed. Execution failed: > `main' threw exception: java.lang.RuntimeException: At least one > deoptimization due to rtm_state_chage is expected: expected 0 > 0 > compiler/rtm/locking/TestRTMLockingThreshold.java > Failed. Execution failed: > `main' threw exception: java.lang.RuntimeException: VM output should > contain two RTM locking statistics entries.: expected 1 to equal 2 > compiler/rtm/locking/TestRTMTotalCountIncrRate.java > Failed. Execution failed: > `main' threw exception: java.lang.RuntimeException: VM output should > contain exactly one RTM locking statistics entry for method > compiler.rtm.locking.TestRTMTotalCountIncrRate$Test::lock: expected 0 > to equal 1 > compiler/rtm/locking/TestUseRTMXendForLockBusy.java > Failed. Execution failed: > `main' threw exception: java.lang.RuntimeException: VM output should > contain exactly one rtm locking statistics entry for method > compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1 > compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java > Failed. Execution failed: > `main' threw exception: java.lang.RuntimeException: RTM locking > statistics should contain non zero total aborts count: expected 0 > 0 > > Are these the same results you are seeing as well? I don't have access to a x64 machine w/ RTM at the moment, but IIRC some tests are failing as well, but fewer in comparison to Power. Much unfortunately I don't know when I'll be able to have a x64 machine available again... I've got the following tests status on a POWER8 machine: FAILED: compiler/rtm/locking/TestRTMAbortThreshold.java FAILED: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java FAILED: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java FAILED: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java FAILED: compiler/rtm/locking/TestRTMLockingCalculationDelay.java FAILED: compiler/rtm/locking/TestRTMLockingThreshold.java FAILED: compiler/rtm/locking/TestRTMRetryCount.java FAILED: compiler/rtm/locking/TestRTMSpinLoopCount.java FAILED: compiler/rtm/locking/TestUseRTMXendForLockBusy.java FAILED: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnUnsupportedConfig.java Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnUnsupportedConfig.java Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java Passed: compiler/rtm/cli/TestRTMRetryCountOption.java Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnUnsupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnUnsupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnUnsupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedCPU.java Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedVM.java Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java Passed: compiler/rtm/locking/TestRTMAbortRatio.java Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java Passed: compiler/rtm/locking/TestUseRTMDeopt.java Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java Test results: passed: 28; failed: 10 Hence similar to what you've reported, except for TestRTMAbortRatio.java which passed [1], although I would expect more aborts than what was reported. > The JDK 9 Early Access Build Test Results site at > http://download.java.net/openjdk/testresults/9/testresults.html > reports these tests as passed, but I think that may be because they > run on hardware which doesn't support RTM? Exactly. I discussed that briefly with David here [2] when fixing [3] and I guess that's the reason for the regression 8171236 [4] not being detected firstly at the Oracle side. Regards, Gustavo [1] http://paste.fedoraproject.org/520455/83645916/raw/ [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024361.html [3] https://bugs.openjdk.java.net/browse/JDK-8164987 [4] https://bugs.openjdk.java.net/browse/JDK-8171236 > @Vladimir, David: do you regularly run the RTM tests on linux/x86_64 > and do they really all pass in your environment? (I've tested with > Linux 3.10 on a "Intel(R) Xeon(R) CPU E7-4820 v3" and with Windows 7 > on a "Intel(R) Core(TM) i5-4300U" which according to /proc/cpuinfo and > coreinfo.exe both support RTM). > > Thank you and best regards, > Volker > > On Thu, Jan 5, 2017 at 3:03 AM, Gustavo Romero > wrote: >> Hi >> >> On 03-01-2017 16:08, Volker Simonis wrote: >>> Hi David, >>> >>> thanks for looking at this change. >>> As this is ppc64-only, I'll sponsor it. >>> >>> Regards, >>> Volker >> >> David, thanks for reviewing the change. >> >> Volker, thanks for sponsoring it. >> >> Vladimir, thanks for setting the proper priority and fix version tag. >> >> >> Regards, >> Gustavo >> >>> On Tue, Jan 3, 2017 at 12:53 AM, David Holmes wrote: >>>> Seems fine. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> On 30/12/2016 11:59 PM, Gustavo Romero wrote: >>>>> >>>>> Hi, >>>>> >>>>> That change is already reviewed by Martin on the ppc-aix-port ML [1], but >>>>> since >>>>> I understand that a formal review has to be submitted to the hs ML I >>>>> resent it. >>>>> >>>>> Is any thing missing on my side? >>>>> >>>>> Thank you. >>>>> >>>>> >>>>> Regards, >>>>> Gustavo >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html >>>>> >>>>> On 15-12-2016 19:03, Gustavo Romero wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Could the following change be reviewed please? >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/ >>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266 >>>>>> >>>>>> Thank you. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Gustavo >>>>>> >>>>> >>>> >>> >> > From alexander.harlap at oracle.com Fri Jan 6 16:35:27 2017 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Fri, 6 Jan 2017 11:35:27 -0500 Subject: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated In-Reply-To: <330cdafb-5cd2-c55f-3558-89bfc91e5757@oracle.com> References: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> <330cdafb-5cd2-c55f-3558-89bfc91e5757@oracle.com> Message-ID: <497ae298-147a-b649-954e-30629b69b043@oracle.com> Change at http://cr.openjdk.java.net/~aharlap/8140588/webrev.01/ accommodates comments from Per, Kim and Martin Yes, there is no measurable performance difference. So make change simpler. Alex On 1/5/2017 7:41 AM, Per Liden wrote: > Hi, > > On 2017-01-05 00:36, Kim Barrett wrote: >>> On Dec 24, 2016, at 10:04 AM, Alexander Harlap >>> wrote: >>> >>> Please review change for JDK-8140588 - Internal Error: >>> gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: >>> queues are empty when activated >>> >>> Change is located at >>> http://cr.openjdk.java.net/~aharlap/8140588/webrev.00/ >>> >>> It implements Per Liden fix for rechecking value of marking in >>> progress value inside C1 g1_pre_barrier code. >>> >>> Also here is optimization described by Thomas Schatzl - do recheck >>> only if patching involved. >> >> I wonder whether it is worth the effort of having distinct stubs for >> the two cases, or just unconditionally perform the recheck in the >> existing stub. Thomas said he found no performance issue with the >> simpler version. > > Agree. If there's no measurable performance gain by having two stubs > (given the other things we do in this path I'd be surprised if there > were) I'd vote for keeping it simple here and have one stub. That > would also "fix" Kim's last comment below. > > cheers, > Per > >> >> ------------------------------------------------------------------------------ >> >> Throughout, copyright dates need updating. >> >> ------------------------------------------------------------------------------ >> >> cpu/aarch64/vm/c1_CodeStubs_aarch64.cpp >> 373 Runtime1::StubID id = patch_code() == lir_patch_none ? >> Runtime1::g1_pre_barrier_slow_id : >> Runtime1::g1_pre_barrier_slow_with_recheck_id; >> >> Assuming we stay with the pair of stubs, this ought to be packaged up >> as a helper function. >> >> Other occurrences: >> src/cpu/arm/vm/c1_CodeStubs_arm.cpp >> src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp >> src/cpu/s390/vm/c1_CodeStubs_s390.cpp >> src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp >> src/cpu/x86/vm/c1_CodeStubs_x86.cpp >> >> ------------------------------------------------------------------------------ >> >> From per.liden at oracle.com Mon Jan 9 09:23:01 2017 From: per.liden at oracle.com (Per Liden) Date: Mon, 9 Jan 2017 10:23:01 +0100 Subject: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated In-Reply-To: <497ae298-147a-b649-954e-30629b69b043@oracle.com> References: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> <330cdafb-5cd2-c55f-3558-89bfc91e5757@oracle.com> <497ae298-147a-b649-954e-30629b69b043@oracle.com> Message-ID: <2390dd5a-4324-8fa5-833e-aa3761d5d9b9@oracle.com> Hi Alex, On 2017-01-06 17:35, Alexander Harlap wrote: > Change at http://cr.openjdk.java.net/~aharlap/8140588/webrev.01/ The x86 and Sparc parts looks good, I'll let others comments on the other ports. However, a few comments: c1_Runtime1_ppc.cpp ------------------- 764 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption"); Please change this to be an assert() instead of a guarantee(). c1_Runtime1_s390.cpp -------------------- 806 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption"); Same here. c1_Runtime1_sparc.cpp --------------------- 873 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, 874 "Assumption"); And same here. cheers, /Per > > accommodates comments from Per, Kim and Martin > > Yes, there is no measurable performance difference. > > So make change simpler. > > Alex > > On 1/5/2017 7:41 AM, Per Liden wrote: >> Hi, >> >> On 2017-01-05 00:36, Kim Barrett wrote: >>>> On Dec 24, 2016, at 10:04 AM, Alexander Harlap >>>> wrote: >>>> >>>> Please review change for JDK-8140588 - Internal Error: >>>> gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: >>>> queues are empty when activated >>>> >>>> Change is located at >>>> http://cr.openjdk.java.net/~aharlap/8140588/webrev.00/ >>>> >>>> It implements Per Liden fix for rechecking value of marking in >>>> progress value inside C1 g1_pre_barrier code. >>>> >>>> Also here is optimization described by Thomas Schatzl - do recheck >>>> only if patching involved. >>> >>> I wonder whether it is worth the effort of having distinct stubs for >>> the two cases, or just unconditionally perform the recheck in the >>> existing stub. Thomas said he found no performance issue with the >>> simpler version. >> >> Agree. If there's no measurable performance gain by having two stubs >> (given the other things we do in this path I'd be surprised if there >> were) I'd vote for keeping it simple here and have one stub. That >> would also "fix" Kim's last comment below. >> >> cheers, >> Per >> >>> >>> ------------------------------------------------------------------------------ >>> >>> Throughout, copyright dates need updating. >>> >>> ------------------------------------------------------------------------------ >>> >>> cpu/aarch64/vm/c1_CodeStubs_aarch64.cpp >>> 373 Runtime1::StubID id = patch_code() == lir_patch_none ? >>> Runtime1::g1_pre_barrier_slow_id : >>> Runtime1::g1_pre_barrier_slow_with_recheck_id; >>> >>> Assuming we stay with the pair of stubs, this ought to be packaged up >>> as a helper function. >>> >>> Other occurrences: >>> src/cpu/arm/vm/c1_CodeStubs_arm.cpp >>> src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp >>> src/cpu/s390/vm/c1_CodeStubs_s390.cpp >>> src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp >>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp >>> >>> ------------------------------------------------------------------------------ >>> >>> > From martin.doerr at sap.com Mon Jan 9 10:41:37 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 9 Jan 2017 10:41:37 +0000 Subject: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated In-Reply-To: <2390dd5a-4324-8fa5-833e-aa3761d5d9b9@oracle.com> References: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> <330cdafb-5cd2-c55f-3558-89bfc91e5757@oracle.com> <497ae298-147a-b649-954e-30629b69b043@oracle.com> <2390dd5a-4324-8fa5-833e-aa3761d5d9b9@oracle.com> Message-ID: <280a54f56aeb4161b615ee9527e16b41@dewdfe13de06.global.corp.sap> Hi Alex, the PPC64 and s390 parts look good, too. Thanks, Martin -----Original Message----- From: Per Liden [mailto:per.liden at oracle.com] Sent: Montag, 9. Januar 2017 10:23 To: Alexander Harlap ; Kim Barrett ; Doerr, Martin Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net Subject: Re: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated Hi Alex, On 2017-01-06 17:35, Alexander Harlap wrote: > Change at http://cr.openjdk.java.net/~aharlap/8140588/webrev.01/ The x86 and Sparc parts looks good, I'll let others comments on the other ports. However, a few comments: c1_Runtime1_ppc.cpp ------------------- 764 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption"); Please change this to be an assert() instead of a guarantee(). c1_Runtime1_s390.cpp -------------------- 806 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption"); Same here. c1_Runtime1_sparc.cpp --------------------- 873 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, 874 "Assumption"); And same here. cheers, /Per > > accommodates comments from Per, Kim and Martin > > Yes, there is no measurable performance difference. > > So make change simpler. > > Alex > > On 1/5/2017 7:41 AM, Per Liden wrote: >> Hi, >> >> On 2017-01-05 00:36, Kim Barrett wrote: >>>> On Dec 24, 2016, at 10:04 AM, Alexander Harlap >>>> wrote: >>>> >>>> Please review change for JDK-8140588 - Internal Error: >>>> gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: >>>> queues are empty when activated >>>> >>>> Change is located at >>>> http://cr.openjdk.java.net/~aharlap/8140588/webrev.00/ >>>> >>>> It implements Per Liden fix for rechecking value of marking in >>>> progress value inside C1 g1_pre_barrier code. >>>> >>>> Also here is optimization described by Thomas Schatzl - do recheck >>>> only if patching involved. >>> >>> I wonder whether it is worth the effort of having distinct stubs for >>> the two cases, or just unconditionally perform the recheck in the >>> existing stub. Thomas said he found no performance issue with the >>> simpler version. >> >> Agree. If there's no measurable performance gain by having two stubs >> (given the other things we do in this path I'd be surprised if there >> were) I'd vote for keeping it simple here and have one stub. That >> would also "fix" Kim's last comment below. >> >> cheers, >> Per >> >>> >>> ------------------------------------------------------------------------------ >>> >>> Throughout, copyright dates need updating. >>> >>> ------------------------------------------------------------------------------ >>> >>> cpu/aarch64/vm/c1_CodeStubs_aarch64.cpp >>> 373 Runtime1::StubID id = patch_code() == lir_patch_none ? >>> Runtime1::g1_pre_barrier_slow_id : >>> Runtime1::g1_pre_barrier_slow_with_recheck_id; >>> >>> Assuming we stay with the pair of stubs, this ought to be packaged up >>> as a helper function. >>> >>> Other occurrences: >>> src/cpu/arm/vm/c1_CodeStubs_arm.cpp >>> src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp >>> src/cpu/s390/vm/c1_CodeStubs_s390.cpp >>> src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp >>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp >>> >>> ------------------------------------------------------------------------------ >>> >>> > From daniel.daugherty at oracle.com Mon Jan 9 16:48:21 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 9 Jan 2017 09:48:21 -0700 Subject: Hotspot for BSD / opinion request In-Reply-To: References: <1488ccc1-e00c-42e7-3cfc-9fd0b5699a63@oracle.com> Message-ID: <3c580abc-9333-8803-abc1-1b0863123060@oracle.com> David C., If you sent the patch as an attachment, then you should be advised that the OpenJDK email servers strip attachments. If the patch is relatively small, then you can send it in-line... Dan On 1/6/17 3:23 PM, David CARLIER wrote: > Thanks, here a patch proposal. Kindest regards. > > On 24 December 2016 at 02:16, David Holmes wrote: >> If there is a platform, we support, where the default settings are >> inappropriate then setting them explicitly would be the right thing to do. >> >> David >> >> >> On 24/12/2016 10:23 AM, Vladimir Kozlov wrote: >>> Hi, >>> >>> Forwarding to mailing lists since I can't answer. >>> May be someone can answer your question on these lists. >>> >>> Regards, >>> Vladimir >>> >>> On 12/23/16 2:17 AM, David CARLIER wrote: >>>> Hi, >>>> >>>> this is my first mail to the maiing list, I have difficulties to push >>>> messages to any mailing lists, but as BSD user/dev I was >>>> looking at code's part like this one >>>> >>>> >>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/70c6fae64754/src/os/bsd/vm/os_bsd.hpp >>>> >>>> >>>> I was wondering if it would be better to explicitally set the attr >>>> type to PTHREAD_MUTEX_NORMAL to insure consistency with AIX and Linux >>>> (on FreeBSD it is PTHREAD_MUTEX_ERRORCHECK by default). >>>> >>>> What do you think ? >>>> >>>> Thanks in advance. >>>> >>>> Kindest regards. >>>> From alexander.harlap at oracle.com Mon Jan 9 19:31:36 2017 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Mon, 9 Jan 2017 14:31:36 -0500 Subject: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated In-Reply-To: <2390dd5a-4324-8fa5-833e-aa3761d5d9b9@oracle.com> References: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> <330cdafb-5cd2-c55f-3558-89bfc91e5757@oracle.com> <497ae298-147a-b649-954e-30629b69b043@oracle.com> <2390dd5a-4324-8fa5-833e-aa3761d5d9b9@oracle.com> Message-ID: Here is change with consistent use of assert: http://cr.openjdk.java.net/~aharlap/8140588/webrev.02/ Alex On 1/9/2017 4:23 AM, Per Liden wrote: > Hi Alex, > > On 2017-01-06 17:35, Alexander Harlap wrote: >> Change at http://cr.openjdk.java.net/~aharlap/8140588/webrev.01/ > > The x86 and Sparc parts looks good, I'll let others comments on the > other ports. However, a few comments: > > > c1_Runtime1_ppc.cpp > ------------------- > 764 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, > "Assumption"); > > Please change this to be an assert() instead of a guarantee(). > > > c1_Runtime1_s390.cpp > -------------------- > 806 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, > "Assumption"); > > Same here. > > c1_Runtime1_sparc.cpp > --------------------- > 873 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, > 874 "Assumption"); > > And same here. > > > cheers, > /Per > >> >> accommodates comments from Per, Kim and Martin >> >> Yes, there is no measurable performance difference. >> >> So make change simpler. >> >> Alex >> >> On 1/5/2017 7:41 AM, Per Liden wrote: >>> Hi, >>> >>> On 2017-01-05 00:36, Kim Barrett wrote: >>>>> On Dec 24, 2016, at 10:04 AM, Alexander Harlap >>>>> wrote: >>>>> >>>>> Please review change for JDK-8140588 - Internal Error: >>>>> gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: >>>>> queues are empty when activated >>>>> >>>>> Change is located at >>>>> http://cr.openjdk.java.net/~aharlap/8140588/webrev.00/ >>>>> >>>>> It implements Per Liden fix for rechecking value of marking in >>>>> progress value inside C1 g1_pre_barrier code. >>>>> >>>>> Also here is optimization described by Thomas Schatzl - do recheck >>>>> only if patching involved. >>>> >>>> I wonder whether it is worth the effort of having distinct stubs for >>>> the two cases, or just unconditionally perform the recheck in the >>>> existing stub. Thomas said he found no performance issue with the >>>> simpler version. >>> >>> Agree. If there's no measurable performance gain by having two stubs >>> (given the other things we do in this path I'd be surprised if there >>> were) I'd vote for keeping it simple here and have one stub. That >>> would also "fix" Kim's last comment below. >>> >>> cheers, >>> Per >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> Throughout, copyright dates need updating. >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> cpu/aarch64/vm/c1_CodeStubs_aarch64.cpp >>>> 373 Runtime1::StubID id = patch_code() == lir_patch_none ? >>>> Runtime1::g1_pre_barrier_slow_id : >>>> Runtime1::g1_pre_barrier_slow_with_recheck_id; >>>> >>>> Assuming we stay with the pair of stubs, this ought to be packaged up >>>> as a helper function. >>>> >>>> Other occurrences: >>>> src/cpu/arm/vm/c1_CodeStubs_arm.cpp >>>> src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp >>>> src/cpu/s390/vm/c1_CodeStubs_s390.cpp >>>> src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp >>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >>>> >> From vladimir.kozlov at oracle.com Tue Jan 10 01:02:58 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 9 Jan 2017 17:02:58 -0800 Subject: RFR(S): 8171266: PPC64: Add support to -XX:RTMSpinLoopCount=0 In-Reply-To: <586EAA01.8060207@linux.vnet.ibm.com> References: <58530522.3030102@linux.vnet.ibm.com> <58666849.1020700@linux.vnet.ibm.com> <586DA958.3020104@linux.vnet.ibm.com> <586EAA01.8060207@linux.vnet.ibm.com> Message-ID: <5df0a239-d242-5853-0f47-2fd2e6d8afcb@oracle.com> I looked on linux test machines we run and they don't RTM :( Or few machines with RTM are not used to run these particular tests. Vladimir On 1/5/17 12:18 PM, Gustavo Romero wrote: > Hi Volker, > > Please see my comments inline. > > On 05-01-2017 11:18, Volker Simonis wrote: >> Hi Gustavo, >> >> I finally got a Power machine which supports RTM. > > Good :) > > >> So before pushing this change, I thought I run the RTM jtreg tests. >> >> Obviously your change improves the situation by preventing crashes >> because of RTMSpinLoopCount=0. But I still get 10 failures when >> running the RTM tests (test/compiler/rtm) on linux/ppc64: > > Yes, before my change TestRTMSpinLoopCount.java was just crashing the JVM. But > after that the test is not passing yet. It looks like it is expecting fewer > abortions and I'm wondering if it's because on Power the transaction is aborted > if a signal is caught in the middle (the JVM uses signal quite frequently...), > thus an intrinsic property of the JVM on Power. I'll continue the investigation. > > >> >> compiler/rtm/locking/TestRTMAbortRatio.java >> Failed. Execution failed: `main' >> threw exception: java.lang.RuntimeException: Expected to get exit >> value of [0] >> compiler/rtm/locking/TestRTMAbortThreshold.java >> Failed. Execution failed: `main' >> threw exception: java.lang.RuntimeException: Expected that method with >> rtm lock elision was deoptimized after 1 lock attempts: expected 10000 >> to equal 1 >> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java >> Failed. Execution failed: `main' >> threw exception: java.lang.RuntimeException: Two uncommon traps with >> reason rtm_state_change should be fired.: expected 0 to equal 2 >> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java >> Failed. Execution failed: `main' >> threw exception: java.lang.RuntimeException: Expected to get only one >> deoptimization due to rtm state change: expected 0 to equal 1 >> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java >> Failed. Execution failed: `main' >> threw exception: java.lang.RuntimeException: Expected to get only one >> deoptimization due to rtm state change: expected 0 to equal 1 >> compiler/rtm/locking/TestRTMLockingCalculationDelay.java >> Failed. Execution failed: `main' >> threw exception: java.lang.RuntimeException: At least one >> deoptimization due to rtm_state_chage is expected: expected 0 > 0 >> compiler/rtm/locking/TestRTMLockingThreshold.java >> Failed. Execution failed: `main' >> threw exception: java.lang.RuntimeException: VM output should contain >> two RTM locking statistics entries.: expected 1 to equal 2 >> compiler/rtm/locking/TestRTMRetryCount.java >> Failed. Execution failed: `main' >> threw exception: java.lang.RuntimeException: It is expected to get 2 >> aborts: expected 3 to equal 2 >> compiler/rtm/locking/TestRTMSpinLoopCount.java >> Failed. Execution failed: `main' >> threw exception: java.lang.RuntimeException: Total aborts count (2001) >> should be less or equal to 1001: expected that 2001 <= 1001 >> compiler/rtm/locking/TestUseRTMXendForLockBusy.java >> Failed. Execution failed: `main' >> threw exception: java.lang.RuntimeException: VM output should contain >> exactly one rtm locking statistics entry for method >> compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1 >> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java >> Failed. Execution failed: `main' >> threw exception: java.lang.RuntimeException: RTM locking statistics >> should contain non zero total aborts count: expected 0 > 0 >> >> On the other hand, the situation on linux/x86_64 seems similar (with >> 7-9 failures depending on the run): >> >> compiler/rtm/locking/TestRTMAbortThreshold.java >> Failed. Execution failed: >> `main' threw exception: java.lang.RuntimeException: Expected that >> method with rtm lock elision was deoptimized after 1 lock attempts: >> expected 10000 to equal 1 >> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java >> Failed. Execution failed: >> `main' threw exception: java.lang.RuntimeException: Two uncommon traps >> with reason rtm_state_change should be fired.: expected 0 to equal 2 >> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java >> Failed. Execution failed: >> `main' threw exception: java.lang.RuntimeException: Expected to get >> only one deoptimization due to rtm state change: expected 0 to equal 1 >> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java >> Failed. Execution failed: >> `main' threw exception: java.lang.RuntimeException: After >> LockThreshold was reached, method should be recompiled with rtm lock >> eliding.: expected null to not equal null >> compiler/rtm/locking/TestRTMLockingCalculationDelay.java >> Failed. Execution failed: >> `main' threw exception: java.lang.RuntimeException: At least one >> deoptimization due to rtm_state_chage is expected: expected 0 > 0 >> compiler/rtm/locking/TestRTMLockingThreshold.java >> Failed. Execution failed: >> `main' threw exception: java.lang.RuntimeException: VM output should >> contain two RTM locking statistics entries.: expected 1 to equal 2 >> compiler/rtm/locking/TestRTMTotalCountIncrRate.java >> Failed. Execution failed: >> `main' threw exception: java.lang.RuntimeException: VM output should >> contain exactly one RTM locking statistics entry for method >> compiler.rtm.locking.TestRTMTotalCountIncrRate$Test::lock: expected 0 >> to equal 1 >> compiler/rtm/locking/TestUseRTMXendForLockBusy.java >> Failed. Execution failed: >> `main' threw exception: java.lang.RuntimeException: VM output should >> contain exactly one rtm locking statistics entry for method >> compiler.testlibrary.rtm.BusyLock::test: expected 0 to equal 1 >> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java >> Failed. Execution failed: >> `main' threw exception: java.lang.RuntimeException: RTM locking >> statistics should contain non zero total aborts count: expected 0 > 0 >> >> Are these the same results you are seeing as well? > > I don't have access to a x64 machine w/ RTM at the moment, but IIRC some tests > are failing as well, but fewer in comparison to Power. Much unfortunately I > don't know when I'll be able to have a x64 machine available again... > > I've got the following tests status on a POWER8 machine: > > FAILED: compiler/rtm/locking/TestRTMAbortThreshold.java > FAILED: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java > FAILED: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java > FAILED: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java > FAILED: compiler/rtm/locking/TestRTMLockingCalculationDelay.java > FAILED: compiler/rtm/locking/TestRTMLockingThreshold.java > FAILED: compiler/rtm/locking/TestRTMRetryCount.java > FAILED: compiler/rtm/locking/TestRTMSpinLoopCount.java > FAILED: compiler/rtm/locking/TestUseRTMXendForLockBusy.java > FAILED: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java > Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnUnsupportedConfig.java > Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestRTMAbortRatioOptionOnUnsupportedConfig.java > Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java > Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java > Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java > Passed: compiler/rtm/cli/TestRTMRetryCountOption.java > Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java > Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnUnsupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnUnsupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnUnsupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedCPU.java > Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedVM.java > Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java > Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java > Passed: compiler/rtm/locking/TestRTMAbortRatio.java > Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java > Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java > Passed: compiler/rtm/locking/TestUseRTMDeopt.java > Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java > Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java > Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java > Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java > Test results: passed: 28; failed: 10 > > Hence similar to what you've reported, except for TestRTMAbortRatio.java > which passed [1], although I would expect more aborts than what was > reported. > > >> The JDK 9 Early Access Build Test Results site at >> http://download.java.net/openjdk/testresults/9/testresults.html >> reports these tests as passed, but I think that may be because they >> run on hardware which doesn't support RTM? > > Exactly. I discussed that briefly with David here [2] when fixing [3] > and I guess that's the reason for the regression 8171236 [4] not being > detected firstly at the Oracle side. > > > Regards, > Gustavo > > [1] http://paste.fedoraproject.org/520455/83645916/raw/ > [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024361.html > [3] https://bugs.openjdk.java.net/browse/JDK-8164987 > [4] https://bugs.openjdk.java.net/browse/JDK-8171236 > > >> @Vladimir, David: do you regularly run the RTM tests on linux/x86_64 >> and do they really all pass in your environment? (I've tested with >> Linux 3.10 on a "Intel(R) Xeon(R) CPU E7-4820 v3" and with Windows 7 >> on a "Intel(R) Core(TM) i5-4300U" which according to /proc/cpuinfo and >> coreinfo.exe both support RTM). >> >> Thank you and best regards, >> Volker >> >> On Thu, Jan 5, 2017 at 3:03 AM, Gustavo Romero >> wrote: >>> Hi >>> >>> On 03-01-2017 16:08, Volker Simonis wrote: >>>> Hi David, >>>> >>>> thanks for looking at this change. >>>> As this is ppc64-only, I'll sponsor it. >>>> >>>> Regards, >>>> Volker >>> >>> David, thanks for reviewing the change. >>> >>> Volker, thanks for sponsoring it. >>> >>> Vladimir, thanks for setting the proper priority and fix version tag. >>> >>> >>> Regards, >>> Gustavo >>> >>>> On Tue, Jan 3, 2017 at 12:53 AM, David Holmes wrote: >>>>> Seems fine. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>> On 30/12/2016 11:59 PM, Gustavo Romero wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> That change is already reviewed by Martin on the ppc-aix-port ML [1], but >>>>>> since >>>>>> I understand that a formal review has to be submitted to the hs ML I >>>>>> resent it. >>>>>> >>>>>> Is any thing missing on my side? >>>>>> >>>>>> Thank you. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Gustavo >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-December/002809.html >>>>>> >>>>>> On 15-12-2016 19:03, Gustavo Romero wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Could the following change be reviewed please? >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~gromero/8171266/0/ >>>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8171266 >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Gustavo >>>>>>> >>>>>> >>>>> >>>> >>> >> > From per.liden at oracle.com Tue Jan 10 10:04:00 2017 From: per.liden at oracle.com (Per Liden) Date: Tue, 10 Jan 2017 11:04:00 +0100 Subject: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated In-Reply-To: References: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> <330cdafb-5cd2-c55f-3558-89bfc91e5757@oracle.com> <497ae298-147a-b649-954e-30629b69b043@oracle.com> <2390dd5a-4324-8fa5-833e-aa3761d5d9b9@oracle.com> Message-ID: <636bd7dc-c299-e8c5-5436-ea59247da5e7@oracle.com> Hi Alex, Looks good, just two nitpicks for the sake of uniformity across the platforms: c1_Runtime1_sparc.cpp --------------------- 873 assert(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, 874 "Assumption"); Indentation looks off here, but please make this one line instead, like the other platforms. c1_Runtime1_arm.cpp ------------------- 565 assert(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "adjust this code"); Please say "Assumption", like the other platforms. If you fix these I don't need to see a new webrev. cheers, Per On 2017-01-09 20:31, Alexander Harlap wrote: > Here is change with consistent use of assert: > > http://cr.openjdk.java.net/~aharlap/8140588/webrev.02/ > > > Alex > > > On 1/9/2017 4:23 AM, Per Liden wrote: >> Hi Alex, >> >> On 2017-01-06 17:35, Alexander Harlap wrote: >>> Change at http://cr.openjdk.java.net/~aharlap/8140588/webrev.01/ >> >> The x86 and Sparc parts looks good, I'll let others comments on the >> other ports. However, a few comments: >> >> >> c1_Runtime1_ppc.cpp >> ------------------- >> 764 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, >> "Assumption"); >> >> Please change this to be an assert() instead of a guarantee(). >> >> >> c1_Runtime1_s390.cpp >> -------------------- >> 806 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, >> "Assumption"); >> >> Same here. >> >> c1_Runtime1_sparc.cpp >> --------------------- >> 873 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, >> 874 "Assumption"); >> >> And same here. >> >> >> cheers, >> /Per >> >>> >>> accommodates comments from Per, Kim and Martin >>> >>> Yes, there is no measurable performance difference. >>> >>> So make change simpler. >>> >>> Alex >>> >>> On 1/5/2017 7:41 AM, Per Liden wrote: >>>> Hi, >>>> >>>> On 2017-01-05 00:36, Kim Barrett wrote: >>>>>> On Dec 24, 2016, at 10:04 AM, Alexander Harlap >>>>>> wrote: >>>>>> >>>>>> Please review change for JDK-8140588 - Internal Error: >>>>>> gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: >>>>>> queues are empty when activated >>>>>> >>>>>> Change is located at >>>>>> http://cr.openjdk.java.net/~aharlap/8140588/webrev.00/ >>>>>> >>>>>> It implements Per Liden fix for rechecking value of marking in >>>>>> progress value inside C1 g1_pre_barrier code. >>>>>> >>>>>> Also here is optimization described by Thomas Schatzl - do recheck >>>>>> only if patching involved. >>>>> >>>>> I wonder whether it is worth the effort of having distinct stubs for >>>>> the two cases, or just unconditionally perform the recheck in the >>>>> existing stub. Thomas said he found no performance issue with the >>>>> simpler version. >>>> >>>> Agree. If there's no measurable performance gain by having two stubs >>>> (given the other things we do in this path I'd be surprised if there >>>> were) I'd vote for keeping it simple here and have one stub. That >>>> would also "fix" Kim's last comment below. >>>> >>>> cheers, >>>> Per >>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> Throughout, copyright dates need updating. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> cpu/aarch64/vm/c1_CodeStubs_aarch64.cpp >>>>> 373 Runtime1::StubID id = patch_code() == lir_patch_none ? >>>>> Runtime1::g1_pre_barrier_slow_id : >>>>> Runtime1::g1_pre_barrier_slow_with_recheck_id; >>>>> >>>>> Assuming we stay with the pair of stubs, this ought to be packaged up >>>>> as a helper function. >>>>> >>>>> Other occurrences: >>>>> src/cpu/arm/vm/c1_CodeStubs_arm.cpp >>>>> src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp >>>>> src/cpu/s390/vm/c1_CodeStubs_s390.cpp >>>>> src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp >>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>> > From alexander.harlap at oracle.com Tue Jan 10 18:45:04 2017 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Tue, 10 Jan 2017 13:45:04 -0500 Subject: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated In-Reply-To: <636bd7dc-c299-e8c5-5436-ea59247da5e7@oracle.com> References: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> <330cdafb-5cd2-c55f-3558-89bfc91e5757@oracle.com> <497ae298-147a-b649-954e-30629b69b043@oracle.com> <2390dd5a-4324-8fa5-833e-aa3761d5d9b9@oracle.com> <636bd7dc-c299-e8c5-5436-ea59247da5e7@oracle.com> Message-ID: I accommodated latest comment from Per. Should I wait for more reviews? Alex On 1/10/2017 5:04 AM, Per Liden wrote: > Hi Alex, > > Looks good, just two nitpicks for the sake of uniformity across the > platforms: > > c1_Runtime1_sparc.cpp > --------------------- > 873 assert(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, > 874 "Assumption"); > > Indentation looks off here, but please make this one line instead, > like the other platforms. > > > c1_Runtime1_arm.cpp > ------------------- > 565 assert(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, > "adjust this code"); > > Please say "Assumption", like the other platforms. > > > If you fix these I don't need to see a new webrev. > > cheers, > Per > > > On 2017-01-09 20:31, Alexander Harlap wrote: >> Here is change with consistent use of assert: >> >> http://cr.openjdk.java.net/~aharlap/8140588/webrev.02/ >> >> >> Alex >> >> >> On 1/9/2017 4:23 AM, Per Liden wrote: >>> Hi Alex, >>> >>> On 2017-01-06 17:35, Alexander Harlap wrote: >>>> Change at http://cr.openjdk.java.net/~aharlap/8140588/webrev.01/ >>> >>> The x86 and Sparc parts looks good, I'll let others comments on the >>> other ports. However, a few comments: >>> >>> >>> c1_Runtime1_ppc.cpp >>> ------------------- >>> 764 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, >>> "Assumption"); >>> >>> Please change this to be an assert() instead of a guarantee(). >>> >>> >>> c1_Runtime1_s390.cpp >>> -------------------- >>> 806 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, >>> "Assumption"); >>> >>> Same here. >>> >>> c1_Runtime1_sparc.cpp >>> --------------------- >>> 873 guarantee(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, >>> 874 "Assumption"); >>> >>> And same here. >>> >>> >>> cheers, >>> /Per >>> >>>> >>>> accommodates comments from Per, Kim and Martin >>>> >>>> Yes, there is no measurable performance difference. >>>> >>>> So make change simpler. >>>> >>>> Alex >>>> >>>> On 1/5/2017 7:41 AM, Per Liden wrote: >>>>> Hi, >>>>> >>>>> On 2017-01-05 00:36, Kim Barrett wrote: >>>>>>> On Dec 24, 2016, at 10:04 AM, Alexander Harlap >>>>>>> wrote: >>>>>>> >>>>>>> Please review change for JDK-8140588 - Internal Error: >>>>>>> gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: >>>>>>> queues are empty when activated >>>>>>> >>>>>>> Change is located at >>>>>>> http://cr.openjdk.java.net/~aharlap/8140588/webrev.00/ >>>>>>> >>>>>>> It implements Per Liden fix for rechecking value of marking in >>>>>>> progress value inside C1 g1_pre_barrier code. >>>>>>> >>>>>>> Also here is optimization described by Thomas Schatzl - do recheck >>>>>>> only if patching involved. >>>>>> >>>>>> I wonder whether it is worth the effort of having distinct stubs for >>>>>> the two cases, or just unconditionally perform the recheck in the >>>>>> existing stub. Thomas said he found no performance issue with the >>>>>> simpler version. >>>>> >>>>> Agree. If there's no measurable performance gain by having two stubs >>>>> (given the other things we do in this path I'd be surprised if there >>>>> were) I'd vote for keeping it simple here and have one stub. That >>>>> would also "fix" Kim's last comment below. >>>>> >>>>> cheers, >>>>> Per >>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>> Throughout, copyright dates need updating. >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>> cpu/aarch64/vm/c1_CodeStubs_aarch64.cpp >>>>>> 373 Runtime1::StubID id = patch_code() == lir_patch_none ? >>>>>> Runtime1::g1_pre_barrier_slow_id : >>>>>> Runtime1::g1_pre_barrier_slow_with_recheck_id; >>>>>> >>>>>> Assuming we stay with the pair of stubs, this ought to be >>>>>> packaged up >>>>>> as a helper function. >>>>>> >>>>>> Other occurrences: >>>>>> src/cpu/arm/vm/c1_CodeStubs_arm.cpp >>>>>> src/cpu/ppc/vm/c1_CodeStubs_ppc.cpp >>>>>> src/cpu/s390/vm/c1_CodeStubs_s390.cpp >>>>>> src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp >>>>>> src/cpu/x86/vm/c1_CodeStubs_x86.cpp >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> From kim.barrett at oracle.com Thu Jan 12 02:25:44 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 11 Jan 2017 21:25:44 -0500 Subject: Request for review JDK-8140588 - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated In-Reply-To: References: <69402E6E-97E5-416D-930A-92435638DE3C@oracle.com> <330cdafb-5cd2-c55f-3558-89bfc91e5757@oracle.com> <497ae298-147a-b649-954e-30629b69b043@oracle.com> <2390dd5a-4324-8fa5-833e-aa3761d5d9b9@oracle.com> Message-ID: <7C5D4034-C8A2-48C4-8403-E4D7CBC085E4@oracle.com> > On Jan 9, 2017, at 2:31 PM, Alexander Harlap wrote: > > Here is change with consistent use of assert: > > http://cr.openjdk.java.net/~aharlap/8140588/webrev.02/ Looks good. From thomas.stuefe at gmail.com Thu Jan 12 13:04:03 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2017 14:04:03 +0100 Subject: RFR(xs): 8172712: configure should check that grep handles empty pattern correctly Message-ID: Dear all, please take a look at this fix. This should prevent configure from using a grep which is not able to handle pattern lists with empty patterns. Bug: https://bugs.openjdk.java.net/browse/JDK-8172712 webrevs: http://cr.openjdk.java.net/~stuefe/webrevs/8172712-configure-should-check-that-grep-handles-empty-pattern-correctly/webrev.00/webrev/ Background: https://bugs.openjdk.java.net/browse/JDK-8172579 was a build error caused by a buggy grep (on AIX) and the easiest way to work around that bug would be to use the GNU version of grep. It was suggested in the orginal mail thread ( http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018495.html) to check this in configure. This change implements this suggestion and checks if grep behaves correctly. Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Thu Jan 12 13:36:37 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 12 Jan 2017 14:36:37 +0100 Subject: RFR(xs): 8172712: configure should check that grep handles empty pattern correctly In-Reply-To: References: Message-ID: Looks good to me. Since the closed generated-configure needs to be regenerated, I'll sponsor and push this patch. /Magnus On 2017-01-12 14:04, Thomas St?fe wrote: > Dear all, > > please take a look at this fix. This should prevent configure from using a > grep which is not able to handle pattern lists with empty patterns. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8172712 > > webrevs: > http://cr.openjdk.java.net/~stuefe/webrevs/8172712-configure-should-check-that-grep-handles-empty-pattern-correctly/webrev.00/webrev/ > > Background: > > https://bugs.openjdk.java.net/browse/JDK-8172579 was a build error caused > by a buggy grep (on AIX) and the easiest way to work around that bug would > be to use the GNU version of grep. It was suggested in the orginal mail > thread ( > http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018495.html) > to check this in configure. > > This change implements this suggestion and checks if grep behaves correctly. > > Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Jan 12 13:59:25 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2017 14:59:25 +0100 Subject: RFR(xs): 8172712: configure should check that grep handles empty pattern correctly In-Reply-To: References: Message-ID: Thank you Magnus! Patch is tested on AIX, Solaris, Linux and Windows, no issues. Kind Regards, Thomas On Thu, Jan 12, 2017 at 2:36 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > Looks good to me. > > Since the closed generated-configure needs to be regenerated, I'll sponsor > and push this patch. > > /Magnus > > > On 2017-01-12 14:04, Thomas St?fe wrote: > > Dear all, > > please take a look at this fix. This should prevent configure from using a > grep which is not able to handle pattern lists with empty patterns. > > Bug:https://bugs.openjdk.java.net/browse/JDK-8172712 > > webrevs:http://cr.openjdk.java.net/~stuefe/webrevs/8172712-configure-should-check-that-grep-handles-empty-pattern-correctly/webrev.00/webrev/ > > Background: > https://bugs.openjdk.java.net/browse/JDK-8172579 was a build error caused > by a buggy grep (on AIX) and the easiest way to work around that bug would > be to use the GNU version of grep. It was suggested in the orginal mail > thread (http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018495.html) > to check this in configure. > > This change implements this suggestion and checks if grep behaves correctly. > > Kind Regards, Thomas > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Thu Jan 12 17:29:59 2017 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 12 Jan 2017 09:29:59 -0800 Subject: RFR(xs): 8172712: configure should check that grep handles empty pattern correctly In-Reply-To: References: Message-ID: I also ran into this problem a couple of weeks ago with some other "misbehaving? grep. Thanks for adding this check! Cheers, Mikael > On Jan 12, 2017, at 5:04 AM, Thomas St?fe wrote: > > Dear all, > > please take a look at this fix. This should prevent configure from using a grep which is not able to handle pattern lists with empty patterns. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8172712 > > webrevs: > http://cr.openjdk.java.net/~stuefe/webrevs/8172712-configure-should-check-that-grep-handles-empty-pattern-correctly/webrev.00/webrev/ > > Background: > > https://bugs.openjdk.java.net/browse/JDK-8172579 was a build error caused by a buggy grep (on AIX) and the easiest way to work around that bug would be to use the GNU version of grep. It was suggested in the orginal mail thread (http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018495.html ) to check this in configure. > > This change implements this suggestion and checks if grep behaves correctly. > > Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Jan 12 19:54:21 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Jan 2017 11:54:21 -0800 Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now In-Reply-To: <3fa78b65-93cc-1c9c-d39c-e7eafa82ce20@oracle.com> References: <586BF343.7040608@oracle.com> <3fa78b65-93cc-1c9c-d39c-e7eafa82ce20@oracle.com> Message-ID: Hi Volker, The general internal Oracle consensus after discussions was that we may allow only very small high priority RFEs for external ports code. It should use FC extension process we used before (labels and request comments) and approved case by case. And this is for limited time only - we all want to have jdk 9 stable on all platforms when it is released as Andrew said. And definitely not if changes touch a common code. If you need then split it into separate changes as bug if possible - I assume you can have cases when you need to add #ifdef into existing tests, for example. Also I would like again to enforce priority limit to P1-P3. If you think a fix should go into jdk 9 it should have high priority. Otherwise it can wait jdk 10. Regards, Vladimir On 1/4/17 11:30 AM, Vladimir Kozlov wrote: > On 1/4/17 2:23 AM, Volker Simonis wrote: >> On Tue, Jan 3, 2017 at 7:53 PM, Vladimir Kozlov >> wrote: >>> We are currently in "Rampdown" phase for jdk 9 which allows only >>> P1-P3 bugs >>> fixes. Note for Hotspot it started week ago. >>> >>> http://openjdk.java.net/projects/jdk9/ >>> >>> Please, make sure bugs you are planning to fix have P1-P3 priority >>> and "fix >>> version" is jdk 9. I just updated JDK-8171266 [1] for that. >>> >> >> Thanks a lot Vladimir. I'll push it today. >> >> Just for clarification: do the "Rampdown phase rules" also apply to >> non-Oracle platforms like ppc64 or s390x? In the past, we were allowed >> to push non P1-P3 bugs or enhancements even in later phases as long as >> they didn't touch shared code. Is this still allowed or do we now have >> to strictly conform to the process even for ppc64/s390x-only changes? > > JDK 9 schedule was approved by all, including Java Community outside > Oracle. > > I looked on original Mark's email about "JDK 9 Rampdown Phase 1" and > there were no exceptions listed: > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html > > But I understand that JDK 9 schedule reflects the process inside Oracle > and may not be applied directly to your process. > I will try to clarify situation with your ports regarding JDK 9 schedule > and inform you. > > Regards, > Vladimir > >> >> Thanks a lot and best regards, >> Volker >> >>> You can rise priority to P3 if you think a bug must be fixed in jdk 9 or >>> defer it to jdk 10 - set "fix version" to 10. >>> >>> I see 3 aarch64 P4-P5 bugs which should be updated accordingly: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8170101 >>> https://bugs.openjdk.java.net/browse/JDK-8170103 >>> https://bugs.openjdk.java.net/browse/JDK-8165058 >>> >>> Thanks, >>> Vladimir >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8171266 >>> "PPC64: Add support to -XX:RTMSpinLoopCount=0" >>> From thomas.stuefe at gmail.com Thu Jan 12 20:02:37 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Jan 2017 20:02:37 +0000 Subject: RFR(xs): 8172712: configure should check that grep handles empty pattern correctly In-Reply-To: References: Message-ID: Thank you! On Thu, 12 Jan 2017 at 18:30, Mikael Vidstedt wrote: > > I also ran into this problem a couple of weeks ago with some other > "misbehaving? grep. Thanks for adding this check! > > Cheers, > Mikael > > > On Jan 12, 2017, at 5:04 AM, Thomas St?fe wrote: > > Dear all, > > please take a look at this fix. This should prevent configure from using a > grep which is not able to handle pattern lists with empty patterns. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8172712 > > webrevs: > > http://cr.openjdk.java.net/~stuefe/webrevs/8172712-configure-should-check-that-grep-handles-empty-pattern-correctly/webrev.00/webrev/ > > Background: > > https://bugs.openjdk.java.net/browse/JDK-8172579 was a build error caused > by a buggy grep (on AIX) and the easiest way to work around that bug would > be to use the GNU version of grep. It was suggested in the orginal mail > thread ( > http://mail.openjdk.java.net/pipermail/build-dev/2017-January/018495.html) > to check this in configure. > > This change implements this suggestion and checks if grep behaves > correctly. > > Kind Regards, Thomas > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Jan 13 08:18:12 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Jan 2017 09:18:12 +0100 Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now In-Reply-To: References: <586BF343.7040608@oracle.com> <3fa78b65-93cc-1c9c-d39c-e7eafa82ce20@oracle.com> Message-ID: OK, got it. Thanks for the clarification, Volker On Thu, Jan 12, 2017 at 8:54 PM, Vladimir Kozlov wrote: > Hi Volker, > > The general internal Oracle consensus after discussions was that we may > allow only very small high priority RFEs for external ports code. It should > use FC extension process we used before (labels and request comments) and > approved case by case. And this is for limited time only - we all want to > have jdk 9 stable on all platforms when it is released as Andrew said. > > And definitely not if changes touch a common code. If you need then split it > into separate changes as bug if possible - I assume you can have cases when > you need to add #ifdef into existing tests, for example. > > Also I would like again to enforce priority limit to P1-P3. If you think a > fix should go into jdk 9 it should have high priority. Otherwise it can wait > jdk 10. > > Regards, > Vladimir > > > On 1/4/17 11:30 AM, Vladimir Kozlov wrote: >> >> On 1/4/17 2:23 AM, Volker Simonis wrote: >>> >>> On Tue, Jan 3, 2017 at 7:53 PM, Vladimir Kozlov >>> wrote: >>>> >>>> We are currently in "Rampdown" phase for jdk 9 which allows only >>>> P1-P3 bugs >>>> fixes. Note for Hotspot it started week ago. >>>> >>>> http://openjdk.java.net/projects/jdk9/ >>>> >>>> Please, make sure bugs you are planning to fix have P1-P3 priority >>>> and "fix >>>> version" is jdk 9. I just updated JDK-8171266 [1] for that. >>>> >>> >>> Thanks a lot Vladimir. I'll push it today. >>> >>> Just for clarification: do the "Rampdown phase rules" also apply to >>> non-Oracle platforms like ppc64 or s390x? In the past, we were allowed >>> to push non P1-P3 bugs or enhancements even in later phases as long as >>> they didn't touch shared code. Is this still allowed or do we now have >>> to strictly conform to the process even for ppc64/s390x-only changes? >> >> >> JDK 9 schedule was approved by all, including Java Community outside >> Oracle. >> >> I looked on original Mark's email about "JDK 9 Rampdown Phase 1" and >> there were no exceptions listed: >> >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html >> >> But I understand that JDK 9 schedule reflects the process inside Oracle >> and may not be applied directly to your process. >> I will try to clarify situation with your ports regarding JDK 9 schedule >> and inform you. >> >> Regards, >> Vladimir >> >>> >>> Thanks a lot and best regards, >>> Volker >>> >>>> You can rise priority to P3 if you think a bug must be fixed in jdk 9 or >>>> defer it to jdk 10 - set "fix version" to 10. >>>> >>>> I see 3 aarch64 P4-P5 bugs which should be updated accordingly: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8170101 >>>> https://bugs.openjdk.java.net/browse/JDK-8170103 >>>> https://bugs.openjdk.java.net/browse/JDK-8165058 >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8171266 >>>> "PPC64: Add support to -XX:RTMSpinLoopCount=0" >>>> > From thomas.stuefe at gmail.com Wed Jan 18 10:24:42 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Jan 2017 11:24:42 +0100 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER Message-ID: Dear all, please review this bugfix for AIX. Issue https://bugs.openjdk.java.net/browse/JDK-8172964 Webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX-SIGDANGER/webrev/ In short, this removes the handling for SIGDANGER from the hotspot. Handling SIGDANGER has almost no benefit for us but interferes with AIX OOM killing mechanism, making effects of ow-paging-space situations on AIX more severe than they would need to be. For more details, please see the bug report. Thanks & Kind Regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Jan 18 16:58:52 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 18 Jan 2017 17:58:52 +0100 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER In-Reply-To: References: Message-ID: Hi Thomas, aside from the copyright notices which have to be updated to 2017 now (no need for a new webrev however) your changes look good. Thanks for fixing, Volker On Wed, Jan 18, 2017 at 11:24 AM, Thomas St?fe wrote: > Dear all, > > please review this bugfix for AIX. > > Issue > https://bugs.openjdk.java.net/browse/JDK-8172964 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX-SIGDANGER/webrev/ > > In short, this removes the handling for SIGDANGER from the hotspot. > Handling SIGDANGER has almost no benefit for us but interferes with AIX OOM > killing mechanism, making effects of ow-paging-space situations on AIX more > severe than they would need to be. > > For more details, please see the bug report. > > Thanks & Kind Regards, > > Thomas From thomas.stuefe at gmail.com Wed Jan 18 17:06:35 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 18 Jan 2017 17:06:35 +0000 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER In-Reply-To: References: Message-ID: Thank you, Volker! On Wed, 18 Jan 2017 at 17:58, Volker Simonis wrote: > Hi Thomas, > > > > aside from the copyright notices which have to be updated to 2017 now > > (no need for a new webrev however) your changes look good. > > > > Thanks for fixing, > > Volker > > > > > > On Wed, Jan 18, 2017 at 11:24 AM, Thomas St?fe > wrote: > > > Dear all, > > > > > > please review this bugfix for AIX. > > > > > > Issue > > > https://bugs.openjdk.java.net/browse/JDK-8172964 > > > Webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX-SIGDANGER/webrev/ > > > > > > In short, this removes the handling for SIGDANGER from the hotspot. > > > Handling SIGDANGER has almost no benefit for us but interferes with AIX > OOM > > > killing mechanism, making effects of ow-paging-space situations on AIX > more > > > severe than they would need to be. > > > > > > For more details, please see the bug report. > > > > > > Thanks & Kind Regards, > > > > > > Thomas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Thu Jan 19 05:31:01 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 19 Jan 2017 00:31:01 -0500 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles Message-ID: Please review this change to jweak to support G1. The problem being addressed is that, when using G1, dereferencing a jweak must ensure the obtained referent is ensured live, just as for other weak reference types. This has always been a requirement, and failure to do so appears to be a since-day1 G1 bug. There are two categories of places that need to address this issue: JNIHandles::resolve and friends, and returning a jobject from native code to Java. In both of these places the jobject whose contained oop is being extracted might really be a jweak. jweak is representationally indistinguishable from jobject; jweak is just a typedef for jobject. The documentation says a jweak can be used anywhere a jobject is permitted, making that type equivalence necessary for a C API. (A C++ API might be able to have distinct types via inheritance, though would still need a method for distinguishing them at runtime. But since JNI is a C API...). The basic approach being taken is to "tag" jweaks by setting the low order bit (recall that jweak == jobject == _jobject*), in order to distinguish them from non-jweak jobjects. This tagging is only being done when the selected GC needs the distinction, e.g. G1. This gives us a representational difference between jobject and jweak on which to base the different behavior, hiding that distinction behind the existing API. JNIHandles::resolve and friends are changed to unconditionally strip off any potential weak tag when translating from jobject to to oop*. That's cheaper than testing for the conditional use of tagging and then stripping. Also stripped when deleting JNI handles. TemplateInterpreterGenerator::generate_native_entry and SharedRuntime::generate_native_wrapper are changed to conditionally emit code to apply the G1 pre-barrier to the value obtained from a jobject result, when the result is tagged as a jweak, which only occurs when using G1. For arm32/arm64, this required moving the g1_write_barrier_pre definitions from InterpreterMacroAssembler to MacroAssembler. Also moved g1_write_barrier_post, for consistency. Note: I've not tested the aarch64 changes; I'll need someone with access to that platform to test. Note: I've not implemented this change for ppc or s390; I'll need someone else to deal with those platforms. (It's been a very long time since I wrote any ppc assembly code, and I've never seen an s390.) Note: I've done a minimal change for zero. Code elsewhere suggests zero doesn't support G1, and I followed that. And finally, JNIHandles::make_weak_global conditionally tags the result. CR: https://bugs.openjdk.java.net/browse/JDK-8166188 Webrev: http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/ In addition to the above webrev, I've also included separate webrevs for a test of this change, and for a whitebox extension needed for that test. The whitebox extension is my in-progress work on JDK-8169517, which is an enhancement targeted for JDK 10, and is not part of this change. Since the test depends on that whitebox extension, the test can't be included with the change either, and will be deferred to JDK 10. But I'm including webrevs for both here, for for reference by reviewers, and for testing on the platforms I don't have access to. http://cr.openjdk.java.net/~kbarrett/8166188/test.03/ http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hsroot.01/ http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hotspot.01/ Testing: All hotspot jtreg tests run locally (Linux x86_64). In particular: - gc/TestReturnJNIWeak (new) - runtime/SameObject (uses NewWeakGlobalRef) Ad hoc hotspot nightly test on Oracle supported platforms. This includes some closed tests that use NewWeakGlobalRef. From christoph.langer at sap.com Thu Jan 19 06:57:15 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Jan 2017 06:57:15 +0000 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER In-Reply-To: References: Message-ID: <9adebe1fd60f4fa5b1e51328eed27be1@derote13de46.global.corp.sap> Hi Thomas, +1 This really seems the right thing to do here. Best regards Christoph > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Volker Simonis > Sent: Mittwoch, 18. Januar 2017 17:59 > To: Thomas St?fe > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER > > Hi Thomas, > > aside from the copyright notices which have to be updated to 2017 now > (no need for a new webrev however) your changes look good. > > Thanks for fixing, > Volker > > > On Wed, Jan 18, 2017 at 11:24 AM, Thomas St?fe > wrote: > > Dear all, > > > > please review this bugfix for AIX. > > > > Issue > > https://bugs.openjdk.java.net/browse/JDK-8172964 > > Webrev: > > http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX- > SIGDANGER/webrev/ > > > > In short, this removes the handling for SIGDANGER from the hotspot. > > Handling SIGDANGER has almost no benefit for us but interferes with AIX > OOM > > killing mechanism, making effects of ow-paging-space situations on AIX more > > severe than they would need to be. > > > > For more details, please see the bug report. > > > > Thanks & Kind Regards, > > > > Thomas From thomas.stuefe at gmail.com Thu Jan 19 07:39:32 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 19 Jan 2017 08:39:32 +0100 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER In-Reply-To: <9adebe1fd60f4fa5b1e51328eed27be1@derote13de46.global.corp.sap> References: <9adebe1fd60f4fa5b1e51328eed27be1@derote13de46.global.corp.sap> Message-ID: Thanks Christoph! On Thu, Jan 19, 2017 at 7:57 AM, Langer, Christoph wrote: > Hi Thomas, > > +1 > > This really seems the right thing to do here. > > Best regards > Christoph > > > -----Original Message----- > > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > > bounces at openjdk.java.net] On Behalf Of Volker Simonis > > Sent: Mittwoch, 18. Januar 2017 17:59 > > To: Thomas St?fe > > Cc: ppc-aix-port-dev at openjdk.java.net; hotspot-runtime-dev at openjdk. > java.net > > Subject: Re: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER > > > > Hi Thomas, > > > > aside from the copyright notices which have to be updated to 2017 now > > (no need for a new webrev however) your changes look good. > > > > Thanks for fixing, > > Volker > > > > > > On Wed, Jan 18, 2017 at 11:24 AM, Thomas St?fe > > wrote: > > > Dear all, > > > > > > please review this bugfix for AIX. > > > > > > Issue > > > https://bugs.openjdk.java.net/browse/JDK-8172964 > > > Webrev: > > > http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX- > > SIGDANGER/webrev/ > > > > > > In short, this removes the handling for SIGDANGER from the hotspot. > > > Handling SIGDANGER has almost no benefit for us but interferes with AIX > > OOM > > > killing mechanism, making effects of ow-paging-space situations on AIX > more > > > severe than they would need to be. > > > > > > For more details, please see the bug report. > > > > > > Thanks & Kind Regards, > > > > > > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Jan 19 08:27:47 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 19 Jan 2017 09:27:47 +0100 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER In-Reply-To: References: Message-ID: Hi, I still need a sponsor. Could someone from Oracle please review and sponsor the change? Thank you! Kind Regards, Thomas On Wed, Jan 18, 2017 at 11:24 AM, Thomas St?fe wrote: > Dear all, > > please review this bugfix for AIX. > > Issue > https://bugs.openjdk.java.net/browse/JDK-8172964 > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX-SIGDANGER/webrev/ > > In short, this removes the handling for SIGDANGER from the hotspot. > Handling SIGDANGER has almost no benefit for us but interferes with AIX OOM > killing mechanism, making effects of ow-paging-space situations on AIX more > severe than they would need to be. > > For more details, please see the bug report. > > Thanks & Kind Regards, > > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Jan 19 09:35:21 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 19 Jan 2017 10:35:21 +0100 Subject: RFR: 8172964: [aix] AIX VM should not handle SIGDANGER In-Reply-To: References: Message-ID: ... Nevermind. Volker just reminded me that we can push AIX only changes ourself. Change was pushed. Kind Regards, Thomas On Thu, Jan 19, 2017 at 9:27 AM, Thomas St?fe wrote: > Hi, > > I still need a sponsor. Could someone from Oracle please review and > sponsor the change? Thank you! > > Kind Regards, Thomas > > On Wed, Jan 18, 2017 at 11:24 AM, Thomas St?fe > wrote: > >> Dear all, >> >> please review this bugfix for AIX. >> >> Issue >> https://bugs.openjdk.java.net/browse/JDK-8172964 >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8172964-AIX-SIGDANGER/webrev/ >> >> In short, this removes the handling for SIGDANGER from the hotspot. >> Handling SIGDANGER has almost no benefit for us but interferes with AIX OOM >> killing mechanism, making effects of ow-paging-space situations on AIX more >> severe than they would need to be. >> >> For more details, please see the bug report. >> >> Thanks & Kind Regards, >> >> Thomas >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Thu Jan 19 16:28:27 2017 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 19 Jan 2017 17:28:27 +0100 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: References: Message-ID: <62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com> Hi Kim, On 2017-01-19 06:31, Kim Barrett wrote: > Please review this change to jweak to support G1. > > The problem being addressed is that, when using G1, dereferencing a > jweak must ensure the obtained referent is ensured live, just as for > other weak reference types. This has always been a requirement, and > failure to do so appears to be a since-day1 G1 bug. > > There are two categories of places that need to address this issue: > JNIHandles::resolve and friends, and returning a jobject from native > code to Java. In both of these places the jobject whose contained oop > is being extracted might really be a jweak. jweak is > representationally indistinguishable from jobject; jweak is just a > typedef for jobject. The documentation says a jweak can be used > anywhere a jobject is permitted, making that type equivalence > necessary for a C API. (A C++ API might be able to have distinct > types via inheritance, though would still need a method for > distinguishing them at runtime. But since JNI is a C API...). > > The basic approach being taken is to "tag" jweaks by setting the low > order bit (recall that jweak == jobject == _jobject*), in order to > distinguish them from non-jweak jobjects. This tagging is only being > done when the selected GC needs the distinction, e.g. G1. This gives > us a representational difference between jobject and jweak on which to > base the different behavior, hiding that distinction behind the > existing API. > > JNIHandles::resolve and friends are changed to unconditionally strip > off any potential weak tag when translating from jobject to to oop*. > That's cheaper than testing for the conditional use of tagging and > then stripping. Also stripped when deleting JNI handles. > > TemplateInterpreterGenerator::generate_native_entry and > SharedRuntime::generate_native_wrapper are changed to conditionally > emit code to apply the G1 pre-barrier to the value obtained from a > jobject result, when the result is tagged as a jweak, which only > occurs when using G1. > > For arm32/arm64, this required moving the g1_write_barrier_pre > definitions from InterpreterMacroAssembler to MacroAssembler. Also > moved g1_write_barrier_post, for consistency. > > Note: I've not tested the aarch64 changes; I'll need someone with > access to that platform to test. > > Note: I've not implemented this change for ppc or s390; I'll need > someone else to deal with those platforms. (It's been a very long > time since I wrote any ppc assembly code, and I've never seen an > s390.) > > Note: I've done a minimal change for zero. Code elsewhere suggests > zero doesn't support G1, and I followed that. > > And finally, JNIHandles::make_weak_global conditionally tags the > result. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8166188 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/ I thought a bit about this issue today and unfortunately I've uncovered yet another location where a weak JNI handle needs to have its weak tag cleared. Consider the following JNI code snippet jobject o = <...>; jweak w = (*env)->NewWeakGlobalRef(env, o); jobject param = w; (*env)->CallStaticVoidMethod(env, c, id, param); jni_CallStaticVoidMethod creates a JNI_ArgumentPusherVaArg and passes that to jni_invoke_static in jni.cpp jni_invoke_static creates a JavaCallArguments object and passes that to the argument pusher and invokes args->iterate( Fingerprinter(method).fingerprint() ); iterate calls get_object() on the args pusher which is supposed to transfer the object parameter from the va_list in CallStaticVoidMethod to the JavaCallArguments object. The code to perform that transfer is this nasty piece of code: inline void get_object() { jobject l = va_arg(_ap, jobject); _arguments->push_oop(Handle((oop *)l, false)); } l here is our jweak and the code just does an unsafe cast to oop* and even fakes a VM Handle using a special constructor in the Handle class. In a debug build (or with -Xcheck:jni) this results in JavaCallArguments::verify catching this bad oop using a SignatureChekker::check_obj (sic) which uses this interesting code snippet to verify an oop: intptr_t v = _value[p]; if (v != 0 ) { size_t t = (size_t)v; bad = (t < (size_t)os::vm_page_size() ) || !Handle::raw_resolve((oop *)v)->is_oop_or_null(true); In a product build we will crash at some random point in the future. I've created a test to provoke this situation and put it at: http://cr.openjdk.java.net/~mgerdin/8166188-pass-arguments/webrev/ run the test with $ make test-hotspot-jtreg-native Sorry for not coming up with this sooner, I just realized this problem today. /Mikael > > In addition to the above webrev, I've also included separate webrevs > for a test of this change, and for a whitebox extension needed for > that test. The whitebox extension is my in-progress work on > JDK-8169517, which is an enhancement targeted for JDK 10, and is not > part of this change. Since the test depends on that whitebox > extension, the test can't be included with the change either, and will > be deferred to JDK 10. But I'm including webrevs for both here, for > for reference by reviewers, and for testing on the platforms I don't > have access to. > > http://cr.openjdk.java.net/~kbarrett/8166188/test.03/ > http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hsroot.01/ > http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hotspot.01/ > > Testing: > All hotspot jtreg tests run locally (Linux x86_64). > In particular: > - gc/TestReturnJNIWeak (new) > - runtime/SameObject (uses NewWeakGlobalRef) > > Ad hoc hotspot nightly test on Oracle supported platforms. This > includes some closed tests that use NewWeakGlobalRef. > From kim.barrett at oracle.com Thu Jan 19 18:04:31 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 19 Jan 2017 13:04:31 -0500 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com> References: <62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com> Message-ID: <29CF89D4-6FC9-4968-BC6B-F7598FB30116@oracle.com> > On Jan 19, 2017, at 11:28 AM, Mikael Gerdin wrote: > > Hi Kim, > > On 2017-01-19 06:31, Kim Barrett wrote: >> Please review this change to jweak to support G1. >> >> [?] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8166188 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/ > > I thought a bit about this issue today and unfortunately I've uncovered yet another location where a weak JNI handle needs to have its weak tag cleared. > Consider the following JNI code snippet > > [?] > I've created a test to provoke this situation and put it at: > http://cr.openjdk.java.net/~mgerdin/8166188-pass-arguments/webrev/ > run the test with > $ make test-hotspot-jtreg-native > > Sorry for not coming up with this sooner, I just realized this problem today. Well, I?m happy you found it before this went out the door. Despite looking for this sort of thing, I completely missed this one. I need to re-review casts to oop*. From bruno.rosa at eldorado.org.br Fri Jan 20 18:42:51 2017 From: bruno.rosa at eldorado.org.br (Bruno Alexandre Rosa) Date: Fri, 20 Jan 2017 18:42:51 +0000 Subject: Enforcing data alignment for intrinsics Message-ID: <920cb730922f42c5a1585fcae6aeb7a8@serv031.corp.eldorado.org.br> Hi all, Currently I'm working on a patch to implement SHA2 intrinsics for ppc64 and came upon this issue: vector load instructions (lvx) assume that the data is 16bytes-aligned. It is possible to access unaligned data, but that requires more than just one instruction, incurring in a performance loss. Is it possible to enforce 16bytes alignment for the input buffer available to the intrinsics? If it is so, can someone give me pointers for making this change? Regards, Bruno Rosa From martin.doerr at sap.com Mon Jan 23 18:46:42 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 23 Jan 2017 18:46:42 +0000 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <29CF89D4-6FC9-4968-BC6B-F7598FB30116@oracle.com> References: <62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com> <29CF89D4-6FC9-4968-BC6B-F7598FB30116@oracle.com> Message-ID: <66867f1838714d17bf76324a513a568a@DEWDFE13DE02.global.corp.sap> Hi everybody, thanks for addressing this issue and for the webrev. While reading code, I was wondering if the result handler for oop types ever gets called (except on PPC64). Looks like it is only there to compare the pointer after the native call and do something special in this case instead of calling it. Wouldn't it be cleaner to use the result handler and take care of the G1 pre barrier there? Btw. PPC64 currently uses a different implementation which really calls the oop result handler. The native entry saves the handle to the frame's lresult field and sets the oop_temp to NULL. The oop result handler takes care of the unboxing. In addition frame::interpreter_frame_result should use JNIHandles::resolve to retrieve the oop (which is not yet implemented as it should be). Also, one has to make sure that the active handles don't get reset too early. This implementation doesn't force the oop to be live. GC may still set it to NULL if it decides to kill the jweak. I think PPC64 and the other platforms should do it the same way. The question is what's the better approach. Best regards, Martin -----Original Message----- From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Kim Barrett Sent: Donnerstag, 19. Januar 2017 19:05 To: Mikael Gerdin Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles > On Jan 19, 2017, at 11:28 AM, Mikael Gerdin wrote: > > Hi Kim, > > On 2017-01-19 06:31, Kim Barrett wrote: >> Please review this change to jweak to support G1. >> >> [...] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8166188 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/ > > I thought a bit about this issue today and unfortunately I've uncovered yet another location where a weak JNI handle needs to have its weak tag cleared. > Consider the following JNI code snippet > > [...] > I've created a test to provoke this situation and put it at: > http://cr.openjdk.java.net/~mgerdin/8166188-pass-arguments/webrev/ > run the test with > $ make test-hotspot-jtreg-native > > Sorry for not coming up with this sooner, I just realized this problem today. Well, I'm happy you found it before this went out the door. Despite looking for this sort of thing, I completely missed this one. I need to re-review casts to oop*. From per.liden at oracle.com Tue Jan 24 10:49:19 2017 From: per.liden at oracle.com (Per Liden) Date: Tue, 24 Jan 2017 11:49:19 +0100 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: References: Message-ID: <5ddce951-f85f-6633-d25b-5359aebe7114@oracle.com> Hi Kim, On 2017-01-19 06:31, Kim Barrett wrote: > Please review this change to jweak to support G1. > > The problem being addressed is that, when using G1, dereferencing a > jweak must ensure the obtained referent is ensured live, just as for > other weak reference types. This has always been a requirement, and > failure to do so appears to be a since-day1 G1 bug. > > There are two categories of places that need to address this issue: > JNIHandles::resolve and friends, and returning a jobject from native > code to Java. In both of these places the jobject whose contained oop > is being extracted might really be a jweak. jweak is > representationally indistinguishable from jobject; jweak is just a > typedef for jobject. The documentation says a jweak can be used > anywhere a jobject is permitted, making that type equivalence > necessary for a C API. (A C++ API might be able to have distinct > types via inheritance, though would still need a method for > distinguishing them at runtime. But since JNI is a C API...). > > The basic approach being taken is to "tag" jweaks by setting the low > order bit (recall that jweak == jobject == _jobject*), in order to > distinguish them from non-jweak jobjects. This tagging is only being > done when the selected GC needs the distinction, e.g. G1. This gives > us a representational difference between jobject and jweak on which to > base the different behavior, hiding that distinction behind the > existing API. I'd like to suggest that we always tag jweaks, regardless of which GC is used. I can't see any performance issues to be afraid of here, but I can see a number of advantages with a unified jweak representation/handling, like avoiding #ifdef INCLUDE_ALL_GCS noise and reducing the number of code paths to test/debug. cheers, Per > > JNIHandles::resolve and friends are changed to unconditionally strip > off any potential weak tag when translating from jobject to to oop*. > That's cheaper than testing for the conditional use of tagging and > then stripping. Also stripped when deleting JNI handles. > > TemplateInterpreterGenerator::generate_native_entry and > SharedRuntime::generate_native_wrapper are changed to conditionally > emit code to apply the G1 pre-barrier to the value obtained from a > jobject result, when the result is tagged as a jweak, which only > occurs when using G1. > > For arm32/arm64, this required moving the g1_write_barrier_pre > definitions from InterpreterMacroAssembler to MacroAssembler. Also > moved g1_write_barrier_post, for consistency. > > Note: I've not tested the aarch64 changes; I'll need someone with > access to that platform to test. > > Note: I've not implemented this change for ppc or s390; I'll need > someone else to deal with those platforms. (It's been a very long > time since I wrote any ppc assembly code, and I've never seen an > s390.) > > Note: I've done a minimal change for zero. Code elsewhere suggests > zero doesn't support G1, and I followed that. > > And finally, JNIHandles::make_weak_global conditionally tags the > result. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8166188 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/ > > In addition to the above webrev, I've also included separate webrevs > for a test of this change, and for a whitebox extension needed for > that test. The whitebox extension is my in-progress work on > JDK-8169517, which is an enhancement targeted for JDK 10, and is not > part of this change. Since the test depends on that whitebox > extension, the test can't be included with the change either, and will > be deferred to JDK 10. But I'm including webrevs for both here, for > for reference by reviewers, and for testing on the platforms I don't > have access to. > > http://cr.openjdk.java.net/~kbarrett/8166188/test.03/ > http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hsroot.01/ > http://cr.openjdk.java.net/~kbarrett/8166188/whitebox/hotspot.01/ > > Testing: > All hotspot jtreg tests run locally (Linux x86_64). > In particular: > - gc/TestReturnJNIWeak (new) > - runtime/SameObject (uses NewWeakGlobalRef) > > Ad hoc hotspot nightly test on Oracle supported platforms. This > includes some closed tests that use NewWeakGlobalRef. > From mikael.gerdin at oracle.com Tue Jan 24 14:50:04 2017 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 24 Jan 2017 15:50:04 +0100 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <66867f1838714d17bf76324a513a568a@DEWDFE13DE02.global.corp.sap> References: <62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com> <29CF89D4-6FC9-4968-BC6B-F7598FB30116@oracle.com> <66867f1838714d17bf76324a513a568a@DEWDFE13DE02.global.corp.sap> Message-ID: <38bbbce8-9bcb-8f4a-cd94-fd14d6a08b4d@oracle.com> Hi Martin, Thanks for taking a look at this change. On 2017-01-23 19:46, Doerr, Martin wrote: > Hi everybody, > > thanks for addressing this issue and for the webrev. > > While reading code, I was wondering if the result handler for oop types ever gets called (except on PPC64). > Looks like it is only there to compare the pointer after the native call and do something special in this case instead of calling it. > > Wouldn't it be cleaner to use the result handler and take care of the G1 pre barrier there? Can't say I know much about the result handlers in general but I get the feeling that they are only there for the interpreter. Are the result handlers applied to the return values of compiled native wrappers as well? Thanks /Mikael > > Btw. PPC64 currently uses a different implementation which really calls the oop result handler. The native entry saves the handle to the frame's lresult field and sets the oop_temp to NULL. The oop result handler takes care of the unboxing. In addition frame::interpreter_frame_result should use JNIHandles::resolve to retrieve the oop (which is not yet implemented as it should be). Also, one has to make sure that the active handles don't get reset too early. > This implementation doesn't force the oop to be live. GC may still set it to NULL if it decides to kill the jweak. > > I think PPC64 and the other platforms should do it the same way. The question is what's the better approach. > > Best regards, > Martin > > > -----Original Message----- > From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Kim Barrett > Sent: Donnerstag, 19. Januar 2017 19:05 > To: Mikael Gerdin > Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers > Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles > >> On Jan 19, 2017, at 11:28 AM, Mikael Gerdin wrote: >> >> Hi Kim, >> >> On 2017-01-19 06:31, Kim Barrett wrote: >>> Please review this change to jweak to support G1. >>> >>> [...] >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8166188 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/ >> >> I thought a bit about this issue today and unfortunately I've uncovered yet another location where a weak JNI handle needs to have its weak tag cleared. >> Consider the following JNI code snippet >> >> [...] >> I've created a test to provoke this situation and put it at: >> http://cr.openjdk.java.net/~mgerdin/8166188-pass-arguments/webrev/ >> run the test with >> $ make test-hotspot-jtreg-native >> >> Sorry for not coming up with this sooner, I just realized this problem today. > > Well, I'm happy you found it before this went out the door. Despite looking for this sort of thing, I completely missed this one. I need to re-review casts to oop*. > From martin.doerr at sap.com Tue Jan 24 17:18:56 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 24 Jan 2017 17:18:56 +0000 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: <38bbbce8-9bcb-8f4a-cd94-fd14d6a08b4d@oracle.com> References: <62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com> <29CF89D4-6FC9-4968-BC6B-F7598FB30116@oracle.com> <66867f1838714d17bf76324a513a568a@DEWDFE13DE02.global.corp.sap> <38bbbce8-9bcb-8f4a-cd94-fd14d6a08b4d@oracle.com> Message-ID: Hi Mikael, I found out how the oop result processing works on x86. I was kind of confused about it, yesterday. The oop case just has an additional piece of code which forces the oop to be alive and visible to GC by copying it from the (possibly weak) handle to the oop result field. Later, the result handler reloads it from there. The current PPC64 implementation doesn't need the additional piece of code, because the oop lives in the (possibly weak) handle until the result handler loads it from there. We need to decide if we keep the PPC64 implementation or not. Not sure if it's worth porting this diff to other platforms. Best regards, Martin -----Original Message----- From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] Sent: Dienstag, 24. Januar 2017 15:50 To: Doerr, Martin ; Kim Barrett Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles Hi Martin, Thanks for taking a look at this change. On 2017-01-23 19:46, Doerr, Martin wrote: > Hi everybody, > > thanks for addressing this issue and for the webrev. > > While reading code, I was wondering if the result handler for oop types ever gets called (except on PPC64). > Looks like it is only there to compare the pointer after the native call and do something special in this case instead of calling it. > > Wouldn't it be cleaner to use the result handler and take care of the G1 pre barrier there? Can't say I know much about the result handlers in general but I get the feeling that they are only there for the interpreter. Are the result handlers applied to the return values of compiled native wrappers as well? Thanks /Mikael > > Btw. PPC64 currently uses a different implementation which really calls the oop result handler. The native entry saves the handle to the frame's lresult field and sets the oop_temp to NULL. The oop result handler takes care of the unboxing. In addition frame::interpreter_frame_result should use JNIHandles::resolve to retrieve the oop (which is not yet implemented as it should be). Also, one has to make sure that the active handles don't get reset too early. > This implementation doesn't force the oop to be live. GC may still set it to NULL if it decides to kill the jweak. > > I think PPC64 and the other platforms should do it the same way. The question is what's the better approach. > > Best regards, > Martin > > > -----Original Message----- > From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] > On Behalf Of Kim Barrett > Sent: Donnerstag, 19. Januar 2017 19:05 > To: Mikael Gerdin > Cc: s390x-port-dev at openjdk.java.net; > ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers > > Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak > JNI handles > >> On Jan 19, 2017, at 11:28 AM, Mikael Gerdin wrote: >> >> Hi Kim, >> >> On 2017-01-19 06:31, Kim Barrett wrote: >>> Please review this change to jweak to support G1. >>> >>> [...] >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8166188 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/ >> >> I thought a bit about this issue today and unfortunately I've uncovered yet another location where a weak JNI handle needs to have its weak tag cleared. >> Consider the following JNI code snippet >> >> [...] >> I've created a test to provoke this situation and put it at: >> http://cr.openjdk.java.net/~mgerdin/8166188-pass-arguments/webrev/ >> run the test with >> $ make test-hotspot-jtreg-native >> >> Sorry for not coming up with this sooner, I just realized this problem today. > > Well, I'm happy you found it before this went out the door. Despite looking for this sort of thing, I completely missed this one. I need to re-review casts to oop*. > From martin.doerr at sap.com Fri Jan 27 16:44:02 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 27 Jan 2017 16:44:02 +0000 Subject: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles In-Reply-To: References: <62da5dd7-c7c7-409f-7b22-018f6f5dd43c@oracle.com> <29CF89D4-6FC9-4968-BC6B-F7598FB30116@oracle.com> <66867f1838714d17bf76324a513a568a@DEWDFE13DE02.global.corp.sap> <38bbbce8-9bcb-8f4a-cd94-fd14d6a08b4d@oracle.com> Message-ID: Hi Kim, Mikael and all, we have implemented the G1 barriers for PPC64 and s390 in this webrev: http://cr.openjdk.java.net/~mdoerr/8166188_s390_ppc64/webrev.00/ The change just adds the barrier code. s390's template interpreter looks pretty much like Oracle's platforms, while PPC64's one loads the oop from the handle inside of the result handler. I think making platform implementations more similar is rather a topic for JDK10. Thanks and best regards, Martin -----Original Message----- From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin Sent: Dienstag, 24. Januar 2017 18:19 To: Mikael Gerdin ; Kim Barrett Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers Subject: RE: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles Hi Mikael, I found out how the oop result processing works on x86. I was kind of confused about it, yesterday. The oop case just has an additional piece of code which forces the oop to be alive and visible to GC by copying it from the (possibly weak) handle to the oop result field. Later, the result handler reloads it from there. The current PPC64 implementation doesn't need the additional piece of code, because the oop lives in the (possibly weak) handle until the result handler loads it from there. We need to decide if we keep the PPC64 implementation or not. Not sure if it's worth porting this diff to other platforms. Best regards, Martin -----Original Message----- From: Mikael Gerdin [mailto:mikael.gerdin at oracle.com] Sent: Dienstag, 24. Januar 2017 15:50 To: Doerr, Martin ; Kim Barrett Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak JNI handles Hi Martin, Thanks for taking a look at this change. On 2017-01-23 19:46, Doerr, Martin wrote: > Hi everybody, > > thanks for addressing this issue and for the webrev. > > While reading code, I was wondering if the result handler for oop types ever gets called (except on PPC64). > Looks like it is only there to compare the pointer after the native call and do something special in this case instead of calling it. > > Wouldn't it be cleaner to use the result handler and take care of the G1 pre barrier there? Can't say I know much about the result handlers in general but I get the feeling that they are only there for the interpreter. Are the result handlers applied to the return values of compiled native wrappers as well? Thanks /Mikael > > Btw. PPC64 currently uses a different implementation which really calls the oop result handler. The native entry saves the handle to the frame's lresult field and sets the oop_temp to NULL. The oop result handler takes care of the unboxing. In addition frame::interpreter_frame_result should use JNIHandles::resolve to retrieve the oop (which is not yet implemented as it should be). Also, one has to make sure that the active handles don't get reset too early. > This implementation doesn't force the oop to be live. GC may still set it to NULL if it decides to kill the jweak. > > I think PPC64 and the other platforms should do it the same way. The question is what's the better approach. > > Best regards, > Martin > > > -----Original Message----- > From: s390x-port-dev [mailto:s390x-port-dev-bounces at openjdk.java.net] > On Behalf Of Kim Barrett > Sent: Donnerstag, 19. Januar 2017 19:05 > To: Mikael Gerdin > Cc: s390x-port-dev at openjdk.java.net; > ppc-aix-port-dev at openjdk.java.net; hotspot-dev developers > > Subject: Re: RFR: 8166188: G1 Needs pre barrier on dereference of weak > JNI handles > >> On Jan 19, 2017, at 11:28 AM, Mikael Gerdin wrote: >> >> Hi Kim, >> >> On 2017-01-19 06:31, Kim Barrett wrote: >>> Please review this change to jweak to support G1. >>> >>> [...] >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8166188 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8166188/hotspot.02/ >> >> I thought a bit about this issue today and unfortunately I've uncovered yet another location where a weak JNI handle needs to have its weak tag cleared. >> Consider the following JNI code snippet >> >> [...] >> I've created a test to provoke this situation and put it at: >> http://cr.openjdk.java.net/~mgerdin/8166188-pass-arguments/webrev/ >> run the test with >> $ make test-hotspot-jtreg-native >> >> Sorry for not coming up with this sooner, I just realized this problem today. > > Well, I'm happy you found it before this went out the door. Despite looking for this sort of thing, I completely missed this one. I need to re-review casts to oop*. > From gromero at linux.vnet.ibm.com Tue Jan 31 11:18:56 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 31 Jan 2017 09:18:56 -0200 Subject: A question on endGroupNode Message-ID: <589072A0.8030509@linux.vnet.ibm.com> Hi, Sometimes the JVM on PPC64 puts a group ending nop (ori r1,r1,0) after conditional branches, like, for instance, the following assembly sequence from C2 generated from Hive code: 379 6.6e-04 : 10000980436c: lwz r14,16(r6) 816 0.0014 : 100009804370: cmplw cr6,r7,r14 : 100009804374: bge cr6,100009804ee8 : 100009804378: ori r1,r1,0 <=== endGroup 167 2.9e-04 : 10000980437c: add r15,r7,r8 892 0.0015 : 100009804380: addi r17,r15,-1 : 100009804384: cmplw cr5,r17,r14 : 100009804388: bge cr5,100009804ee8 262 4.5e-04 : 10000980438c: ori r1,r1,0 <=== endGroup 648 0.0011 : 100009804390: li r14,0 : 100009804394: cmpld cr6,r5,r14 : 100009804398: beq cr6,100009804ee8 267 4.6e-04 : 10000980439c: ori r1,r1,0 <=== endGroup 930 0.0016 : 1000098043a0: addis r20,r29,384 : 1000098043a4: addi r20,r20,16384 The (ori r1, r1, 0) seems to be emitted from a endGroupNode defined in: http://hg.openjdk.java.net/jdk9/hs/hotspot/file/6c1e79a99176/src/cpu/ppc/vm/ppc.ad#l13261 Nonetheless, I could not generated any endGroupNode using SPECjvm2008 (i.e. looking at the log from -XX:+PrintOptoAssembly there is no "End Bundle" anywhere). Any idea why it exists primarily and if there is any option to control its emission or even a particular way to avoid the creation of an endGroupNode? Thank you. Best regards, Gustavo From devnexen at gmail.com Fri Jan 6 22:23:53 2017 From: devnexen at gmail.com (David CARLIER) Date: Fri, 06 Jan 2017 22:23:53 -0000 Subject: Hotspot for BSD / opinion request In-Reply-To: References: <1488ccc1-e00c-42e7-3cfc-9fd0b5699a63@oracle.com> Message-ID: Thanks, here a patch proposal. Kindest regards. On 24 December 2016 at 02:16, David Holmes wrote: > If there is a platform, we support, where the default settings are > inappropriate then setting them explicitly would be the right thing to do. > > David > > > On 24/12/2016 10:23 AM, Vladimir Kozlov wrote: >> >> Hi, >> >> Forwarding to mailing lists since I can't answer. >> May be someone can answer your question on these lists. >> >> Regards, >> Vladimir >> >> On 12/23/16 2:17 AM, David CARLIER wrote: >>> >>> Hi, >>> >>> this is my first mail to the maiing list, I have difficulties to push >>> messages to any mailing lists, but as BSD user/dev I was >>> looking at code's part like this one >>> >>> >>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/70c6fae64754/src/os/bsd/vm/os_bsd.hpp >>> >>> >>> I was wondering if it would be better to explicitally set the attr >>> type to PTHREAD_MUTEX_NORMAL to insure consistency with AIX and Linux >>> (on FreeBSD it is PTHREAD_MUTEX_ERRORCHECK by default). >>> >>> What do you think ? >>> >>> Thanks in advance. >>> >>> Kindest regards. >>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-src-os-bsd-vm-os_bsd_hpp Type: application/octet-stream Size: 1640 bytes Desc: not available URL: From devnexen at gmail.com Mon Jan 9 17:38:12 2017 From: devnexen at gmail.com (David CARLIER) Date: Mon, 09 Jan 2017 17:38:12 -0000 Subject: Hotspot for BSD / opinion request In-Reply-To: <3c580abc-9333-8803-abc1-1b0863123060@oracle.com> References: <1488ccc1-e00c-42e7-3cfc-9fd0b5699a63@oracle.com> <3c580abc-9333-8803-abc1-1b0863123060@oracle.com> Message-ID: Hi sure thing diff --git a/src/os/bsd/vm/os_bsd.hpp b/src/os/bsd/vm/os_bsd.hpp --- a/src/os/bsd/vm/os_bsd.hpp +++ b/src/os/bsd/vm/os_bsd.hpp @@ -175,6 +175,7 @@ volatile int _Event; volatile int _nParked; pthread_mutex_t _mutex[1]; + pthread_mutexattr_t _attr[1]; pthread_cond_t _cond[1]; double PostPad[2]; Thread * _Assoc; @@ -187,7 +188,11 @@ int status; status = pthread_cond_init(_cond, NULL); assert_status(status == 0, status, "cond_init"); - status = pthread_mutex_init(_mutex, NULL); + status = pthread_mutexattr_init(_attr); + assert_status(status == 0, status, "attr_init"); + status = pthread_mutexattr_settype(_attr, PTHREAD_MUTEX_NORMAL); + assert_status(status == 0, status, "attr_settype"); + status = pthread_mutex_init(_mutex, _attr); assert_status(status == 0, status, "mutex_init"); _Event = 0; _nParked = 0; @@ -206,6 +211,7 @@ class PlatformParker : public CHeapObj { protected: pthread_mutex_t _mutex[1]; + pthread_mutexattr_t _attr[1]; pthread_cond_t _cond[1]; public: // TODO-FIXME: make dtor private @@ -216,7 +222,11 @@ int status; status = pthread_cond_init(_cond, NULL); assert_status(status == 0, status, "cond_init"); - status = pthread_mutex_init(_mutex, NULL); + status = pthread_mutexattr_init(_attr); + assert_status(status == 0, status, "attr_init"); + status = pthread_mutexattr_settype(_attr, PTHREAD_MUTEX_NORMAL); + assert_status(status == 0, status, "attr_settype"); + status = pthread_mutex_init(_mutex, _attr); assert_status(status == 0, status, "mutex_init"); } }; Kind regards. Thanks. On 9 January 2017 at 16:48, Daniel D. Daugherty wrote: > David C., > > If you sent the patch as an attachment, then you should be advised that > the OpenJDK email servers strip attachments. If the patch is relatively > small, then you can send it in-line... > > Dan > > > > On 1/6/17 3:23 PM, David CARLIER wrote: >> >> Thanks, here a patch proposal. Kindest regards. >> >> On 24 December 2016 at 02:16, David Holmes >> wrote: >>> >>> If there is a platform, we support, where the default settings are >>> inappropriate then setting them explicitly would be the right thing to >>> do. >>> >>> David >>> >>> >>> On 24/12/2016 10:23 AM, Vladimir Kozlov wrote: >>>> >>>> Hi, >>>> >>>> Forwarding to mailing lists since I can't answer. >>>> May be someone can answer your question on these lists. >>>> >>>> Regards, >>>> Vladimir >>>> >>>> On 12/23/16 2:17 AM, David CARLIER wrote: >>>>> >>>>> Hi, >>>>> >>>>> this is my first mail to the maiing list, I have difficulties to push >>>>> messages to any mailing lists, but as BSD user/dev I was >>>>> looking at code's part like this one >>>>> >>>>> >>>>> >>>>> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/70c6fae64754/src/os/bsd/vm/os_bsd.hpp >>>>> >>>>> >>>>> I was wondering if it would be better to explicitally set the attr >>>>> type to PTHREAD_MUTEX_NORMAL to insure consistency with AIX and Linux >>>>> (on FreeBSD it is PTHREAD_MUTEX_ERRORCHECK by default). >>>>> >>>>> What do you think ? >>>>> >>>>> Thanks in advance. >>>>> >>>>> Kindest regards. >>>>> >