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 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 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 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 dmitry.fazunenko at oracle.com Mon Jan 9 13:50:44 2017 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Mon, 9 Jan 2017 16:50:44 +0300 Subject: Fwd: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial. In-Reply-To: References: Message-ID: Hi in the new year! I got off line comment from Igor I. that Xmx is not needed here at all. And I agree with Igor. GCBasher test was written many years ago, probably in those times when default maximum heap size was 64MB. So, specifying Xmx was necessary to increase heap to allocate such a big structure. Nowadays, it's hard to find a host where maximum heap size set by the ergonomics will be less than 256MB. GCBasher doesn't try to allocate all available memory, it just allocates a big structure several time. So, I think -Xmx option could be removed from this test: http://cr.openjdk.java.net/~dfazunen/8169643/webrev.02/ Tested by RBT with and without -XX:-UseCompressedOpps Thanks, Dima -------- Forwarded Message -------- Subject: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial. Date: Thu, 29 Dec 2016 17:25:26 +0300 From: Dmitry Fazunenenko To: hotspot-gc-dev Hi everyone, I'm looking for a couple of review for a simple change in test: -Xmx128m -> -Xmx256m http://cr.openjdk.java.net/~dfazunen/8169643/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8169643 The GCBasher test fails with OOM if run with -XX:-UseCompressedOpps. The root cause is 128Mb is not enough to locate a big structure if Opps are not compressed. Giving more memory fixes the problem (TestGCBasherWithParallel.java specifies 256m and doesn't fail) Thanks, Dima -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Mon Jan 9 13:57:14 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 9 Jan 2017 16:57:14 +0300 Subject: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial. In-Reply-To: References: Message-ID: Hi Dima, the fix looks good to me, thank you. ? Igor > On Jan 9, 2017, at 4:50 PM, Dmitry Fazunenko wrote: > > Hi in the new year! > > I got off line comment from Igor I. that Xmx is not needed here at all. > And I agree with Igor. > GCBasher test was written many years ago, probably in those times when default maximum heap size was 64MB. > So, specifying Xmx was necessary to increase heap to allocate such a big structure. > Nowadays, it's hard to find a host where maximum heap size set by the ergonomics will be less than 256MB. > GCBasher doesn't try to allocate all available memory, it just allocates a big structure several time. > So, I think -Xmx option could be removed from this test: > > http://cr.openjdk.java.net/~dfazunen/8169643/webrev.02/ > > Tested by RBT with and without -XX:-UseCompressedOpps > > > Thanks, > Dima > > > > -------- Forwarded Message -------- > Subject: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial. > Date: Thu, 29 Dec 2016 17:25:26 +0300 > From: Dmitry Fazunenenko > To: hotspot-gc-dev > > Hi everyone, > > I'm looking for a couple of review for a simple change in test: -Xmx128m > -> -Xmx256m > > > http://cr.openjdk.java.net/~dfazunen/8169643/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8169643 > > > The GCBasher test fails with OOM if run with -XX:-UseCompressedOpps. > The root cause is 128Mb is not enough to locate a big structure if Opps > are not compressed. > Giving more memory fixes the problem (TestGCBasherWithParallel.java > specifies 256m and doesn't fail) > > Thanks, > Dima > > > From dmitry.fazunenko at oracle.com Mon Jan 9 14:01:42 2017 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Mon, 9 Jan 2017 17:01:42 +0300 Subject: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial. In-Reply-To: References: Message-ID: <7536401a-f02f-cb0d-6ef3-263626ef91de@oracle.com> Hi Igor, thanks for such a prompt response. -- Dima On 09.01.2017 16:57, Igor Ignatyev wrote: > Hi Dima, > > the fix looks good to me, thank you. > > ? Igor >> On Jan 9, 2017, at 4:50 PM, Dmitry Fazunenko wrote: >> >> Hi in the new year! >> >> I got off line comment from Igor I. that Xmx is not needed here at all. >> And I agree with Igor. >> GCBasher test was written many years ago, probably in those times when default maximum heap size was 64MB. >> So, specifying Xmx was necessary to increase heap to allocate such a big structure. >> Nowadays, it's hard to find a host where maximum heap size set by the ergonomics will be less than 256MB. >> GCBasher doesn't try to allocate all available memory, it just allocates a big structure several time. >> So, I think -Xmx option could be removed from this test: >> >> http://cr.openjdk.java.net/~dfazunen/8169643/webrev.02/ >> >> Tested by RBT with and without -XX:-UseCompressedOpps >> >> >> Thanks, >> Dima >> >> >> >> -------- Forwarded Message -------- >> Subject: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial. >> Date: Thu, 29 Dec 2016 17:25:26 +0300 >> From: Dmitry Fazunenenko >> To: hotspot-gc-dev >> >> Hi everyone, >> >> I'm looking for a couple of review for a simple change in test: -Xmx128m >> -> -Xmx256m >> >> >> http://cr.openjdk.java.net/~dfazunen/8169643/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8169643 >> >> >> The GCBasher test fails with OOM if run with -XX:-UseCompressedOpps. >> The root cause is 128Mb is not enough to locate a big structure if Opps >> are not compressed. >> Giving more memory fixes the problem (TestGCBasherWithParallel.java >> specifies 256m and doesn't fail) >> >> Thanks, >> Dima >> >> >> From michail.chernov at oracle.com Mon Jan 9 14:06:01 2017 From: michail.chernov at oracle.com (Michail Chernov) Date: Mon, 9 Jan 2017 17:06:01 +0300 Subject: Fwd: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial. In-Reply-To: References: Message-ID: Hi Dima, The change looks good to me. Misha On 09.01.2017 16:50, Dmitry Fazunenko wrote: > Hi in the new year! > > I got off line comment from Igor I. that Xmx is not needed here at all. > And I agree with Igor. > GCBasher test was written many years ago, probably in those times when > default maximum heap size was 64MB. > So, specifying Xmx was necessary to increase heap to allocate such a > big structure. > Nowadays, it's hard to find a host where maximum heap size set by the > ergonomics will be less than 256MB. > GCBasher doesn't try to allocate all available memory, it just > allocates a big structure several time. > So, I think -Xmx option could be removed from this test: > > http://cr.openjdk.java.net/~dfazunen/8169643/webrev.02/ > > Tested by RBT with and without -XX:-UseCompressedOpps > > > Thanks, > Dima > > > > -------- Forwarded Message -------- > Subject: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, > CMS and Serial. > Date: Thu, 29 Dec 2016 17:25:26 +0300 > From: Dmitry Fazunenenko > To: hotspot-gc-dev > > > > Hi everyone, > > I'm looking for a couple of review for a simple change in test: -Xmx128m > -> -Xmx256m > > http://cr.openjdk.java.net/~dfazunen/8169643/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8169643 > > The GCBasher test fails with OOM if run with -XX:-UseCompressedOpps. > The root cause is 128Mb is not enough to locate a big structure if Opps > are not compressed. > Giving more memory fixes the problem (TestGCBasherWithParallel.java > specifies 256m and doesn't fail) > > Thanks, > Dima > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.schatzl at oracle.com Mon Jan 9 14:38:46 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 09 Jan 2017 15:38:46 +0100 Subject: Fwd: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial. In-Reply-To: References: Message-ID: <1483972726.7068.31.camel@oracle.com> Hi, On Mon, 2017-01-09 at 16:50 +0300, Dmitry Fazunenko wrote: > Hi in the new year! > > I got off line comment from Igor I. that? Xmx is not needed here at > all.? > And I agree with Igor.? > GCBasher test was written many years ago, probably in those times > when default maximum heap size was 64MB. > So, specifying Xmx was necessary to increase heap to allocate such a > big structure. > Nowadays, it's hard to find a host where maximum heap size set by the > ergonomics will be less than 256MB.? > GCBasher doesn't try to allocate all available memory, it just > allocates a big structure several time.? > So, I think -Xmx option could be removed from this test: > > http://cr.openjdk.java.net/~dfazunen/8169643/webrev.02/ > > Tested by RBT with and without -XX:-UseCompressedOpps > ? I think the limitation has been introduced so that gcbasher does something useful, i.e. execute enough GCs. With a multi-GB heap at its disposal, I expect that the amount of GCs executed will be significantly lower than it is now. I prefer to have a 256M limit to none; and maybe the test could be run once with and without UseCompressedOops with appropriate heap sizes instead if there is enough cpu time in our testing infrastructure. Thanks, ? Thomas 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 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 dmitry.fazunenko at oracle.com Tue Jan 10 16:09:35 2017 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 10 Jan 2017 19:09:35 +0300 Subject: Fwd: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial. In-Reply-To: <1483972726.7068.31.camel@oracle.com> References: <1483972726.7068.31.camel@oracle.com> Message-ID: <90f2b410-2726-7d62-f261-8363ff7aa457@oracle.com> Hi Thomas, On 09.01.2017 17:38, Thomas Schatzl wrote: > Hi, > > On Mon, 2017-01-09 at 16:50 +0300, Dmitry Fazunenko wrote: >> Hi in the new year! >> >> I got off line comment from Igor I. that Xmx is not needed here at >> all. >> And I agree with Igor. >> GCBasher test was written many years ago, probably in those times >> when default maximum heap size was 64MB. >> So, specifying Xmx was necessary to increase heap to allocate such a >> big structure. >> Nowadays, it's hard to find a host where maximum heap size set by the >> ergonomics will be less than 256MB. >> GCBasher doesn't try to allocate all available memory, it just >> allocates a big structure several time. >> So, I think -Xmx option could be removed from this test: >> >> http://cr.openjdk.java.net/~dfazunen/8169643/webrev.02/ >> >> Tested by RBT with and without -XX:-UseCompressedOpps >> > I think the limitation has been introduced so that gcbasher does > something useful, i.e. execute enough GCs. With a multi-GB heap at its > disposal, I expect that the amount of GCs executed will be > significantly lower than it is now. Your arguments do certainly make sense. > I prefer to have a 256M limit to none; and maybe the test could be run > once with and without UseCompressedOops with appropriate heap sizes > instead if there is enough cpu time in our testing infrastructure. I suggest to start with original version of the fix: http://cr.openjdk.java.net/~dfazunen/8169643/webrev.00/ (+ copyright updates) and submit an RFE to limit max heap size depending of UseCompressedOops value. Such RFE could implemented much easily after integration of JDK-8172417 Verundy: Library to simplify using TestNG for Hotspot test development Now it's a bit tricky to get known from the test the values of external tags. Are you okay with that? Thanks, Dima > > Thanks, > Thomas > 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 thomas.schatzl at oracle.com Tue Jan 10 19:58:21 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 10 Jan 2017 20:58:21 +0100 Subject: Fwd: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial. In-Reply-To: <90f2b410-2726-7d62-f261-8363ff7aa457@oracle.com> References: <1483972726.7068.31.camel@oracle.com> <90f2b410-2726-7d62-f261-8363ff7aa457@oracle.com> Message-ID: <1484078301.3755.0.camel@oracle.com> Hi Dima, On Tue, 2017-01-10 at 19:09 +0300, Dmitry Fazunenko wrote: > Hi Thomas, > > > > On 09.01.2017 17:38, Thomas Schatzl wrote: > > > > Hi, > > > > On Mon, 2017-01-09 at 16:50 +0300, Dmitry Fazunenko wrote: > > > > > > Hi in the new year! > > > > > > I got off line comment from Igor I. that??Xmx is not needed here > > > at > > > all. > > > And I agree with Igor. > > > GCBasher test was written many years ago, probably in those times > > > when default maximum heap size was 64MB. > > > So, specifying Xmx was necessary to increase heap to allocate > > > such a > > > big structure. > > > Nowadays, it's hard to find a host where maximum heap size set by > > > the > > > ergonomics will be less than 256MB. > > > GCBasher doesn't try to allocate all available memory, it just > > > allocates a big structure several time. > > > So, I think -Xmx option could be removed from this test: > > > > > > http://cr.openjdk.java.net/~dfazunen/8169643/webrev.02/ > > > > > > Tested by RBT with and without -XX:-UseCompressedOpps > > > > > ???I think the limitation has been introduced so that gcbasher does > > something useful, i.e. execute enough GCs. With a multi-GB heap at > > its > > disposal, I expect that the amount of GCs executed will be > > significantly lower than it is now. > Your arguments do certainly make sense. > > > > I prefer to have a 256M limit to none; and maybe the test could be > > run > > once with and without UseCompressedOops with appropriate heap sizes > > instead if there is enough cpu time in our testing infrastructure. > I suggest to start with original version of the fix: > http://cr.openjdk.java.net/~dfazunen/8169643/webrev.00/ > (+ copyright updates) > > and submit an RFE to limit max heap size depending of > UseCompressedOops? > value. > Such RFE could implemented much easily after integration of > ?????JDK-8172417 Verundy: Library to simplify using TestNG for > Hotspot ?test development > Now it's a bit tricky to get known from the test the values of > external tags. > > Are you okay with that? ?yes, thanks. Thomas From dmitry.fazunenko at oracle.com Wed Jan 11 10:25:29 2017 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 11 Jan 2017 13:25:29 +0300 Subject: Fwd: RFR (XXS): 8169643: [TESTBUG] GCBasher test fails with G1, CMS and Serial. In-Reply-To: <1484078301.3755.0.camel@oracle.com> References: <1483972726.7068.31.camel@oracle.com> <90f2b410-2726-7d62-f261-8363ff7aa457@oracle.com> <1484078301.3755.0.camel@oracle.com> Message-ID: <8c07da3f-6a79-5936-bf38-2843cceae455@oracle.com> For the record, the final version of change: http://cr.openjdk.java.net/~dfazunen/8169643/webrev.03/ Thanks Dima PS: JDK-8172556 was submitted for the further improvement. On 10.01.2017 22:58, Thomas Schatzl wrote: > Hi Dima, > > On Tue, 2017-01-10 at 19:09 +0300, Dmitry Fazunenko wrote: >> Hi Thomas, >> >> >> >> On 09.01.2017 17:38, Thomas Schatzl wrote: >>> Hi, >>> >>> On Mon, 2017-01-09 at 16:50 +0300, Dmitry Fazunenko wrote: >>>> Hi in the new year! >>>> >>>> I got off line comment from Igor I. that Xmx is not needed here >>>> at >>>> all. >>>> And I agree with Igor. >>>> GCBasher test was written many years ago, probably in those times >>>> when default maximum heap size was 64MB. >>>> So, specifying Xmx was necessary to increase heap to allocate >>>> such a >>>> big structure. >>>> Nowadays, it's hard to find a host where maximum heap size set by >>>> the >>>> ergonomics will be less than 256MB. >>>> GCBasher doesn't try to allocate all available memory, it just >>>> allocates a big structure several time. >>>> So, I think -Xmx option could be removed from this test: >>>> >>>> http://cr.openjdk.java.net/~dfazunen/8169643/webrev.02/ >>>> >>>> Tested by RBT with and without -XX:-UseCompressedOpps >>>> >>> I think the limitation has been introduced so that gcbasher does >>> something useful, i.e. execute enough GCs. With a multi-GB heap at >>> its >>> disposal, I expect that the amount of GCs executed will be >>> significantly lower than it is now. >> Your arguments do certainly make sense. >>> I prefer to have a 256M limit to none; and maybe the test could be >>> run >>> once with and without UseCompressedOops with appropriate heap sizes >>> instead if there is enough cpu time in our testing infrastructure. >> I suggest to start with original version of the fix: >> http://cr.openjdk.java.net/~dfazunen/8169643/webrev.00/ >> (+ copyright updates) >> >> and submit an RFE to limit max heap size depending of >> UseCompressedOops >> value. >> Such RFE could implemented much easily after integration of >> JDK-8172417 Verundy: Library to simplify using TestNG for >> Hotspot test development >> Now it's a bit tricky to get known from the test the values of >> external tags. >> >> Are you okay with that? > yes, thanks. > > Thomas > -------------- next part -------------- An HTML attachment was scrubbed... URL: 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 michail.chernov at oracle.com Fri Jan 13 11:56:58 2017 From: michail.chernov at oracle.com (Michail Chernov) Date: Fri, 13 Jan 2017 14:56:58 +0300 Subject: RFR: 8170737: Not enough old space utilisation Message-ID: <575dc789-9c7b-2a25-ce86-13054321a083@oracle.com> Hi, Could I have a reviews for this change, please? http://cr.openjdk.java.net/~mchernov/8170737/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8170737 Test fails because Runtime.maxMemory() results depends on the heap size shrinking. So need to calculate the expected heap occupation before a garbage allocation. Tests were updated accordingly. Also GcProvokerImpl.java was removed because it was not removed on previous commit by mistake. Tested via RBT. Thanks, Michail From dmitry.fazunenko at oracle.com Fri Jan 13 16:55:11 2017 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 13 Jan 2017 19:55:11 +0300 Subject: RFR: 8170737: Not enough old space utilisation In-Reply-To: <575dc789-9c7b-2a25-ce86-13054321a083@oracle.com> References: <575dc789-9c7b-2a25-ce86-13054321a083@oracle.com> Message-ID: <55d3c7e8-db6b-98b7-03b7-363b85c36162@oracle.com> Hi Michail, GarbageProducer tries to predict at the beginning how many objects to allocate later to achieve target memory usage percent. This way doesn't look like a good idea: - objects created by libraries (during initialization) may not be collected yet - eatMetaspace() besides allocating metaspace consumes some heap space, but this amount is not taken into account. Will it make sense to use MXBean for heap as well as for metaspace? Thanks, Dima ps: one more nit: "GarbageProducer{" - please insert a space. On 13.01.2017 14:56, Michail Chernov wrote: > Hi, > > Could I have a reviews for this change, please? > > http://cr.openjdk.java.net/~mchernov/8170737/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8170737 > > Test fails because Runtime.maxMemory() results depends on the heap > size shrinking. So need to calculate the expected heap occupation > before a garbage allocation. Tests were updated accordingly. Also > GcProvokerImpl.java was removed because it was not removed on previous > commit by mistake. > Tested via RBT. > > Thanks, > Michail From alexander.harlap at oracle.com Fri Jan 13 17:48:33 2017 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Fri, 13 Jan 2017 12:48:33 -0500 Subject: Need a sponsor to push attached 8140588 Message-ID: <74511470-15a2-da62-2c83-cdee8cbf134f@oracle.com> I need a sponsor to push attached 8140588.patch - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated Patch should go into jdk9/hs/hotspot Reviewed by Per Liden, Kim Barrett and Martin Doerr. Alex -------------- next part -------------- # HG changeset patch # User aharlap # Date 1484328474 18000 # Node ID dae51c6f942a2504b8de6fe654f716f2e18a30b6 # Parent ebcd23d638c4f6329a623c739ec608476740c918 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated Summary: Re-check queue active state before updating Reviewed-by: pliden, kbarrett, mdoerr diff -r ebcd23d638c4 -r dae51c6f942a src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp --- a/src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp Fri Jan 13 07:19:03 2017 -0500 +++ b/src/cpu/aarch64/vm/c1_Runtime1_aarch64.cpp Fri Jan 13 12:27:54 2017 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2017, Oracle and/or its affiliates. All rights reserved. * Copyright (c) 2014, Red Hat Inc. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * @@ -1179,6 +1179,15 @@ Label done; Label runtime; + // Is marking still active? + if (in_bytes(SATBMarkQueue::byte_width_of_active()) == 4) { + __ ldrw(tmp, in_progress); + } else { + assert(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption"); + __ ldrb(tmp, in_progress); + } + __ cbzw(tmp, done); + // Can we store original value in the thread's buffer? __ ldr(tmp, queue_index); __ cbz(tmp, runtime); diff -r ebcd23d638c4 -r dae51c6f942a src/cpu/arm/vm/c1_Runtime1_arm.cpp --- a/src/cpu/arm/vm/c1_Runtime1_arm.cpp Fri Jan 13 07:19:03 2017 -0500 +++ b/src/cpu/arm/vm/c1_Runtime1_arm.cpp Fri Jan 13 12:27:54 2017 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2008, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2008, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -551,6 +551,8 @@ const Register r_index_1 = R1; const Register r_buffer_2 = R2; + Address queue_active(Rthread, in_bytes(JavaThread::satb_mark_queue_offset() + + SATBMarkQueue::byte_offset_of_active())); Address queue_index(Rthread, in_bytes(JavaThread::satb_mark_queue_offset() + SATBMarkQueue::byte_offset_of_index())); Address buffer(Rthread, in_bytes(JavaThread::satb_mark_queue_offset() + @@ -559,6 +561,11 @@ Label done; Label runtime; + // Is marking still active? + assert(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption"); + __ ldrb(R1, queue_active); + __ cbz(R1, done); + __ ldr(r_index_1, queue_index); __ ldr(r_pre_val_0, Address(SP, nb_saved_regs*wordSize)); __ ldr(r_buffer_2, buffer); diff -r ebcd23d638c4 -r dae51c6f942a src/cpu/ppc/vm/c1_Runtime1_ppc.cpp --- a/src/cpu/ppc/vm/c1_Runtime1_ppc.cpp Fri Jan 13 07:19:03 2017 -0500 +++ b/src/cpu/ppc/vm/c1_Runtime1_ppc.cpp Fri Jan 13 12:27:54 2017 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2017, Oracle and/or its affiliates. All rights reserved. * Copyright (c) 2012, 2015 SAP SE. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * @@ -741,7 +741,10 @@ Register tmp = R14; Register tmp2 = R15; - Label refill, restart; + Label refill, restart, marking_not_active; + int satb_q_active_byte_offset = + in_bytes(JavaThread::satb_mark_queue_offset() + + SATBMarkQueue::byte_offset_of_active()); int satb_q_index_byte_offset = in_bytes(JavaThread::satb_mark_queue_offset() + SATBMarkQueue::byte_offset_of_index()); @@ -753,6 +756,16 @@ __ std(tmp, -16, R1_SP); __ std(tmp2, -24, R1_SP); + // Is marking still active? + if (in_bytes(SATBMarkQueue::byte_width_of_active()) == 4) { + __ lwz(tmp, satb_q_active_byte_offset, R16_thread); + } else { + assert(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption"); + __ lbz(tmp, satb_q_active_byte_offset, R16_thread); + } + __ cmpdi(CCR0, tmp, 0); + __ beq(CCR0, marking_not_active); + __ bind(restart); // Load the index into the SATB buffer. SATBMarkQueue::_index is a // size_t so ld_ptr is appropriate. @@ -769,6 +782,7 @@ __ std(tmp, satb_q_index_byte_offset, R16_thread); __ stdx(pre_val, tmp2, tmp); // [_buf + index] := + __ bind(marking_not_active); // Restore temp registers and return-from-leaf. __ ld(tmp2, -24, R1_SP); __ ld(tmp, -16, R1_SP); diff -r ebcd23d638c4 -r dae51c6f942a src/cpu/s390/vm/c1_Runtime1_s390.cpp --- a/src/cpu/s390/vm/c1_Runtime1_s390.cpp Fri Jan 13 07:19:03 2017 -0500 +++ b/src/cpu/s390/vm/c1_Runtime1_s390.cpp Fri Jan 13 12:27:54 2017 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2017 Oracle and/or its affiliates. All rights reserved. * Copyright (c) 2016 SAP SE. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * @@ -784,7 +784,10 @@ Register tmp = Z_R6; // Must be non-volatile because it is used to save pre_val. Register tmp2 = Z_R7; - Label refill, restart; + Label refill, restart, marking_not_active; + int satb_q_active_byte_offset = + in_bytes(JavaThread::satb_mark_queue_offset() + + SATBMarkQueue::byte_offset_of_active()); int satb_q_index_byte_offset = in_bytes(JavaThread::satb_mark_queue_offset() + SATBMarkQueue::byte_offset_of_index()); @@ -796,6 +799,15 @@ __ z_stg(tmp, 0*BytesPerWord + FrameMap::first_available_sp_in_frame, Z_SP); __ z_stg(tmp2, 1*BytesPerWord + FrameMap::first_available_sp_in_frame, Z_SP); + // Is marking still active? + if (in_bytes(SATBMarkQueue::byte_width_of_active()) == 4) { + __ load_and_test_int(tmp, Address(Z_thread, satb_q_active_byte_offset)); + } else { + assert(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption"); + __ 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. + __ bind(restart); // Load the index into the SATB buffer. SATBMarkQueue::_index is a // size_t so ld_ptr is appropriate. @@ -810,6 +822,7 @@ __ z_stg(pre_val, 0, tmp, tmp2); // [_buf + index] := __ z_stg(tmp, satb_q_index_byte_offset, Z_thread); + __ bind(marking_not_active); // Restore tmp registers (see assertion in G1PreBarrierStub::emit_code()). __ z_lg(tmp, 0*BytesPerWord + FrameMap::first_available_sp_in_frame, Z_SP); __ z_lg(tmp2, 1*BytesPerWord + FrameMap::first_available_sp_in_frame, Z_SP); diff -r ebcd23d638c4 -r dae51c6f942a src/cpu/sparc/vm/c1_Runtime1_sparc.cpp --- a/src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Fri Jan 13 07:19:03 2017 -0500 +++ b/src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Fri Jan 13 12:27:54 2017 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -856,7 +856,9 @@ Register tmp2 = G3_scratch; Label refill, restart; - bool with_frame = false; // I don't know if we can do with-frame. + int satb_q_active_byte_offset = + in_bytes(JavaThread::satb_mark_queue_offset() + + SATBMarkQueue::byte_offset_of_active()); int satb_q_index_byte_offset = in_bytes(JavaThread::satb_mark_queue_offset() + SATBMarkQueue::byte_offset_of_index()); @@ -864,6 +866,17 @@ in_bytes(JavaThread::satb_mark_queue_offset() + SATBMarkQueue::byte_offset_of_buf()); + // Is marking still active? + if (in_bytes(SATBMarkQueue::byte_width_of_active()) == 4) { + __ ld(G2_thread, satb_q_active_byte_offset, tmp); + } else { + assert(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption"); + __ ldsb(G2_thread, satb_q_active_byte_offset, tmp); + } + __ cmp_and_br_short(tmp, G0, Assembler::notEqual, Assembler::pt, restart); + __ retl(); + __ delayed()->nop(); + __ bind(restart); // Load the index into the SATB buffer. SATBMarkQueue::_index is a // size_t so ld_ptr is appropriate diff -r ebcd23d638c4 -r dae51c6f942a src/cpu/x86/vm/c1_Runtime1_x86.cpp --- a/src/cpu/x86/vm/c1_Runtime1_x86.cpp Fri Jan 13 07:19:03 2017 -0500 +++ b/src/cpu/x86/vm/c1_Runtime1_x86.cpp Fri Jan 13 12:27:54 2017 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2015, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -1623,6 +1623,8 @@ NOT_LP64(__ get_thread(thread);) + Address queue_active(thread, in_bytes(JavaThread::satb_mark_queue_offset() + + SATBMarkQueue::byte_offset_of_active())); Address queue_index(thread, in_bytes(JavaThread::satb_mark_queue_offset() + SATBMarkQueue::byte_offset_of_index())); Address buffer(thread, in_bytes(JavaThread::satb_mark_queue_offset() + @@ -1631,6 +1633,15 @@ Label done; Label runtime; + // Is marking still active? + if (in_bytes(SATBMarkQueue::byte_width_of_active()) == 4) { + __ cmpl(queue_active, 0); + } else { + assert(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption"); + __ cmpb(queue_active, 0); + } + __ jcc(Assembler::equal, done); + // Can we store original value in the thread's buffer? __ movptr(tmp, queue_index); From kim.barrett at oracle.com Fri Jan 13 19:45:00 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 13 Jan 2017 14:45:00 -0500 Subject: Need a sponsor to push attached 8140588 In-Reply-To: <74511470-15a2-da62-2c83-cdee8cbf134f@oracle.com> References: <74511470-15a2-da62-2c83-cdee8cbf134f@oracle.com> Message-ID: <57B663FB-1792-4D91-B9D1-17B0CA6D3B8F@oracle.com> > On Jan 13, 2017, at 12:48 PM, Alexander Harlap wrote: > > I need a sponsor to push attached 8140588.patch - Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated > > Patch should go into jdk9/hs/hotspot > > Reviewed by Per Liden, Kim Barrett and Martin Doerr. > > > Alex I?ll sponsor. From alexander.harlap at oracle.com Wed Jan 18 15:57:56 2017 From: alexander.harlap at oracle.com (Alexander Harlap) Date: Wed, 18 Jan 2017 10:57:56 -0500 Subject: Fwd: Request for review JDK-8169634 - Logging fails with 'pure virtual method called' In-Reply-To: <2cfde1f0-b7ea-bac1-722b-b0577acbac87@oracle.com> References: <2cfde1f0-b7ea-bac1-722b-b0577acbac87@oracle.com> Message-ID: <07e5c385-799e-cab4-807c-622f0ef3b1f4@oracle.com> Hi David, Here is a link to stalled code review where I wanted to fix problem by avoiding globals. What is your opinion? Thank you, Alex -------- Forwarded Message -------- Subject: Request for review JDK-8169634 - Logging fails with 'pure virtual method called' Date: Tue, 20 Dec 2016 17:16:10 -0500 From: Alexander Harlap Organization: Oracle Corporation To: hotspot-gc-dev at openjdk.java.net Please review suggested change for JDK-8169634 - Logging fails with 'pure virtual method called' Change is located at http://cr.openjdk.java.net/~aharlap/8169634/webrev.00/ Reported problem points to access virtual method of of statically initialized object MarkSweep::follow_root_closure after calling global destructor for that object (from exit()). Currently AllStatic class MarkSweep declares few statically allocated closures and Stack<..> objects. Suggested change converts MarkSweep class and all its closures and stacks<..> to be the stack allocated objects. Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jan 19 00:50:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Jan 2017 10:50:53 +1000 Subject: Fwd: Request for review JDK-8169634 - Logging fails with 'pure virtual method called' In-Reply-To: <07e5c385-799e-cab4-807c-622f0ef3b1f4@oracle.com> References: <2cfde1f0-b7ea-bac1-722b-b0577acbac87@oracle.com> <07e5c385-799e-cab4-807c-622f0ef3b1f4@oracle.com> Message-ID: Hi Alex, I think reducing dependencies on statically initialized and destroyed globals is a good thing, but unless they are all eradicated then it just narrows the window for potential problems. There has been a lot of discussion around 8169634 and the crash is just a symptom of the real underlying problem - which is termination of the VM process without shutting down the VM first. So this has been passed back to the launcher folk to see how to make things more robust - with suggestions now in the bug report. Thanks, David On 19/01/2017 1:57 AM, Alexander Harlap wrote: > Hi David, > > Here is a link to stalled code review where I wanted to fix problem by > avoiding globals. > > What is your opinion? > > > Thank you, > > Alex > > > > > -------- Forwarded Message -------- > Subject: Request for review JDK-8169634 - Logging fails with 'pure > virtual method called' > Date: Tue, 20 Dec 2016 17:16:10 -0500 > From: Alexander Harlap > Organization: Oracle Corporation > To: hotspot-gc-dev at openjdk.java.net > > > > Please review suggested change for JDK-8169634 > - Logging fails with > 'pure virtual method called' > > Change is located at http://cr.openjdk.java.net/~aharlap/8169634/webrev.00/ > > Reported problem points to access virtual method of of statically > initialized object MarkSweep::follow_root_closure after calling global > destructor for that object (from exit()). > > Currently AllStatic class MarkSweep declares few statically allocated > closures and Stack<..> objects. > > Suggested change converts MarkSweep class and all its closures and > stacks<..> to be the stack allocated objects. > > Alex > > > From david.holmes at oracle.com Thu Jan 19 01:24:23 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Jan 2017 11:24:23 +1000 Subject: RFR (XS) 8172972: Add gc/g1/logging/TestG1LoggingFailure.java to the ProblemList Message-ID: <7cc560e2-498c-cb0e-7e32-26775726a3b3@oracle.com> Subject says it all. bug: https://bugs.openjdk.java.net/browse/JDK-8172972 Related/blocking bug: https://bugs.openjdk.java.net/browse/JDK-8169634 webrev: http://cr.openjdk.java.net/~dholmes/8172972/webrev/ Patch below for convenience Thanks, David ----- --- old/test/ProblemList.txt 2017-01-18 20:08:23.481992142 -0500 +++ new/test/ProblemList.txt 2017-01-18 20:08:21.513878841 -0500 @@ -1,5 +1,5 @@ # -# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # # This code is free software; you can redistribute it and/or modify it @@ -55,6 +55,7 @@ gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java 8156755 generic-all gc/survivorAlignment/TestPromotionToSurvivor.java 8129886 generic-all +gc/g1/logging/TestG1LoggingFailure.java 8169634 generic-all ############################################################################# From kim.barrett at oracle.com Thu Jan 19 23:46:17 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 19 Jan 2017 18:46:17 -0500 Subject: RFR (XS) 8172972: Add gc/g1/logging/TestG1LoggingFailure.java to the ProblemList In-Reply-To: <7cc560e2-498c-cb0e-7e32-26775726a3b3@oracle.com> References: <7cc560e2-498c-cb0e-7e32-26775726a3b3@oracle.com> Message-ID: <6280E010-210A-4522-8CCE-16526B34055D@oracle.com> > On Jan 18, 2017, at 8:24 PM, David Holmes wrote: > > Subject says it all. > > bug: https://bugs.openjdk.java.net/browse/JDK-8172972 > > Related/blocking bug: https://bugs.openjdk.java.net/browse/JDK-8169634 > > webrev: http://cr.openjdk.java.net/~dholmes/8172972/webrev/ > > Patch below for convenience > > Thanks, > David > ----- > > --- old/test/ProblemList.txt 2017-01-18 20:08:23.481992142 -0500 > +++ new/test/ProblemList.txt 2017-01-18 20:08:21.513878841 -0500 > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. > +# Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. > # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > # > # This code is free software; you can redistribute it and/or modify it > @@ -55,6 +55,7 @@ > > gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java 8156755 generic-all > gc/survivorAlignment/TestPromotionToSurvivor.java 8129886 generic-all > +gc/g1/logging/TestG1LoggingFailure.java 8169634 generic-all > > ############################################################################# Looks good. Reviewed. Also looks trivial. From david.holmes at oracle.com Thu Jan 19 23:51:43 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Jan 2017 09:51:43 +1000 Subject: RFR (XS) 8172972: Add gc/g1/logging/TestG1LoggingFailure.java to the ProblemList In-Reply-To: <6280E010-210A-4522-8CCE-16526B34055D@oracle.com> References: <7cc560e2-498c-cb0e-7e32-26775726a3b3@oracle.com> <6280E010-210A-4522-8CCE-16526B34055D@oracle.com> Message-ID: Thanks Kim. Will push under trivial change rule. David On 20/01/2017 9:46 AM, Kim Barrett wrote: >> On Jan 18, 2017, at 8:24 PM, David Holmes wrote: >> >> Subject says it all. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8172972 >> >> Related/blocking bug: https://bugs.openjdk.java.net/browse/JDK-8169634 >> >> webrev: http://cr.openjdk.java.net/~dholmes/8172972/webrev/ >> >> Patch below for convenience >> >> Thanks, >> David >> ----- >> >> --- old/test/ProblemList.txt 2017-01-18 20:08:23.481992142 -0500 >> +++ new/test/ProblemList.txt 2017-01-18 20:08:21.513878841 -0500 >> @@ -1,5 +1,5 @@ >> # >> -# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. >> +# Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved. >> # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> # >> # This code is free software; you can redistribute it and/or modify it >> @@ -55,6 +55,7 @@ >> >> gc/g1/humongousObjects/objectGraphTest/TestObjectGraphAfterGC.java 8156755 generic-all >> gc/survivorAlignment/TestPromotionToSurvivor.java 8129886 generic-all >> +gc/g1/logging/TestG1LoggingFailure.java 8169634 generic-all >> >> ############################################################################# > > Looks good. Reviewed. > > Also looks trivial. > From michail.chernov at oracle.com Tue Jan 24 14:52:15 2017 From: michail.chernov at oracle.com (Michail Chernov) Date: Tue, 24 Jan 2017 17:52:15 +0300 Subject: RFR: 8170737: Not enough old space utilisation In-Reply-To: <55d3c7e8-db6b-98b7-03b7-363b85c36162@oracle.com> References: <575dc789-9c7b-2a25-ce86-13054321a083@oracle.com> <55d3c7e8-db6b-98b7-03b7-363b85c36162@oracle.com> Message-ID: Hi Dima, Thanks for your response. Updated webrev: http://cr.openjdk.java.net/~mchernov/8170737/webrev.01/ Tests were refactored. There were several problems: 1. Checking of jstat output consistency should not be performed during GC cycles because it can cause to additional failures. There is checking in GarbageProducerTestBase.java that during jstat execution were not any GC cycles. Jstat gets performance counters values sequentially, so GC cycles should be avoided. 2. New gen size should be limited, because there can be OOME while eating 70% of heap on some configurations. 3. Tests failed to get expected old gen occupancy because background VM activity can change real occupancy. Now tests check real heap occupancy (using MXBean) and compares it with jstat output. The testing is in progress. Thanks, Michail On 13/01/2017 19:55, Dmitry Fazunenko wrote: > Hi Michail, > > GarbageProducer tries to predict at the beginning how many objects to > allocate later to achieve target memory usage percent. > This way doesn't look like a good idea: > - objects created by libraries (during initialization) may not be > collected yet > - eatMetaspace() besides allocating metaspace consumes some heap > space, but this amount is not taken into account. > > Will it make sense to use MXBean for heap as well as for metaspace? > > Thanks, > Dima > > ps: one more nit: "GarbageProducer{" - please insert a space. > > On 13.01.2017 14:56, Michail Chernov wrote: >> Hi, >> >> Could I have a reviews for this change, please? >> >> http://cr.openjdk.java.net/~mchernov/8170737/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8170737 >> >> Test fails because Runtime.maxMemory() results depends on the heap >> size shrinking. So need to calculate the expected heap occupation >> before a garbage allocation. Tests were updated accordingly. Also >> GcProvokerImpl.java was removed because it was not removed on >> previous commit by mistake. >> Tested via RBT. >> >> Thanks, >> Michail > > From michail.chernov at oracle.com Thu Jan 26 11:00:39 2017 From: michail.chernov at oracle.com (Michail Chernov) Date: Thu, 26 Jan 2017 14:00:39 +0300 Subject: RFR: 8170737: Not enough old space utilisation In-Reply-To: References: <575dc789-9c7b-2a25-ce86-13054321a083@oracle.com> <55d3c7e8-db6b-98b7-03b7-363b85c36162@oracle.com> Message-ID: Hi, I updated the webrev according to offline coments from Dmitry Fazunenko. GarbageProducerTestBase was renamed to GarbageProducerTest. GcCauseTest02 and GcTest02 now uses GarbageProducerTest directly without inheritance. http://cr.openjdk.java.net/~mchernov/8170737/webrev.02_to_01/ http://cr.openjdk.java.net/~mchernov/8170737/webrev.02/ Thanks, Michail On 24/01/2017 17:52, Michail Chernov wrote: > Hi Dima, > > Thanks for your response. > > Updated webrev: > http://cr.openjdk.java.net/~mchernov/8170737/webrev.01/ > > Tests were refactored. > There were several problems: > 1. Checking of jstat output consistency should not be performed during > GC cycles because it can cause to additional failures. There is > checking in GarbageProducerTestBase.java that during jstat execution > were not any GC cycles. Jstat gets performance counters values > sequentially, so GC cycles should be avoided. > 2. New gen size should be limited, because there can be OOME while > eating 70% of heap on some configurations. > 3. Tests failed to get expected old gen occupancy because background > VM activity can change real occupancy. Now tests check real heap > occupancy (using MXBean) and compares it with jstat output. > > The testing is in progress. > > Thanks, > Michail > > On 13/01/2017 19:55, Dmitry Fazunenko wrote: >> Hi Michail, >> >> GarbageProducer tries to predict at the beginning how many objects to >> allocate later to achieve target memory usage percent. >> This way doesn't look like a good idea: >> - objects created by libraries (during initialization) may not be >> collected yet >> - eatMetaspace() besides allocating metaspace consumes some heap >> space, but this amount is not taken into account. >> >> Will it make sense to use MXBean for heap as well as for metaspace? >> >> Thanks, >> Dima >> >> ps: one more nit: "GarbageProducer{" - please insert a space. >> >> On 13.01.2017 14:56, Michail Chernov wrote: >>> Hi, >>> >>> Could I have a reviews for this change, please? >>> >>> http://cr.openjdk.java.net/~mchernov/8170737/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8170737 >>> >>> Test fails because Runtime.maxMemory() results depends on the heap >>> size shrinking. So need to calculate the expected heap occupation >>> before a garbage allocation. Tests were updated accordingly. Also >>> GcProvokerImpl.java was removed because it was not removed on >>> previous commit by mistake. >>> Tested via RBT. >>> >>> Thanks, >>> Michail >> >> > > From thomas.schatzl at oracle.com Thu Jan 26 11:25:59 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 26 Jan 2017 12:25:59 +0100 Subject: RFR (XS): 8173229: Wrong assert whether all remembered set entries have been iterated over in presence of coarsenings Message-ID: <1485429959.3308.16.camel@oracle.com> Hi all, ? can I get reviews for this change that removes an assert with a wrong condition? The problem is that G1 remset management intentionally does not properly synchronize state when one thread adds a remembered set entry to a fine PRT and another thread coarsens that one. In that case, the PRT's bitmap and separate occupancy counter can get inconsistent in basically all possible benign ways (i.e. one bit too many in the bitmap, or one bit too few) every time. This behavior is documented at the top of heapRegionRemSet.cpp, but the assert tries to verify that the number of iterated fine PRT remembered set entries corresponds to what the fine PRT thinks it is. My solution to that problem is to remove that assert (and some additional dead code that does the same thing). The reason is that fixing this assert seems not worth the effort: - the existing assert is only checked if we have only one worker thread. This seems unusual nowadays, kind of supported by the fact that this assert has been introduced on day one, and apparently never before triggered in this case. - one could add a check to further tighten the assert, i.e. only check if there were no coarsenings; however the #coarsenings counter is a global right now, which means that any remembered set coarsening at any point during execution disables this check completely. - one could do extensive analysis of the situation and then update the PRTs to fix it so that next time we don't need to get into this situation again. However, that would make the assert even slower (counting occupied cards is very slow), and I am kind of against an assertion that updates state... CR: https://bugs.openjdk.java.net/browse/JDK-8173229 Webrev: http://cr.openjdk.java.net/~tschatzl/8173229/webrev/ Testing: Did 1000+ runs of that test with remembered set verification without issues. Previous runs showed that the situation occurs every 50-100 runs, so it should have been checked a few times already. Thanks, ? Thomas From dmitry.fazunenko at oracle.com Thu Jan 26 11:54:52 2017 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 26 Jan 2017 14:54:52 +0300 Subject: RFR: 8170737: Not enough old space utilisation In-Reply-To: References: <575dc789-9c7b-2a25-ce86-13054321a083@oracle.com> <55d3c7e8-db6b-98b7-03b7-363b85c36162@oracle.com> Message-ID: Hi Michail, new version looks good to me. Thanks for addressing my comments. -- Dima On 26.01.2017 14:00, Michail Chernov wrote: > Hi, > > I updated the webrev according to offline coments from Dmitry Fazunenko. > GarbageProducerTestBase was renamed to GarbageProducerTest. > GcCauseTest02 and GcTest02 now uses GarbageProducerTest directly > without inheritance. > > http://cr.openjdk.java.net/~mchernov/8170737/webrev.02_to_01/ > http://cr.openjdk.java.net/~mchernov/8170737/webrev.02/ > > Thanks, > Michail > > On 24/01/2017 17:52, Michail Chernov wrote: >> Hi Dima, >> >> Thanks for your response. >> >> Updated webrev: >> http://cr.openjdk.java.net/~mchernov/8170737/webrev.01/ >> >> Tests were refactored. >> There were several problems: >> 1. Checking of jstat output consistency should not be performed >> during GC cycles because it can cause to additional failures. There >> is checking in GarbageProducerTestBase.java that during jstat >> execution were not any GC cycles. Jstat gets performance counters >> values sequentially, so GC cycles should be avoided. >> 2. New gen size should be limited, because there can be OOME while >> eating 70% of heap on some configurations. >> 3. Tests failed to get expected old gen occupancy because background >> VM activity can change real occupancy. Now tests check real heap >> occupancy (using MXBean) and compares it with jstat output. >> >> The testing is in progress. >> >> Thanks, >> Michail >> >> On 13/01/2017 19:55, Dmitry Fazunenko wrote: >>> Hi Michail, >>> >>> GarbageProducer tries to predict at the beginning how many objects >>> to allocate later to achieve target memory usage percent. >>> This way doesn't look like a good idea: >>> - objects created by libraries (during initialization) may not be >>> collected yet >>> - eatMetaspace() besides allocating metaspace consumes some heap >>> space, but this amount is not taken into account. >>> >>> Will it make sense to use MXBean for heap as well as for metaspace? >>> >>> Thanks, >>> Dima >>> >>> ps: one more nit: "GarbageProducer{" - please insert a space. >>> >>> On 13.01.2017 14:56, Michail Chernov wrote: >>>> Hi, >>>> >>>> Could I have a reviews for this change, please? >>>> >>>> http://cr.openjdk.java.net/~mchernov/8170737/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8170737 >>>> >>>> Test fails because Runtime.maxMemory() results depends on the heap >>>> size shrinking. So need to calculate the expected heap occupation >>>> before a garbage allocation. Tests were updated accordingly. Also >>>> GcProvokerImpl.java was removed because it was not removed on >>>> previous commit by mistake. >>>> Tested via RBT. >>>> >>>> Thanks, >>>> Michail >>> >>> >> >> > From mikael.gerdin at oracle.com Thu Jan 26 12:47:51 2017 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Thu, 26 Jan 2017 13:47:51 +0100 Subject: RFR (XS): 8173229: Wrong assert whether all remembered set entries have been iterated over in presence of coarsenings In-Reply-To: <1485429959.3308.16.camel@oracle.com> References: <1485429959.3308.16.camel@oracle.com> Message-ID: <69abd823-f02e-8ede-df05-3b8401af22d1@oracle.com> Hi Thomas, On 2017-01-26 12:25, Thomas Schatzl wrote: > Hi all, > > can I get reviews for this change that removes an assert with a wrong > condition? > > The problem is that G1 remset management intentionally does not > properly synchronize state when one thread adds a remembered set entry > to a fine PRT and another thread coarsens that one. In that case, the > PRT's bitmap and separate occupancy counter can get inconsistent in > basically all possible benign ways (i.e. one bit too many in the > bitmap, or one bit too few) every time. > > This behavior is documented at the top of heapRegionRemSet.cpp, but the > assert tries to verify that the number of iterated fine PRT remembered > set entries corresponds to what the fine PRT thinks it is. > > My solution to that problem is to remove that assert (and some > additional dead code that does the same thing). The reason is that > fixing this assert seems not worth the effort: > > - the existing assert is only checked if we have only one worker > thread. This seems unusual nowadays, kind of supported by the fact that > this assert has been introduced on day one, and apparently never before > triggered in this case. > > - one could add a check to further tighten the assert, i.e. only check > if there were no coarsenings; however the #coarsenings counter is a > global right now, which means that any remembered set coarsening at any > point during execution disables this check completely. > > - one could do extensive analysis of the situation and then update the > PRTs to fix it so that next time we don't need to get into this > situation again. However, that would make the assert even slower > (counting occupied cards is very slow), and I am kind of against an > assertion that updates state... > > CR: > https://bugs.openjdk.java.net/browse/JDK-8173229 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8173229/webrev/ Looks good to me. /Mikael > Testing: > Did 1000+ runs of that test with remembered set verification without > issues. Previous runs showed that the situation occurs every 50-100 > runs, so it should have been checked a few times already. > > Thanks, > Thomas > From erik.helin at oracle.com Thu Jan 26 13:13:01 2017 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 26 Jan 2017 14:13:01 +0100 Subject: RFR (XS): 8173229: Wrong assert whether all remembered set entries have been iterated over in presence of coarsenings In-Reply-To: <1485429959.3308.16.camel@oracle.com> References: <1485429959.3308.16.camel@oracle.com> Message-ID: On 01/26/2017 12:25 PM, Thomas Schatzl wrote: > Hi all, > > can I get reviews for this change that removes an assert with a wrong > condition? > > The problem is that G1 remset management intentionally does not > properly synchronize state when one thread adds a remembered set entry > to a fine PRT and another thread coarsens that one. In that case, the > PRT's bitmap and separate occupancy counter can get inconsistent in > basically all possible benign ways (i.e. one bit too many in the > bitmap, or one bit too few) every time. > > This behavior is documented at the top of heapRegionRemSet.cpp, but the > assert tries to verify that the number of iterated fine PRT remembered > set entries corresponds to what the fine PRT thinks it is. > > My solution to that problem is to remove that assert (and some > additional dead code that does the same thing). The reason is that > fixing this assert seems not worth the effort: > > - the existing assert is only checked if we have only one worker > thread. This seems unusual nowadays, kind of supported by the fact that > this assert has been introduced on day one, and apparently never before > triggered in this case. > > - one could add a check to further tighten the assert, i.e. only check > if there were no coarsenings; however the #coarsenings counter is a > global right now, which means that any remembered set coarsening at any > point during execution disables this check completely. > > - one could do extensive analysis of the situation and then update the > PRTs to fix it so that next time we don't need to get into this > situation again. However, that would make the assert even slower > (counting occupied cards is very slow), and I am kind of against an > assertion that updates state... > > CR: > https://bugs.openjdk.java.net/browse/JDK-8173229 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8173229/webrev/ Looks good, Reviewed. Thanks for fixing this! Erik > Testing: > Did 1000+ runs of that test with remembered set verification without > issues. Previous runs showed that the situation occurs every 50-100 > runs, so it should have been checked a few times already. > > Thanks, > Thomas > From thomas.schatzl at oracle.com Thu Jan 26 13:20:53 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 26 Jan 2017 14:20:53 +0100 Subject: RFR (XS): 8173229: Wrong assert whether all remembered set entries have been iterated over in presence of coarsenings In-Reply-To: References: <1485429959.3308.16.camel@oracle.com> Message-ID: <1485436853.3308.18.camel@oracle.com> Hi Erik, On Thu, 2017-01-26 at 14:13 +0100, Erik Helin wrote: > On 01/26/2017 12:25 PM, Thomas Schatzl wrote: > > > > Hi all, > > > > ? can I get reviews for this change that removes an assert with a > > wrong > > condition? > > [...] > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8173229 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8173229/webrev/ > Looks good, Reviewed. Thanks for fixing this! ? thanks for your review. Thomas From thomas.schatzl at oracle.com Thu Jan 26 13:21:19 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 26 Jan 2017 14:21:19 +0100 Subject: RFR (XS): 8173229: Wrong assert whether all remembered set entries have been iterated over in presence of coarsenings In-Reply-To: <69abd823-f02e-8ede-df05-3b8401af22d1@oracle.com> References: <1485429959.3308.16.camel@oracle.com> <69abd823-f02e-8ede-df05-3b8401af22d1@oracle.com> Message-ID: <1485436879.3308.19.camel@oracle.com> Hi Mikael, On Thu, 2017-01-26 at 13:47 +0100, Mikael Gerdin wrote: > Hi Thomas, > > On 2017-01-26 12:25, Thomas Schatzl wrote: > > > > Hi all, > > > > ? can I get reviews for this change that removes an assert with a > > wrong > > condition? > > [...] > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8173229 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8173229/webrev/ > Looks good to me. > /Mikael ? thanks for your review. Thomas