From vladimir.x.ivanov at oracle.com Wed Oct 1 07:59:25 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 01 Oct 2014 11:59:25 +0400 Subject: [9] RFR(S): 8059390: code cache fills up for bigapps/Weblogic+medrec/nowarnings In-Reply-To: <542ABA84.2010902@oracle.com> References: <542ABA84.2010902@oracle.com> Message-ID: <542BB45D.8070407@oracle.com> Looks good. Best regards, Vladimir Ivanov On 9/30/14, 6:13 PM, Zolt?n Maj? wrote: > Hi, > > > please review the following patch (contributed by Tobias Hartmann): > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059390 > > Problem: The code cache fills up for the test > bigapps/Weblogic+medrec/nowarnings. Affected platforms are: linux_x64, > solaris_sparcv9, windows_x64-64, solaris_x64, with tiered compilation > both on/off. > > Solution: The bug is caused by the segmented code cache changes > JDK-8015774. The problem is that with -XX:-SegmentedCodeCache > 'CodeCache::reverse_free_ratio' always returns 0 because > 'CodeCache::get_code_heap' returns NULL for > CodeBlobType::MethodNonProfiled and CodeBlobType::MethodProfiled. > > Retrieve code heap in CodeCache ::allocate(), in > CodeCache::report_codemem_full(), and in > CodeCache::unallocated_capacity() also if segmented code cache is disabled. > > Webrev: http://cr.openjdk.java.net/~zmajo/8059390/webrev.00/ > > Testing: > > JPRT > Aurora Weblogic+medrec on solaris_x64, solaris_sparcv9 and linux_amd64. > > Thank you and best regards, > > > Zoltan > From zoltan.majo at oracle.com Wed Oct 1 07:59:44 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 01 Oct 2014 09:59:44 +0200 Subject: [9] RFR(S): 8059390: code cache fills up for bigapps/Weblogic+medrec/nowarnings In-Reply-To: <542BB45D.8070407@oracle.com> References: <542ABA84.2010902@oracle.com> <542BB45D.8070407@oracle.com> Message-ID: <542BB470.8020301@oracle.com> Thank you, Vladimir and Tobias. Best regards, Zoltan On 10/01/2014 09:59 AM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 9/30/14, 6:13 PM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following patch (contributed by Tobias Hartmann): >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059390 >> >> Problem: The code cache fills up for the test >> bigapps/Weblogic+medrec/nowarnings. Affected platforms are: linux_x64, >> solaris_sparcv9, windows_x64-64, solaris_x64, with tiered compilation >> both on/off. >> >> Solution: The bug is caused by the segmented code cache changes >> JDK-8015774. The problem is that with -XX:-SegmentedCodeCache >> 'CodeCache::reverse_free_ratio' always returns 0 because >> 'CodeCache::get_code_heap' returns NULL for >> CodeBlobType::MethodNonProfiled and CodeBlobType::MethodProfiled. >> >> Retrieve code heap in CodeCache ::allocate(), in >> CodeCache::report_codemem_full(), and in >> CodeCache::unallocated_capacity() also if segmented code cache is >> disabled. >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8059390/webrev.00/ >> >> Testing: >> >> JPRT >> Aurora Weblogic+medrec on solaris_x64, solaris_sparcv9 and linux_amd64. >> >> Thank you and best regards, >> >> >> Zoltan >> From vladimir.x.ivanov at oracle.com Wed Oct 1 11:07:27 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 01 Oct 2014 15:07:27 +0400 Subject: [9] RFR (XS): 8058828: Wrong ciConstant type for arrays from ConstantPool::_resolved_reference Message-ID: <542BE06F.9080903@oracle.com> http://cr.openjdk.java.net/~vlivanov/8058828/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8058828 There are 2 unrelated problems for the same scenario. ciEnv::get_constant_by_index_impl doesn't distinguish T_OBJECT & T_ARRAY cases for constant pool patches in VM anonymous classes. The fix is to adjust the type, if a constant value is an array. ciTypeFlow::StateVector::do_ldc has too strong assertion. Since basic_type = {T_OBJECT|T_ARRAY}, obj->is_array() should be also expected. Testing: failing tests, regression test. Thanks! Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Wed Oct 1 16:43:24 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 01 Oct 2014 20:43:24 +0400 Subject: [9] RFR (XXS): 8059556: C2: crash while inlining MethodHandle invocation w/ null receiver Message-ID: <542C2F2C.8030006@oracle.com> http://cr.openjdk.java.net/~vlivanov/8059556/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8059556 In case a receiver == null and it is a compile-time constant, it's type is TypePtr::NULL_PTR and it is not an oop pointer. Hence, receiver_type == NULL. There's no purpose in computing speculative_receiver_type in such case. Make the code in agreement with the similar speculative code in Parse::do_call(). Testing: regression test Thanks! Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Wed Oct 1 17:07:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Oct 2014 10:07:37 -0700 Subject: [9] RFR (XXS): 8059556: C2: crash while inlining MethodHandle invocation w/ null receiver In-Reply-To: <542C2F2C.8030006@oracle.com> References: <542C2F2C.8030006@oracle.com> Message-ID: <542C34D9.1050208@oracle.com> Changes are good. Thank you for fixing it. We need to backport it too after testing in jdk9. Thanks, Vladimir On 10/1/14 9:43 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8059556/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8059556 > > In case a receiver == null and it is a compile-time constant, it's type is TypePtr::NULL_PTR and it is not an oop > pointer. Hence, receiver_type == NULL. There's no purpose in computing speculative_receiver_type in such case. > > Make the code in agreement with the similar speculative code in Parse::do_call(). > > Testing: regression test > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Wed Oct 1 17:15:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Oct 2014 10:15:37 -0700 Subject: [9] RFR (XS): 8058828: Wrong ciConstant type for arrays from ConstantPool::_resolved_reference In-Reply-To: <542BE06F.9080903@oracle.com> References: <542BE06F.9080903@oracle.com> Message-ID: <542C36B9.2030703@oracle.com> On 10/1/14 4:07 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8058828/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8058828 > > There are 2 unrelated problems for the same scenario. > > ciEnv::get_constant_by_index_impl doesn't distinguish T_OBJECT & T_ARRAY cases for constant pool patches in VM anonymous > classes. > The fix is to adjust the type, if a constant value is an array. Should we add check that class is anonymous? Can this be in normal class? > > ciTypeFlow::StateVector::do_ldc has too strong assertion. Since basic_type = {T_OBJECT|T_ARRAY}, obj->is_array() should > be also expected. This is good. Thanks, Vladimir > > Testing: failing tests, regression test. > > Thanks! > > Best regards, > Vladimir Ivanov From john.r.rose at oracle.com Wed Oct 1 17:34:38 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Oct 2014 10:34:38 -0700 Subject: [9] RFR (XS): 8058828: Wrong ciConstant type for arrays from ConstantPool::_resolved_reference In-Reply-To: <542C36B9.2030703@oracle.com> References: <542BE06F.9080903@oracle.com> <542C36B9.2030703@oracle.com> Message-ID: <917CC1A7-28AE-44AE-B2AD-D5664ADA8A47@oracle.com> Reviewed. On Oct 1, 2014, at 10:15 AM, Vladimir Kozlov wrote: > On 10/1/14 4:07 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8058828/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8058828 >> >> There are 2 unrelated problems for the same scenario. >> >> ciEnv::get_constant_by_index_impl doesn't distinguish T_OBJECT & T_ARRAY cases for constant pool patches in VM anonymous >> classes. >> The fix is to adjust the type, if a constant value is an array. > > Should we add check that class is anonymous? Can this be in normal class? It can't be a normal class at present. When we get array constants, that will change. I lean towards keeping the assert as-is, and not adding a new test for kind of class. But I would be OK either way. ? John > >> ciTypeFlow::StateVector::do_ldc has too strong assertion. Since basic_type = {T_OBJECT|T_ARRAY}, obj->is_array() should >> be also expected. > > This is good. > > Thanks, > Vladimir > >> >> Testing: failing tests, regression test. >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov From john.r.rose at oracle.com Wed Oct 1 17:37:09 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Oct 2014 10:37:09 -0700 Subject: [9] RFR (XXS): 8059556: C2: crash while inlining MethodHandle invocation w/ null receiver In-Reply-To: <542C2F2C.8030006@oracle.com> References: <542C2F2C.8030006@oracle.com> Message-ID: <28604078-FA80-4AEE-B3DA-59722AC47B84@oracle.com> Reviewed. Suggest: 52 try { 53 run(); 54 } catch (NullPointerException e) { 55 // expected 55.1 continue; 56 } 56.1 throw new InternalError("not expected"); On Oct 1, 2014, at 9:43 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8059556/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8059556 > > In case a receiver == null and it is a compile-time constant, it's type is TypePtr::NULL_PTR and it is not an oop pointer. Hence, receiver_type == NULL. There's no purpose in computing speculative_receiver_type in such case. > > Make the code in agreement with the similar speculative code in Parse::do_call(). > > Testing: regression test > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Wed Oct 1 18:03:13 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Oct 2014 11:03:13 -0700 Subject: [9] RFR (XS): 8058828: Wrong ciConstant type for arrays from ConstantPool::_resolved_reference In-Reply-To: <917CC1A7-28AE-44AE-B2AD-D5664ADA8A47@oracle.com> References: <542BE06F.9080903@oracle.com> <542C36B9.2030703@oracle.com> <917CC1A7-28AE-44AE-B2AD-D5664ADA8A47@oracle.com> Message-ID: <542C41E1.4040304@oracle.com> On 10/1/14 10:34 AM, John Rose wrote: > Reviewed. > > On Oct 1, 2014, at 10:15 AM, Vladimir Kozlov wrote: > >> On 10/1/14 4:07 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8058828/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8058828 >>> >>> There are 2 unrelated problems for the same scenario. >>> >>> ciEnv::get_constant_by_index_impl doesn't distinguish T_OBJECT & T_ARRAY cases for constant pool patches in VM anonymous >>> classes. >>> The fix is to adjust the type, if a constant value is an array. >> >> Should we add check that class is anonymous? Can this be in normal class? > > It can't be a normal class at present. When we get array constants, that will change. > > I lean towards keeping the assert as-is, and not adding a new test for kind of class. But I would be OK either way. Thank you John. then lets keep it as it is. Reviewed. Vladimir > > ? John > >> >>> ciTypeFlow::StateVector::do_ldc has too strong assertion. Since basic_type = {T_OBJECT|T_ARRAY}, obj->is_array() should >>> be also expected. >> >> This is good. >> >> Thanks, >> Vladimir >> >>> >>> Testing: failing tests, regression test. >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov > From vladimir.x.ivanov at oracle.com Wed Oct 1 19:25:52 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 01 Oct 2014 23:25:52 +0400 Subject: [9] RFR (XS): 8058828: Wrong ciConstant type for arrays from ConstantPool::_resolved_reference In-Reply-To: <542C41E1.4040304@oracle.com> References: <542BE06F.9080903@oracle.com> <542C36B9.2030703@oracle.com> <917CC1A7-28AE-44AE-B2AD-D5664ADA8A47@oracle.com> <542C41E1.4040304@oracle.com> Message-ID: <542C5540.3040703@oracle.com> Vladimir, John, thanks for the review. Best regards, Vladimir Ivanov On 10/1/14, 10:03 PM, Vladimir Kozlov wrote: > On 10/1/14 10:34 AM, John Rose wrote: >> Reviewed. >> >> On Oct 1, 2014, at 10:15 AM, Vladimir Kozlov >> wrote: >> >>> On 10/1/14 4:07 AM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8058828/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8058828 >>>> >>>> There are 2 unrelated problems for the same scenario. >>>> >>>> ciEnv::get_constant_by_index_impl doesn't distinguish T_OBJECT & >>>> T_ARRAY cases for constant pool patches in VM anonymous >>>> classes. >>>> The fix is to adjust the type, if a constant value is an array. >>> >>> Should we add check that class is anonymous? Can this be in normal >>> class? >> >> It can't be a normal class at present. When we get array constants, >> that will change. >> >> I lean towards keeping the assert as-is, and not adding a new test for >> kind of class. But I would be OK either way. > > Thank you John. then lets keep it as it is. Reviewed. > > Vladimir > >> >> ? John >> >>> >>>> ciTypeFlow::StateVector::do_ldc has too strong assertion. Since >>>> basic_type = {T_OBJECT|T_ARRAY}, obj->is_array() should >>>> be also expected. >>> >>> This is good. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Testing: failing tests, regression test. >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Vladimir Ivanov >> From vladimir.x.ivanov at oracle.com Wed Oct 1 19:27:24 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 01 Oct 2014 23:27:24 +0400 Subject: [9] RFR (XXS): 8059556: C2: crash while inlining MethodHandle invocation w/ null receiver In-Reply-To: <28604078-FA80-4AEE-B3DA-59722AC47B84@oracle.com> References: <542C2F2C.8030006@oracle.com> <28604078-FA80-4AEE-B3DA-59722AC47B84@oracle.com> Message-ID: <542C559C.1060502@oracle.com> Vladmir, John, thanks for the review. > Suggest: > 52 try { > 53 run(); > 54 } catch (NullPointerException e) { > 55 // expected > 55.1 continue; > 56 } > 56.1 throw new InternalError("not expected"); Good point. I'll update the test. Best regards, Vladimir Ivanov > > On Oct 1, 2014, at 9:43 AM, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vlivanov/8059556/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8059556 >> >> In case a receiver == null and it is a compile-time constant, it's type is TypePtr::NULL_PTR and it is not an oop pointer. Hence, receiver_type == NULL. There's no purpose in computing speculative_receiver_type in such case. >> >> Make the code in agreement with the similar speculative code in Parse::do_call(). >> >> Testing: regression test >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > From vladimir.kozlov at oracle.com Thu Oct 2 04:05:32 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 01 Oct 2014 21:05:32 -0700 Subject: [9] RFR(S) 8059299: assert(adr_type != NULL) failed: expecting TypeKlassPtr Message-ID: <542CCF0C.7020809@oracle.com> http://cr.openjdk.java.net/~kvn/8059299/webrev/ https://bugs.openjdk.java.net/browse/JDK-8059299 Code in Parse::catch_inline_exceptions() incorrectly assumed that all paths reach the merge point in next code: catch (Exception e) { if (e instanceof Exception1) { counter1++; } else if (e instanceof Exception2) { counter2++; } counter++; throw e; } But we generate an uncommon trap when profiling information matches checked exception (in the bug case Exception2, which is the only thrown exception). The fix is to use top() for dead paths when initializing Phi node of exceptions klasses. Also did code style clean up in surrounding code. Added new regression test. Thanks, Vladimir From john.r.rose at oracle.com Thu Oct 2 06:06:39 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 1 Oct 2014 23:06:39 -0700 Subject: [9] RFR(S) 8059299: assert(adr_type != NULL) failed: expecting TypeKlassPtr In-Reply-To: <542CCF0C.7020809@oracle.com> References: <542CCF0C.7020809@oracle.com> Message-ID: <1661B744-3CAC-4ABE-BC38-107D932AE34B@oracle.com> On Oct 1, 2014, at 9:05 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8059299/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8059299 > > Code in Parse::catch_inline_exceptions() incorrectly assumed that all paths reach the merge point in next code: > > catch (Exception e) { > if (e instanceof Exception1) { > counter1++; > } else if (e instanceof Exception2) { > counter2++; > } > counter++; > throw e; > } > > But we generate an uncommon trap when profiling information matches checked exception (in the bug case Exception2, which is the only thrown exception). > > The fix is to use top() for dead paths when initializing Phi node of exceptions klasses. Also did code style clean up in surrounding code. > > Added new regression test. Reviewed. I suggest adding a check at the end, that the counters have their expected values, to add more certainty that the test is doing what it appears to be doing. (You could add another counter0++ before throw new Exception2() and check against that.) ? John From vladimir.x.ivanov at oracle.com Thu Oct 2 10:18:01 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 02 Oct 2014 14:18:01 +0400 Subject: [9] RFR(S) 8059299: assert(adr_type != NULL) failed: expecting TypeKlassPtr In-Reply-To: <542CCF0C.7020809@oracle.com> References: <542CCF0C.7020809@oracle.com> Message-ID: <542D2659.6020902@oracle.com> Looks good. Best regards, Vladimir Ivanov On 10/2/14, 8:05 AM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8059299/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8059299 > > Code in Parse::catch_inline_exceptions() incorrectly assumed that all > paths reach the merge point in next code: > > catch (Exception e) { > if (e instanceof Exception1) { > counter1++; > } else if (e instanceof Exception2) { > counter2++; > } > counter++; > throw e; > } > > But we generate an uncommon trap when profiling information matches > checked exception (in the bug case Exception2, which is the only thrown > exception). > > The fix is to use top() for dead paths when initializing Phi node of > exceptions klasses. Also did code style clean up in surrounding code. > > Added new regression test. > > Thanks, > Vladimir From tobias.hartmann at oracle.com Thu Oct 2 11:49:42 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 02 Oct 2014 13:49:42 +0200 Subject: [9] RFR(XS): 8059559: SIGSEGV at CodeHeap::allocate(unsigned int, bool) Message-ID: <542D3BD6.9090906@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8059559 Webrev: http://cr.openjdk.java.net/~thartmann/8059559/webrev.00/ Problem: 'CodeCache::heap_available' assumes that with '-XX:TieredStopAtLevel=0' we only use the interpreter. This is wrong because we still generate compiled forms of method handle intrinsics (see 'SystemDictionary::find_method_handle_intrinsic'). We therefore need to create the non-profiled code heap. Solution: Change 'CodeCache::heap_available' to create the non-profiled code heap if TieredStopAtLevel=0 is set. I also adapted the test ' compiler/codecache/CheckSegmentedCodeCache'. Thanks, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Oct 2 16:18:37 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 02 Oct 2014 09:18:37 -0700 Subject: [9] RFR(XS): 8059559: SIGSEGV at CodeHeap::allocate(unsigned int, bool) In-Reply-To: <542D3BD6.9090906@oracle.com> References: <542D3BD6.9090906@oracle.com> Message-ID: <542D7ADD.3030809@oracle.com> This fix is good. But I want ask why the test did not catch 8059596 problem? Can you add new check for that case? Thanks, Vladimir On 10/2/14 4:49 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059559 > Webrev: http://cr.openjdk.java.net/~thartmann/8059559/webrev.00/ > > Problem: > 'CodeCache::heap_available' assumes that with '-XX:TieredStopAtLevel=0' we only use the interpreter. This is wrong > because we still generate compiled forms of method handle intrinsics (see > 'SystemDictionary::find_method_handle_intrinsic'). We therefore need to create the non-profiled code heap. > > Solution: > Change 'CodeCache::heap_available' to create the non-profiled code heap if TieredStopAtLevel=0 is set. I also adapted > the test ' compiler/codecache/CheckSegmentedCodeCache'. > > Thanks, > Tobias From vitalyd at gmail.com Thu Oct 2 16:21:51 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 2 Oct 2014 12:21:51 -0400 Subject: [9] RFR(XS): 8059559: SIGSEGV at CodeHeap::allocate(unsigned int, bool) In-Reply-To: <542D3BD6.9090906@oracle.com> References: <542D3BD6.9090906@oracle.com> Message-ID: Hi Tobias, } else if (Arguments::mode() == Arguments::_int) { 258 // Interpreter only: we don't need any method code heaps 259 return (code_blob_type == CodeBlobType::NonNMethod); Minor point, but perhaps the comment should be amended? Thanks On Thu, Oct 2, 2014 at 7:49 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059559 > Webrev: http://cr.openjdk.java.net/~thartmann/8059559/webrev.00/ > > Problem: > 'CodeCache::heap_available' assumes that with '-XX:TieredStopAtLevel=0' we > only use the interpreter. This is wrong because we still generate compiled > forms of method handle intrinsics (see > 'SystemDictionary::find_method_handle_intrinsic'). We therefore need to > create the non-profiled code heap. > > Solution: > Change 'CodeCache::heap_available' to create the non-profiled code heap if > TieredStopAtLevel=0 is set. I also adapted the test ' > compiler/codecache/CheckSegmentedCodeCache'. > > Thanks, > Tobias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Oct 2 16:27:25 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 02 Oct 2014 09:27:25 -0700 Subject: [9] RFR(S) 8059299: assert(adr_type != NULL) failed: expecting TypeKlassPtr In-Reply-To: <542D2659.6020902@oracle.com> References: <542CCF0C.7020809@oracle.com> <542D2659.6020902@oracle.com> Message-ID: <542D7CED.6080000@oracle.com> Thank you, Vladimir Vladimir K On 10/2/14 3:18 AM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 10/2/14, 8:05 AM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8059299/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8059299 >> >> Code in Parse::catch_inline_exceptions() incorrectly assumed that all >> paths reach the merge point in next code: >> >> catch (Exception e) { >> if (e instanceof Exception1) { >> counter1++; >> } else if (e instanceof Exception2) { >> counter2++; >> } >> counter++; >> throw e; >> } >> >> But we generate an uncommon trap when profiling information matches >> checked exception (in the bug case Exception2, which is the only thrown >> exception). >> >> The fix is to use top() for dead paths when initializing Phi node of >> exceptions klasses. Also did code style clean up in surrounding code. >> >> Added new regression test. >> >> Thanks, >> Vladimir From vladimir.kozlov at oracle.com Thu Oct 2 16:28:00 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 02 Oct 2014 09:28:00 -0700 Subject: [9] RFR(S) 8059299: assert(adr_type != NULL) failed: expecting TypeKlassPtr In-Reply-To: <1661B744-3CAC-4ABE-BC38-107D932AE34B@oracle.com> References: <542CCF0C.7020809@oracle.com> <1661B744-3CAC-4ABE-BC38-107D932AE34B@oracle.com> Message-ID: <542D7D10.8000806@oracle.com> Thank you, John I will add counters check. Thanks, Vladimir On 10/1/14 11:06 PM, John Rose wrote: > On Oct 1, 2014, at 9:05 PM, Vladimir Kozlov wrote: > >> http://cr.openjdk.java.net/~kvn/8059299/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8059299 >> >> Code in Parse::catch_inline_exceptions() incorrectly assumed that all paths reach the merge point in next code: >> >> catch (Exception e) { >> if (e instanceof Exception1) { >> counter1++; >> } else if (e instanceof Exception2) { >> counter2++; >> } >> counter++; >> throw e; >> } >> >> But we generate an uncommon trap when profiling information matches checked exception (in the bug case Exception2, which is the only thrown exception). >> >> The fix is to use top() for dead paths when initializing Phi node of exceptions klasses. Also did code style clean up in surrounding code. >> >> Added new regression test. > > Reviewed. > > I suggest adding a check at the end, that the counters have their expected values, to add more certainty that the test is doing what it appears to be doing. (You could add another counter0++ before throw new Exception2() and check against that.) > > ? John > From igor.veresov at oracle.com Fri Oct 3 04:17:52 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 2 Oct 2014 21:17:52 -0700 Subject: RFR(XS) 8059621: JVM crashes with "unexpected index type" assert in LIRGenerator::do_UnsafeGetRaw Message-ID: <03D43B2E-80C2-4F9F-8952-40584BD2D892@oracle.com> I incorrectly assumed that LIRItem.load_noconstant() always leaves constants alone. On SPARC that is not the case. So it?s incorrect to assume that if a value was a constant in HIR it will stay a constant in LIR. The fix is to ask LIR for types and constness. JBS: https://bugs.openjdk.java.net/browse/JDK-8059621 Webrev: http://cr.openjdk.java.net/~iveresov/8059621/webrev.00 Thanks, igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Oct 3 05:48:14 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 02 Oct 2014 22:48:14 -0700 Subject: RFR(XS) 8059621: JVM crashes with "unexpected index type" assert in LIRGenerator::do_UnsafeGetRaw In-Reply-To: <03D43B2E-80C2-4F9F-8952-40584BD2D892@oracle.com> References: <03D43B2E-80C2-4F9F-8952-40584BD2D892@oracle.com> Message-ID: <542E389E.9030809@oracle.com> Okay, I think. Vladimir K On 10/2/14 9:17 PM, Igor Veresov wrote: > I incorrectly assumed that LIRItem.load_noconstant() always leaves constants alone. On SPARC that is not the case. So > it?s incorrect to assume that if a value was a constant in HIR it will stay a constant in LIR. The fix is to ask LIR for > types and constness. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8059621 > Webrev: http://cr.openjdk.java.net/~iveresov/8059621/webrev.00 > > Thanks, > igor From igor.veresov at oracle.com Fri Oct 3 06:32:20 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 2 Oct 2014 23:32:20 -0700 Subject: RFR(XS) 8059621: JVM crashes with "unexpected index type" assert in LIRGenerator::do_UnsafeGetRaw In-Reply-To: <542E389E.9030809@oracle.com> References: <03D43B2E-80C2-4F9F-8952-40584BD2D892@oracle.com> <542E389E.9030809@oracle.com> Message-ID: Thanks, Vladimir! igor On Oct 2, 2014, at 10:48 PM, Vladimir Kozlov wrote: > Okay, I think. > > Vladimir K > > On 10/2/14 9:17 PM, Igor Veresov wrote: >> I incorrectly assumed that LIRItem.load_noconstant() always leaves constants alone. On SPARC that is not the case. So >> it?s incorrect to assume that if a value was a constant in HIR it will stay a constant in LIR. The fix is to ask LIR for >> types and constness. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8059621 >> Webrev: http://cr.openjdk.java.net/~iveresov/8059621/webrev.00 >> >> Thanks, >> igor From tobias.hartmann at oracle.com Fri Oct 3 07:43:31 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 03 Oct 2014 09:43:31 +0200 Subject: [9] RFR(XS): 8059559: SIGSEGV at CodeHeap::allocate(unsigned int, bool) In-Reply-To: <542D7ADD.3030809@oracle.com> References: <542D3BD6.9090906@oracle.com> <542D7ADD.3030809@oracle.com> Message-ID: <542E53A3.80600@oracle.com> Hi Vladimir, thanks for the review. On 02.10.2014 18:18, Vladimir Kozlov wrote: > This fix is good. > > But I want ask why the test did not catch 8059596 problem? Can you add > new check for that case? We did not catch the bug because it occurred only if a ReservedCodeCacheSize >= 240M was set. None of our tests does this. I added a corresponding check to the test and made it more robust by also checking the exit value. New webrev: http://cr.openjdk.java.net/~thartmann/8059559/webrev.01/ Thanks, Tobias > Thanks, > Vladimir > > On 10/2/14 4:49 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059559 >> Webrev: http://cr.openjdk.java.net/~thartmann/8059559/webrev.00/ >> >> Problem: >> 'CodeCache::heap_available' assumes that with >> '-XX:TieredStopAtLevel=0' we only use the interpreter. This is wrong >> because we still generate compiled forms of method handle intrinsics >> (see >> 'SystemDictionary::find_method_handle_intrinsic'). We therefore need >> to create the non-profiled code heap. >> >> Solution: >> Change 'CodeCache::heap_available' to create the non-profiled code >> heap if TieredStopAtLevel=0 is set. I also adapted >> the test ' compiler/codecache/CheckSegmentedCodeCache'. >> >> Thanks, >> Tobias From tobias.hartmann at oracle.com Fri Oct 3 07:47:30 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 03 Oct 2014 09:47:30 +0200 Subject: [9] RFR(XS): 8059559: SIGSEGV at CodeHeap::allocate(unsigned int, bool) In-Reply-To: References: <542D3BD6.9090906@oracle.com> Message-ID: <542E5492.90404@oracle.com> Hi Vitaly, thanks for the feedback. On 02.10.2014 18:21, Vitaly Davidovich wrote: > Hi Tobias, > > } else if (Arguments::mode() == Arguments::_int) { > > 258 // Interpreter only: we don't need any method code heaps > 259 return (code_blob_type == CodeBlobType::NonNMethod); > > Minor point, but perhaps the comment should be amended? The comment is still correct because we don't need any method code heaps in interpreter-only mode. However, if TieredStopAtLevel=0 is set, we are not in interpreter-only mode and therefore need the non-profiled code heap (we exit through the else branch annotated with "No TieredCompilation"). Best, Tobias > > Thanks > > On Thu, Oct 2, 2014 at 7:49 AM, Tobias Hartmann > > wrote: > > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059559 > Webrev: http://cr.openjdk.java.net/~thartmann/8059559/webrev.00/ > > > Problem: > 'CodeCache::heap_available' assumes that with > '-XX:TieredStopAtLevel=0' we only use the interpreter. This is > wrong because we still generate compiled forms of method handle > intrinsics (see 'SystemDictionary::find_method_handle_intrinsic'). > We therefore need to create the non-profiled code heap. > > Solution: > Change 'CodeCache::heap_available' to create the non-profiled code > heap if TieredStopAtLevel=0 is set. I also adapted the test ' > compiler/codecache/CheckSegmentedCodeCache'. > > Thanks, > Tobias > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Fri Oct 3 09:22:31 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 03 Oct 2014 11:22:31 +0200 Subject: [9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled Message-ID: <542E6AD7.1060307@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8046268 Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/ == Problem == The whitebox tests assume that after the invocation of 'CompilerWhiteBoxTest.compile()' the method is always compiled and 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR compilations [1] this is does not hold. For example, in case of the following events: 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile 'SimpleTestCase.Helper.osrMethod()'. 2) OSR compilation is performed at level 4. An uncommon trap is added after the loop because profiling never reached that point. Execution continues with the OSR version. 3) Deoptimization is triggered because the loop finishes (reason: 'unstable if'). The OSR nmethod is made non-entrant and removed from the OSR list (see 'nmethod::invalidate_osr_method'). 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the method is OSR compiled. Because the OSR nmethod was removed from the list, check compiled returns false (see WB_IsMethodCompiled). This was caused by the fix for JDK-8030976 [2] because we now trust the profile information more and add uncommon traps to untaken paths. In this case we add an uncommon trap after the loop exit: private int osrMethod() { int result = 0; for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) { result += method(); } return result; } == Solution == I added code to 'warm up' the methods before triggering OSR compilation by executing them a limited number of times. Like this, the profile information marks the loop exit as taken and we don't add an uncommon trap. == Testing == - Executed failing tests on JPRT Thanks, Tobias [1] OSR compiled methods: compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC [2] https://bugs.openjdk.java.net/browse/JDK-8030976 From albert.noll at oracle.com Fri Oct 3 10:18:28 2014 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 03 Oct 2014 12:18:28 +0200 Subject: [9] RFR(S): 8059331: Print additional information for the assert in Compile::start() Message-ID: <542E77F4.8020504@oracle.com> Hi, could I get reviews for this small patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8059331 Webrev: http://cr.openjdk.java.net/~anoll/8059529/webrev.00/ The assert failed once in JDK-8058434. Printing the failure reason in the assert helps tracking down the problem. Best, Albert From boris.molodenkov at oracle.com Fri Oct 3 10:53:53 2014 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Fri, 03 Oct 2014 14:53:53 +0400 Subject: [8u40] Request for approval: backport of JDK-8057165 Message-ID: <542E8041.1010101@oracle.com> Hi All, I would like to backport fix for JDK-8057165 to 8u40. Bug id: https://bugs.openjdk.java.net/browse/JDK-8057165 Webrev: http://cr.openjdk.java.net/~fzhinkin/bmoloden/8057165/webrev.00/ Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3a59d786378b Review thread for original fix: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-September/015514.html testing: jprt Thanks, Boris From boris.molodenkov at oracle.com Fri Oct 3 11:00:16 2014 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Fri, 03 Oct 2014 15:00:16 +0400 Subject: [8u40] Request for approval: backport of JDK-8057165 In-Reply-To: <542E8041.1010101@oracle.com> References: <542E8041.1010101@oracle.com> Message-ID: <542E81C0.9000602@oracle.com> Sorry, Latest webrev is http://cr.openjdk.java.net/~fzhinkin/bmoloden/8057165/webrev.01/ Boris On 10/03/2014 02:53 PM, Boris Molodenkov wrote: > Hi All, > > I would like to backport fix for JDK-8057165 to 8u40. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8057165 > Webrev: http://cr.openjdk.java.net/~fzhinkin/bmoloden/8057165/webrev.00/ > Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3a59d786378b > Review thread for original fix: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-September/015514.html > > > testing: jprt > > Thanks, > Boris > From vitalyd at gmail.com Fri Oct 3 12:29:24 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 3 Oct 2014 08:29:24 -0400 Subject: [9] RFR(XS): 8059559: SIGSEGV at CodeHeap::allocate(unsigned int, bool) In-Reply-To: <542E5492.90404@oracle.com> References: <542D3BD6.9090906@oracle.com> <542E5492.90404@oracle.com> Message-ID: Ok. The reason I mentioned this is because of these lines right below the one you changed: 264 // No TieredCompilation: we only need the non-nmethod and non-profiled code heap 265 return (code_blob_type == CodeBlobType::NonNMethod) || 266 (code_blob_type == CodeBlobType::MethodNonProfiled); That one mentions that it needs non-nmethod heap, so thought similar comment was warranted in your change. But you know better than me :). Thanks Sent from my phone On Oct 3, 2014 3:47 AM, "Tobias Hartmann" wrote: > Hi Vitaly, > > thanks for the feedback. > > On 02.10.2014 18:21, Vitaly Davidovich wrote: > > Hi Tobias, > > } else if (Arguments::mode() == Arguments::_int) { > > 258 // Interpreter only: we don't need any method code heaps > 259 return (code_blob_type == CodeBlobType::NonNMethod); > > > Minor point, but perhaps the comment should be amended? > > > The comment is still correct because we don't need any method code heaps > in interpreter-only mode. > > However, if TieredStopAtLevel=0 is set, we are not in interpreter-only > mode and therefore need the non-profiled code heap (we exit through the > else branch annotated with "No TieredCompilation"). > > Best, > Tobias > > > Thanks > > On Thu, Oct 2, 2014 at 7:49 AM, Tobias Hartmann < > tobias.hartmann at oracle.com> wrote: > >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059559 >> Webrev: http://cr.openjdk.java.net/~thartmann/8059559/webrev.00/ >> >> Problem: >> 'CodeCache::heap_available' assumes that with '-XX:TieredStopAtLevel=0' >> we only use the interpreter. This is wrong because we still generate >> compiled forms of method handle intrinsics (see >> 'SystemDictionary::find_method_handle_intrinsic'). We therefore need to >> create the non-profiled code heap. >> >> Solution: >> Change 'CodeCache::heap_available' to create the non-profiled code heap >> if TieredStopAtLevel=0 is set. I also adapted the test ' >> compiler/codecache/CheckSegmentedCodeCache'. >> >> Thanks, >> Tobias >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Fri Oct 3 13:23:29 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 03 Oct 2014 15:23:29 +0200 Subject: [9] RFR(XS): 8059559: SIGSEGV at CodeHeap::allocate(unsigned int, bool) In-Reply-To: References: <542D3BD6.9090906@oracle.com> <542E5492.90404@oracle.com> Message-ID: <542EA351.9020203@oracle.com> Hi Vitaly, yes, but the comment only says that we don't need any _method_ code heaps. Of course we do need the non-nmethod code heap (for example to store the interpreter). Best, Tobias On 03.10.2014 14:29, Vitaly Davidovich wrote: > > Ok. The reason I mentioned this is because of these lines right below > the one you changed: > > 264 // No TieredCompilation: we only need the non-nmethod and > non-profiled code heap > 265 return (code_blob_type == CodeBlobType::NonNMethod) || > 266 (code_blob_type == CodeBlobType::MethodNonProfiled); > > That one mentions that it needs non-nmethod heap, so thought similar > comment was warranted in your change. But you know better than me :). > > Thanks > Sent from my phone > > On Oct 3, 2014 3:47 AM, "Tobias Hartmann" > wrote: > > Hi Vitaly, > > thanks for the feedback. > > On 02.10.2014 18:21, Vitaly Davidovich wrote: >> Hi Tobias, >> >> } else if (Arguments::mode() == Arguments::_int) { >> >> 258 // Interpreter only: we don't need any method code heaps >> 259 return (code_blob_type == CodeBlobType::NonNMethod); >> >> Minor point, but perhaps the comment should be amended? > > The comment is still correct because we don't need any method code > heaps in interpreter-only mode. > > However, if TieredStopAtLevel=0 is set, we are not in > interpreter-only mode and therefore need the non-profiled code > heap (we exit through the else branch annotated with "No > TieredCompilation"). > > Best, > Tobias > >> >> Thanks >> >> On Thu, Oct 2, 2014 at 7:49 AM, Tobias Hartmann >> > >> wrote: >> >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059559 >> Webrev: >> http://cr.openjdk.java.net/~thartmann/8059559/webrev.00/ >> >> >> Problem: >> 'CodeCache::heap_available' assumes that with >> '-XX:TieredStopAtLevel=0' we only use the interpreter. This >> is wrong because we still generate compiled forms of method >> handle intrinsics (see >> 'SystemDictionary::find_method_handle_intrinsic'). We >> therefore need to create the non-profiled code heap. >> >> Solution: >> Change 'CodeCache::heap_available' to create the non-profiled >> code heap if TieredStopAtLevel=0 is set. I also adapted the >> test ' compiler/codecache/CheckSegmentedCodeCache'. >> >> Thanks, >> Tobias >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iggy.veresov at gmail.com Fri Oct 3 04:15:56 2014 From: iggy.veresov at gmail.com (Igor Veresov) Date: Thu, 2 Oct 2014 21:15:56 -0700 Subject: RFR(XS) 8059621: JVM crashes with "unexpected index type" assert in LIRGenerator::do_UnsafeGetRaw Message-ID: I incorrectly assumed that LIRItem.load_noconstant() always leaves constants alone. On SPARC that is not the case. So it?s incorrect to assume that if a value was a constant in HIR it will stay a constant in LIR. The fix is to ask LIR for types and constness. JBS: https://bugs.openjdk.java.net/browse/JDK-8059621 Webrev: http://cr.openjdk.java.net/~iveresov/8059621/webrev.00 Thanks, igor From tobias.hartmann at oracle.com Fri Oct 3 14:24:39 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 03 Oct 2014 16:24:39 +0200 Subject: [9] RFR(XS): 8059675: Missing ResourceMark in nmethod::clear_ic_stubs() Message-ID: <542EB1A7.2000302@oracle.com> Hi, please review the following small patch that adds a missing ResourceMark to nmethod::clear_ic_stubs(). Bug: https://bugs.openjdk.java.net/browse/JDK-8059675 Webrev: http://cr.openjdk.java.net/~thartmann/8059675/webrev.00/ Tested fix with failing test. Thanks, Tobias From albert.noll at oracle.com Fri Oct 3 14:36:13 2014 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 03 Oct 2014 16:36:13 +0200 Subject: [9] RFR(XS): 8059675: Missing ResourceMark in nmethod::clear_ic_stubs() In-Reply-To: <542EB1A7.2000302@oracle.com> References: <542EB1A7.2000302@oracle.com> Message-ID: <542EB45D.4010904@oracle.com> Hi Tobias, did you check other in nmethod.cpp where we have the following code: CompiledIC *ic = CompiledIC_at(&iter); For example in: verify_icholder_relocations() do_unloading(...) do_unloading_parallel(..) verify_metadata_loaders(..) metadata_do(..) verify_interrupt_point(..) print_calls(...) Best, Albert On 10/03/2014 04:24 PM, Tobias Hartmann wrote: > Hi, > > please review the following small patch that adds a missing > ResourceMark to nmethod::clear_ic_stubs(). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059675 > Webrev: http://cr.openjdk.java.net/~thartmann/8059675/webrev.00/ > > Tested fix with failing test. > > Thanks, > Tobias From vladimir.kozlov at oracle.com Fri Oct 3 17:00:42 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Oct 2014 10:00:42 -0700 Subject: [8u40] Request for approval: backport of JDK-8057165 In-Reply-To: <542E81C0.9000602@oracle.com> References: <542E8041.1010101@oracle.com> <542E81C0.9000602@oracle.com> Message-ID: <542ED63A.2050009@oracle.com> Looks good. Thanks, Vladimir On 10/3/14 4:00 AM, Boris Molodenkov wrote: > Sorry, > Latest webrev is http://cr.openjdk.java.net/~fzhinkin/bmoloden/8057165/webrev.01/ > > Boris > > On 10/03/2014 02:53 PM, Boris Molodenkov wrote: >> Hi All, >> >> I would like to backport fix for JDK-8057165 to 8u40. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8057165 >> Webrev: http://cr.openjdk.java.net/~fzhinkin/bmoloden/8057165/webrev.00/ >> Changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3a59d786378b >> Review thread for original fix: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2014-September/015514.html >> >> testing: jprt >> >> Thanks, >> Boris >> > From vladimir.kozlov at oracle.com Fri Oct 3 17:13:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Oct 2014 10:13:24 -0700 Subject: [9] RFR(S): 8059331: Print additional information for the assert in Compile::start() In-Reply-To: <542E77F4.8020504@oracle.com> References: <542E77F4.8020504@oracle.com> Message-ID: <542ED934.1020405@oracle.com> Looks fine. Thanks, Vladimir On 10/3/14 3:18 AM, Albert Noll wrote: > Hi, > > could I get reviews for this small patch? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059331 > Webrev: http://cr.openjdk.java.net/~anoll/8059529/webrev.00/ > > The assert failed once in JDK-8058434. Printing the failure reason in the assert helps > tracking down the problem. > > Best, > Albert From vladimir.kozlov at oracle.com Fri Oct 3 17:20:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 03 Oct 2014 10:20:52 -0700 Subject: [9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled In-Reply-To: <542E6AD7.1060307@oracle.com> References: <542E6AD7.1060307@oracle.com> Message-ID: <542EDAF4.2030000@oracle.com> Nightly runs done with -Xcomp. Make sure your changes still work. 200 for tiered may be too high. C1 compilation triggered before that, please check. Thanks, Vladimir On 10/3/14 2:22 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8046268 > Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/ > > == Problem == > The whitebox tests assume that after the invocation of 'CompilerWhiteBoxTest.compile()' the method is always compiled > and 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR compilations [1] this is does not hold. For > example, in case of the following events: > > 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile 'SimpleTestCase.Helper.osrMethod()'. > 2) OSR compilation is performed at level 4. An uncommon trap is added after the loop because profiling never reached > that point. Execution continues with the OSR version. > 3) Deoptimization is triggered because the loop finishes (reason: 'unstable if'). The OSR nmethod is made non-entrant > and removed from the OSR list (see 'nmethod::invalidate_osr_method'). > 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the method is OSR compiled. Because the OSR nmethod > was removed from the list, check compiled returns false (see WB_IsMethodCompiled). > > This was caused by the fix for JDK-8030976 [2] because we now trust the profile information more and add uncommon traps > to untaken paths. In this case we add an uncommon trap after the loop exit: > > private int osrMethod() { > int result = 0; > for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) { > result += method(); > } > return result; > } > > == Solution == > I added code to 'warm up' the methods before triggering OSR compilation by executing them a limited number of times. > Like this, the profile information marks the loop exit as taken and we don't add an uncommon trap. > > == Testing == > - Executed failing tests on JPRT > > Thanks, > Tobias > > > [1] OSR compiled methods: > compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR > compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD > compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC > > [2] https://bugs.openjdk.java.net/browse/JDK-8030976 From dean.long at oracle.com Fri Oct 3 18:07:16 2014 From: dean.long at oracle.com (dean long) Date: Fri, 03 Oct 2014 11:07:16 -0700 Subject: [9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled In-Reply-To: <542E6AD7.1060307@oracle.com> References: <542E6AD7.1060307@oracle.com> Message-ID: <542EE5D4.9050304@oracle.com> In the future, it might be useful for the whitebox interface to return a compilation count for a method. That way we can query "is or was compiled" vs. "is currently compiled". dl On 10/3/2014 2:22 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8046268 > Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/ > > == Problem == > The whitebox tests assume that after the invocation of > 'CompilerWhiteBoxTest.compile()' the method is always compiled and > 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR > compilations [1] this is does not hold. For example, in case of the > following events: > > 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile > 'SimpleTestCase.Helper.osrMethod()'. > 2) OSR compilation is performed at level 4. An uncommon trap is added > after the loop because profiling never reached that point. Execution > continues with the OSR version. > 3) Deoptimization is triggered because the loop finishes (reason: > 'unstable if'). The OSR nmethod is made non-entrant and removed from > the OSR list (see 'nmethod::invalidate_osr_method'). > 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the > method is OSR compiled. Because the OSR nmethod was removed from the > list, check compiled returns false (see WB_IsMethodCompiled). > > This was caused by the fix for JDK-8030976 [2] because we now trust > the profile information more and add uncommon traps to untaken paths. > In this case we add an uncommon trap after the loop exit: > > private int osrMethod() { > int result = 0; > for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) { > result += method(); > } > return result; > } > > == Solution == > I added code to 'warm up' the methods before triggering OSR > compilation by executing them a limited number of times. Like this, > the profile information marks the loop exit as taken and we don't add > an uncommon trap. > > == Testing == > - Executed failing tests on JPRT > > Thanks, > Tobias > > > [1] OSR compiled methods: > compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR > compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD > compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC > > [2] https://bugs.openjdk.java.net/browse/JDK-8030976 From igor.veresov at oracle.com Fri Oct 3 21:37:07 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 3 Oct 2014 14:37:07 -0700 Subject: RFR - Avoid G1 write barriers on newly allocated objects In-Reply-To: <5418AE85.1070309@oracle.com> References: <540A47E0.2080803@oracle.com> <2548885.ND5rUTNDSq@mgerdin03> <54136502.2000305@oracle.com> <54137E92.4030803@oracle.com> <541768C1.20507@oracle.com> <54178A86.4090500@oracle.com> <5418AE85.1070309@oracle.com> Message-ID: <3EB00253-5BB0-47DA-8C68-5F4AF243B4F4@oracle.com> Sorry that I couldn?t get this for so long. The C2 part seems very good. The only comment is that the code (the post-barrier elimination part) depends on the fact the the new object is allocated in the young gen. Would it make sense to harden the code a little bit in case G1 gets single-generation or changes its allocation scheme? Like adding G1CollectedHeap::new_objects_require_post_barrier() or something like that? Anyways, up to you, reviewed. igor On Sep 16, 2014, at 2:41 PM, Staffan Friberg wrote: > Thanks Vladimir, > > Updated with your suggestions. Added a small comment in g1_can_remove_pre_barrier method since the alloc == NULL check is quite a bit earlier. > > New webrev, http://cr.openjdk.java.net/~sfriberg/8057737/webrev.03 > > Cheers, > Staffan > > > On 09/15/2014 05:55 PM, Vladimir Kozlov wrote: >> You need only check (alloc == st_alloc) because alloc != NULL at this point: >> >> + if (st_alloc != NULL && alloc == st_alloc) { >> >> >> You can clean up g1_can_remove_pre_barrier() too (remove st_alloc == NULL check). >> >> I would also reverse the last check there because you bailout from loop anyway: >> >> + if (captured_store == NULL || captured_store == st_init->zero_memory()) { >> + return true; >> + } >> + } >> + } >> + >> + // Unless there is an explicit 'continue', we must bail out here, >> >> >> Vladimir >> >> On 9/15/14 3:31 PM, Staffan Friberg wrote: >>> Hi Vladimir, >>> >>> Uploaded a new webrev with fixes to the below issues, >>> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.02 >>> >>> Still removes expected barriers. >>> >>> Thanks, >>> Staffan >>> >>> On 09/12/2014 04:15 PM, Vladimir Kozlov wrote: >>>> Fix indention in 2 checks: >>>> >>>> + if (use_ReduceInitialCardMarks() && >>>> + g1_can_remove_*_barrier(&_gvn, adr, bt, alias_idx)) { >>>> >>>> Typo 'iff' in both comments: >>>> >>>> + * Returns true iff the barrier can be removed >>>> >>>> In g1_can_remove_post_barrier() use: >>>> >>>> + // Start search from Store node >>>> + Node* ctrl = store->in(MemNode::Control); >>>> >>>> Control edge can't point to an other Store so you should not check it >>>> inside loop. >>>> As result you don't need loop. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/12/14 2:26 PM, Staffan Friberg wrote: >>>>> Hi Mikael, >>>>> >>>>> I updated the documentation, and uploaded a new webrev, >>>>> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.01 >>>>> >>>>> Thanks for agreeing to sponsor, and the good idea about pushing to >>>>> hs-gc for extra coverage. >>>>> >>>>> Thanks, >>>>> Staffan >>>>> >>>>> On 09/09/2014 07:31 AM, Mikael Gerdin wrote: >>>>>> Hi Staffan, >>>>>> >>>>>> On Friday 05 September 2014 16.31.44 Staffan Friberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Copying both the compiler and GC alias as the optimization involves >>>>>>> both >>>>>>> groups. >>>>>>> >>>>>>> This optimization aims to avoid generating G1 barriers for newly >>>>>>> allocated objects where the compiler can prove that the object has not >>>>>>> been written to earlier and there is no safepoint between the >>>>>>> allocation >>>>>>> and the write. The bug has some further details and microbenchmark >>>>>>> result. The new code has fairly extensive comments about the >>>>>>> optimization. >>>>>>> >>>>>>> It would be great if the GC team can help validate that the premise of >>>>>>> the optimization is correct as well. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~sfriberg/8057737/webrev/ >>>>>> I mostly read through the comments since I can't decode what the IR >>>>>> transforms >>>>>> intend to do :) >>>>>> >>>>>> We usually stick to the terms "old generation" and "young >>>>>> generation" instead >>>>>> of "Old Space" and "Young Space". >>>>>> >>>>>> "G1 also requires to keep track of objects between different >>>>>> + * regions to enable evacuation of old regions" >>>>>> should probably be. >>>>>> .."to keep track of references between different regions" >>>>>> >>>>>> I leave it to the compiler team to review the actual code changes. >>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8057737 >>>>>>> >>>>>>> I would also need a sponsor for this change if it passes review. >>>>>> I'll push this to hs-gc after review since we have more G1 test >>>>>> coverage on >>>>>> hs-gc. >>>>>> >>>>>> /Mikael >>>>>> >>>>>>> Thanks, >>>>>>> Staffan >>>>> >>> > From igor.ignatyev at oracle.com Sun Oct 5 15:39:27 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sun, 05 Oct 2014 19:39:27 +0400 Subject: RFR(XXS) : 8059732 : improve hotspot_*test targets Message-ID: <5431662F.2040804@oracle.com> webrev: http://cr.openjdk.java.net/~iignatyev/8059732/webrev.00/ 33 lines changed: 20 ins; 9 del; 4 mod; Hi all, Please review changes in hotspot_*test targets: - common part is extracted as sanitytest target - flags to test are stored in TEST_FLAGS variable - tests fail if one of executions fail (not the last one, as it was before) jbs: https://bugs.openjdk.java.net/browse/JDK-8059732 testing: jprt -- Thanks Igor From tobias.hartmann at oracle.com Mon Oct 6 06:43:19 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 06 Oct 2014 08:43:19 +0200 Subject: [9] RFR(XS): 8059675: Missing ResourceMark in nmethod::clear_ic_stubs() In-Reply-To: <542EB45D.4010904@oracle.com> References: <542EB1A7.2000302@oracle.com> <542EB45D.4010904@oracle.com> Message-ID: <54323A07.9020304@oracle.com> Hi Albert, I just noticed that there actually is a ResourceMark in 'CompileBroker::compiler_thread_loop' [1]. The bug only occurs with your (not yet integrated) changes for 8046809 [2] because you call the sweeper from a non-compiler thread without a ResourceMark there. I closed the bug as 'not an issue'. Best, Tobias [1] Stack trace: nmethod::clear_ic_stubs NMethodSweeper::process_nmethod NMethodSweeper::sweep_code_cache NMethodSweeper::possibly_sweep CompileQueue::get CompileBroker::compiler_thread_loop [2] https://bugs.openjdk.java.net/browse/JDK-8046809 On 03.10.2014 16:36, Albert Noll wrote: > Hi Tobias, > > did you check other in nmethod.cpp where we have the following code: > CompiledIC *ic = CompiledIC_at(&iter); > > For example in: > > verify_icholder_relocations() > do_unloading(...) > do_unloading_parallel(..) > verify_metadata_loaders(..) > metadata_do(..) > verify_interrupt_point(..) > print_calls(...) > > Best, > Albert > > > On 10/03/2014 04:24 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following small patch that adds a missing >> ResourceMark to nmethod::clear_ic_stubs(). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059675 >> Webrev: http://cr.openjdk.java.net/~thartmann/8059675/webrev.00/ >> >> Tested fix with failing test. >> >> Thanks, >> Tobias > From albert.noll at oracle.com Mon Oct 6 06:46:40 2014 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 06 Oct 2014 08:46:40 +0200 Subject: [9] RFR(S): 8059331: Print additional information for the assert in Compile::start() In-Reply-To: <542ED934.1020405@oracle.com> References: <542E77F4.8020504@oracle.com> <542ED934.1020405@oracle.com> Message-ID: <54323AD0.6010100@oracle.com> Thanks for looking at this, Vladimir. Best, Albert On 10/03/2014 07:13 PM, Vladimir Kozlov wrote: > Looks fine. > > Thanks, > Vladimir > > On 10/3/14 3:18 AM, Albert Noll wrote: >> Hi, >> >> could I get reviews for this small patch? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059331 >> Webrev: http://cr.openjdk.java.net/~anoll/8059529/webrev.00/ >> >> The assert failed once in JDK-8058434. Printing the failure reason in >> the assert helps >> tracking down the problem. >> >> Best, >> Albert From albert.noll at oracle.com Mon Oct 6 06:53:20 2014 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 06 Oct 2014 08:53:20 +0200 Subject: [9] RFR(XS): 8059675: Missing ResourceMark in nmethod::clear_ic_stubs() In-Reply-To: <54323A07.9020304@oracle.com> References: <542EB1A7.2000302@oracle.com> <542EB45D.4010904@oracle.com> <54323A07.9020304@oracle.com> Message-ID: <54323C60.5030701@oracle.com> Hi Tobias, that makes sense, thanks. Best, Albert On 10/06/2014 08:43 AM, Tobias Hartmann wrote: > Hi Albert, > > I just noticed that there actually is a ResourceMark in > 'CompileBroker::compiler_thread_loop' [1]. The bug only occurs with > your (not yet integrated) changes for 8046809 [2] because you call the > sweeper from a non-compiler thread without a ResourceMark there. > > I closed the bug as 'not an issue'. > > Best, > Tobias > > [1] Stack trace: > nmethod::clear_ic_stubs > NMethodSweeper::process_nmethod > NMethodSweeper::sweep_code_cache > NMethodSweeper::possibly_sweep > CompileQueue::get > CompileBroker::compiler_thread_loop > > [2] https://bugs.openjdk.java.net/browse/JDK-8046809 > > > On 03.10.2014 16:36, Albert Noll wrote: >> Hi Tobias, >> >> did you check other in nmethod.cpp where we have the following code: >> CompiledIC *ic = CompiledIC_at(&iter); >> >> For example in: >> >> verify_icholder_relocations() >> do_unloading(...) >> do_unloading_parallel(..) >> verify_metadata_loaders(..) >> metadata_do(..) >> verify_interrupt_point(..) >> print_calls(...) >> >> Best, >> Albert >> >> >> On 10/03/2014 04:24 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following small patch that adds a missing >>> ResourceMark to nmethod::clear_ic_stubs(). >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059675 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8059675/webrev.00/ >>> >>> Tested fix with failing test. >>> >>> Thanks, >>> Tobias >> > From roland.westrelin at oracle.com Mon Oct 6 09:49:19 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 6 Oct 2014 11:49:19 +0200 Subject: RFR(M): 8054478 C2: Incorrectly compiled char[] array access crashes JVM In-Reply-To: <523201FA-F50D-4112-B4B4-DA61B6DFCDB4@oracle.com> References: <523201FA-F50D-4112-B4B4-DA61B6DFCDB4@oracle.com> Message-ID: <5040216D-84CA-4CCF-82CF-5D15DF4B7D08@oracle.com> Anyone? Roland. On Sep 17, 2014, at 7:03 PM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8054478/webrev.00/ > > The IR after parsing is this in pseudo code: > > i_main = 0; > while(true) { > if (i_main >= 1000000) return; > i_main++; > char[] array = new char[1]; > if (pattern1 != null) { > i = 0; > while(true) { > if (i >= 0) { > do { > if (pattern0 == null) uncommon_trap; > if (pattern0.length u< i) uncommon_trap; > if (pattern0[i] != 0) { > if (pattern1.length u< i) uncommon_trap; > if (pattern1[i] != 0) { > goto out1; > } > } > i?; > pos?; > if (pos != -1) { > goto out2; > } > } while (i >= 0); > goto out1; > } > out2: > c = array[pos]; > } > } > out1: > } > > The do {} while loop is a CountedLoop. The null check & range check are moved out of the loop. Then a pre and a post loops are created and the body is unrolled. The pattern0[i] LoadNode nodes in the unrolled body have a control that is set to the range check before the pre loop. In the unrolled loop, because of the if (pos != -1) test in the first copy of the loop, the compiler finds that in the second copy of the loop body pos is != -1 and so the loop is exited before reaching the end of the unrolled loop. The back branch of the unrolled loop is dead. The compiler optimizes the CountedLoopNode of the unrolled loop out because it doesn?t have a back branch anymore, PhiNodes are removed and the LoadNode for pattern0[i] in the unroll loop body is now independent of the input control of the CountedLoop. Its control is still set to the range check before the pre loop. In the generated code, the pre loop is followed by the pattern1[i] access which is incorrect because it happens before the if (i >= 0) that dominated the unrolled loop before it was removed. > > The graph is good as long as the CountedLoop is not removed because the LoadNode depends on a PhiNode of the CountedLoop. But as soon as the CountedLoop is removed and the PhiNode is disconnected, the LoadNode no longer depends on the check that guarded the CountedLoop. > > Vladimir suggested (in a private conversation) that I use a CastII (control dependent on the if that guards the main loop with as input the input value to the induction variable in the loop) as a way to guarantee correct dependencies. There are 2 problems with this: > > 1) the CastII nodes are removed after CCP. I added a flag to the CastII nodes so we can mark CastII nodes that can?t be removed and should be left as they are post-CCP. > 2) we don?t know the range of values that are possible on the if branch that enters the main loop right away (it can be adjusted as loop opts are applied). We may actually never know it if it depends on non constants. If we use a type for a range that is too wide in the CastII the CastII may be optimized out incorrectly. I added another flag to the CastII to mark nodes that cannot be optimized. In CastII:Ideal I added code that tries to figure out a better type for the CastII so we may be able to optimize the CastII as the compiler optimizes the IR. > > Another independent issue here is that the main loop is actually never executed because the loop of the test is a single iteration loop so the compiler should be able to optimize out the main loop entirely but it doesn?t. PhiNode::Value() has this code: > > CountedLoopNode *l = r->is_CountedLoop() ? r->as_CountedLoop() : NULL; > if( l && l->can_be_counted_loop(phase) && > ((const Node*)l->phi() == this) ) { // Trip counted loop! > > ... > if( lo->_hi < hi->_lo ) // Reversed endpoints are well defined :-( > return TypeInt::make(lo->_lo,hi->_hi,3); > } > } > } > > that returns an accurate value for the Phi node of a CountedLoop. In this case we want the pre loop?s Phi to return an accurate type that would then make the guard of the main loop optimize. The pre loop is guarded by a test on an opaque node which is later removed. If PhiNode::Value() is called before the Opaque1 node is removed then, the limit type is int and it cannot return anything accurate. If it?s called after, then limit type is a constant and PhiNode::Value() also returns a constant for the pre-loop. Then the main loop is optimized out. To fix this: I added code to Opaque1Node::Ideal so it reenqueues the Phi when the opaque node is removed. > > Roland. From roland.westrelin at oracle.com Mon Oct 6 15:05:57 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Mon, 6 Oct 2014 17:05:57 +0200 Subject: [9] RFR (XS): 8058825: EA: ConnectionGraph::split_unique_types does incorrect scalar replacement In-Reply-To: <5429A555.7060303@oracle.com> References: <542985E5.1030203@oracle.com> <54298980.2030606@oracle.com> <5429A555.7060303@oracle.com> Message-ID: <09C36110-3970-42B0-A5E9-16F946BB1FF9@oracle.com> > What I saw on 9 is that there are no eliminated allocations on the test. I experimented a little [1] with the test case and it seems the new shape doesn't allow both allocations to go away. Both allocations go away on 8u40 and there's no allocation elimination on 9. Is it related to this? https://bugs.openjdk.java.net/browse/JDK-8058746 I have a fix for this one going out soon. Roland. From david.holmes at oracle.com Tue Oct 7 06:35:06 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 07 Oct 2014 16:35:06 +1000 Subject: RFR(XXS) : 8059732 : improve hotspot_*test targets In-Reply-To: <5431662F.2040804@oracle.com> References: <5431662F.2040804@oracle.com> Message-ID: <5433899A.4040405@oracle.com> Hi Igor, Looks okay to me. Thanks, David On 6/10/2014 1:39 AM, Igor Ignatyev wrote: > webrev: http://cr.openjdk.java.net/~iignatyev/8059732/webrev.00/ > 33 lines changed: 20 ins; 9 del; 4 mod; > > Hi all, > > Please review changes in hotspot_*test targets: > - common part is extracted as sanitytest target > - flags to test are stored in TEST_FLAGS variable > - tests fail if one of executions fail (not the last one, as it was > before) > > jbs: https://bugs.openjdk.java.net/browse/JDK-8059732 > testing: jprt > From roland.westrelin at oracle.com Tue Oct 7 08:36:11 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 7 Oct 2014 10:36:11 +0200 Subject: RFR(XS): 8058746: escape analysis special case code for array copy broken by 7173584 Message-ID: <834241B6-1DD9-45FE-AE17-614360C56B0A@oracle.com> Change that introduced array copy macro nodes broke escape analysis support for array copies: http://cr.openjdk.java.net/~roland/8058746/webrev.00/ Roland. From igor.veresov at oracle.com Tue Oct 7 09:47:03 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 7 Oct 2014 02:47:03 -0700 Subject: RFR(XS): 8058746: escape analysis special case code for array copy broken by 7173584 In-Reply-To: <834241B6-1DD9-45FE-AE17-614360C56B0A@oracle.com> References: <834241B6-1DD9-45FE-AE17-614360C56B0A@oracle.com> Message-ID: <16608DBC-8962-408A-956D-0DE98222C8DD@oracle.com> Looks good to me. igor On Oct 7, 2014, at 1:36 AM, Roland Westrelin wrote: > Change that introduced array copy macro nodes broke escape analysis support for array copies: > > http://cr.openjdk.java.net/~roland/8058746/webrev.00/ > > Roland. From zoltan.majo at oracle.com Tue Oct 7 10:32:32 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 07 Oct 2014 12:32:32 +0200 Subject: [9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation) Message-ID: <5433C140.9070400@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8059604 Problem: With tiered compilation enabled, the value of 6 different thresholds must be set to control when the JVM compiles methods for the first time. That is too detailed for the average customer. Solution: This patch adds a new flag, CompileThresholdScalingPercentage, to control when methods are first compiled. The new flag scales thresholds the following way: - if CompileThresholdScalingPercentage==100, the default threshold values are used - if CompileThresholdScalingPercentage>100, threshold values are scaled up (e.g., CompileThresholdScalingPercentage=120 scales up thresholds by a factor of 1.2X) - if 0 < CompileThresholdScalingPercentage < 100, threshold values are scaled down accordingly. The new flag works both with and without tiered compilation. Thus, the new flag allows compilation to be controlled the same way both with and without tiered compilation: - with tiered compilation enabled, the value of the flags Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog, Tier3InvocationThreshold, Tier3MinInvocationThreshold, Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled - with tiered compilation disabled, the value of CompileThreshold is scaled Currently, tiered and non-tiered compilation treats threshold values slightly differently: For a threshold value of N and without tiered compilation enabled, methods are compiled *before* their Nth execution. With tiered compilation enabled, methods are compiled *after* the their Nth execution. The patch addresses the difference between tiered/non-tiered compilation: Methods are compiled right before their Nth execution in both cases (the non-tiered way). If CompileThresholdScalingPercentage==0, all methods are interpreted (similarly to the case when CompileThreshold==0). This patch is the second (out of three) parts of JDK-8050853 (adding support for per-compilation thresholds): https://bugs.openjdk.java.net/browse/JDK-8050853 . Webrev: http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/ Testing: JPRT, manual testing Thank you and best regards, Zoltan From albert.noll at oracle.com Tue Oct 7 10:56:06 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 07 Oct 2014 12:56:06 +0200 Subject: [9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation) In-Reply-To: <5433C140.9070400@oracle.com> References: <5433C140.9070400@oracle.com> Message-ID: <5433C6C6.20602@oracle.com> Hi Zoltan, here is some high-level feedback: How about using a scaling factor instead of using percentage? What happens if a threshold becomes 0 after scaling? Best, Albert On 10/07/2014 12:32 PM, Zolt?n Maj? wrote: > Hi, > > > please review the following patch. > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059604 > > > Problem: With tiered compilation enabled, the value of 6 different > thresholds must be set to control when the JVM compiles methods for > the first time. That is too detailed for the average customer. > > > Solution: This patch adds a new flag, > CompileThresholdScalingPercentage, to control when methods are first > compiled. The new flag scales thresholds the following way: > > - if CompileThresholdScalingPercentage==100, the default threshold > values are used > - if CompileThresholdScalingPercentage>100, threshold values are > scaled up (e.g., CompileThresholdScalingPercentage=120 scales up > thresholds by a factor of 1.2X) > - if 0 < CompileThresholdScalingPercentage < 100, threshold values are > scaled down accordingly. > > The new flag works both with and without tiered compilation. Thus, the > new flag allows compilation to be controlled the same way both with > and without tiered compilation: > > - with tiered compilation enabled, the value of the flags > Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog, > Tier3InvocationThreshold, Tier3MinInvocationThreshold, > Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled > > - with tiered compilation disabled, the value of CompileThreshold is > scaled > > Currently, tiered and non-tiered compilation treats threshold values > slightly differently: For a threshold value of N and without tiered > compilation enabled, methods are compiled *before* their Nth > execution. With tiered compilation enabled, methods are compiled > *after* the their Nth execution. > > The patch addresses the difference between tiered/non-tiered > compilation: Methods are compiled right before their Nth execution in > both cases (the non-tiered way). If > CompileThresholdScalingPercentage==0, all methods are interpreted > (similarly to the case when CompileThreshold==0). > > This patch is the second (out of three) parts of JDK-8050853 (adding > support for per-compilation thresholds): > https://bugs.openjdk.java.net/browse/JDK-8050853 . > > > Webrev: http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/ > > > Testing: JPRT, manual testing > > > Thank you and best regards, > > > Zoltan > From tobias.hartmann at oracle.com Tue Oct 7 11:03:04 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 07 Oct 2014 13:03:04 +0200 Subject: [9] RFR(XS): 8059735: make_not_entrant_or_zombie sees zombies Message-ID: <5433C868.3000606@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8059735 Webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.00/ Problem: In 'NMethodSweeper::process_nmethod' a non-entrant nmethod is processed and can be converted to zombie (line 549 of sweeper.cpp). To clean the IC stubs of that nmethod [1] we acquire the CompiledIC_lock and check for a safepoint. In this case, there is a safepoint request and we block. During the safepoint a VM_Deoptimize operation is executed (due to classloading) and the non-entrant nmethod is set to zombie by 'CodeCache::make_marked_nmethods_zombies'. After the safepoint the sweeper continues and tries to set the nmethod to zombie again. Solution: Use a MutexLockerEx with the '_no_safepoint_check_flag' to acquire the CompiledIC_lock. Testing: - Failing tests - JPRT Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8058737 -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.noll at oracle.com Tue Oct 7 11:16:05 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 07 Oct 2014 13:16:05 +0200 Subject: [9] RFR(XS): 8059735: make_not_entrant_or_zombie sees zombies In-Reply-To: <5433C868.3000606@oracle.com> References: <5433C868.3000606@oracle.com> Message-ID: <5433CB75.7050807@oracle.com> Hi Tobias, would it also work to check the state of the nmethod before calling make_zombie? if (nm->is_not_entrant()) { nm->make_zombie() } In any case, it would be nice the have a comment that explains why we should not enter a safpoint / have to do the extra check as described above. Best, Albert On 10/07/2014 01:03 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059735 > Webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.00/ > > Problem: > In 'NMethodSweeper::process_nmethod' a non-entrant nmethod is > processed and can be converted to zombie (line 549 of sweeper.cpp). To > clean the IC stubs of that nmethod [1] we acquire the CompiledIC_lock > and check for a safepoint. In this case, there is a safepoint request > and we block. During the safepoint a VM_Deoptimize operation is > executed (due to classloading) and the non-entrant nmethod is set to > zombie by 'CodeCache::make_marked_nmethods_zombies'. After the > safepoint the sweeper continues and tries to set the nmethod to zombie > again. > > Solution: > Use a MutexLockerEx with the '_no_safepoint_check_flag' to acquire the > CompiledIC_lock. > > Testing: > - Failing tests > - JPRT > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8058737 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.gerdin at oracle.com Tue Oct 7 11:35:20 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 07 Oct 2014 13:35:20 +0200 Subject: [9] RFR(XS): 8059735: make_not_entrant_or_zombie sees zombies In-Reply-To: <5433C868.3000606@oracle.com> References: <5433C868.3000606@oracle.com> Message-ID: <5433CFF8.1030605@oracle.com> Hi Tobias, On 2014-10-07 13:03, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059735 > Webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.00/ > > Problem: > In 'NMethodSweeper::process_nmethod' a non-entrant nmethod is processed > and can be converted to zombie (line 549 of sweeper.cpp). To clean the > IC stubs of that nmethod [1] we acquire the CompiledIC_lock and check > for a safepoint. In this case, there is a safepoint request and we > block. During the safepoint a VM_Deoptimize operation is executed (due > to classloading) and the non-entrant nmethod is set to zombie by > 'CodeCache::make_marked_nmethods_zombies'. After the safepoint the > sweeper continues and tries to set the nmethod to zombie again. > > Solution: > Use a MutexLockerEx with the '_no_safepoint_check_flag' to acquire the > CompiledIC_lock. This is an unsafe operation which will lead to a deadlock. You _cannot_ mix taking a single lock object with and without _no_safepoint_check_flag! See https://bugs.openjdk.java.net/browse/JDK-8047290 /Mikael > > Testing: > - Failing tests > - JPRT > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8058737 From tobias.hartmann at oracle.com Tue Oct 7 12:24:14 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 07 Oct 2014 14:24:14 +0200 Subject: [9] RFR(XS): 8059735: make_not_entrant_or_zombie sees zombies In-Reply-To: <5433CFF8.1030605@oracle.com> References: <5433C868.3000606@oracle.com> <5433CFF8.1030605@oracle.com> Message-ID: <5433DB6E.9040200@oracle.com> Hi Mikael, thanks for the information, I didn't know that. I will change the fix according to Albert's proposal. Best, Tobias On 07.10.2014 13:35, Mikael Gerdin wrote: > Hi Tobias, > > On 2014-10-07 13:03, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059735 >> Webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.00/ >> >> Problem: >> In 'NMethodSweeper::process_nmethod' a non-entrant nmethod is processed >> and can be converted to zombie (line 549 of sweeper.cpp). To clean the >> IC stubs of that nmethod [1] we acquire the CompiledIC_lock and check >> for a safepoint. In this case, there is a safepoint request and we >> block. During the safepoint a VM_Deoptimize operation is executed (due >> to classloading) and the non-entrant nmethod is set to zombie by >> 'CodeCache::make_marked_nmethods_zombies'. After the safepoint the >> sweeper continues and tries to set the nmethod to zombie again. >> >> Solution: >> Use a MutexLockerEx with the '_no_safepoint_check_flag' to acquire the >> CompiledIC_lock. > > This is an unsafe operation which will lead to a deadlock. > You _cannot_ mix taking a single lock object with and without > _no_safepoint_check_flag! > > See > https://bugs.openjdk.java.net/browse/JDK-8047290 > > /Mikael > >> >> Testing: >> - Failing tests >> - JPRT >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8058737 From tobias.hartmann at oracle.com Tue Oct 7 13:08:59 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 07 Oct 2014 15:08:59 +0200 Subject: [9] RFR(XS): 8059735: make_not_entrant_or_zombie sees zombies In-Reply-To: <5433CB75.7050807@oracle.com> References: <5433C868.3000606@oracle.com> <5433CB75.7050807@oracle.com> Message-ID: <5433E5EB.7020206@oracle.com> Hi Albert, thanks for the review. On 07.10.2014 13:16, Albert Noll wrote: > Hi Tobias, > > would it also work to check the state of the nmethod before calling > make_zombie? > > if (nm->is_not_entrant()) { > nm->make_zombie() > } Yes, regarding Mikael's comment, that is a better solution. > In any case, it would be nice the have a comment that explains why we > should not enter a > safpoint / have to do the extra check as described above. I changed the fix accordingly and added an additional comment. I also moved the statistics/debugging code such that it is only executed if the sweeper sets the nmethod to zombie. New webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.01/ Thanks, Tobias > > Best, > Albert > > > On 10/07/2014 01:03 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059735 >> Webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.00/ >> >> Problem: >> In 'NMethodSweeper::process_nmethod' a non-entrant nmethod is >> processed and can be converted to zombie (line 549 of sweeper.cpp). To >> clean the IC stubs of that nmethod [1] we acquire the CompiledIC_lock >> and check for a safepoint. In this case, there is a safepoint request >> and we block. During the safepoint a VM_Deoptimize operation is >> executed (due to classloading) and the non-entrant nmethod is set to >> zombie by 'CodeCache::make_marked_nmethods_zombies'. After the >> safepoint the sweeper continues and tries to set the nmethod to zombie >> again. >> >> Solution: >> Use a MutexLockerEx with the '_no_safepoint_check_flag' to acquire the >> CompiledIC_lock. >> >> Testing: >> - Failing tests >> - JPRT >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8058737 > From albert.noll at oracle.com Tue Oct 7 13:21:51 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 07 Oct 2014 15:21:51 +0200 Subject: [9] RFR(XS): 8059735: make_not_entrant_or_zombie sees zombies In-Reply-To: <5433E5EB.7020206@oracle.com> References: <5433C868.3000606@oracle.com> <5433CB75.7050807@oracle.com> <5433E5EB.7020206@oracle.com> Message-ID: <5433E8EF.6080509@oracle.com> Hi Tobias, On 10/07/2014 03:08 PM, Tobias Hartmann wrote: > Hi Albert, > > thanks for the review. > > On 07.10.2014 13:16, Albert Noll wrote: >> Hi Tobias, >> >> would it also work to check the state of the nmethod before calling >> make_zombie? >> >> if (nm->is_not_entrant()) { >> nm->make_zombie() >> } > > Yes, regarding Mikael's comment, that is a better solution. > >> In any case, it would be nice the have a comment that explains why we >> should not enter a >> safpoint / have to do the extra check as described above. > > I changed the fix accordingly and added an additional comment. I also > moved the statistics/debugging code such that it is only executed if > the sweeper sets the nmethod to zombie. > > New webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.01/ I have one additional question. Do we need to hold the "CompiledIC_lock" when we call make_zombie()? Best, Albert > Thanks, > Tobias > >> >> Best, >> Albert >> >> >> On 10/07/2014 01:03 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059735 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.00/ >>> >>> Problem: >>> In 'NMethodSweeper::process_nmethod' a non-entrant nmethod is >>> processed and can be converted to zombie (line 549 of sweeper.cpp). To >>> clean the IC stubs of that nmethod [1] we acquire the CompiledIC_lock >>> and check for a safepoint. In this case, there is a safepoint request >>> and we block. During the safepoint a VM_Deoptimize operation is >>> executed (due to classloading) and the non-entrant nmethod is set to >>> zombie by 'CodeCache::make_marked_nmethods_zombies'. After the >>> safepoint the sweeper continues and tries to set the nmethod to zombie >>> again. >>> >>> Solution: >>> Use a MutexLockerEx with the '_no_safepoint_check_flag' to acquire the >>> CompiledIC_lock. >>> >>> Testing: >>> - Failing tests >>> - JPRT >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8058737 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zoltan.majo at oracle.com Tue Oct 7 13:45:30 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 07 Oct 2014 15:45:30 +0200 Subject: [9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation) In-Reply-To: <5433C6C6.20602@oracle.com> References: <5433C140.9070400@oracle.com> <5433C6C6.20602@oracle.com> Message-ID: <5433EE7A.9060607@oracle.com> Hi Albert, thank you for your feedback. On 10/07/2014 12:56 PM, Albert Noll wrote: > How about using a scaling factor instead of using percentage? I think that is a good idea because a scaling factor (expressed as a double) allows a finer-grained control of compilation thresholds than a scaling percentage (expressed as an integer). Here is the webrev with the scaling factor: http://cr.openjdk.java.net/~zmajo/8059604/webrev.01/ The name of the flag is changed to CompileThresholdScaling (from CompileThresholdScalingPercentage). > What happens if a threshold becomes 0 after scaling? Then all methods will be interpreted. That seems to be the convention (in src/share/vm/runtime/arguments.cpp). Best regards, Zoltan > > Best, > Albert > > > On 10/07/2014 12:32 PM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following patch. >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059604 >> >> >> Problem: With tiered compilation enabled, the value of 6 different >> thresholds must be set to control when the JVM compiles methods for >> the first time. That is too detailed for the average customer. >> >> >> Solution: This patch adds a new flag, >> CompileThresholdScalingPercentage, to control when methods are first >> compiled. The new flag scales thresholds the following way: >> >> - if CompileThresholdScalingPercentage==100, the default threshold >> values are used >> - if CompileThresholdScalingPercentage>100, threshold values are >> scaled up (e.g., CompileThresholdScalingPercentage=120 scales up >> thresholds by a factor of 1.2X) >> - if 0 < CompileThresholdScalingPercentage < 100, threshold values >> are scaled down accordingly. >> >> The new flag works both with and without tiered compilation. Thus, >> the new flag allows compilation to be controlled the same way both >> with and without tiered compilation: >> >> - with tiered compilation enabled, the value of the flags >> Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog, >> Tier3InvocationThreshold, Tier3MinInvocationThreshold, >> Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled >> >> - with tiered compilation disabled, the value of CompileThreshold is >> scaled >> >> Currently, tiered and non-tiered compilation treats threshold values >> slightly differently: For a threshold value of N and without tiered >> compilation enabled, methods are compiled *before* their Nth >> execution. With tiered compilation enabled, methods are compiled >> *after* the their Nth execution. >> >> The patch addresses the difference between tiered/non-tiered >> compilation: Methods are compiled right before their Nth execution in >> both cases (the non-tiered way). If >> CompileThresholdScalingPercentage==0, all methods are interpreted >> (similarly to the case when CompileThreshold==0). >> >> This patch is the second (out of three) parts of JDK-8050853 (adding >> support for per-compilation thresholds): >> https://bugs.openjdk.java.net/browse/JDK-8050853 . >> >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/ >> >> >> Testing: JPRT, manual testing >> >> >> Thank you and best regards, >> >> >> Zoltan >> > From zoltan.majo at oracle.com Tue Oct 7 13:47:27 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 07 Oct 2014 15:47:27 +0200 Subject: [9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation) In-Reply-To: <5433EE7A.9060607@oracle.com> References: <5433C140.9070400@oracle.com> <5433C6C6.20602@oracle.com> <5433EE7A.9060607@oracle.com> Message-ID: <5433EEEF.1070303@oracle.com> P.S.: Forgot to say that the new version (webrev.01) passes all JPRT tests. On 10/07/2014 03:45 PM, Zolt?n Maj? wrote: > Hi Albert, > > > thank you for your feedback. > > On 10/07/2014 12:56 PM, Albert Noll wrote: >> How about using a scaling factor instead of using percentage? > > I think that is a good idea because a scaling factor (expressed as a > double) allows a finer-grained control of compilation thresholds than > a scaling percentage (expressed as an integer). > > Here is the webrev with the scaling factor: > > http://cr.openjdk.java.net/~zmajo/8059604/webrev.01/ > > The name of the flag is changed to CompileThresholdScaling (from > CompileThresholdScalingPercentage). > >> What happens if a threshold becomes 0 after scaling? > > Then all methods will be interpreted. That seems to be the convention > (in src/share/vm/runtime/arguments.cpp). > > Best regards, > > > Zoltan > >> >> Best, >> Albert >> >> >> On 10/07/2014 12:32 PM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the following patch. >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059604 >>> >>> >>> Problem: With tiered compilation enabled, the value of 6 different >>> thresholds must be set to control when the JVM compiles methods for >>> the first time. That is too detailed for the average customer. >>> >>> >>> Solution: This patch adds a new flag, >>> CompileThresholdScalingPercentage, to control when methods are first >>> compiled. The new flag scales thresholds the following way: >>> >>> - if CompileThresholdScalingPercentage==100, the default threshold >>> values are used >>> - if CompileThresholdScalingPercentage>100, threshold values are >>> scaled up (e.g., CompileThresholdScalingPercentage=120 scales up >>> thresholds by a factor of 1.2X) >>> - if 0 < CompileThresholdScalingPercentage < 100, threshold values >>> are scaled down accordingly. >>> >>> The new flag works both with and without tiered compilation. Thus, >>> the new flag allows compilation to be controlled the same way both >>> with and without tiered compilation: >>> >>> - with tiered compilation enabled, the value of the flags >>> Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog, >>> Tier3InvocationThreshold, Tier3MinInvocationThreshold, >>> Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled >>> >>> - with tiered compilation disabled, the value of CompileThreshold is >>> scaled >>> >>> Currently, tiered and non-tiered compilation treats threshold values >>> slightly differently: For a threshold value of N and without tiered >>> compilation enabled, methods are compiled *before* their Nth >>> execution. With tiered compilation enabled, methods are compiled >>> *after* the their Nth execution. >>> >>> The patch addresses the difference between tiered/non-tiered >>> compilation: Methods are compiled right before their Nth execution >>> in both cases (the non-tiered way). If >>> CompileThresholdScalingPercentage==0, all methods are interpreted >>> (similarly to the case when CompileThreshold==0). >>> >>> This patch is the second (out of three) parts of JDK-8050853 (adding >>> support for per-compilation thresholds): >>> https://bugs.openjdk.java.net/browse/JDK-8050853 . >>> >>> >>> Webrev: http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/ >>> >>> >>> Testing: JPRT, manual testing >>> >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >> > From tobias.hartmann at oracle.com Tue Oct 7 14:52:14 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 07 Oct 2014 16:52:14 +0200 Subject: [9] RFR(XS): 8059735: make_not_entrant_or_zombie sees zombies In-Reply-To: <5433E8EF.6080509@oracle.com> References: <5433C868.3000606@oracle.com> <5433CB75.7050807@oracle.com> <5433E5EB.7020206@oracle.com> <5433E8EF.6080509@oracle.com> Message-ID: <5433FE1E.1020403@oracle.com> Hi Albert, On 07.10.2014 15:21, Albert Noll wrote: > Hi Tobias, > > On 10/07/2014 03:08 PM, Tobias Hartmann wrote: >> Hi Albert, >> >> thanks for the review. >> >> On 07.10.2014 13:16, Albert Noll wrote: >>> Hi Tobias, >>> >>> would it also work to check the state of the nmethod before calling >>> make_zombie? >>> >>> if (nm->is_not_entrant()) { >>> nm->make_zombie() >>> } >> >> Yes, regarding Mikael's comment, that is a better solution. >> >>> In any case, it would be nice the have a comment that explains why we >>> should not enter a >>> safpoint / have to do the extra check as described above. >> >> I changed the fix accordingly and added an additional comment. I also >> moved the statistics/debugging code such that it is only executed if >> the sweeper sets the nmethod to zombie. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.01/ > I have one additional question. Do we need to hold the "CompiledIC_lock" > when > we call make_zombie()? No, we don't need to hold the lock for 'make_zombie()'. I narrowed the scope of the lock: http://cr.openjdk.java.net/~thartmann/8059735/webrev.02/ Thanks, Tobias > > Best, > Albert > >> Thanks, >> Tobias >> >>> >>> Best, >>> Albert >>> >>> >>> On 10/07/2014 01:03 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059735 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.00/ >>>> >>>> Problem: >>>> In 'NMethodSweeper::process_nmethod' a non-entrant nmethod is >>>> processed and can be converted to zombie (line 549 of sweeper.cpp). To >>>> clean the IC stubs of that nmethod [1] we acquire the CompiledIC_lock >>>> and check for a safepoint. In this case, there is a safepoint request >>>> and we block. During the safepoint a VM_Deoptimize operation is >>>> executed (due to classloading) and the non-entrant nmethod is set to >>>> zombie by 'CodeCache::make_marked_nmethods_zombies'. After the >>>> safepoint the sweeper continues and tries to set the nmethod to zombie >>>> again. >>>> >>>> Solution: >>>> Use a MutexLockerEx with the '_no_safepoint_check_flag' to acquire the >>>> CompiledIC_lock. >>>> >>>> Testing: >>>> - Failing tests >>>> - JPRT >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8058737 >>> > From vladimir.kozlov at oracle.com Tue Oct 7 16:29:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 07 Oct 2014 09:29:11 -0700 Subject: [9] RFR(XS): 8059735: make_not_entrant_or_zombie sees zombies In-Reply-To: <5433FE1E.1020403@oracle.com> References: <5433C868.3000606@oracle.com> <5433CB75.7050807@oracle.com> <5433E5EB.7020206@oracle.com> <5433E8EF.6080509@oracle.com> <5433FE1E.1020403@oracle.com> Message-ID: <543414D7.4090702@oracle.com> Looks good. Thanks, Vladimir On 10/7/14 7:52 AM, Tobias Hartmann wrote: > Hi Albert, > > On 07.10.2014 15:21, Albert Noll wrote: >> Hi Tobias, >> >> On 10/07/2014 03:08 PM, Tobias Hartmann wrote: >>> Hi Albert, >>> >>> thanks for the review. >>> >>> On 07.10.2014 13:16, Albert Noll wrote: >>>> Hi Tobias, >>>> >>>> would it also work to check the state of the nmethod before calling >>>> make_zombie? >>>> >>>> if (nm->is_not_entrant()) { >>>> nm->make_zombie() >>>> } >>> >>> Yes, regarding Mikael's comment, that is a better solution. >>> >>>> In any case, it would be nice the have a comment that explains why we >>>> should not enter a >>>> safpoint / have to do the extra check as described above. >>> >>> I changed the fix accordingly and added an additional comment. I also >>> moved the statistics/debugging code such that it is only executed if >>> the sweeper sets the nmethod to zombie. >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.01/ >> I have one additional question. Do we need to hold the "CompiledIC_lock" >> when >> we call make_zombie()? > > No, we don't need to hold the lock for 'make_zombie()'. I narrowed the > scope of the lock: > > http://cr.openjdk.java.net/~thartmann/8059735/webrev.02/ > > Thanks, > Tobias > >> >> Best, >> Albert >> >>> Thanks, >>> Tobias >>> >>>> >>>> Best, >>>> Albert >>>> >>>> >>>> On 10/07/2014 01:03 PM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059735 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.00/ >>>>> >>>>> Problem: >>>>> In 'NMethodSweeper::process_nmethod' a non-entrant nmethod is >>>>> processed and can be converted to zombie (line 549 of sweeper.cpp). To >>>>> clean the IC stubs of that nmethod [1] we acquire the CompiledIC_lock >>>>> and check for a safepoint. In this case, there is a safepoint request >>>>> and we block. During the safepoint a VM_Deoptimize operation is >>>>> executed (due to classloading) and the non-entrant nmethod is set to >>>>> zombie by 'CodeCache::make_marked_nmethods_zombies'. After the >>>>> safepoint the sweeper continues and tries to set the nmethod to zombie >>>>> again. >>>>> >>>>> Solution: >>>>> Use a MutexLockerEx with the '_no_safepoint_check_flag' to acquire the >>>>> CompiledIC_lock. >>>>> >>>>> Testing: >>>>> - Failing tests >>>>> - JPRT >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8058737 >>>> >> From vladimir.kozlov at oracle.com Tue Oct 7 16:46:48 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 07 Oct 2014 09:46:48 -0700 Subject: RFR(XS): 8058746: escape analysis special case code for array copy broken by 7173584 In-Reply-To: <834241B6-1DD9-45FE-AE17-614360C56B0A@oracle.com> References: <834241B6-1DD9-45FE-AE17-614360C56B0A@oracle.com> Message-ID: <543418F8.9060604@oracle.com> Good. Thanks, Vladimir On 10/7/14 1:36 AM, Roland Westrelin wrote: > Change that introduced array copy macro nodes broke escape analysis support for array copies: > > http://cr.openjdk.java.net/~roland/8058746/webrev.00/ > > Roland. > From vladimir.x.ivanov at oracle.com Tue Oct 7 16:54:39 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 07 Oct 2014 20:54:39 +0400 Subject: RFR(XS): 8058746: escape analysis special case code for array copy broken by 7173584 In-Reply-To: <834241B6-1DD9-45FE-AE17-614360C56B0A@oracle.com> References: <834241B6-1DD9-45FE-AE17-614360C56B0A@oracle.com> Message-ID: <54341ACF.3000805@oracle.com> Looks good. Best regards, Vladimir Ivanov On 10/7/14, 12:36 PM, Roland Westrelin wrote: > Change that introduced array copy macro nodes broke escape analysis support for array copies: > > http://cr.openjdk.java.net/~roland/8058746/webrev.00/ > > Roland. > From vladimir.x.ivanov at oracle.com Tue Oct 7 16:55:34 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 07 Oct 2014 20:55:34 +0400 Subject: [9] RFR (XS): 8058825: EA: ConnectionGraph::split_unique_types does incorrect scalar replacement In-Reply-To: <09C36110-3970-42B0-A5E9-16F946BB1FF9@oracle.com> References: <542985E5.1030203@oracle.com> <54298980.2030606@oracle.com> <5429A555.7060303@oracle.com> <09C36110-3970-42B0-A5E9-16F946BB1FF9@oracle.com> Message-ID: <54341B06.6030305@oracle.com> Roland, thanks for the pointer. It should be the same problem. Best regards, Vladimir Ivanov On 10/6/14, 7:05 PM, Roland Westrelin wrote: >> What I saw on 9 is that there are no eliminated allocations on the test. I experimented a little [1] with the test case and it seems the new shape doesn't allow both allocations to go away. Both allocations go away on 8u40 and there's no allocation elimination on 9. > > Is it related to this? > > https://bugs.openjdk.java.net/browse/JDK-8058746 > > I have a fix for this one going out soon. > > Roland. > From tobias.hartmann at oracle.com Tue Oct 7 16:59:31 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 07 Oct 2014 18:59:31 +0200 Subject: [9] RFR(XS): 8059735: make_not_entrant_or_zombie sees zombies In-Reply-To: <543414D7.4090702@oracle.com> References: <5433C868.3000606@oracle.com> <5433CB75.7050807@oracle.com> <5433E5EB.7020206@oracle.com> <5433E8EF.6080509@oracle.com> <5433FE1E.1020403@oracle.com> <543414D7.4090702@oracle.com> Message-ID: <54341BF3.2080203@oracle.com> Thanks, Vladimir. Best, Tobias On 07.10.2014 18:29, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/7/14 7:52 AM, Tobias Hartmann wrote: >> Hi Albert, >> >> On 07.10.2014 15:21, Albert Noll wrote: >>> Hi Tobias, >>> >>> On 10/07/2014 03:08 PM, Tobias Hartmann wrote: >>>> Hi Albert, >>>> >>>> thanks for the review. >>>> >>>> On 07.10.2014 13:16, Albert Noll wrote: >>>>> Hi Tobias, >>>>> >>>>> would it also work to check the state of the nmethod before calling >>>>> make_zombie? >>>>> >>>>> if (nm->is_not_entrant()) { >>>>> nm->make_zombie() >>>>> } >>>> >>>> Yes, regarding Mikael's comment, that is a better solution. >>>> >>>>> In any case, it would be nice the have a comment that explains why we >>>>> should not enter a >>>>> safpoint / have to do the extra check as described above. >>>> >>>> I changed the fix accordingly and added an additional comment. I also >>>> moved the statistics/debugging code such that it is only executed if >>>> the sweeper sets the nmethod to zombie. >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.01/ >>> I have one additional question. Do we need to hold the "CompiledIC_lock" >>> when >>> we call make_zombie()? >> >> No, we don't need to hold the lock for 'make_zombie()'. I narrowed the >> scope of the lock: >> >> http://cr.openjdk.java.net/~thartmann/8059735/webrev.02/ >> >> Thanks, >> Tobias >> >>> >>> Best, >>> Albert >>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 10/07/2014 01:03 PM, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> please review the following patch. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059735 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.00/ >>>>>> >>>>>> Problem: >>>>>> In 'NMethodSweeper::process_nmethod' a non-entrant nmethod is >>>>>> processed and can be converted to zombie (line 549 of >>>>>> sweeper.cpp). To >>>>>> clean the IC stubs of that nmethod [1] we acquire the CompiledIC_lock >>>>>> and check for a safepoint. In this case, there is a safepoint request >>>>>> and we block. During the safepoint a VM_Deoptimize operation is >>>>>> executed (due to classloading) and the non-entrant nmethod is set to >>>>>> zombie by 'CodeCache::make_marked_nmethods_zombies'. After the >>>>>> safepoint the sweeper continues and tries to set the nmethod to >>>>>> zombie >>>>>> again. >>>>>> >>>>>> Solution: >>>>>> Use a MutexLockerEx with the '_no_safepoint_check_flag' to acquire >>>>>> the >>>>>> CompiledIC_lock. >>>>>> >>>>>> Testing: >>>>>> - Failing tests >>>>>> - JPRT >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8058737 >>>>> >>> From zoltan.majo at oracle.com Tue Oct 7 17:53:00 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 07 Oct 2014 19:53:00 +0200 Subject: [9] RFR(S): 8059847: complement JDK-8055286 and JDK-8056964 changes Message-ID: <5434287C.6060204@oracle.com> Hi, please review the following small patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8059847 Problem: CompileCommand=option does not support flags of type double. Solution: Add support for flags of type double. Output: java -XX:CompileCommand=option,Test::test,ccstrlist,MyListOption,_foo,_bar -XX:CompileCommand=option,Test::test,ccstr,MyStrOption,_foo -XX:CompileCommand=option,Test::test,bool,MyBoolOption,false -XX:CompileCommand=option,Test::test,intx,MyIntxOption,-1 -XX:CompileCommand=option,Test::test,uintx,MyUintxOption,1 -XX:CompileCommand=option,Test::test,MyFlag -XX:CompileCommand=option,Test::test,double,MyDoubleOption,1.123 -version CompilerOracle: option Test.test const char* MyListOption = '_foo _bar' CompilerOracle: option Test.test const char* MyStrOption = '_foo' CompilerOracle: option Test.test bool MyBoolOption = false CompilerOracle: option Test.test intx MyIntxOption = -1 CompilerOracle: option Test.test uintx MyUintxOption = 1 CompilerOracle: option Test.test bool MyFlag = true CompilerOracle: option Test.test double MyDoubleOption = '1.123000' java version "1.9.0-ea" Java(TM) SE Runtime Environment (build 1.9.0-ea-b33) Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-fastdebug-internal, mixed mode) Webrev: http://cr.openjdk.java.net/~zmajo/8059847/webrev.00/ Testing: JPRT Thank you and best regards, Zoltan From david.r.chase at oracle.com Tue Oct 7 18:06:29 2014 From: david.r.chase at oracle.com (David Chase) Date: Tue, 7 Oct 2014 14:06:29 -0400 Subject: [9] RFR(S): 8059847: complement JDK-8055286 and JDK-8056964 changes In-Reply-To: <5434287C.6060204@oracle.com> References: <5434287C.6060204@oracle.com> Message-ID: Not a R-reviewer, but I approve. Do we need to add a test (? what would it look like?) to ensure that it works? David On 2014-10-07, at 1:53 PM, Zolt?n Maj? wrote: > Hi, > > > please review the following small patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059847 > > Problem: CompileCommand=option does not support flags of type double. > > Solution: Add support for flags of type double. Output: > > java -XX:CompileCommand=option,Test::test,ccstrlist,MyListOption,_foo,_bar -XX:CompileCommand=option,Test::test,ccstr,MyStrOption,_foo -XX:CompileCommand=option,Test::test,bool,MyBoolOption,false -XX:CompileCommand=option,Test::test,intx,MyIntxOption,-1 -XX:CompileCommand=option,Test::test,uintx,MyUintxOption,1 -XX:CompileCommand=option,Test::test,MyFlag -XX:CompileCommand=option,Test::test,double,MyDoubleOption,1.123 -version > > CompilerOracle: option Test.test const char* MyListOption = '_foo _bar' > CompilerOracle: option Test.test const char* MyStrOption = '_foo' > CompilerOracle: option Test.test bool MyBoolOption = false > CompilerOracle: option Test.test intx MyIntxOption = -1 > CompilerOracle: option Test.test uintx MyUintxOption = 1 > CompilerOracle: option Test.test bool MyFlag = true > CompilerOracle: option Test.test double MyDoubleOption = '1.123000' > java version "1.9.0-ea" > Java(TM) SE Runtime Environment (build 1.9.0-ea-b33) > Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-fastdebug-internal, mixed mode) > > > Webrev: http://cr.openjdk.java.net/~zmajo/8059847/webrev.00/ > > Testing: JPRT > > Thank you and best regards, > > > Zoltan > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From staffan.friberg at oracle.com Tue Oct 7 19:18:35 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 07 Oct 2014 12:18:35 -0700 Subject: RFR - Avoid G1 write barriers on newly allocated objects In-Reply-To: <3EB00253-5BB0-47DA-8C68-5F4AF243B4F4@oracle.com> References: <540A47E0.2080803@oracle.com> <2548885.ND5rUTNDSq@mgerdin03> <54136502.2000305@oracle.com> <54137E92.4030803@oracle.com> <541768C1.20507@oracle.com> <54178A86.4090500@oracle.com> <5418AE85.1070309@oracle.com> <3EB00253-5BB0-47DA-8C68-5F4AF243B4F4@oracle.com> Message-ID: <54343C8B.7080701@oracle.com> This is handled already for humongous objects, they will generate deferred card marks for as part of their allocation if they are allocated outside of the young space. See CollectedHeap::new_store_pre_barrier and OptoRuntime::new_store_pre_barrier for details. Agree that it could be made more visible, but it is probably better handled that as a G1 update when required. Thanks for the review. //Staffan On 10/03/2014 02:37 PM, Igor Veresov wrote: > Sorry that I couldn?t get this for so long. > The C2 part seems very good. The only comment is that the code (the post-barrier elimination part) depends on the fact the the new object is allocated in the young gen. Would it make sense to harden the code a little bit in case G1 gets single-generation or changes its allocation scheme? Like adding G1CollectedHeap::new_objects_require_post_barrier() or something like that? Anyways, up to you, reviewed. > > igor > > On Sep 16, 2014, at 2:41 PM, Staffan Friberg wrote: > >> Thanks Vladimir, >> >> Updated with your suggestions. Added a small comment in g1_can_remove_pre_barrier method since the alloc == NULL check is quite a bit earlier. >> >> New webrev, http://cr.openjdk.java.net/~sfriberg/8057737/webrev.03 >> >> Cheers, >> Staffan >> >> >> On 09/15/2014 05:55 PM, Vladimir Kozlov wrote: >>> You need only check (alloc == st_alloc) because alloc != NULL at this point: >>> >>> + if (st_alloc != NULL && alloc == st_alloc) { >>> >>> >>> You can clean up g1_can_remove_pre_barrier() too (remove st_alloc == NULL check). >>> >>> I would also reverse the last check there because you bailout from loop anyway: >>> >>> + if (captured_store == NULL || captured_store == st_init->zero_memory()) { >>> + return true; >>> + } >>> + } >>> + } >>> + >>> + // Unless there is an explicit 'continue', we must bail out here, >>> >>> >>> Vladimir >>> >>> On 9/15/14 3:31 PM, Staffan Friberg wrote: >>>> Hi Vladimir, >>>> >>>> Uploaded a new webrev with fixes to the below issues, >>>> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.02 >>>> >>>> Still removes expected barriers. >>>> >>>> Thanks, >>>> Staffan >>>> >>>> On 09/12/2014 04:15 PM, Vladimir Kozlov wrote: >>>>> Fix indention in 2 checks: >>>>> >>>>> + if (use_ReduceInitialCardMarks() && >>>>> + g1_can_remove_*_barrier(&_gvn, adr, bt, alias_idx)) { >>>>> >>>>> Typo 'iff' in both comments: >>>>> >>>>> + * Returns true iff the barrier can be removed >>>>> >>>>> In g1_can_remove_post_barrier() use: >>>>> >>>>> + // Start search from Store node >>>>> + Node* ctrl = store->in(MemNode::Control); >>>>> >>>>> Control edge can't point to an other Store so you should not check it >>>>> inside loop. >>>>> As result you don't need loop. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/12/14 2:26 PM, Staffan Friberg wrote: >>>>>> Hi Mikael, >>>>>> >>>>>> I updated the documentation, and uploaded a new webrev, >>>>>> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.01 >>>>>> >>>>>> Thanks for agreeing to sponsor, and the good idea about pushing to >>>>>> hs-gc for extra coverage. >>>>>> >>>>>> Thanks, >>>>>> Staffan >>>>>> >>>>>> On 09/09/2014 07:31 AM, Mikael Gerdin wrote: >>>>>>> Hi Staffan, >>>>>>> >>>>>>> On Friday 05 September 2014 16.31.44 Staffan Friberg wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Copying both the compiler and GC alias as the optimization involves >>>>>>>> both >>>>>>>> groups. >>>>>>>> >>>>>>>> This optimization aims to avoid generating G1 barriers for newly >>>>>>>> allocated objects where the compiler can prove that the object has not >>>>>>>> been written to earlier and there is no safepoint between the >>>>>>>> allocation >>>>>>>> and the write. The bug has some further details and microbenchmark >>>>>>>> result. The new code has fairly extensive comments about the >>>>>>>> optimization. >>>>>>>> >>>>>>>> It would be great if the GC team can help validate that the premise of >>>>>>>> the optimization is correct as well. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~sfriberg/8057737/webrev/ >>>>>>> I mostly read through the comments since I can't decode what the IR >>>>>>> transforms >>>>>>> intend to do :) >>>>>>> >>>>>>> We usually stick to the terms "old generation" and "young >>>>>>> generation" instead >>>>>>> of "Old Space" and "Young Space". >>>>>>> >>>>>>> "G1 also requires to keep track of objects between different >>>>>>> + * regions to enable evacuation of old regions" >>>>>>> should probably be. >>>>>>> .."to keep track of references between different regions" >>>>>>> >>>>>>> I leave it to the compiler team to review the actual code changes. >>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8057737 >>>>>>>> >>>>>>>> I would also need a sponsor for this change if it passes review. >>>>>>> I'll push this to hs-gc after review since we have more G1 test >>>>>>> coverage on >>>>>>> hs-gc. >>>>>>> >>>>>>> /Mikael >>>>>>> >>>>>>>> Thanks, >>>>>>>> Staffan From vladimir.kozlov at oracle.com Tue Oct 7 20:46:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 07 Oct 2014 13:46:35 -0700 Subject: [9] RFR(S): 8059847: complement JDK-8055286 and JDK-8056964 changes In-Reply-To: References: <5434287C.6060204@oracle.com> Message-ID: <5434512B.9000307@oracle.com> On 10/7/14 11:06 AM, David Chase wrote: > Not a R-reviewer, but I approve. +1 as Reviewer :) > Do we need to add a test (? what would it look like?) to ensure that it works? Yes, please, add a regression test. Thanks, Vladimir > > David > > On 2014-10-07, at 1:53 PM, Zolt?n Maj? wrote: > >> Hi, >> >> >> please review the following small patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059847 >> >> Problem: CompileCommand=option does not support flags of type double. >> >> Solution: Add support for flags of type double. Output: >> >> java -XX:CompileCommand=option,Test::test,ccstrlist,MyListOption,_foo,_bar -XX:CompileCommand=option,Test::test,ccstr,MyStrOption,_foo -XX:CompileCommand=option,Test::test,bool,MyBoolOption,false -XX:CompileCommand=option,Test::test,intx,MyIntxOption,-1 -XX:CompileCommand=option,Test::test,uintx,MyUintxOption,1 -XX:CompileCommand=option,Test::test,MyFlag -XX:CompileCommand=option,Test::test,double,MyDoubleOption,1.123 -version >> >> CompilerOracle: option Test.test const char* MyListOption = '_foo _bar' >> CompilerOracle: option Test.test const char* MyStrOption = '_foo' >> CompilerOracle: option Test.test bool MyBoolOption = false >> CompilerOracle: option Test.test intx MyIntxOption = -1 >> CompilerOracle: option Test.test uintx MyUintxOption = 1 >> CompilerOracle: option Test.test bool MyFlag = true >> CompilerOracle: option Test.test double MyDoubleOption = '1.123000' >> java version "1.9.0-ea" >> Java(TM) SE Runtime Environment (build 1.9.0-ea-b33) >> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-fastdebug-internal, mixed mode) >> >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8059847/webrev.00/ >> >> Testing: JPRT >> >> Thank you and best regards, >> >> >> Zoltan >> > From igor.veresov at oracle.com Tue Oct 7 21:17:01 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 7 Oct 2014 14:17:01 -0700 Subject: [9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation) In-Reply-To: <5433EE7A.9060607@oracle.com> References: <5433C140.9070400@oracle.com> <5433C6C6.20602@oracle.com> <5433EE7A.9060607@oracle.com> Message-ID: <0DBAED7F-65DF-4D15-AFDB-636DF7F70C16@oracle.com> Hi, Zoltan! A couple of comments: 1. It would probably be nice not to do multiplications at every event but rather compute everything once during the startup. Perhaps it would be better to scale command line options right in arguments.cpp ? Or setup accessors in Arguments that would compute and cache the values. If you just scale the options the change would be smaller though. What do you think? 2. Why aren?t you scaling Tier{2,3}{Invoke,Backedge}NotifyFreqLog and Tier23InlineeNotifyFreqLog? Probably can be solved by (1) automatically. igor On Oct 7, 2014, at 6:45 AM, Zolt?n Maj? wrote: > Hi Albert, > > > thank you for your feedback. > > On 10/07/2014 12:56 PM, Albert Noll wrote: >> How about using a scaling factor instead of using percentage? > > I think that is a good idea because a scaling factor (expressed as a double) allows a finer-grained control of compilation thresholds than a scaling percentage (expressed as an integer). > > Here is the webrev with the scaling factor: > > http://cr.openjdk.java.net/~zmajo/8059604/webrev.01/ > > The name of the flag is changed to CompileThresholdScaling (from CompileThresholdScalingPercentage). > >> What happens if a threshold becomes 0 after scaling? > > Then all methods will be interpreted. That seems to be the convention (in src/share/vm/runtime/arguments.cpp). > > Best regards, > > > Zoltan > >> >> Best, >> Albert >> >> >> On 10/07/2014 12:32 PM, Zolt?n Maj? wrote: >>> Hi, >>> >>> >>> please review the following patch. >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059604 >>> >>> >>> Problem: With tiered compilation enabled, the value of 6 different thresholds must be set to control when the JVM compiles methods for the first time. That is too detailed for the average customer. >>> >>> >>> Solution: This patch adds a new flag, CompileThresholdScalingPercentage, to control when methods are first compiled. The new flag scales thresholds the following way: >>> >>> - if CompileThresholdScalingPercentage==100, the default threshold values are used >>> - if CompileThresholdScalingPercentage>100, threshold values are scaled up (e.g., CompileThresholdScalingPercentage=120 scales up thresholds by a factor of 1.2X) >>> - if 0 < CompileThresholdScalingPercentage < 100, threshold values are scaled down accordingly. >>> >>> The new flag works both with and without tiered compilation. Thus, the new flag allows compilation to be controlled the same way both with and without tiered compilation: >>> >>> - with tiered compilation enabled, the value of the flags Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog, Tier3InvocationThreshold, Tier3MinInvocationThreshold, Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled >>> >>> - with tiered compilation disabled, the value of CompileThreshold is scaled >>> >>> Currently, tiered and non-tiered compilation treats threshold values slightly differently: For a threshold value of N and without tiered compilation enabled, methods are compiled *before* their Nth execution. With tiered compilation enabled, methods are compiled *after* the their Nth execution. >>> >>> The patch addresses the difference between tiered/non-tiered compilation: Methods are compiled right before their Nth execution in both cases (the non-tiered way). If CompileThresholdScalingPercentage==0, all methods are interpreted (similarly to the case when CompileThreshold==0). >>> >>> This patch is the second (out of three) parts of JDK-8050853 (adding support for per-compilation thresholds): https://bugs.openjdk.java.net/browse/JDK-8050853 . >>> >>> >>> Webrev: http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/ >>> >>> >>> Testing: JPRT, manual testing >>> >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >> > From mikael.gerdin at oracle.com Wed Oct 8 07:07:09 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 08 Oct 2014 09:07:09 +0200 Subject: RFR - Avoid G1 write barriers on newly allocated objects In-Reply-To: <54343C8B.7080701@oracle.com> References: <540A47E0.2080803@oracle.com> <2548885.ND5rUTNDSq@mgerdin03> <54136502.2000305@oracle.com> <54137E92.4030803@oracle.com> <541768C1.20507@oracle.com> <54178A86.4090500@oracle.com> <5418AE85.1070309@oracle.com> <3EB00253-5BB0-47DA-8C68-5F4AF243B4F4@oracle.com> <54343C8B.7080701@oracle.com> Message-ID: <5434E29D.3010507@oracle.com> Staffan, On 10/07/2014 09:18 PM, Staffan Friberg wrote: > This is handled already for humongous objects, they will generate > deferred card marks for as part of their allocation if they are > allocated outside of the young space. > See CollectedHeap::new_store_pre_barrier and > OptoRuntime::new_store_pre_barrier for details. > > Agree that it could be made more visible, but it is probably better > handled that as a G1 update when required. > > Thanks for the review. It looks like this change is through the review process. If you send me a changeset patch with the final version of the change I'll push it to jdk9/hs-gc /Mikael > > //Staffan > > On 10/03/2014 02:37 PM, Igor Veresov wrote: >> Sorry that I couldn?t get this for so long. >> The C2 part seems very good. The only comment is that the code (the >> post-barrier elimination part) depends on the fact the the new object >> is allocated in the young gen. Would it make sense to harden the code >> a little bit in case G1 gets single-generation or changes its >> allocation scheme? Like adding >> G1CollectedHeap::new_objects_require_post_barrier() or something like >> that? Anyways, up to you, reviewed. >> >> igor >> >> On Sep 16, 2014, at 2:41 PM, Staffan Friberg >> wrote: >> >>> Thanks Vladimir, >>> >>> Updated with your suggestions. Added a small comment in >>> g1_can_remove_pre_barrier method since the alloc == NULL check is >>> quite a bit earlier. >>> >>> New webrev, http://cr.openjdk.java.net/~sfriberg/8057737/webrev.03 >>> >>> Cheers, >>> Staffan >>> >>> >>> On 09/15/2014 05:55 PM, Vladimir Kozlov wrote: >>>> You need only check (alloc == st_alloc) because alloc != NULL at >>>> this point: >>>> >>>> + if (st_alloc != NULL && alloc == st_alloc) { >>>> >>>> >>>> You can clean up g1_can_remove_pre_barrier() too (remove st_alloc == >>>> NULL check). >>>> >>>> I would also reverse the last check there because you bailout from >>>> loop anyway: >>>> >>>> + if (captured_store == NULL || captured_store == >>>> st_init->zero_memory()) { >>>> + return true; >>>> + } >>>> + } >>>> + } >>>> + >>>> + // Unless there is an explicit 'continue', we must bail out here, >>>> >>>> >>>> Vladimir >>>> >>>> On 9/15/14 3:31 PM, Staffan Friberg wrote: >>>>> Hi Vladimir, >>>>> >>>>> Uploaded a new webrev with fixes to the below issues, >>>>> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.02 >>>>> >>>>> Still removes expected barriers. >>>>> >>>>> Thanks, >>>>> Staffan >>>>> >>>>> On 09/12/2014 04:15 PM, Vladimir Kozlov wrote: >>>>>> Fix indention in 2 checks: >>>>>> >>>>>> + if (use_ReduceInitialCardMarks() && >>>>>> + g1_can_remove_*_barrier(&_gvn, adr, bt, alias_idx)) { >>>>>> >>>>>> Typo 'iff' in both comments: >>>>>> >>>>>> + * Returns true iff the barrier can be removed >>>>>> >>>>>> In g1_can_remove_post_barrier() use: >>>>>> >>>>>> + // Start search from Store node >>>>>> + Node* ctrl = store->in(MemNode::Control); >>>>>> >>>>>> Control edge can't point to an other Store so you should not check it >>>>>> inside loop. >>>>>> As result you don't need loop. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 9/12/14 2:26 PM, Staffan Friberg wrote: >>>>>>> Hi Mikael, >>>>>>> >>>>>>> I updated the documentation, and uploaded a new webrev, >>>>>>> http://cr.openjdk.java.net/~sfriberg/8057737/webrev.01 >>>>>>> >>>>>>> Thanks for agreeing to sponsor, and the good idea about pushing to >>>>>>> hs-gc for extra coverage. >>>>>>> >>>>>>> Thanks, >>>>>>> Staffan >>>>>>> >>>>>>> On 09/09/2014 07:31 AM, Mikael Gerdin wrote: >>>>>>>> Hi Staffan, >>>>>>>> >>>>>>>> On Friday 05 September 2014 16.31.44 Staffan Friberg wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Copying both the compiler and GC alias as the optimization >>>>>>>>> involves >>>>>>>>> both >>>>>>>>> groups. >>>>>>>>> >>>>>>>>> This optimization aims to avoid generating G1 barriers for newly >>>>>>>>> allocated objects where the compiler can prove that the object >>>>>>>>> has not >>>>>>>>> been written to earlier and there is no safepoint between the >>>>>>>>> allocation >>>>>>>>> and the write. The bug has some further details and microbenchmark >>>>>>>>> result. The new code has fairly extensive comments about the >>>>>>>>> optimization. >>>>>>>>> >>>>>>>>> It would be great if the GC team can help validate that the >>>>>>>>> premise of >>>>>>>>> the optimization is correct as well. >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net/~sfriberg/8057737/webrev/ >>>>>>>> I mostly read through the comments since I can't decode what the IR >>>>>>>> transforms >>>>>>>> intend to do :) >>>>>>>> >>>>>>>> We usually stick to the terms "old generation" and "young >>>>>>>> generation" instead >>>>>>>> of "Old Space" and "Young Space". >>>>>>>> >>>>>>>> "G1 also requires to keep track of objects between different >>>>>>>> + * regions to enable evacuation of old regions" >>>>>>>> should probably be. >>>>>>>> .."to keep track of references between different regions" >>>>>>>> >>>>>>>> I leave it to the compiler team to review the actual code changes. >>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8057737 >>>>>>>>> >>>>>>>>> I would also need a sponsor for this change if it passes review. >>>>>>>> I'll push this to hs-gc after review since we have more G1 test >>>>>>>> coverage on >>>>>>>> hs-gc. >>>>>>>> >>>>>>>> /Mikael >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Staffan > From albert.noll at oracle.com Wed Oct 8 07:16:49 2014 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 08 Oct 2014 09:16:49 +0200 Subject: [9] RFR(XS): 8059735: make_not_entrant_or_zombie sees zombies In-Reply-To: <5433FE1E.1020403@oracle.com> References: <5433C868.3000606@oracle.com> <5433CB75.7050807@oracle.com> <5433E5EB.7020206@oracle.com> <5433E8EF.6080509@oracle.com> <5433FE1E.1020403@oracle.com> Message-ID: <5434E4E1.2010301@oracle.com> Hi Tobias, this looks good to me as well. Best, Albert On 10/07/2014 04:52 PM, Tobias Hartmann wrote: > Hi Albert, > > On 07.10.2014 15:21, Albert Noll wrote: >> Hi Tobias, >> >> On 10/07/2014 03:08 PM, Tobias Hartmann wrote: >>> Hi Albert, >>> >>> thanks for the review. >>> >>> On 07.10.2014 13:16, Albert Noll wrote: >>>> Hi Tobias, >>>> >>>> would it also work to check the state of the nmethod before calling >>>> make_zombie? >>>> >>>> if (nm->is_not_entrant()) { >>>> nm->make_zombie() >>>> } >>> >>> Yes, regarding Mikael's comment, that is a better solution. >>> >>>> In any case, it would be nice the have a comment that explains why we >>>> should not enter a >>>> safpoint / have to do the extra check as described above. >>> >>> I changed the fix accordingly and added an additional comment. I also >>> moved the statistics/debugging code such that it is only executed if >>> the sweeper sets the nmethod to zombie. >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.01/ >> I have one additional question. Do we need to hold the "CompiledIC_lock" >> when >> we call make_zombie()? > > No, we don't need to hold the lock for 'make_zombie()'. I narrowed the > scope of the lock: > > http://cr.openjdk.java.net/~thartmann/8059735/webrev.02/ > > Thanks, > Tobias > >> >> Best, >> Albert >> >>> Thanks, >>> Tobias >>> >>>> >>>> Best, >>>> Albert >>>> >>>> >>>> On 10/07/2014 01:03 PM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059735 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.00/ >>>>> >>>>> Problem: >>>>> In 'NMethodSweeper::process_nmethod' a non-entrant nmethod is >>>>> processed and can be converted to zombie (line 549 of >>>>> sweeper.cpp). To >>>>> clean the IC stubs of that nmethod [1] we acquire the CompiledIC_lock >>>>> and check for a safepoint. In this case, there is a safepoint request >>>>> and we block. During the safepoint a VM_Deoptimize operation is >>>>> executed (due to classloading) and the non-entrant nmethod is set to >>>>> zombie by 'CodeCache::make_marked_nmethods_zombies'. After the >>>>> safepoint the sweeper continues and tries to set the nmethod to >>>>> zombie >>>>> again. >>>>> >>>>> Solution: >>>>> Use a MutexLockerEx with the '_no_safepoint_check_flag' to acquire >>>>> the >>>>> CompiledIC_lock. >>>>> >>>>> Testing: >>>>> - Failing tests >>>>> - JPRT >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8058737 >>>> >> From tobias.hartmann at oracle.com Wed Oct 8 07:18:48 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 08 Oct 2014 09:18:48 +0200 Subject: [9] RFR(XS): 8059735: make_not_entrant_or_zombie sees zombies In-Reply-To: <5434E4E1.2010301@oracle.com> References: <5433C868.3000606@oracle.com> <5433CB75.7050807@oracle.com> <5433E5EB.7020206@oracle.com> <5433E8EF.6080509@oracle.com> <5433FE1E.1020403@oracle.com> <5434E4E1.2010301@oracle.com> Message-ID: <5434E558.5000400@oracle.com> Thanks, Albert. Best, Tobias On 08.10.2014 09:16, Albert Noll wrote: > Hi Tobias, > > this looks good to me as well. > > Best, > Albert > > On 10/07/2014 04:52 PM, Tobias Hartmann wrote: >> Hi Albert, >> >> On 07.10.2014 15:21, Albert Noll wrote: >>> Hi Tobias, >>> >>> On 10/07/2014 03:08 PM, Tobias Hartmann wrote: >>>> Hi Albert, >>>> >>>> thanks for the review. >>>> >>>> On 07.10.2014 13:16, Albert Noll wrote: >>>>> Hi Tobias, >>>>> >>>>> would it also work to check the state of the nmethod before calling >>>>> make_zombie? >>>>> >>>>> if (nm->is_not_entrant()) { >>>>> nm->make_zombie() >>>>> } >>>> >>>> Yes, regarding Mikael's comment, that is a better solution. >>>> >>>>> In any case, it would be nice the have a comment that explains why we >>>>> should not enter a >>>>> safpoint / have to do the extra check as described above. >>>> >>>> I changed the fix accordingly and added an additional comment. I also >>>> moved the statistics/debugging code such that it is only executed if >>>> the sweeper sets the nmethod to zombie. >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.01/ >>> I have one additional question. Do we need to hold the "CompiledIC_lock" >>> when >>> we call make_zombie()? >> >> No, we don't need to hold the lock for 'make_zombie()'. I narrowed the >> scope of the lock: >> >> http://cr.openjdk.java.net/~thartmann/8059735/webrev.02/ >> >> Thanks, >> Tobias >> >>> >>> Best, >>> Albert >>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 10/07/2014 01:03 PM, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> please review the following patch. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059735 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8059735/webrev.00/ >>>>>> >>>>>> Problem: >>>>>> In 'NMethodSweeper::process_nmethod' a non-entrant nmethod is >>>>>> processed and can be converted to zombie (line 549 of >>>>>> sweeper.cpp). To >>>>>> clean the IC stubs of that nmethod [1] we acquire the CompiledIC_lock >>>>>> and check for a safepoint. In this case, there is a safepoint request >>>>>> and we block. During the safepoint a VM_Deoptimize operation is >>>>>> executed (due to classloading) and the non-entrant nmethod is set to >>>>>> zombie by 'CodeCache::make_marked_nmethods_zombies'. After the >>>>>> safepoint the sweeper continues and tries to set the nmethod to >>>>>> zombie >>>>>> again. >>>>>> >>>>>> Solution: >>>>>> Use a MutexLockerEx with the '_no_safepoint_check_flag' to acquire >>>>>> the >>>>>> CompiledIC_lock. >>>>>> >>>>>> Testing: >>>>>> - Failing tests >>>>>> - JPRT >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8058737 >>>>> >>> > From tobias.hartmann at oracle.com Wed Oct 8 07:43:40 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 08 Oct 2014 09:43:40 +0200 Subject: [9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled In-Reply-To: <542EE5D4.9050304@oracle.com> References: <542E6AD7.1060307@oracle.com> <542EE5D4.9050304@oracle.com> Message-ID: <5434EB2C.10600@oracle.com> Hi Dean, thanks for the feedback. On 03.10.2014 20:07, dean long wrote: > In the future, it might be useful for the whitebox interface to return a > compilation count for a method. > That way we can query "is or was compiled" vs. "is currently compiled". Yes that would be useful but there are some tests that need a compiled version of the method. For example, compiler.whitebox.GetNMethodTest. Best, Tobias > > dl > > On 10/3/2014 2:22 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8046268 >> Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/ >> >> == Problem == >> The whitebox tests assume that after the invocation of >> 'CompilerWhiteBoxTest.compile()' the method is always compiled and >> 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR >> compilations [1] this is does not hold. For example, in case of the >> following events: >> >> 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile >> 'SimpleTestCase.Helper.osrMethod()'. >> 2) OSR compilation is performed at level 4. An uncommon trap is added >> after the loop because profiling never reached that point. Execution >> continues with the OSR version. >> 3) Deoptimization is triggered because the loop finishes (reason: >> 'unstable if'). The OSR nmethod is made non-entrant and removed from >> the OSR list (see 'nmethod::invalidate_osr_method'). >> 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the >> method is OSR compiled. Because the OSR nmethod was removed from the >> list, check compiled returns false (see WB_IsMethodCompiled). >> >> This was caused by the fix for JDK-8030976 [2] because we now trust >> the profile information more and add uncommon traps to untaken paths. >> In this case we add an uncommon trap after the loop exit: >> >> private int osrMethod() { >> int result = 0; >> for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) { >> result += method(); >> } >> return result; >> } >> >> == Solution == >> I added code to 'warm up' the methods before triggering OSR >> compilation by executing them a limited number of times. Like this, >> the profile information marks the loop exit as taken and we don't add >> an uncommon trap. >> >> == Testing == >> - Executed failing tests on JPRT >> >> Thanks, >> Tobias >> >> >> [1] OSR compiled methods: >> compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR >> compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD >> compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8030976 > From tobias.hartmann at oracle.com Wed Oct 8 08:29:11 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 08 Oct 2014 10:29:11 +0200 Subject: [9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled In-Reply-To: <542EDAF4.2030000@oracle.com> References: <542E6AD7.1060307@oracle.com> <542EDAF4.2030000@oracle.com> Message-ID: <5434F5D7.3050207@oracle.com> Hi Vladimir, thanks for the review. On 03.10.2014 19:20, Vladimir Kozlov wrote: > Nightly runs done with -Xcomp. Make sure your changes still work. I did some more testing on JPRT with -Xcomp and also with -XX:-TieredCompilation. No failures (the results are linked in the comment section). Most tests explicitly specify '-Xmixed'. > 200 for tiered may be too high. C1 compilation triggered before that, > please check. Yes, that's intended. After some more testing I even increased the value to 2000 to make sure that the loop exit branch probability is high enough and we never add an uncommon trap. If the method is compiled during warmup the following deoptimization ensures that we throw away the compiled version and an OSR compilation is triggered: 551 // Make sure method is not (yet) compiled 552 deoptimize(m); I also added code to wait for a potential background compilation (see 'Helper.deoptimize') because the method may still be in the compile queue. The fixed tests pass on all platforms with and without -Xcomp. New webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.01/ Thanks, Tobias > > Thanks, > Vladimir > > On 10/3/14 2:22 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8046268 >> Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/ >> >> == Problem == >> The whitebox tests assume that after the invocation of >> 'CompilerWhiteBoxTest.compile()' the method is always compiled >> and 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR >> compilations [1] this is does not hold. For >> example, in case of the following events: >> >> 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile >> 'SimpleTestCase.Helper.osrMethod()'. >> 2) OSR compilation is performed at level 4. An uncommon trap is added >> after the loop because profiling never reached >> that point. Execution continues with the OSR version. >> 3) Deoptimization is triggered because the loop finishes (reason: >> 'unstable if'). The OSR nmethod is made non-entrant >> and removed from the OSR list (see 'nmethod::invalidate_osr_method'). >> 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the >> method is OSR compiled. Because the OSR nmethod >> was removed from the list, check compiled returns false (see >> WB_IsMethodCompiled). >> >> This was caused by the fix for JDK-8030976 [2] because we now trust >> the profile information more and add uncommon traps >> to untaken paths. In this case we add an uncommon trap after the loop >> exit: >> >> private int osrMethod() { >> int result = 0; >> for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) { >> result += method(); >> } >> return result; >> } >> >> == Solution == >> I added code to 'warm up' the methods before triggering OSR >> compilation by executing them a limited number of times. >> Like this, the profile information marks the loop exit as taken and we >> don't add an uncommon trap. >> >> == Testing == >> - Executed failing tests on JPRT >> >> Thanks, >> Tobias >> >> >> [1] OSR compiled methods: >> compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR >> compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD >> compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8030976 From igor.ignatyev at oracle.com Wed Oct 8 09:10:08 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 08 Oct 2014 13:10:08 +0400 Subject: [9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled In-Reply-To: <5434EB2C.10600@oracle.com> References: <542E6AD7.1060307@oracle.com> <542EE5D4.9050304@oracle.com> <5434EB2C.10600@oracle.com> Message-ID: <5434FF70.5060006@oracle.com> Dean/Tobias, I've filed an RFE for it -- https://bugs.openjdk.java.net/browse/JDK-8059923. Igor On 10/08/2014 11:43 AM, Tobias Hartmann wrote: > Hi Dean, > > thanks for the feedback. > > On 03.10.2014 20:07, dean long wrote: >> In the future, it might be useful for the whitebox interface to return a >> compilation count for a method. >> That way we can query "is or was compiled" vs. "is currently compiled". > > Yes that would be useful but there are some tests that need a compiled > version of the method. For example, compiler.whitebox.GetNMethodTest. > > Best, > Tobias > >> >> dl >> >> On 10/3/2014 2:22 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046268 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/ >>> >>> == Problem == >>> The whitebox tests assume that after the invocation of >>> 'CompilerWhiteBoxTest.compile()' the method is always compiled and >>> 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR >>> compilations [1] this is does not hold. For example, in case of the >>> following events: >>> >>> 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile >>> 'SimpleTestCase.Helper.osrMethod()'. >>> 2) OSR compilation is performed at level 4. An uncommon trap is added >>> after the loop because profiling never reached that point. Execution >>> continues with the OSR version. >>> 3) Deoptimization is triggered because the loop finishes (reason: >>> 'unstable if'). The OSR nmethod is made non-entrant and removed from >>> the OSR list (see 'nmethod::invalidate_osr_method'). >>> 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the >>> method is OSR compiled. Because the OSR nmethod was removed from the >>> list, check compiled returns false (see WB_IsMethodCompiled). >>> >>> This was caused by the fix for JDK-8030976 [2] because we now trust >>> the profile information more and add uncommon traps to untaken paths. >>> In this case we add an uncommon trap after the loop exit: >>> >>> private int osrMethod() { >>> int result = 0; >>> for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) { >>> result += method(); >>> } >>> return result; >>> } >>> >>> == Solution == >>> I added code to 'warm up' the methods before triggering OSR >>> compilation by executing them a limited number of times. Like this, >>> the profile information marks the loop exit as taken and we don't add >>> an uncommon trap. >>> >>> == Testing == >>> - Executed failing tests on JPRT >>> >>> Thanks, >>> Tobias >>> >>> >>> [1] OSR compiled methods: >>> compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR >>> compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD >>> compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8030976 >> From igor.ignatyev at oracle.com Wed Oct 8 09:18:50 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 08 Oct 2014 13:18:50 +0400 Subject: [9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled In-Reply-To: <5434F5D7.3050207@oracle.com> References: <542E6AD7.1060307@oracle.com> <542EDAF4.2030000@oracle.com> <5434F5D7.3050207@oracle.com> Message-ID: <5435017A.60707@oracle.com> Tobias, On 10/08/2014 12:29 PM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > > On 03.10.2014 19:20, Vladimir Kozlov wrote: >> Nightly runs done with -Xcomp. Make sure your changes still work. > > I did some more testing on JPRT with -Xcomp and also with > -XX:-TieredCompilation. No failures (the results are linked in the > comment section). Most tests explicitly specify '-Xmixed'. > >> 200 for tiered may be too high. C1 compilation triggered before that, >> please check. > > Yes, that's intended. After some more testing I even increased the value > to 2000 to make sure that the loop exit branch probability is high > enough and we never add an uncommon trap. If the method is compiled > during warmup the following deoptimization ensures that we throw away > the compiled version and an OSR compilation is triggered: > > 551 // Make sure method is not (yet) compiled > 552 deoptimize(m); no, it doesn't since you call 'WhiteBox.getWhiteBox().deoptimizeMethod(e, false);' where false means non-osr. > > I also added code to wait for a potential background compilation (see > 'Helper.deoptimize') because the method may still be in the compile queue. we already have 'CompilerWhiteBoxTest::waitBackgroundCompilation', I think it'd be better to add an argument to it and make it static, but leave instance method w/o args which calls it w/ method. > > The fixed tests pass on all platforms with and without -Xcomp. > > New webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.01/ > > Thanks, > Tobias > >> >> Thanks, >> Vladimir >> >> On 10/3/14 2:22 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046268 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/ >>> >>> == Problem == >>> The whitebox tests assume that after the invocation of >>> 'CompilerWhiteBoxTest.compile()' the method is always compiled >>> and 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR >>> compilations [1] this is does not hold. For >>> example, in case of the following events: >>> >>> 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile >>> 'SimpleTestCase.Helper.osrMethod()'. >>> 2) OSR compilation is performed at level 4. An uncommon trap is added >>> after the loop because profiling never reached >>> that point. Execution continues with the OSR version. >>> 3) Deoptimization is triggered because the loop finishes (reason: >>> 'unstable if'). The OSR nmethod is made non-entrant >>> and removed from the OSR list (see 'nmethod::invalidate_osr_method'). >>> 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the >>> method is OSR compiled. Because the OSR nmethod >>> was removed from the list, check compiled returns false (see >>> WB_IsMethodCompiled). >>> >>> This was caused by the fix for JDK-8030976 [2] because we now trust >>> the profile information more and add uncommon traps >>> to untaken paths. In this case we add an uncommon trap after the loop >>> exit: >>> >>> private int osrMethod() { >>> int result = 0; >>> for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) { >>> result += method(); >>> } >>> return result; >>> } >>> >>> == Solution == >>> I added code to 'warm up' the methods before triggering OSR >>> compilation by executing them a limited number of times. >>> Like this, the profile information marks the loop exit as taken and we >>> don't add an uncommon trap. >>> >>> == Testing == >>> - Executed failing tests on JPRT >>> >>> Thanks, >>> Tobias >>> >>> >>> [1] OSR compiled methods: >>> compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR >>> compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD >>> compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8030976 From tobias.hartmann at oracle.com Wed Oct 8 09:53:23 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 08 Oct 2014 11:53:23 +0200 Subject: [9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled In-Reply-To: <5435017A.60707@oracle.com> References: <542E6AD7.1060307@oracle.com> <542EDAF4.2030000@oracle.com> <5434F5D7.3050207@oracle.com> <5435017A.60707@oracle.com> Message-ID: <54350993.2040000@oracle.com> Hi Igor, thanks for the review. On 08.10.2014 11:18, Igor Ignatyev wrote: > Tobias, > > On 10/08/2014 12:29 PM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. >> >> On 03.10.2014 19:20, Vladimir Kozlov wrote: >>> Nightly runs done with -Xcomp. Make sure your changes still work. >> >> I did some more testing on JPRT with -Xcomp and also with >> -XX:-TieredCompilation. No failures (the results are linked in the >> comment section). Most tests explicitly specify '-Xmixed'. >> >>> 200 for tiered may be too high. C1 compilation triggered before that, >>> please check. >> >> Yes, that's intended. After some more testing I even increased the value >> to 2000 to make sure that the loop exit branch probability is high >> enough and we never add an uncommon trap. If the method is compiled >> during warmup the following deoptimization ensures that we throw away >> the compiled version and an OSR compilation is triggered: >> >> 551 // Make sure method is not (yet) compiled >> 552 deoptimize(m); > no, it doesn't since you call 'WhiteBox.getWhiteBox().deoptimizeMethod(e, > false);' where false means non-osr. Yes, that's intended. We want to trigger an OSR compilation after the warmup. Therefore we remove all non-OSR versions by deoptimizing them. If the warmup triggers an OSR compilation (which is really unlikely because the loop is executed for only one iteration each) that's fine as well. I added some comments to make this more explicit. >> >> I also added code to wait for a potential background compilation (see >> 'Helper.deoptimize') because the method may still be in the compile queue. > we already have 'CompilerWhiteBoxTest::waitBackgroundCompilation', I think it'd > be better to add an argument to it and make it static, but leave instance method > w/o args which calls it w/ method. Done. New webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.02/ Thanks, Tobias >> >> The fixed tests pass on all platforms with and without -Xcomp. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.01/ >> >> Thanks, >> Tobias >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/3/14 2:22 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046268 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/ >>>> >>>> == Problem == >>>> The whitebox tests assume that after the invocation of >>>> 'CompilerWhiteBoxTest.compile()' the method is always compiled >>>> and 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR >>>> compilations [1] this is does not hold. For >>>> example, in case of the following events: >>>> >>>> 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile >>>> 'SimpleTestCase.Helper.osrMethod()'. >>>> 2) OSR compilation is performed at level 4. An uncommon trap is added >>>> after the loop because profiling never reached >>>> that point. Execution continues with the OSR version. >>>> 3) Deoptimization is triggered because the loop finishes (reason: >>>> 'unstable if'). The OSR nmethod is made non-entrant >>>> and removed from the OSR list (see 'nmethod::invalidate_osr_method'). >>>> 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the >>>> method is OSR compiled. Because the OSR nmethod >>>> was removed from the list, check compiled returns false (see >>>> WB_IsMethodCompiled). >>>> >>>> This was caused by the fix for JDK-8030976 [2] because we now trust >>>> the profile information more and add uncommon traps >>>> to untaken paths. In this case we add an uncommon trap after the loop >>>> exit: >>>> >>>> private int osrMethod() { >>>> int result = 0; >>>> for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) { >>>> result += method(); >>>> } >>>> return result; >>>> } >>>> >>>> == Solution == >>>> I added code to 'warm up' the methods before triggering OSR >>>> compilation by executing them a limited number of times. >>>> Like this, the profile information marks the loop exit as taken and we >>>> don't add an uncommon trap. >>>> >>>> == Testing == >>>> - Executed failing tests on JPRT >>>> >>>> Thanks, >>>> Tobias >>>> >>>> >>>> [1] OSR compiled methods: >>>> compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR >>>> compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD >>>> compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC >>>> >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8030976 From roland.westrelin at oracle.com Wed Oct 8 12:33:13 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 8 Oct 2014 14:33:13 +0200 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass Message-ID: http://cr.openjdk.java.net/~roland/6700100/webrev.00/ Converts ArrayCopy nodes for small instance clones to series of loads/stores + a little bit of cleanup. Small array clones & copies as loads/stores are coming next in another change. Roland. From zoltan.majo at oracle.com Wed Oct 8 14:22:36 2014 From: zoltan.majo at oracle.com (=?windows-1252?Q?Zolt=E1n_Maj=F3?=) Date: Wed, 08 Oct 2014 16:22:36 +0200 Subject: [9] RFR(S): 8059847: complement JDK-8055286 and JDK-8056964 changes In-Reply-To: <5434512B.9000307@oracle.com> References: <5434287C.6060204@oracle.com> <5434512B.9000307@oracle.com> Message-ID: <543548AC.7050300@oracle.com> Hi David and Vladimir, thank you for your feedback. On 10/07/2014 10:46 PM, Vladimir Kozlov wrote: > On 10/7/14 11:06 AM, David Chase wrote: > >> Do we need to add a test (? what would it look like?) to ensure that >> it works? > > Yes, please, add a regression test. I added a regression test ('compiler/startup/CheckCompileCommandOption.java'). Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8059847/webrev.01/ Thank you and best regards, Zoltan > > Thanks, > Vladimir > >> >> David >> >> On 2014-10-07, at 1:53 PM, Zolt?n Maj? wrote: >> >>> Hi, >>> >>> >>> please review the following small patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059847 >>> >>> Problem: CompileCommand=option does not support flags of type double. >>> >>> Solution: Add support for flags of type double. Output: >>> >>> java >>> -XX:CompileCommand=option,Test::test,ccstrlist,MyListOption,_foo,_bar -XX:CompileCommand=option,Test::test,ccstr,MyStrOption,_foo >>> -XX:CompileCommand=option,Test::test,bool,MyBoolOption,false >>> -XX:CompileCommand=option,Test::test,intx,MyIntxOption,-1 >>> -XX:CompileCommand=option,Test::test,uintx,MyUintxOption,1 >>> -XX:CompileCommand=option,Test::test,MyFlag >>> -XX:CompileCommand=option,Test::test,double,MyDoubleOption,1.123 >>> -version >>> >>> CompilerOracle: option Test.test const char* MyListOption = '_foo _bar' >>> CompilerOracle: option Test.test const char* MyStrOption = '_foo' >>> CompilerOracle: option Test.test bool MyBoolOption = false >>> CompilerOracle: option Test.test intx MyIntxOption = -1 >>> CompilerOracle: option Test.test uintx MyUintxOption = 1 >>> CompilerOracle: option Test.test bool MyFlag = true >>> CompilerOracle: option Test.test double MyDoubleOption = '1.123000' >>> java version "1.9.0-ea" >>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b33) >>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-fastdebug-internal, >>> mixed mode) >>> >>> >>> Webrev: http://cr.openjdk.java.net/~zmajo/8059847/webrev.00/ >>> >>> Testing: JPRT >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >> From vladimir.kozlov at oracle.com Wed Oct 8 15:27:04 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 08 Oct 2014 08:27:04 -0700 Subject: [9] RFR(S): 8059847: complement JDK-8055286 and JDK-8056964 changes In-Reply-To: <543548AC.7050300@oracle.com> References: <5434287C.6060204@oracle.com> <5434512B.9000307@oracle.com> <543548AC.7050300@oracle.com> Message-ID: <543557C8.6030709@oracle.com> Hi Zoltan, You don't need /othervm if there are no additional flags. Instead of /startup/ I would suggest /oracle/ subdir name since we testing code in compilerOracle. 42 // Type (1) is used to check if a flag "someflag" is enabled for a 43 // method. I would say: 42 // Type (1) is used to enable a boolean flag for a method. Should it be "bool,MyBoolOption,100"?: 135 // wrong value for bool flag 136 "-XX:CompileCommand=option,Test::test,bool,MyBoolOption,intx,100", Same problem with next test which does not match the comment: 140 // intx flag name missing 141 "-XX:CompileCommand=option,Test::test,bool,MyBoolOption,false,intx,100", Please, separate next checks to be clear which one is incorrect: 179 if (TYPE_1_ARGUMENTS.length != TYPE_1_EXPECTED_OUTPUTS.length 180 || TYPE_2_ARGUMENTS.length != TYPE_2_EXPECTED_OUTPUTS.length) { 181 throw new RuntimeException("Test is set up incorrectly: length of arguments and expected outputs does not match."); 182 } Thanks, Vladimir On 10/8/14 7:22 AM, Zolt?n Maj? wrote: > Hi David and Vladimir, > > > thank you for your feedback. > > On 10/07/2014 10:46 PM, Vladimir Kozlov wrote: >> On 10/7/14 11:06 AM, David Chase wrote: >> >>> Do we need to add a test (? what would it look like?) to ensure that it works? >> >> Yes, please, add a regression test. > > I added a regression test ('compiler/startup/CheckCompileCommandOption.java'). Here is the updated webrev: > > http://cr.openjdk.java.net/~zmajo/8059847/webrev.01/ > > Thank you and best regards, > > > Zoltan > >> >> Thanks, >> Vladimir >> >>> >>> David >>> >>> On 2014-10-07, at 1:53 PM, Zolt?n Maj? wrote: >>> >>>> Hi, >>>> >>>> >>>> please review the following small patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059847 >>>> >>>> Problem: CompileCommand=option does not support flags of type double. >>>> >>>> Solution: Add support for flags of type double. Output: >>>> >>>> java -XX:CompileCommand=option,Test::test,ccstrlist,MyListOption,_foo,_bar >>>> -XX:CompileCommand=option,Test::test,ccstr,MyStrOption,_foo >>>> -XX:CompileCommand=option,Test::test,bool,MyBoolOption,false >>>> -XX:CompileCommand=option,Test::test,intx,MyIntxOption,-1 -XX:CompileCommand=option,Test::test,uintx,MyUintxOption,1 >>>> -XX:CompileCommand=option,Test::test,MyFlag -XX:CompileCommand=option,Test::test,double,MyDoubleOption,1.123 -version >>>> >>>> CompilerOracle: option Test.test const char* MyListOption = '_foo _bar' >>>> CompilerOracle: option Test.test const char* MyStrOption = '_foo' >>>> CompilerOracle: option Test.test bool MyBoolOption = false >>>> CompilerOracle: option Test.test intx MyIntxOption = -1 >>>> CompilerOracle: option Test.test uintx MyUintxOption = 1 >>>> CompilerOracle: option Test.test bool MyFlag = true >>>> CompilerOracle: option Test.test double MyDoubleOption = '1.123000' >>>> java version "1.9.0-ea" >>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b33) >>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-fastdebug-internal, mixed mode) >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~zmajo/8059847/webrev.00/ >>>> >>>> Testing: JPRT >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>> > From vladimir.kozlov at oracle.com Wed Oct 8 15:37:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 08 Oct 2014 08:37:01 -0700 Subject: [9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled In-Reply-To: <54350993.2040000@oracle.com> References: <542E6AD7.1060307@oracle.com> <542EDAF4.2030000@oracle.com> <5434F5D7.3050207@oracle.com> <5435017A.60707@oracle.com> <54350993.2040000@oracle.com> Message-ID: <54355A1D.7070307@oracle.com> webrev.02 looks good to me. Thanks, Vladimir On 10/8/14 2:53 AM, Tobias Hartmann wrote: > Hi Igor, > > thanks for the review. > > On 08.10.2014 11:18, Igor Ignatyev wrote: >> Tobias, >> >> On 10/08/2014 12:29 PM, Tobias Hartmann wrote: >>> Hi Vladimir, >>> >>> thanks for the review. >>> >>> On 03.10.2014 19:20, Vladimir Kozlov wrote: >>>> Nightly runs done with -Xcomp. Make sure your changes still work. >>> >>> I did some more testing on JPRT with -Xcomp and also with >>> -XX:-TieredCompilation. No failures (the results are linked in the >>> comment section). Most tests explicitly specify '-Xmixed'. >>> >>>> 200 for tiered may be too high. C1 compilation triggered before that, >>>> please check. >>> >>> Yes, that's intended. After some more testing I even increased the value >>> to 2000 to make sure that the loop exit branch probability is high >>> enough and we never add an uncommon trap. If the method is compiled >>> during warmup the following deoptimization ensures that we throw away >>> the compiled version and an OSR compilation is triggered: >>> >>> 551 // Make sure method is not (yet) compiled >>> 552 deoptimize(m); >> no, it doesn't since you call 'WhiteBox.getWhiteBox().deoptimizeMethod(e, >> false);' where false means non-osr. > > Yes, that's intended. We want to trigger an OSR compilation after the warmup. Therefore we remove all non-OSR versions > by deoptimizing them. If the warmup triggers an OSR compilation (which is really unlikely because the loop is executed > for only one iteration each) that's fine as well. > > I added some comments to make this more explicit. > >>> >>> I also added code to wait for a potential background compilation (see >>> 'Helper.deoptimize') because the method may still be in the compile queue. >> we already have 'CompilerWhiteBoxTest::waitBackgroundCompilation', I think it'd >> be better to add an argument to it and make it static, but leave instance method >> w/o args which calls it w/ method. > > Done. New webrev: > > http://cr.openjdk.java.net/~thartmann/8046268/webrev.02/ > > Thanks, > Tobias > >>> >>> The fixed tests pass on all platforms with and without -Xcomp. >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.01/ >>> >>> Thanks, >>> Tobias >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/3/14 2:22 AM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046268 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/ >>>>> >>>>> == Problem == >>>>> The whitebox tests assume that after the invocation of >>>>> 'CompilerWhiteBoxTest.compile()' the method is always compiled >>>>> and 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR >>>>> compilations [1] this is does not hold. For >>>>> example, in case of the following events: >>>>> >>>>> 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile >>>>> 'SimpleTestCase.Helper.osrMethod()'. >>>>> 2) OSR compilation is performed at level 4. An uncommon trap is added >>>>> after the loop because profiling never reached >>>>> that point. Execution continues with the OSR version. >>>>> 3) Deoptimization is triggered because the loop finishes (reason: >>>>> 'unstable if'). The OSR nmethod is made non-entrant >>>>> and removed from the OSR list (see 'nmethod::invalidate_osr_method'). >>>>> 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the >>>>> method is OSR compiled. Because the OSR nmethod >>>>> was removed from the list, check compiled returns false (see >>>>> WB_IsMethodCompiled). >>>>> >>>>> This was caused by the fix for JDK-8030976 [2] because we now trust >>>>> the profile information more and add uncommon traps >>>>> to untaken paths. In this case we add an uncommon trap after the loop >>>>> exit: >>>>> >>>>> private int osrMethod() { >>>>> int result = 0; >>>>> for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) { >>>>> result += method(); >>>>> } >>>>> return result; >>>>> } >>>>> >>>>> == Solution == >>>>> I added code to 'warm up' the methods before triggering OSR >>>>> compilation by executing them a limited number of times. >>>>> Like this, the profile information marks the loop exit as taken and we >>>>> don't add an uncommon trap. >>>>> >>>>> == Testing == >>>>> - Executed failing tests on JPRT >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> >>>>> [1] OSR compiled methods: >>>>> compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR >>>>> compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD >>>>> compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC >>>>> >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8030976 From dean.long at oracle.com Thu Oct 9 05:34:14 2014 From: dean.long at oracle.com (dean long) Date: Wed, 08 Oct 2014 22:34:14 -0700 Subject: [9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled In-Reply-To: <5434FF70.5060006@oracle.com> References: <542E6AD7.1060307@oracle.com> <542EE5D4.9050304@oracle.com> <5434EB2C.10600@oracle.com> <5434FF70.5060006@oracle.com> Message-ID: <54361E56.1090900@oracle.com> Thanks Igor! dl On 10/8/2014 2:10 AM, Igor Ignatyev wrote: > Dean/Tobias, > > I've filed an RFE for it -- > https://bugs.openjdk.java.net/browse/JDK-8059923. > > Igor > > On 10/08/2014 11:43 AM, Tobias Hartmann wrote: >> Hi Dean, >> >> thanks for the feedback. >> >> On 03.10.2014 20:07, dean long wrote: >>> In the future, it might be useful for the whitebox interface to >>> return a >>> compilation count for a method. >>> That way we can query "is or was compiled" vs. "is currently compiled". >> >> Yes that would be useful but there are some tests that need a compiled >> version of the method. For example, compiler.whitebox.GetNMethodTest. >> >> Best, >> Tobias >> >>> >>> dl >>> >>> On 10/3/2014 2:22 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046268 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/ >>>> >>>> == Problem == >>>> The whitebox tests assume that after the invocation of >>>> 'CompilerWhiteBoxTest.compile()' the method is always compiled and >>>> 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR >>>> compilations [1] this is does not hold. For example, in case of the >>>> following events: >>>> >>>> 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile >>>> 'SimpleTestCase.Helper.osrMethod()'. >>>> 2) OSR compilation is performed at level 4. An uncommon trap is added >>>> after the loop because profiling never reached that point. Execution >>>> continues with the OSR version. >>>> 3) Deoptimization is triggered because the loop finishes (reason: >>>> 'unstable if'). The OSR nmethod is made non-entrant and removed from >>>> the OSR list (see 'nmethod::invalidate_osr_method'). >>>> 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the >>>> method is OSR compiled. Because the OSR nmethod was removed from the >>>> list, check compiled returns false (see WB_IsMethodCompiled). >>>> >>>> This was caused by the fix for JDK-8030976 [2] because we now trust >>>> the profile information more and add uncommon traps to untaken paths. >>>> In this case we add an uncommon trap after the loop exit: >>>> >>>> private int osrMethod() { >>>> int result = 0; >>>> for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) { >>>> result += method(); >>>> } >>>> return result; >>>> } >>>> >>>> == Solution == >>>> I added code to 'warm up' the methods before triggering OSR >>>> compilation by executing them a limited number of times. Like this, >>>> the profile information marks the loop exit as taken and we don't add >>>> an uncommon trap. >>>> >>>> == Testing == >>>> - Executed failing tests on JPRT >>>> >>>> Thanks, >>>> Tobias >>>> >>>> >>>> [1] OSR compiled methods: >>>> compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR >>>> compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD >>>> compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC >>>> >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8030976 >>> From tobias.hartmann at oracle.com Thu Oct 9 05:54:10 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 09 Oct 2014 07:54:10 +0200 Subject: [9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled In-Reply-To: <54355A1D.7070307@oracle.com> References: <542E6AD7.1060307@oracle.com> <542EDAF4.2030000@oracle.com> <5434F5D7.3050207@oracle.com> <5435017A.60707@oracle.com> <54350993.2040000@oracle.com> <54355A1D.7070307@oracle.com> Message-ID: <54362302.4080808@oracle.com> Thank you, Vladimir. Best, Tobias On 08.10.2014 17:37, Vladimir Kozlov wrote: > webrev.02 looks good to me. > > Thanks, > Vladimir > > On 10/8/14 2:53 AM, Tobias Hartmann wrote: >> Hi Igor, >> >> thanks for the review. >> >> On 08.10.2014 11:18, Igor Ignatyev wrote: >>> Tobias, >>> >>> On 10/08/2014 12:29 PM, Tobias Hartmann wrote: >>>> Hi Vladimir, >>>> >>>> thanks for the review. >>>> >>>> On 03.10.2014 19:20, Vladimir Kozlov wrote: >>>>> Nightly runs done with -Xcomp. Make sure your changes still work. >>>> >>>> I did some more testing on JPRT with -Xcomp and also with >>>> -XX:-TieredCompilation. No failures (the results are linked in the >>>> comment section). Most tests explicitly specify '-Xmixed'. >>>> >>>>> 200 for tiered may be too high. C1 compilation triggered before that, >>>>> please check. >>>> >>>> Yes, that's intended. After some more testing I even increased the value >>>> to 2000 to make sure that the loop exit branch probability is high >>>> enough and we never add an uncommon trap. If the method is compiled >>>> during warmup the following deoptimization ensures that we throw away >>>> the compiled version and an OSR compilation is triggered: >>>> >>>> 551 // Make sure method is not (yet) compiled >>>> 552 deoptimize(m); >>> no, it doesn't since you call 'WhiteBox.getWhiteBox().deoptimizeMethod(e, >>> false);' where false means non-osr. >> >> Yes, that's intended. We want to trigger an OSR compilation after the warmup. >> Therefore we remove all non-OSR versions >> by deoptimizing them. If the warmup triggers an OSR compilation (which is >> really unlikely because the loop is executed >> for only one iteration each) that's fine as well. >> >> I added some comments to make this more explicit. >> >>>> >>>> I also added code to wait for a potential background compilation (see >>>> 'Helper.deoptimize') because the method may still be in the compile queue. >>> we already have 'CompilerWhiteBoxTest::waitBackgroundCompilation', I think it'd >>> be better to add an argument to it and make it static, but leave instance method >>> w/o args which calls it w/ method. >> >> Done. New webrev: >> >> http://cr.openjdk.java.net/~thartmann/8046268/webrev.02/ >> >> Thanks, >> Tobias >> >>>> >>>> The fixed tests pass on all platforms with and without -Xcomp. >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.01/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/3/14 2:22 AM, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> please review the following patch. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046268 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/ >>>>>> >>>>>> == Problem == >>>>>> The whitebox tests assume that after the invocation of >>>>>> 'CompilerWhiteBoxTest.compile()' the method is always compiled >>>>>> and 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR >>>>>> compilations [1] this is does not hold. For >>>>>> example, in case of the following events: >>>>>> >>>>>> 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile >>>>>> 'SimpleTestCase.Helper.osrMethod()'. >>>>>> 2) OSR compilation is performed at level 4. An uncommon trap is added >>>>>> after the loop because profiling never reached >>>>>> that point. Execution continues with the OSR version. >>>>>> 3) Deoptimization is triggered because the loop finishes (reason: >>>>>> 'unstable if'). The OSR nmethod is made non-entrant >>>>>> and removed from the OSR list (see 'nmethod::invalidate_osr_method'). >>>>>> 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the >>>>>> method is OSR compiled. Because the OSR nmethod >>>>>> was removed from the list, check compiled returns false (see >>>>>> WB_IsMethodCompiled). >>>>>> >>>>>> This was caused by the fix for JDK-8030976 [2] because we now trust >>>>>> the profile information more and add uncommon traps >>>>>> to untaken paths. In this case we add an uncommon trap after the loop >>>>>> exit: >>>>>> >>>>>> private int osrMethod() { >>>>>> int result = 0; >>>>>> for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) { >>>>>> result += method(); >>>>>> } >>>>>> return result; >>>>>> } >>>>>> >>>>>> == Solution == >>>>>> I added code to 'warm up' the methods before triggering OSR >>>>>> compilation by executing them a limited number of times. >>>>>> Like this, the profile information marks the loop exit as taken and we >>>>>> don't add an uncommon trap. >>>>>> >>>>>> == Testing == >>>>>> - Executed failing tests on JPRT >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>> >>>>>> [1] OSR compiled methods: >>>>>> compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR >>>>>> compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD >>>>>> compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC >>>>>> >>>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8030976 From tobias.hartmann at oracle.com Thu Oct 9 06:52:48 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 09 Oct 2014 08:52:48 +0200 Subject: [9] RFR(S): 8046268: compiler/whitebox/ tests fail : must be osr_compiled In-Reply-To: <5434FF70.5060006@oracle.com> References: <542E6AD7.1060307@oracle.com> <542EE5D4.9050304@oracle.com> <5434EB2C.10600@oracle.com> <5434FF70.5060006@oracle.com> Message-ID: <543630C0.2050208@oracle.com> Thank you! Best, Tobias On 08.10.2014 11:10, Igor Ignatyev wrote: > Dean/Tobias, > > I've filed an RFE for it -- https://bugs.openjdk.java.net/browse/JDK-8059923. > > Igor > > On 10/08/2014 11:43 AM, Tobias Hartmann wrote: >> Hi Dean, >> >> thanks for the feedback. >> >> On 03.10.2014 20:07, dean long wrote: >>> In the future, it might be useful for the whitebox interface to return a >>> compilation count for a method. >>> That way we can query "is or was compiled" vs. "is currently compiled". >> >> Yes that would be useful but there are some tests that need a compiled >> version of the method. For example, compiler.whitebox.GetNMethodTest. >> >> Best, >> Tobias >> >>> >>> dl >>> >>> On 10/3/2014 2:22 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8046268 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8046268/webrev.00/ >>>> >>>> == Problem == >>>> The whitebox tests assume that after the invocation of >>>> 'CompilerWhiteBoxTest.compile()' the method is always compiled and >>>> 'CompilerWhiteBoxTest.checkCompiled()' will return true. For OSR >>>> compilations [1] this is does not hold. For example, in case of the >>>> following events: >>>> >>>> 1) The test invokes 'CompilerWhiteBoxTest.compile()' to OSR compile >>>> 'SimpleTestCase.Helper.osrMethod()'. >>>> 2) OSR compilation is performed at level 4. An uncommon trap is added >>>> after the loop because profiling never reached that point. Execution >>>> continues with the OSR version. >>>> 3) Deoptimization is triggered because the loop finishes (reason: >>>> 'unstable if'). The OSR nmethod is made non-entrant and removed from >>>> the OSR list (see 'nmethod::invalidate_osr_method'). >>>> 4) The test uses CompilerWhiteBoxTest.checkCompiled() to make sure the >>>> method is OSR compiled. Because the OSR nmethod was removed from the >>>> list, check compiled returns false (see WB_IsMethodCompiled). >>>> >>>> This was caused by the fix for JDK-8030976 [2] because we now trust >>>> the profile information more and add uncommon traps to untaken paths. >>>> In this case we add an uncommon trap after the loop exit: >>>> >>>> private int osrMethod() { >>>> int result = 0; >>>> for (long i = 0; i < CompilerWhiteBoxTest.BACKEDGE_THRESHOLD; ++i) { >>>> result += method(); >>>> } >>>> return result; >>>> } >>>> >>>> == Solution == >>>> I added code to 'warm up' the methods before triggering OSR >>>> compilation by executing them a limited number of times. Like this, >>>> the profile information marks the loop exit as taken and we don't add >>>> an uncommon trap. >>>> >>>> == Testing == >>>> - Executed failing tests on JPRT >>>> >>>> Thanks, >>>> Tobias >>>> >>>> >>>> [1] OSR compiled methods: >>>> compiler.whitebox.SimpleTestCase.Helper.OSR_CONSTRUCTOR >>>> compiler.whitebox.SimpleTestCase.Helper.OSR_METHOD >>>> compiler.whitebox.SimpleTestCase.Helper.OSR_STATIC >>>> >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8030976 >>> From zoltan.majo at oracle.com Thu Oct 9 08:20:53 2014 From: zoltan.majo at oracle.com (=?windows-1252?Q?Zolt=E1n_Maj=F3?=) Date: Thu, 09 Oct 2014 10:20:53 +0200 Subject: [9] RFR(S): 8059847: complement JDK-8055286 and JDK-8056964 changes In-Reply-To: <543557C8.6030709@oracle.com> References: <5434287C.6060204@oracle.com> <5434512B.9000307@oracle.com> <543548AC.7050300@oracle.com> <543557C8.6030709@oracle.com> Message-ID: <54364565.3050303@oracle.com> Hi Vladimir, thank you for your feedback! On 10/08/2014 05:27 PM, Vladimir Kozlov wrote: > You don't need /othervm if there are no additional flags. OK, I removed it. > Instead of /startup/ I would suggest /oracle/ subdir name since we > testing code in compilerOracle. OK, I moved the test to the 'oracle' subdirectory. > 42 // Type (1) is used to check if a flag "someflag" is enabled for a > 43 // method. > > I would say: > > 42 // Type (1) is used to enable a boolean flag for a method. I updated the comment in the test (and also in compilerOracle.cpp on line 732). > Should it be "bool,MyBoolOption,100"?: > > 135 // wrong value for bool flag > 136 "-XX:CompileCommand=option,Test::test,bool,MyBoolOption,intx,100", I changed the test to what you've suggested. > Same problem with next test which does not match the comment: > > 140 // intx flag name missing > 141 > "-XX:CompileCommand=option,Test::test,bool,MyBoolOption,false,intx,100", I changed this test as well. I've also added three new tests to TYPE_2_INVALID_ARGUMENTS. The new tests are very similar to the ones in webrev.01. > Please, separate next checks to be clear which one is incorrect: > > 179 if (TYPE_1_ARGUMENTS.length != > TYPE_1_EXPECTED_OUTPUTS.length > 180 || TYPE_2_ARGUMENTS.length != > TYPE_2_EXPECTED_OUTPUTS.length) { > 181 throw new RuntimeException("Test is set up > incorrectly: length of arguments and expected outputs does not match."); > 182 } I separated the checks and updated the error messages. Here is the new webrev: http://cr.openjdk.java.net/~zmajo/8059847/webrev.02/ Thank you! Best regards, Zoltan > > Thanks, > Vladimir > > On 10/8/14 7:22 AM, Zolt?n Maj? wrote: >> Hi David and Vladimir, >> >> >> thank you for your feedback. >> >> On 10/07/2014 10:46 PM, Vladimir Kozlov wrote: >>> On 10/7/14 11:06 AM, David Chase wrote: >>> >>>> Do we need to add a test (? what would it look like?) to ensure >>>> that it works? >>> >>> Yes, please, add a regression test. >> >> I added a regression test >> ('compiler/startup/CheckCompileCommandOption.java'). Here is the >> updated webrev: >> >> http://cr.openjdk.java.net/~zmajo/8059847/webrev.01/ >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> David >>>> >>>> On 2014-10-07, at 1:53 PM, Zolt?n Maj? wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> please review the following small patch. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059847 >>>>> >>>>> Problem: CompileCommand=option does not support flags of type double. >>>>> >>>>> Solution: Add support for flags of type double. Output: >>>>> >>>>> java >>>>> -XX:CompileCommand=option,Test::test,ccstrlist,MyListOption,_foo,_bar >>>>> -XX:CompileCommand=option,Test::test,ccstr,MyStrOption,_foo >>>>> -XX:CompileCommand=option,Test::test,bool,MyBoolOption,false >>>>> -XX:CompileCommand=option,Test::test,intx,MyIntxOption,-1 >>>>> -XX:CompileCommand=option,Test::test,uintx,MyUintxOption,1 >>>>> -XX:CompileCommand=option,Test::test,MyFlag >>>>> -XX:CompileCommand=option,Test::test,double,MyDoubleOption,1.123 >>>>> -version >>>>> >>>>> CompilerOracle: option Test.test const char* MyListOption = '_foo >>>>> _bar' >>>>> CompilerOracle: option Test.test const char* MyStrOption = '_foo' >>>>> CompilerOracle: option Test.test bool MyBoolOption = false >>>>> CompilerOracle: option Test.test intx MyIntxOption = -1 >>>>> CompilerOracle: option Test.test uintx MyUintxOption = 1 >>>>> CompilerOracle: option Test.test bool MyFlag = true >>>>> CompilerOracle: option Test.test double MyDoubleOption = '1.123000' >>>>> java version "1.9.0-ea" >>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b33) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-fastdebug-internal, >>>>> mixed mode) >>>>> >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~zmajo/8059847/webrev.00/ >>>>> >>>>> Testing: JPRT >>>>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>> >> From albert.noll at oracle.com Thu Oct 9 08:24:58 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 09 Oct 2014 10:24:58 +0200 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. Message-ID: <5436465A.3080001@oracle.com> Hi, could I get reviews for this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8046809 Problem: The test generates an artificially large number of adapters. CodeCacheMinimumFreeSpace in not large enough to hold all adapters, if the code cache gets full. Furthermore, the JVM is in a state where no safepoint is requested. As a result, stack scanning of active methods does not happen and consequently nmethods cannot be flushed from the code cache. Solution: The following two changes fix the problem: 1) Introduce a new VM operation that forces stack scanning of active methods In the current design, the code cache sweeper can only make progress (i.e., remove compiled code) if safepoints are triggered. More specifically, several safepoints must occur to concert compiled code from state 'not_entrant' to 'unloaded'. If no safepoints are triggered, code cannot be removed from the code cache. If the code cache fills up and safepoints are triggered too infrequently, the sweeper cannot remove compiled code from the code cache fast enough. This patch forces a VM operation to do stack scanning, if there is 10% free space in the code cache. Is parameter is currently constant. I command line parameter can be added to provide the user with explicit control over this threshold. I think we can add such a command line parameter on demand. 2) Use a dedicated sweeper thread that processes the whole code cache at once (remove NmethodSweepFraction) Using a separate sweeper thread comes at the cost requiring more memory (mostly the stack size of the sweeper thread) but has numerous benefits: a) Code gets simpler: We can remove NMethodSweepFraction and NmethodSweepCheckInterval b) More aggressive sweeping: If the code cache gets full, we can process the entire code cache without taking away cycles that are potentially needed for compilation. The patch also removes CodeCacheMinimumFreeSpace and 'critical' code cache allocations. Due to a bug in heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved for 'critical' allocations. The following lines produce an underflow if heap_unallocated_capacity() < CodeCacheMinimumFreeSpace: segments_to_size(number_of_segments) > (heap_unallocated_capacity() - CodeCacheMinimumFreeSpace) Since the critical part in the code cache was never used for its intended purpose and we did not have problems due to that, we can remove it. Correctness testing: Failing test case, JPRT Performance testing: The bug contains a link to performance results. Webrev: http://cr.openjdk.java.net/~anoll/8046809/webrev.02/ Many thanks in advance, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Thu Oct 9 11:30:35 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 09 Oct 2014 13:30:35 +0200 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <5436465A.3080001@oracle.com> References: <5436465A.3080001@oracle.com> Message-ID: <543671DB.3050702@oracle.com> Hi Albert, I think having a separate sweeper thread is a good approach. Some (minor) comments: - In 'CodeCache::allocate' you should move the following code down to just before we return NULL because it should only be executed if the code cache is full and not in case of the 'fallback': 361 MutexUnlockerEx mu(CodeCache_lock, Mutex::_no_safepoint_check_flag); 362 CompileBroker::handle_full_code_cache(code_blob_type); - I think you should add a comment to the call site of 'NMethodSweeper::notify()' saying what it does. - The indentation of lines in 'SmallCodeCacheStartup.java' (line 37) is wrong. - I think you can remove the "force_sweep" parameter from "NMethodSweeper::do_stack_scanning" and only invoke it if you want to enforce sweeping. Maybe add a comment to the call site describing why we only check the MethodNonProfiled code heap. - It would be good to have a performance comparison to a baseline version without your changes because a different amount of sweeping may affect overall performance. - Don't forget the CCC request because you removed product flags :) Removing critical allocations together with CodeCacheMinimumFreeSpace is also good because it was broken and inconsistent (e.g., method handle intrinsics are not critical). Best, Tobias On 09.10.2014 10:24, Albert Noll wrote: > Hi, > > could I get reviews for this patch? > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8046809 > > Problem: > The test generates an artificially large number of adapters. > CodeCacheMinimumFreeSpace in not large enough to hold all adapters, > if the code cache gets full. Furthermore, the JVM is in a state where no > safepoint is requested. As a result, stack scanning of active > methods does not happen and consequently nmethods cannot be flushed from the > code cache. > > Solution: > The following two changes fix the problem: > > 1) Introduce a new VM operation that forces stack scanning of active methods > > In the current design, the code cache sweeper can only make progress (i.e., > remove compiled code) if > safepoints are triggered. More specifically, several safepoints must occur to > concert compiled code from > state 'not_entrant' to 'unloaded'. If no safepoints are triggered, code cannot > be removed from the code > cache. If the code cache fills up and safepoints are triggered too infrequently, > the sweeper cannot remove > compiled code from the code cache fast enough. > > This patch forces a VM operation to do stack scanning, if there is 10% free > space in the code cache. Is parameter > is currently constant. I command line parameter can be added to provide the user > with explicit control over this > threshold. I think we can add such a command line parameter on demand. > > 2) Use a dedicated sweeper thread that processes the whole code cache at once > (remove NmethodSweepFraction) > Using a separate sweeper thread comes at the cost requiring more memory (mostly > the stack size of the sweeper > thread) but has numerous benefits: > a) Code gets simpler: We can remove NMethodSweepFraction and > NmethodSweepCheckInterval > b) More aggressive sweeping: If the code cache gets full, we can process the > entire code > cache without taking away cycles that are potentially needed for compilation. > > The patch also removes CodeCacheMinimumFreeSpace and 'critical' code cache > allocations. Due to a bug in > heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved for 'critical' > allocations. The following > lines produce an underflow if heap_unallocated_capacity() < > CodeCacheMinimumFreeSpace: > > segments_to_size(number_of_segments) > (heap_unallocated_capacity() - > CodeCacheMinimumFreeSpace) > > Since the critical part in the code cache was never used for its intended > purpose and we did not have problems > due to that, we can remove it. > > Correctness testing: > Failing test case, JPRT > > Performance testing: > The bug contains a link to performance results. > > Webrev: > http://cr.openjdk.java.net/~anoll/8046809/webrev.02/ > > Many thanks in advance, > Albert From zoltan.majo at oracle.com Thu Oct 9 16:43:02 2014 From: zoltan.majo at oracle.com (=?windows-1252?Q?Zolt=E1n_Maj=F3?=) Date: Thu, 09 Oct 2014 18:43:02 +0200 Subject: [9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation) In-Reply-To: <0DBAED7F-65DF-4D15-AFDB-636DF7F70C16@oracle.com> References: <5433C140.9070400@oracle.com> <5433C6C6.20602@oracle.com> <5433EE7A.9060607@oracle.com> <0DBAED7F-65DF-4D15-AFDB-636DF7F70C16@oracle.com> Message-ID: <5436BB16.7010703@oracle.com> Hi Igor, thank you for your feedback! On 10/07/2014 11:17 PM, Igor Veresov wrote: > 1. It would probably be nice not to do multiplications at every event but rather compute everything once during the startup. Perhaps it would be better to scale command line options right in arguments.cpp ? Or setup accessors in Arguments that would compute and cache the values. If you just scale the options the change would be smaller though. What do you think? That is a good idea. I changed the code to scale thresholds in arguments.cpp (in Arguments::apply_ergo()). > 2. Why aren?t you scaling Tier{2,3}{Invoke,Backedge}NotifyFreqLog and Tier23InlineeNotifyFreqLog? Probably can be solved by (1) automatically. The previous patch adjusts only the transition from Tier 0 to Tier 3 (when methods get first compiled). But now that you've suggested, I extended the patch to scale Tier4* compilation thresholds and Tier{2,3} notification thresholds as well. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8059604/webrev.02/ I tested the new patch with JPRT and manual testing. Thank you and best regards, Zoltan > igor > > On Oct 7, 2014, at 6:45 AM, Zolt?n Maj? wrote: > >> Hi Albert, >> >> >> thank you for your feedback. >> >> On 10/07/2014 12:56 PM, Albert Noll wrote: >>> How about using a scaling factor instead of using percentage? >> I think that is a good idea because a scaling factor (expressed as a double) allows a finer-grained control of compilation thresholds than a scaling percentage (expressed as an integer). >> >> Here is the webrev with the scaling factor: >> >> http://cr.openjdk.java.net/~zmajo/8059604/webrev.01/ >> >> The name of the flag is changed to CompileThresholdScaling (from CompileThresholdScalingPercentage). >> >>> What happens if a threshold becomes 0 after scaling? >> Then all methods will be interpreted. That seems to be the convention (in src/share/vm/runtime/arguments.cpp). >> >> Best regards, >> >> >> Zoltan >> >>> Best, >>> Albert >>> >>> >>> On 10/07/2014 12:32 PM, Zolt?n Maj? wrote: >>>> Hi, >>>> >>>> >>>> please review the following patch. >>>> >>>> >>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8059604 >>>> >>>> >>>> Problem: With tiered compilation enabled, the value of 6 different thresholds must be set to control when the JVM compiles methods for the first time. That is too detailed for the average customer. >>>> >>>> >>>> Solution: This patch adds a new flag, CompileThresholdScalingPercentage, to control when methods are first compiled. The new flag scales thresholds the following way: >>>> >>>> - if CompileThresholdScalingPercentage==100, the default threshold values are used >>>> - if CompileThresholdScalingPercentage>100, threshold values are scaled up (e.g., CompileThresholdScalingPercentage=120 scales up thresholds by a factor of 1.2X) >>>> - if 0 < CompileThresholdScalingPercentage < 100, threshold values are scaled down accordingly. >>>> >>>> The new flag works both with and without tiered compilation. Thus, the new flag allows compilation to be controlled the same way both with and without tiered compilation: >>>> >>>> - with tiered compilation enabled, the value of the flags Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog, Tier3InvocationThreshold, Tier3MinInvocationThreshold, Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled >>>> >>>> - with tiered compilation disabled, the value of CompileThreshold is scaled >>>> >>>> Currently, tiered and non-tiered compilation treats threshold values slightly differently: For a threshold value of N and without tiered compilation enabled, methods are compiled *before* their Nth execution. With tiered compilation enabled, methods are compiled *after* the their Nth execution. >>>> >>>> The patch addresses the difference between tiered/non-tiered compilation: Methods are compiled right before their Nth execution in both cases (the non-tiered way). If CompileThresholdScalingPercentage==0, all methods are interpreted (similarly to the case when CompileThreshold==0). >>>> >>>> This patch is the second (out of three) parts of JDK-8050853 (adding support for per-compilation thresholds):https://bugs.openjdk.java.net/browse/JDK-8050853 . >>>> >>>> >>>> Webrev:http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/ >>>> >>>> >>>> Testing: JPRT, manual testing >>>> >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> From vladimir.kozlov at oracle.com Thu Oct 9 16:48:09 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Oct 2014 09:48:09 -0700 Subject: [9] RFR(S): 8059847: complement JDK-8055286 and JDK-8056964 changes In-Reply-To: <54364565.3050303@oracle.com> References: <5434287C.6060204@oracle.com> <5434512B.9000307@oracle.com> <543548AC.7050300@oracle.com> <543557C8.6030709@oracle.com> <54364565.3050303@oracle.com> Message-ID: <5436BC49.8070900@oracle.com> webrev.02 looks good. Thanks, Vladimir On 10/9/14 1:20 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > thank you for your feedback! > > On 10/08/2014 05:27 PM, Vladimir Kozlov wrote: >> You don't need /othervm if there are no additional flags. > > OK, I removed it. > >> Instead of /startup/ I would suggest /oracle/ subdir name since we testing code in compilerOracle. > > OK, I moved the test to the 'oracle' subdirectory. > >> 42 // Type (1) is used to check if a flag "someflag" is enabled for a >> 43 // method. >> >> I would say: >> >> 42 // Type (1) is used to enable a boolean flag for a method. > > I updated the comment in the test (and also in compilerOracle.cpp on line 732). > >> Should it be "bool,MyBoolOption,100"?: >> >> 135 // wrong value for bool flag >> 136 "-XX:CompileCommand=option,Test::test,bool,MyBoolOption,intx,100", > > I changed the test to what you've suggested. > >> Same problem with next test which does not match the comment: >> >> 140 // intx flag name missing >> 141 "-XX:CompileCommand=option,Test::test,bool,MyBoolOption,false,intx,100", > > I changed this test as well. > > I've also added three new tests to TYPE_2_INVALID_ARGUMENTS. The new tests are very similar to the ones in webrev.01. > >> Please, separate next checks to be clear which one is incorrect: >> >> 179 if (TYPE_1_ARGUMENTS.length != TYPE_1_EXPECTED_OUTPUTS.length >> 180 || TYPE_2_ARGUMENTS.length != TYPE_2_EXPECTED_OUTPUTS.length) { >> 181 throw new RuntimeException("Test is set up incorrectly: length of arguments and expected outputs does >> not match."); >> 182 } > > I separated the checks and updated the error messages. > > Here is the new webrev: > > http://cr.openjdk.java.net/~zmajo/8059847/webrev.02/ > > Thank you! > > Best regards, > > > Zoltan > >> >> Thanks, >> Vladimir >> >> On 10/8/14 7:22 AM, Zolt?n Maj? wrote: >>> Hi David and Vladimir, >>> >>> >>> thank you for your feedback. >>> >>> On 10/07/2014 10:46 PM, Vladimir Kozlov wrote: >>>> On 10/7/14 11:06 AM, David Chase wrote: >>>> >>>>> Do we need to add a test (? what would it look like?) to ensure that it works? >>>> >>>> Yes, please, add a regression test. >>> >>> I added a regression test ('compiler/startup/CheckCompileCommandOption.java'). Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~zmajo/8059847/webrev.01/ >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> David >>>>> >>>>> On 2014-10-07, at 1:53 PM, Zolt?n Maj? wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> please review the following small patch. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059847 >>>>>> >>>>>> Problem: CompileCommand=option does not support flags of type double. >>>>>> >>>>>> Solution: Add support for flags of type double. Output: >>>>>> >>>>>> java -XX:CompileCommand=option,Test::test,ccstrlist,MyListOption,_foo,_bar >>>>>> -XX:CompileCommand=option,Test::test,ccstr,MyStrOption,_foo >>>>>> -XX:CompileCommand=option,Test::test,bool,MyBoolOption,false >>>>>> -XX:CompileCommand=option,Test::test,intx,MyIntxOption,-1 -XX:CompileCommand=option,Test::test,uintx,MyUintxOption,1 >>>>>> -XX:CompileCommand=option,Test::test,MyFlag -XX:CompileCommand=option,Test::test,double,MyDoubleOption,1.123 -version >>>>>> >>>>>> CompilerOracle: option Test.test const char* MyListOption = '_foo _bar' >>>>>> CompilerOracle: option Test.test const char* MyStrOption = '_foo' >>>>>> CompilerOracle: option Test.test bool MyBoolOption = false >>>>>> CompilerOracle: option Test.test intx MyIntxOption = -1 >>>>>> CompilerOracle: option Test.test uintx MyUintxOption = 1 >>>>>> CompilerOracle: option Test.test bool MyFlag = true >>>>>> CompilerOracle: option Test.test double MyDoubleOption = '1.123000' >>>>>> java version "1.9.0-ea" >>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b33) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-fastdebug-internal, mixed mode) >>>>>> >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~zmajo/8059847/webrev.00/ >>>>>> >>>>>> Testing: JPRT >>>>>> >>>>>> Thank you and best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>> >>> > From zoltan.majo at oracle.com Thu Oct 9 17:19:32 2014 From: zoltan.majo at oracle.com (=?windows-1252?Q?Zolt=E1n_Maj=F3?=) Date: Thu, 09 Oct 2014 19:19:32 +0200 Subject: [9] RFR(S): 8059847: complement JDK-8055286 and JDK-8056964 changes In-Reply-To: <5436BC49.8070900@oracle.com> References: <5434287C.6060204@oracle.com> <5434512B.9000307@oracle.com> <543548AC.7050300@oracle.com> <543557C8.6030709@oracle.com> <54364565.3050303@oracle.com> <5436BC49.8070900@oracle.com> Message-ID: <5436C3A4.40902@oracle.com> Thank you, Vladimir! Zoltan On 10/09/2014 06:48 PM, Vladimir Kozlov wrote: > webrev.02 looks good. > > Thanks, > Vladimir > > On 10/9/14 1:20 AM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> thank you for your feedback! >> >> On 10/08/2014 05:27 PM, Vladimir Kozlov wrote: >>> You don't need /othervm if there are no additional flags. >> >> OK, I removed it. >> >>> Instead of /startup/ I would suggest /oracle/ subdir name since we >>> testing code in compilerOracle. >> >> OK, I moved the test to the 'oracle' subdirectory. >> >>> 42 // Type (1) is used to check if a flag "someflag" is enabled >>> for a >>> 43 // method. >>> >>> I would say: >>> >>> 42 // Type (1) is used to enable a boolean flag for a method. >> >> I updated the comment in the test (and also in compilerOracle.cpp on >> line 732). >> >>> Should it be "bool,MyBoolOption,100"?: >>> >>> 135 // wrong value for bool flag >>> 136 "-XX:CompileCommand=option,Test::test,bool,MyBoolOption,intx,100", >> >> I changed the test to what you've suggested. >> >>> Same problem with next test which does not match the comment: >>> >>> 140 // intx flag name missing >>> 141 >>> "-XX:CompileCommand=option,Test::test,bool,MyBoolOption,false,intx,100", >>> >> >> I changed this test as well. >> >> I've also added three new tests to TYPE_2_INVALID_ARGUMENTS. The new >> tests are very similar to the ones in webrev.01. >> >>> Please, separate next checks to be clear which one is incorrect: >>> >>> 179 if (TYPE_1_ARGUMENTS.length != >>> TYPE_1_EXPECTED_OUTPUTS.length >>> 180 || TYPE_2_ARGUMENTS.length != >>> TYPE_2_EXPECTED_OUTPUTS.length) { >>> 181 throw new RuntimeException("Test is set up >>> incorrectly: length of arguments and expected outputs does >>> not match."); >>> 182 } >> >> I separated the checks and updated the error messages. >> >> Here is the new webrev: >> >> http://cr.openjdk.java.net/~zmajo/8059847/webrev.02/ >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/8/14 7:22 AM, Zolt?n Maj? wrote: >>>> Hi David and Vladimir, >>>> >>>> >>>> thank you for your feedback. >>>> >>>> On 10/07/2014 10:46 PM, Vladimir Kozlov wrote: >>>>> On 10/7/14 11:06 AM, David Chase wrote: >>>>> >>>>>> Do we need to add a test (? what would it look like?) to ensure >>>>>> that it works? >>>>> >>>>> Yes, please, add a regression test. >>>> >>>> I added a regression test >>>> ('compiler/startup/CheckCompileCommandOption.java'). Here is the >>>> updated webrev: >>>> >>>> http://cr.openjdk.java.net/~zmajo/8059847/webrev.01/ >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> David >>>>>> >>>>>> On 2014-10-07, at 1:53 PM, Zolt?n Maj? >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> please review the following small patch. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059847 >>>>>>> >>>>>>> Problem: CompileCommand=option does not support flags of type >>>>>>> double. >>>>>>> >>>>>>> Solution: Add support for flags of type double. Output: >>>>>>> >>>>>>> java >>>>>>> -XX:CompileCommand=option,Test::test,ccstrlist,MyListOption,_foo,_bar >>>>>>> >>>>>>> -XX:CompileCommand=option,Test::test,ccstr,MyStrOption,_foo >>>>>>> -XX:CompileCommand=option,Test::test,bool,MyBoolOption,false >>>>>>> -XX:CompileCommand=option,Test::test,intx,MyIntxOption,-1 >>>>>>> -XX:CompileCommand=option,Test::test,uintx,MyUintxOption,1 >>>>>>> -XX:CompileCommand=option,Test::test,MyFlag >>>>>>> -XX:CompileCommand=option,Test::test,double,MyDoubleOption,1.123 >>>>>>> -version >>>>>>> >>>>>>> CompilerOracle: option Test.test const char* MyListOption = >>>>>>> '_foo _bar' >>>>>>> CompilerOracle: option Test.test const char* MyStrOption = '_foo' >>>>>>> CompilerOracle: option Test.test bool MyBoolOption = false >>>>>>> CompilerOracle: option Test.test intx MyIntxOption = -1 >>>>>>> CompilerOracle: option Test.test uintx MyUintxOption = 1 >>>>>>> CompilerOracle: option Test.test bool MyFlag = true >>>>>>> CompilerOracle: option Test.test double MyDoubleOption = '1.123000' >>>>>>> java version "1.9.0-ea" >>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b33) >>>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>>> 1.9.0-fastdebug-internal, mixed mode) >>>>>>> >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~zmajo/8059847/webrev.00/ >>>>>>> >>>>>>> Testing: JPRT >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>> >>>> >> From vladimir.kozlov at oracle.com Thu Oct 9 17:43:14 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Oct 2014 10:43:14 -0700 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <5436465A.3080001@oracle.com> References: <5436465A.3080001@oracle.com> Message-ID: <5436C932.3050006@oracle.com> On 10/9/14 1:24 AM, Albert Noll wrote: > Hi, > > could I get reviews for this patch? > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8046809 > > Problem: > The test generates an artificially large number of adapters. > CodeCacheMinimumFreeSpace in not large enough to hold all adapters, > if the code cache gets full. Furthermore, the JVM is in a state where no > safepoint is requested. As a result, stack scanning of active > methods does not happen and consequently nmethods cannot be flushed from > the code cache. > > Solution: > The following two changes fix the problem: > > 1) Introduce a new VM operation that forces stack scanning of active methods > > In the current design, the code cache sweeper can only make progress > (i.e., remove compiled code) if > safepoints are triggered. More specifically, several safepoints must > occur to concert compiled code from > state 'not_entrant' to 'unloaded'. If no safepoints are triggered, code > cannot be removed from the code > cache. If the code cache fills up and safepoints are triggered too > infrequently, the sweeper cannot remove > compiled code from the code cache fast enough. > > This patch forces a VM operation to do stack scanning, if there is 10% > free space in the code cache. Is parameter > is currently constant. I command line parameter can be added to provide > the user with explicit control over this > threshold. I think we can add such a command line parameter on demand. There is flag GuaranteedSafepointInterval. The corresponding code in VMThread::loop() is guarded by SafepointSynchronize::is_cleanup_needed(). You may add additional condition there. > > 2) Use a dedicated sweeper thread that processes the whole code cache at > once (remove NmethodSweepFraction) > Using a separate sweeper thread comes at the cost requiring more memory > (mostly the stack size of the sweeper > thread) but has numerous benefits: > a) Code gets simpler: We can remove NMethodSweepFraction and > NmethodSweepCheckInterval > b) More aggressive sweeping: If the code cache gets full, we can process > the entire code > cache without taking away cycles that are potentially needed for > compilation. > > The patch also removes CodeCacheMinimumFreeSpace and 'critical' code > cache allocations. Due to a bug in > heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved for > 'critical' allocations. The following > lines produce an underflow if heap_unallocated_capacity() < > CodeCacheMinimumFreeSpace: > > segments_to_size(number_of_segments) > (heap_unallocated_capacity() - > CodeCacheMinimumFreeSpace) > > Since the critical part in the code cache was never used for its > intended purpose and we did not have problems > due to that, we can remove it. Can you do CodeCacheMinimumFreeSpace and 'critical' code removal in a separate changes? Current changes are big enough already. Thanks, Vladimir > > Correctness testing: > Failing test case, JPRT > > Performance testing: > The bug contains a link to performance results. > > Webrev: > http://cr.openjdk.java.net/~anoll/8046809/webrev.02/ > > Many thanks in advance, > Albert From igor.veresov at oracle.com Thu Oct 9 18:58:28 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 9 Oct 2014 11:58:28 -0700 Subject: [9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation) In-Reply-To: <5436BB16.7010703@oracle.com> References: <5433C140.9070400@oracle.com> <5433C6C6.20602@oracle.com> <5433EE7A.9060607@oracle.com> <0DBAED7F-65DF-4D15-AFDB-636DF7F70C16@oracle.com> <5436BB16.7010703@oracle.com> Message-ID: <2F9E5CC6-F48F-4250-8D78-5C1AC9BAB82C@oracle.com> That looks good to me. igor On Oct 9, 2014, at 9:43 AM, Zolt?n Maj? wrote: > Hi Igor, > > > thank you for your feedback! > > On 10/07/2014 11:17 PM, Igor Veresov wrote: >> 1. It would probably be nice not to do multiplications at every event but rather compute everything once during the startup. Perhaps it would be better to scale command line options right in arguments.cpp ? Or setup accessors in Arguments that would compute and cache the values. If you just scale the options the change would be smaller though. What do you think? > > That is a good idea. I changed the code to scale thresholds in arguments.cpp (in Arguments::apply_ergo()). > >> 2. Why aren?t you scaling Tier{2,3}{Invoke,Backedge}NotifyFreqLog and Tier23InlineeNotifyFreqLog? Probably can be solved by (1) automatically. > > The previous patch adjusts only the transition from Tier 0 to Tier 3 (when methods get first compiled). But now that you've suggested, I extended the patch to scale Tier4* compilation thresholds and Tier{2,3} notification thresholds as well. > > Here is the updated webrev: > > http://cr.openjdk.java.net/~zmajo/8059604/webrev.02/ > > I tested the new patch with JPRT and manual testing. > > Thank you and best regards, > > > Zoltan > >> igor >> >> On Oct 7, 2014, at 6:45 AM, Zolt?n Maj? wrote: >> >>> Hi Albert, >>> >>> >>> thank you for your feedback. >>> >>> On 10/07/2014 12:56 PM, Albert Noll wrote: >>>> How about using a scaling factor instead of using percentage? >>> I think that is a good idea because a scaling factor (expressed as a double) allows a finer-grained control of compilation thresholds than a scaling percentage (expressed as an integer). >>> >>> Here is the webrev with the scaling factor: >>> >>> http://cr.openjdk.java.net/~zmajo/8059604/webrev.01/ >>> >>> The name of the flag is changed to CompileThresholdScaling (from CompileThresholdScalingPercentage). >>> >>>> What happens if a threshold becomes 0 after scaling? >>> Then all methods will be interpreted. That seems to be the convention (in src/share/vm/runtime/arguments.cpp). >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>>> Best, >>>> Albert >>>> >>>> >>>> On 10/07/2014 12:32 PM, Zolt?n Maj? wrote: >>>>> Hi, >>>>> >>>>> >>>>> please review the following patch. >>>>> >>>>> >>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8059604 >>>>> >>>>> >>>>> Problem: With tiered compilation enabled, the value of 6 different thresholds must be set to control when the JVM compiles methods for the first time. That is too detailed for the average customer. >>>>> >>>>> >>>>> Solution: This patch adds a new flag, CompileThresholdScalingPercentage, to control when methods are first compiled. The new flag scales thresholds the following way: >>>>> >>>>> - if CompileThresholdScalingPercentage==100, the default threshold values are used >>>>> - if CompileThresholdScalingPercentage>100, threshold values are scaled up (e.g., CompileThresholdScalingPercentage=120 scales up thresholds by a factor of 1.2X) >>>>> - if 0 < CompileThresholdScalingPercentage < 100, threshold values are scaled down accordingly. >>>>> >>>>> The new flag works both with and without tiered compilation. Thus, the new flag allows compilation to be controlled the same way both with and without tiered compilation: >>>>> >>>>> - with tiered compilation enabled, the value of the flags Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog, Tier3InvocationThreshold, Tier3MinInvocationThreshold, Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled >>>>> >>>>> - with tiered compilation disabled, the value of CompileThreshold is scaled >>>>> >>>>> Currently, tiered and non-tiered compilation treats threshold values slightly differently: For a threshold value of N and without tiered compilation enabled, methods are compiled *before* their Nth execution. With tiered compilation enabled, methods are compiled *after* the their Nth execution. >>>>> >>>>> The patch addresses the difference between tiered/non-tiered compilation: Methods are compiled right before their Nth execution in both cases (the non-tiered way). If CompileThresholdScalingPercentage==0, all methods are interpreted (similarly to the case when CompileThreshold==0). >>>>> >>>>> This patch is the second (out of three) parts of JDK-8050853 (adding support for per-compilation thresholds):https://bugs.openjdk.java.net/browse/JDK-8050853 . >>>>> >>>>> >>>>> Webrev:http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/ >>>>> >>>>> >>>>> Testing: JPRT, manual testing >>>>> >>>>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> > From vladimir.kozlov at oracle.com Thu Oct 9 19:32:19 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Oct 2014 12:32:19 -0700 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: References: Message-ID: <5436E2C3.7060008@oracle.com> Hi roland, Sorry it took so long. Could you explain changes in fieldStreams.hpp? How it worked before? I see that the change only affects code in FieldStreamBase(Array* fields, constantPoolHandle constants, int start, int limit). And can it be simple done as?: return num_fields + _index; StressArrayCopyMacroNode flag is used in product code. Make it diagnostic. Why you skip klasses with injected fields? I thought nof_nonstatic_fields() includes them. Add comment. How we benefit from doing this optimization during parsing? Why you need StressArrayCopyMacroNode? Otherwise changes looks reasonable. Thanks, Vladimir On 10/8/14 5:33 AM, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/6700100/webrev.00/ > > Converts ArrayCopy nodes for small instance clones to series of loads/stores + a little bit of cleanup. > > Small array clones & copies as loads/stores are coming next in another change. > > Roland. > From roland.westrelin at oracle.com Thu Oct 9 21:08:12 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 9 Oct 2014 23:08:12 +0200 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: <5436E2C3.7060008@oracle.com> References: <5436E2C3.7060008@oracle.com> Message-ID: Hi Vladimir, Thanks for reviewing this. > Sorry it took so long. I sent this one yesterday so no, it didn?t take long! Maybe you?re thinking about 8054478 which has been out for a bit longer. I?m curious what you think about that one. > Could you explain changes in fieldStreams.hpp? How it worked before? > I see that the change only affects code in FieldStreamBase(Array* fields, constantPoolHandle constants, int start, int limit). InternalFieldStream was not used anywhere and it?s broken. That change to FieldStreamBase fixes it. InternalFieldStream starts iterating from k->java_fields_count() up to num_fields so num_fields must be the total number of fields. > And can it be simple done as?: > > return num_fields + _index; I use the same code pattern as the next loop: 70 for (int i = _index; i*FieldInfo::field_slots < length; i++) { 76 num_fields ++; 77 } But that doesn?t make much sense, you?re right. I?ll fix it. > StressArrayCopyMacroNode flag is used in product code. Make it diagnostic. > > Why you skip klasses with injected fields? I thought nof_nonstatic_fields() includes them. Add comment. I skip them because they are rare and it seems simpler to simply skip them. ciInstanceKlass::compute_nonstatic_fields_impl() uses JavaFieldStream that only iterates over regular java fields. > > How we benefit from doing this optimization during parsing? Why you need StressArrayCopyMacroNode? It?s a stress option. The Ideal transformation is often applied at parse time and I wanted to make sure I could stress test the Ideal transformation during IGVN because it performs somewhat trickier graph transformations. Why would I need to make it diagnostic? Rolaand. > > Otherwise changes looks reasonable. > > Thanks, > Vladimir > > On 10/8/14 5:33 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/6700100/webrev.00/ >> >> Converts ArrayCopy nodes for small instance clones to series of loads/stores + a little bit of cleanup. >> >> Small array clones & copies as loads/stores are coming next in another change. >> >> Roland. >> From vladimir.kozlov at oracle.com Thu Oct 9 21:24:06 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 09 Oct 2014 14:24:06 -0700 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: References: <5436E2C3.7060008@oracle.com> Message-ID: <5436FCF6.7080309@oracle.com> On 10/9/14 2:08 PM, Roland Westrelin wrote: > Hi Vladimir, > > Thanks for reviewing this. > >> Sorry it took so long. > > I sent this one yesterday so no, it didn?t take long! Maybe you?re thinking about 8054478 which has been out for a bit longer. I?m curious what you think about that one. Yes, that one. I am not happy about those changes so I need time to think about it and may have some suggestions. > >> Could you explain changes in fieldStreams.hpp? How it worked before? >> I see that the change only affects code in FieldStreamBase(Array* fields, constantPoolHandle constants, int start, int limit). > > InternalFieldStream was not used anywhere and it?s broken. That change to FieldStreamBase fixes it. > InternalFieldStream starts iterating from k->java_fields_count() up to num_fields so num_fields must be the total number of fields. Good. > >> And can it be simple done as?: >> >> return num_fields + _index; > > I use the same code pattern as the next loop: > > 70 for (int i = _index; i*FieldInfo::field_slots < length; i++) { > > 76 num_fields ++; > 77 } > > But that doesn?t make much sense, you?re right. I?ll fix it. > >> StressArrayCopyMacroNode flag is used in product code. Make it diagnostic. >> >> Why you skip klasses with injected fields? I thought nof_nonstatic_fields() includes them. Add comment. > > I skip them because they are rare and it seems simpler to simply skip them. But you do the check (scanning all fields) for all classes. That is what I am concern about. May be it is better to add a flag to InstanceKlass during class parsing when fields are injected? > ciInstanceKlass::compute_nonstatic_fields_impl() uses JavaFieldStream that only iterates over regular java fields. Okay. > >> >> How we benefit from doing this optimization during parsing? Why you need StressArrayCopyMacroNode? > > It?s a stress option. The Ideal transformation is often applied at parse time and I wanted to make sure I could stress test the Ideal transformation during IGVN because it performs somewhat trickier graph transformations. Why would I need to make it diagnostic? My question was why not to do that always after parse, during IGVN? You expand arraycopy node to several memory nodes which increase nodes count and complicate the graph. It may be premature to do that during parsing. On other hand ClearArrayNode::Ideal() is executed during parsing too. Yes, you don't need StressArrayCopyMacroNode be diagnostic if you don't want to stress product VM. Vladimir > > Rolaand. > >> >> Otherwise changes looks reasonable. >> >> Thanks, >> Vladimir >> >> On 10/8/14 5:33 AM, Roland Westrelin wrote: >>> http://cr.openjdk.java.net/~roland/6700100/webrev.00/ >>> >>> Converts ArrayCopy nodes for small instance clones to series of loads/stores + a little bit of cleanup. >>> >>> Small array clones & copies as loads/stores are coming next in another change. >>> >>> Roland. >>> > From dean.long at oracle.com Fri Oct 10 04:41:09 2014 From: dean.long at oracle.com (dean long) Date: Thu, 09 Oct 2014 21:41:09 -0700 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <5436465A.3080001@oracle.com> References: <5436465A.3080001@oracle.com> Message-ID: <54376365.1050301@oracle.com> Hi Albert, 256 { 257 ThreadBlockInVM tbivm(JavaThread::current()); 258 MutexLockerEx waiter(CodeCache_lock, Mutex::_no_safepoint_check_flag); 259 const long wait_time = 60*60*24 * 1000; 260 timeout = CodeCache_lock->wait(Mutex::_no_safepoint_check_flag, wait_time); 261 } 262 // We need to check for the safepoint to be able to exit the VM 263 MutexLockerEx waiter(CodeCache_lock, Mutex::_no_safepoint_check_flag); 264 NMethodSweeper::handle_safepoint_request(); How about simplifying the above so that you don't release and then reacquire the lock: 256 { 257 ThreadBlockInVM tbivm(JavaThread::current()); 258 MutexLockerEx waiter(CodeCache_lock, Mutex::_no_safepoint_check_flag); 259 const long wait_time = 60*60*24 * 1000; 260 timeout = CodeCache_lock->wait(Mutex::_no_safepoint_check_flag, wait_time); 261 // We need to check for the safepoint to be able to exit the VM 262 NMethodSweeper::handle_safepoint_request(); 263 } (This is not a full review, just a comment.) dl On 10/9/2014 1:24 AM, Albert Noll wrote: > Hi, > > could I get reviews for this patch? > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8046809 > > Problem: > The test generates an artificially large number of adapters. > CodeCacheMinimumFreeSpace in not large enough to hold all adapters, > if the code cache gets full. Furthermore, the JVM is in a state where > no safepoint is requested. As a result, stack scanning of active > methods does not happen and consequently nmethods cannot be flushed > from the code cache. > > Solution: > The following two changes fix the problem: > > 1) Introduce a new VM operation that forces stack scanning of active > methods > > In the current design, the code cache sweeper can only make progress > (i.e., remove compiled code) if > safepoints are triggered. More specifically, several safepoints must > occur to concert compiled code from > state 'not_entrant' to 'unloaded'. If no safepoints are triggered, > code cannot be removed from the code > cache. If the code cache fills up and safepoints are triggered too > infrequently, the sweeper cannot remove > compiled code from the code cache fast enough. > > This patch forces a VM operation to do stack scanning, if there is 10% > free space in the code cache. Is parameter > is currently constant. I command line parameter can be added to > provide the user with explicit control over this > threshold. I think we can add such a command line parameter on demand. > > 2) Use a dedicated sweeper thread that processes the whole code cache > at once (remove NmethodSweepFraction) > Using a separate sweeper thread comes at the cost requiring more > memory (mostly the stack size of the sweeper > thread) but has numerous benefits: > a) Code gets simpler: We can remove NMethodSweepFraction and > NmethodSweepCheckInterval > b) More aggressive sweeping: If the code cache gets full, we can > process the entire code > cache without taking away cycles that are potentially needed for > compilation. > > The patch also removes CodeCacheMinimumFreeSpace and 'critical' code > cache allocations. Due to a bug in > heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved for > 'critical' allocations. The following > lines produce an underflow if heap_unallocated_capacity() < > CodeCacheMinimumFreeSpace: > > segments_to_size(number_of_segments) > (heap_unallocated_capacity() - > CodeCacheMinimumFreeSpace) > > Since the critical part in the code cache was never used for its > intended purpose and we did not have problems > due to that, we can remove it. > > Correctness testing: > Failing test case, JPRT > > Performance testing: > The bug contains a link to performance results. > > Webrev: > http://cr.openjdk.java.net/~anoll/8046809/webrev.02/ > > Many thanks in advance, > Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.noll at oracle.com Fri Oct 10 07:21:15 2014 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 10 Oct 2014 09:21:15 +0200 Subject: [9] RFR(S): 8059847: complement JDK-8055286 and JDK-8056964 changes In-Reply-To: <54364565.3050303@oracle.com> References: <5434287C.6060204@oracle.com> <5434512B.9000307@oracle.com> <543548AC.7050300@oracle.com> <543557C8.6030709@oracle.com> <54364565.3050303@oracle.com> Message-ID: <543788EB.8070000@oracle.com> Hi Zoltan, On 10/09/2014 10:20 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > thank you for your feedback! > > On 10/08/2014 05:27 PM, Vladimir Kozlov wrote: >> You don't need /othervm if there are no additional flags. > > OK, I removed it. > >> Instead of /startup/ I would suggest /oracle/ subdir name since we >> testing code in compilerOracle. > > OK, I moved the test to the 'oracle' subdirectory. > >> 42 // Type (1) is used to check if a flag "someflag" is enabled >> for a >> 43 // method. >> >> I would say: >> >> 42 // Type (1) is used to enable a boolean flag for a method. > > I updated the comment in the test (and also in compilerOracle.cpp on > line 732). > >> Should it be "bool,MyBoolOption,100"?: >> >> 135 // wrong value for bool flag >> 136 "-XX:CompileCommand=option,Test::test,bool,MyBoolOption,intx,100", > > I changed the test to what you've suggested. > >> Same problem with next test which does not match the comment: >> >> 140 // intx flag name missing >> 141 >> "-XX:CompileCommand=option,Test::test,bool,MyBoolOption,false,intx,100", > > I changed this test as well. > > I've also added three new tests to TYPE_2_INVALID_ARGUMENTS. The new > tests are very similar to the ones in webrev.01. > >> Please, separate next checks to be clear which one is incorrect: >> >> 179 if (TYPE_1_ARGUMENTS.length != >> TYPE_1_EXPECTED_OUTPUTS.length >> 180 || TYPE_2_ARGUMENTS.length != >> TYPE_2_EXPECTED_OUTPUTS.length) { >> 181 throw new RuntimeException("Test is set up >> incorrectly: length of arguments and expected outputs does not match."); >> 182 } > > I separated the checks and updated the error messages. > > Here is the new webrev: > > http://cr.openjdk.java.net/~zmajo/8059847/webrev.02/ > That looks good to me (not a reviewer). Best, Albert > Thank you! > > Best regards, > > > Zoltan > >> >> Thanks, >> Vladimir >> >> On 10/8/14 7:22 AM, Zolt?n Maj? wrote: >>> Hi David and Vladimir, >>> >>> >>> thank you for your feedback. >>> >>> On 10/07/2014 10:46 PM, Vladimir Kozlov wrote: >>>> On 10/7/14 11:06 AM, David Chase wrote: >>>> >>>>> Do we need to add a test (? what would it look like?) to ensure >>>>> that it works? >>>> >>>> Yes, please, add a regression test. >>> >>> I added a regression test >>> ('compiler/startup/CheckCompileCommandOption.java'). Here is the >>> updated webrev: >>> >>> http://cr.openjdk.java.net/~zmajo/8059847/webrev.01/ >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> David >>>>> >>>>> On 2014-10-07, at 1:53 PM, Zolt?n Maj? >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> please review the following small patch. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059847 >>>>>> >>>>>> Problem: CompileCommand=option does not support flags of type >>>>>> double. >>>>>> >>>>>> Solution: Add support for flags of type double. Output: >>>>>> >>>>>> java >>>>>> -XX:CompileCommand=option,Test::test,ccstrlist,MyListOption,_foo,_bar >>>>>> >>>>>> -XX:CompileCommand=option,Test::test,ccstr,MyStrOption,_foo >>>>>> -XX:CompileCommand=option,Test::test,bool,MyBoolOption,false >>>>>> -XX:CompileCommand=option,Test::test,intx,MyIntxOption,-1 >>>>>> -XX:CompileCommand=option,Test::test,uintx,MyUintxOption,1 >>>>>> -XX:CompileCommand=option,Test::test,MyFlag >>>>>> -XX:CompileCommand=option,Test::test,double,MyDoubleOption,1.123 >>>>>> -version >>>>>> >>>>>> CompilerOracle: option Test.test const char* MyListOption = '_foo >>>>>> _bar' >>>>>> CompilerOracle: option Test.test const char* MyStrOption = '_foo' >>>>>> CompilerOracle: option Test.test bool MyBoolOption = false >>>>>> CompilerOracle: option Test.test intx MyIntxOption = -1 >>>>>> CompilerOracle: option Test.test uintx MyUintxOption = 1 >>>>>> CompilerOracle: option Test.test bool MyFlag = true >>>>>> CompilerOracle: option Test.test double MyDoubleOption = '1.123000' >>>>>> java version "1.9.0-ea" >>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b33) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>> 1.9.0-fastdebug-internal, mixed mode) >>>>>> >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~zmajo/8059847/webrev.00/ >>>>>> >>>>>> Testing: JPRT >>>>>> >>>>>> Thank you and best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>> >>> > From zoltan.majo at oracle.com Fri Oct 10 07:32:58 2014 From: zoltan.majo at oracle.com (=?windows-1252?Q?Zolt=E1n_Maj=F3?=) Date: Fri, 10 Oct 2014 09:32:58 +0200 Subject: [9] RFR(S): 8059847: complement JDK-8055286 and JDK-8056964 changes In-Reply-To: <543788EB.8070000@oracle.com> References: <5434287C.6060204@oracle.com> <5434512B.9000307@oracle.com> <543548AC.7050300@oracle.com> <543557C8.6030709@oracle.com> <54364565.3050303@oracle.com> <543788EB.8070000@oracle.com> Message-ID: <54378BAA.80205@oracle.com> Hi Albert, thank you for the feedback! As this is a small change, I think we can push it with only one Reviewer's review. Best regards, Zoltan On 10/10/2014 09:21 AM, Albert Noll wrote: > Hi Zoltan, > > > On 10/09/2014 10:20 AM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> thank you for your feedback! >> >> On 10/08/2014 05:27 PM, Vladimir Kozlov wrote: >>> You don't need /othervm if there are no additional flags. >> >> OK, I removed it. >> >>> Instead of /startup/ I would suggest /oracle/ subdir name since we >>> testing code in compilerOracle. >> >> OK, I moved the test to the 'oracle' subdirectory. >> >>> 42 // Type (1) is used to check if a flag "someflag" is enabled >>> for a >>> 43 // method. >>> >>> I would say: >>> >>> 42 // Type (1) is used to enable a boolean flag for a method. >> >> I updated the comment in the test (and also in compilerOracle.cpp on >> line 732). >> >>> Should it be "bool,MyBoolOption,100"?: >>> >>> 135 // wrong value for bool flag >>> 136 "-XX:CompileCommand=option,Test::test,bool,MyBoolOption,intx,100", >> >> I changed the test to what you've suggested. >> >>> Same problem with next test which does not match the comment: >>> >>> 140 // intx flag name missing >>> 141 >>> "-XX:CompileCommand=option,Test::test,bool,MyBoolOption,false,intx,100", >>> >> >> I changed this test as well. >> >> I've also added three new tests to TYPE_2_INVALID_ARGUMENTS. The new >> tests are very similar to the ones in webrev.01. >> >>> Please, separate next checks to be clear which one is incorrect: >>> >>> 179 if (TYPE_1_ARGUMENTS.length != >>> TYPE_1_EXPECTED_OUTPUTS.length >>> 180 || TYPE_2_ARGUMENTS.length != >>> TYPE_2_EXPECTED_OUTPUTS.length) { >>> 181 throw new RuntimeException("Test is set up >>> incorrectly: length of arguments and expected outputs does not >>> match."); >>> 182 } >> >> I separated the checks and updated the error messages. >> >> Here is the new webrev: >> >> http://cr.openjdk.java.net/~zmajo/8059847/webrev.02/ >> > That looks good to me (not a reviewer). > > Best, > Albert > >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/8/14 7:22 AM, Zolt?n Maj? wrote: >>>> Hi David and Vladimir, >>>> >>>> >>>> thank you for your feedback. >>>> >>>> On 10/07/2014 10:46 PM, Vladimir Kozlov wrote: >>>>> On 10/7/14 11:06 AM, David Chase wrote: >>>>> >>>>>> Do we need to add a test (? what would it look like?) to ensure >>>>>> that it works? >>>>> >>>>> Yes, please, add a regression test. >>>> >>>> I added a regression test >>>> ('compiler/startup/CheckCompileCommandOption.java'). Here is the >>>> updated webrev: >>>> >>>> http://cr.openjdk.java.net/~zmajo/8059847/webrev.01/ >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> David >>>>>> >>>>>> On 2014-10-07, at 1:53 PM, Zolt?n Maj? >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> please review the following small patch. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059847 >>>>>>> >>>>>>> Problem: CompileCommand=option does not support flags of type >>>>>>> double. >>>>>>> >>>>>>> Solution: Add support for flags of type double. Output: >>>>>>> >>>>>>> java >>>>>>> -XX:CompileCommand=option,Test::test,ccstrlist,MyListOption,_foo,_bar >>>>>>> >>>>>>> -XX:CompileCommand=option,Test::test,ccstr,MyStrOption,_foo >>>>>>> -XX:CompileCommand=option,Test::test,bool,MyBoolOption,false >>>>>>> -XX:CompileCommand=option,Test::test,intx,MyIntxOption,-1 >>>>>>> -XX:CompileCommand=option,Test::test,uintx,MyUintxOption,1 >>>>>>> -XX:CompileCommand=option,Test::test,MyFlag >>>>>>> -XX:CompileCommand=option,Test::test,double,MyDoubleOption,1.123 >>>>>>> -version >>>>>>> >>>>>>> CompilerOracle: option Test.test const char* MyListOption = >>>>>>> '_foo _bar' >>>>>>> CompilerOracle: option Test.test const char* MyStrOption = '_foo' >>>>>>> CompilerOracle: option Test.test bool MyBoolOption = false >>>>>>> CompilerOracle: option Test.test intx MyIntxOption = -1 >>>>>>> CompilerOracle: option Test.test uintx MyUintxOption = 1 >>>>>>> CompilerOracle: option Test.test bool MyFlag = true >>>>>>> CompilerOracle: option Test.test double MyDoubleOption = '1.123000' >>>>>>> java version "1.9.0-ea" >>>>>>> Java(TM) SE Runtime Environment (build 1.9.0-ea-b33) >>>>>>> Java HotSpot(TM) 64-Bit Server VM (build >>>>>>> 1.9.0-fastdebug-internal, mixed mode) >>>>>>> >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~zmajo/8059847/webrev.00/ >>>>>>> >>>>>>> Testing: JPRT >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>> >>>> >> > From zoltan.majo at oracle.com Fri Oct 10 07:53:05 2014 From: zoltan.majo at oracle.com (=?windows-1252?Q?Zolt=E1n_Maj=F3?=) Date: Fri, 10 Oct 2014 09:53:05 +0200 Subject: [9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation) In-Reply-To: <2F9E5CC6-F48F-4250-8D78-5C1AC9BAB82C@oracle.com> References: <5433C140.9070400@oracle.com> <5433C6C6.20602@oracle.com> <5433EE7A.9060607@oracle.com> <0DBAED7F-65DF-4D15-AFDB-636DF7F70C16@oracle.com> <5436BB16.7010703@oracle.com> <2F9E5CC6-F48F-4250-8D78-5C1AC9BAB82C@oracle.com> Message-ID: <54379061.5070506@oracle.com> Thank you, Igor, for the review. Could somebody please provide a second Reviewer's review? I think the change is too large to be pushed with only one "Review". Thank you! Best regards, Zoltan On 10/09/2014 08:58 PM, Igor Veresov wrote: > That looks good to me. > > igor > > On Oct 9, 2014, at 9:43 AM, Zolt?n Maj? wrote: > >> Hi Igor, >> >> >> thank you for your feedback! >> >> On 10/07/2014 11:17 PM, Igor Veresov wrote: >>> 1. It would probably be nice not to do multiplications at every event but rather compute everything once during the startup. Perhaps it would be better to scale command line options right in arguments.cpp ? Or setup accessors in Arguments that would compute and cache the values. If you just scale the options the change would be smaller though. What do you think? >> That is a good idea. I changed the code to scale thresholds in arguments.cpp (in Arguments::apply_ergo()). >> >>> 2. Why aren?t you scaling Tier{2,3}{Invoke,Backedge}NotifyFreqLog and Tier23InlineeNotifyFreqLog? Probably can be solved by (1) automatically. >> The previous patch adjusts only the transition from Tier 0 to Tier 3 (when methods get first compiled). But now that you've suggested, I extended the patch to scale Tier4* compilation thresholds and Tier{2,3} notification thresholds as well. >> >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~zmajo/8059604/webrev.02/ >> >> I tested the new patch with JPRT and manual testing. >> >> Thank you and best regards, >> >> >> Zoltan >> >>> igor >>> >>> On Oct 7, 2014, at 6:45 AM, Zolt?n Maj? wrote: >>> >>>> Hi Albert, >>>> >>>> >>>> thank you for your feedback. >>>> >>>> On 10/07/2014 12:56 PM, Albert Noll wrote: >>>>> How about using a scaling factor instead of using percentage? >>>> I think that is a good idea because a scaling factor (expressed as a double) allows a finer-grained control of compilation thresholds than a scaling percentage (expressed as an integer). >>>> >>>> Here is the webrev with the scaling factor: >>>> >>>> http://cr.openjdk.java.net/~zmajo/8059604/webrev.01/ >>>> >>>> The name of the flag is changed to CompileThresholdScaling (from CompileThresholdScalingPercentage). >>>> >>>>> What happens if a threshold becomes 0 after scaling? >>>> Then all methods will be interpreted. That seems to be the convention (in src/share/vm/runtime/arguments.cpp). >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 10/07/2014 12:32 PM, Zolt?n Maj? wrote: >>>>>> Hi, >>>>>> >>>>>> >>>>>> please review the following patch. >>>>>> >>>>>> >>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8059604 >>>>>> >>>>>> >>>>>> Problem: With tiered compilation enabled, the value of 6 different thresholds must be set to control when the JVM compiles methods for the first time. That is too detailed for the average customer. >>>>>> >>>>>> >>>>>> Solution: This patch adds a new flag, CompileThresholdScalingPercentage, to control when methods are first compiled. The new flag scales thresholds the following way: >>>>>> >>>>>> - if CompileThresholdScalingPercentage==100, the default threshold values are used >>>>>> - if CompileThresholdScalingPercentage>100, threshold values are scaled up (e.g., CompileThresholdScalingPercentage=120 scales up thresholds by a factor of 1.2X) >>>>>> - if 0 < CompileThresholdScalingPercentage < 100, threshold values are scaled down accordingly. >>>>>> >>>>>> The new flag works both with and without tiered compilation. Thus, the new flag allows compilation to be controlled the same way both with and without tiered compilation: >>>>>> >>>>>> - with tiered compilation enabled, the value of the flags Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog, Tier3InvocationThreshold, Tier3MinInvocationThreshold, Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled >>>>>> >>>>>> - with tiered compilation disabled, the value of CompileThreshold is scaled >>>>>> >>>>>> Currently, tiered and non-tiered compilation treats threshold values slightly differently: For a threshold value of N and without tiered compilation enabled, methods are compiled *before* their Nth execution. With tiered compilation enabled, methods are compiled *after* the their Nth execution. >>>>>> >>>>>> The patch addresses the difference between tiered/non-tiered compilation: Methods are compiled right before their Nth execution in both cases (the non-tiered way). If CompileThresholdScalingPercentage==0, all methods are interpreted (similarly to the case when CompileThreshold==0). >>>>>> >>>>>> This patch is the second (out of three) parts of JDK-8050853 (adding support for per-compilation thresholds):https://bugs.openjdk.java.net/browse/JDK-8050853 . >>>>>> >>>>>> >>>>>> Webrev:http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/ >>>>>> >>>>>> >>>>>> Testing: JPRT, manual testing >>>>>> >>>>>> >>>>>> Thank you and best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> From nils.eliasson at oracle.com Fri Oct 10 09:01:53 2014 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 10 Oct 2014 11:01:53 +0200 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <5436465A.3080001@oracle.com> References: <5436465A.3080001@oracle.com> Message-ID: <5437A081.4060608@oracle.com> Hi, Albert Overall a very welcome change to move the sweeper into a separate thread. On 2014-10-09 10:24, Albert Noll wrote: > The patch also removes CodeCacheMinimumFreeSpace and 'critical' code > cache allocations. Due to a bug in > heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved for > 'critical' allocations. The following > lines produce an underflow if heap_unallocated_capacity() < > CodeCacheMinimumFreeSpace: > > segments_to_size(number_of_segments) > (heap_unallocated_capacity() - > CodeCacheMinimumFreeSpace) > > Since the critical part in the code cache was never used for its > intended purpose and we did not have problems > due to that, we can remove it. Are you sure? The reasons for the CodeCacheMinimumFreeSpace and critical allocations where problems with code cache fragmentation in long running applications, where small compilations would starve out the adaptors and cause VM shutdown. You won't see this other than in the really long running tests. It might be broken - but then we should open a bug and fix it. (And in the long run we should handle the fragmentation with relocating code.) Regards, //Nils From roland.westrelin at oracle.com Fri Oct 10 11:30:16 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 10 Oct 2014 13:30:16 +0200 Subject: RFR(XS): 8058746: escape analysis special case code for array copy broken by 7173584 In-Reply-To: <54341ACF.3000805@oracle.com> References: <834241B6-1DD9-45FE-AE17-614360C56B0A@oracle.com> <54341ACF.3000805@oracle.com> Message-ID: <38B41DBD-32EA-4EF2-B08E-4879248ED6ED@oracle.com> Thanks Vladimir, Vladimir and Igor for the reviews. Roland. On Oct 7, 2014, at 6:54 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 10/7/14, 12:36 PM, Roland Westrelin wrote: >> Change that introduced array copy macro nodes broke escape analysis support for array copies: >> >> http://cr.openjdk.java.net/~roland/8058746/webrev.00/ >> >> Roland. >> From roland.westrelin at oracle.com Fri Oct 10 12:07:00 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 10 Oct 2014 14:07:00 +0200 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: <5436FCF6.7080309@oracle.com> References: <5436E2C3.7060008@oracle.com> <5436FCF6.7080309@oracle.com> Message-ID: >>> Why you skip klasses with injected fields? I thought nof_nonstatic_fields() includes them. Add comment. >> >> I skip them because they are rare and it seems simpler to simply skip them. > > But you do the check (scanning all fields) for all classes. That is what I am concern about. May be it is better to add a flag to InstanceKlass during class parsing when fields are injected? The computation is done lazily when we actually need it and it?s only needed when there?s a clone so is it really such a big deal? >>> How we benefit from doing this optimization during parsing? Why you need StressArrayCopyMacroNode? >> >> It?s a stress option. The Ideal transformation is often applied at parse time and I wanted to make sure I could stress test the Ideal transformation during IGVN because it performs somewhat trickier graph transformations. Why would I need to make it diagnostic? > > My question was why not to do that always after parse, during IGVN? You expand arraycopy node to several memory nodes which increase nodes count and complicate the graph. It may be premature to do that during parsing. On other hand ClearArrayNode::Ideal() is executed during parsing too. If we wanted to delay that transformation, wouldn?t we also want a few passes of IGVN to happen before we do the transformation? Roland. From albert.noll at oracle.com Fri Oct 10 14:30:43 2014 From: albert.noll at oracle.com (Albert Noll) Date: Fri, 10 Oct 2014 16:30:43 +0200 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <5437A081.4060608@oracle.com> References: <5436465A.3080001@oracle.com> <5437A081.4060608@oracle.com> Message-ID: <5437ED93.6080806@oracle.com> Tobias, Vladimir, Dean, Nils, thanks for looking at the patch and for your feedback. @Tobias I have adapted your suggestions. @Vladimir I tried to add a condition to SafepointSynchronize::is_cleanup_needed() that returns 'true' if the code cache has less than 10% free space. Unfortunately, that does not fix the bug. A safepoint interval of 1000ms seems to be too coarse to free space in the code cache fast enough. It seems that the concept of critical memory allocations (allocations that must succeed for the VM to be able to continue to execute) is broken. For example, we need to compile method handle intrinsics (otherwise we get a java.lang.VirtualMachineError: out of space in CodeCache for method handle intrinsic). However, method handle intrinsic are not critical allocations. For this reason, test/compiler/startup/SmallCodeCacheStartup.java fails with a 32-bit client version. We will get a new nightly bug soon... The current patch fixes this. I want to keep the removal of critical allocations in this patch, since aggressive sweeping (enabled by the VM operation that forces stack scanning) replaces the concept of critical allocations in the code cache. I think these two changes belong together. If you still want me to, I will do a separate change for critical allocation removal. @Dean I removed the corresponding code. It was a fragment that I missed to delete. @Nils CodeCacheMinimumFreeSpace did not guarantee that the VM can continue to execute. In the failing test that is reported in the bug, 500K was not enough to generate all adapters. The test can be changed such that a CodeCacheMinimumFreeSpace size of 1m, 2m, 3m, etc. is too small too. What value should we choose? Also, as noted above, method handle intrinsic need to be compiled to be able to continue execution. Method handle intrinsic are currently not critical, so we must make them critical allocations. As a consequence, we must re-evaluate the default size of CodeCacheMinimumFreeSpace. The current approach enables very aggressive sweeping, if the code cache is 90% full. It is very likely that code will be flushed from the code cache in the next 5-10 invocations of CodeCache::allocate(). In a sense, the remaining 10% can be considered as a 'critical region' that is used as a 'buffer' until we free space in the code cache. This bug proves that the proposed strategy solves the problem better than CodeCacheMinimumFreeSpace. Maybe we should provide the user with control over this threshold, i.e., replace CodeCacheMinimumFreeSpace with a different command line flag that allows the user to specify the percentage (currently 90%) at which aggressive sweeping starts. We could also use a fixed-size. I don't think that having two thresholds (the threshold where we start aggressive sweeping AND CodeCacheMinimumFreeSpace) is necessary. What do you think? The performance runs show that waking up the sweeper thread for every allocation has a negative impact on startup time. To fix this, in the current patch, the sweeper thread is only woken up, if the code cache is more than 10% occupied. I will issue a new performance run and compare it against b34 (which includes the segmented code cache). Here is the new webrev: http://cr.openjdk.java.net/~anoll/8046809/webrev.03/ Best, Albert On 10/10/2014 11:01 AM, Nils Eliasson wrote: > Hi, Albert > > Overall a very welcome change to move the sweeper into a separate thread. > > On 2014-10-09 10:24, Albert Noll wrote: >> The patch also removes CodeCacheMinimumFreeSpace and 'critical' code >> cache allocations. Due to a bug in >> heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved for >> 'critical' allocations. The following >> lines produce an underflow if heap_unallocated_capacity() < >> CodeCacheMinimumFreeSpace: >> >> segments_to_size(number_of_segments) > (heap_unallocated_capacity() - >> CodeCacheMinimumFreeSpace) >> >> Since the critical part in the code cache was never used for its >> intended purpose and we did not have problems >> due to that, we can remove it. > > Are you sure? The reasons for the CodeCacheMinimumFreeSpace and > critical allocations where problems with code cache fragmentation in > long running applications, where small compilations would starve out > the adaptors and cause VM shutdown. You won't see this other than in > the really long running tests. It might be broken - but then we should > open a bug and fix it. (And in the long run we should handle the > fragmentation with relocating code.) > > Regards, > //Nils From vladimir.kozlov at oracle.com Fri Oct 10 16:57:59 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Oct 2014 09:57:59 -0700 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <5437ED93.6080806@oracle.com> References: <5436465A.3080001@oracle.com> <5437A081.4060608@oracle.com> <5437ED93.6080806@oracle.com> Message-ID: <54381017.6020809@oracle.com> On 10/10/14 7:30 AM, Albert Noll wrote: > Tobias, Vladimir, Dean, Nils, thanks for looking at the patch and for your feedback. > > @Tobias > I have adapted your suggestions. > > @Vladimir > I tried to add a condition to SafepointSynchronize::is_cleanup_needed() that returns 'true' if the code cache has less > than 10% free space. Unfortunately, that does not fix the bug. A safepoint interval of 1000ms seems to be too coarse > to free space in the code cache fast enough. Okay, thank you for trying. > > It seems that the concept of critical memory allocations (allocations that must succeed for the VM to be able to > continue to execute) is broken. For example, we need to compile method handle intrinsics (otherwise we get a > java.lang.VirtualMachineError: out of space in CodeCache for method handle intrinsic). However, method handle intrinsic > are not critical allocations. For this reason, test/compiler/startup/SmallCodeCacheStartup.java fails with a 32-bit client > version. We will get a new nightly bug soon... The current patch fixes this. > > I want to keep the removal of critical allocations in this patch, since aggressive sweeping (enabled by the VM > operation that forces stack scanning) replaces the concept of critical allocations in the code cache. I think > these two changes belong together. If you still want me to, I will do a separate change for critical allocation > removal. Okay, I am fine with this removal. > > @Dean > I removed the corresponding code. It was a fragment that I missed to delete. > > @Nils > CodeCacheMinimumFreeSpace did not guarantee that the VM can continue to execute. In the failing test > that is reported in the bug, 500K was not enough to generate all adapters. The test can be changed such > that a CodeCacheMinimumFreeSpace size of 1m, 2m, 3m, etc. is too small too. What value should we choose? > > Also, as noted above, method handle intrinsic need to be compiled to be able to continue execution. > Method handle intrinsic are currently not critical, so we must make them critical allocations. As a consequence, > we must re-evaluate the default size of CodeCacheMinimumFreeSpace. > > The current approach enables very aggressive sweeping, if the code cache is 90% full. It is very likely that code > will be flushed from the code cache in the next 5-10 invocations of CodeCache::allocate(). In a sense, the remaining > 10% can be considered as a 'critical region' that is used as a 'buffer' until we free space in the code cache. This bug > proves that the proposed strategy solves the problem better than CodeCacheMinimumFreeSpace. > > Maybe we should provide the user with control over this threshold, i.e., replace CodeCacheMinimumFreeSpace > with a different command line flag that allows the user to specify the percentage (currently 90%) at which aggressive Yes, it should be flag. I think it should be percentage. Thanks, Vladimir > sweeping starts. We could also use a fixed-size. I don't think that having two thresholds (the threshold where we start > aggressive sweeping AND CodeCacheMinimumFreeSpace) is necessary. > > What do you think? > > > > The performance runs show that waking up the sweeper thread for every allocation has a negative impact > on startup time. To fix this, in the current patch, the sweeper thread is only woken up, if the code cache is > more than 10% occupied. I will issue a new performance run and compare it against b34 (which includes > the segmented code cache). > > Here is the new webrev: > http://cr.openjdk.java.net/~anoll/8046809/webrev.03/ > > Best, > Albert > > > On 10/10/2014 11:01 AM, Nils Eliasson wrote: >> Hi, Albert >> >> Overall a very welcome change to move the sweeper into a separate thread. >> >> On 2014-10-09 10:24, Albert Noll wrote: >>> The patch also removes CodeCacheMinimumFreeSpace and 'critical' code cache allocations. Due to a bug in >>> heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved for 'critical' allocations. The following >>> lines produce an underflow if heap_unallocated_capacity() < CodeCacheMinimumFreeSpace: >>> >>> segments_to_size(number_of_segments) > (heap_unallocated_capacity() - CodeCacheMinimumFreeSpace) >>> >>> Since the critical part in the code cache was never used for its intended purpose and we did not have problems >>> due to that, we can remove it. >> >> Are you sure? The reasons for the CodeCacheMinimumFreeSpace and critical allocations where problems with code cache >> fragmentation in long running applications, where small compilations would starve out the adaptors and cause VM >> shutdown. You won't see this other than in the really long running tests. It might be broken - but then we should open >> a bug and fix it. (And in the long run we should handle the fragmentation with relocating code.) >> >> Regards, >> //Nils > From vladimir.kozlov at oracle.com Fri Oct 10 17:18:04 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Oct 2014 10:18:04 -0700 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: References: <5436E2C3.7060008@oracle.com> <5436FCF6.7080309@oracle.com> Message-ID: <543814CC.2080905@oracle.com> On 10/10/14 5:07 AM, Roland Westrelin wrote: >>>> Why you skip klasses with injected fields? I thought nof_nonstatic_fields() includes them. Add comment. >>> >>> I skip them because they are rare and it seems simpler to simply skip them. >> >> But you do the check (scanning all fields) for all classes. That is what I am concern about. May be it is better to add a flag to InstanceKlass during class parsing when fields are injected? > > The computation is done lazily when we actually need it and it?s only needed when there?s a clone so is it really such a big deal? Okay, at least swap ik->has_injected_fields() check in the condition to execute it last. > >>>> How we benefit from doing this optimization during parsing? Why you need StressArrayCopyMacroNode? >>> >>> It?s a stress option. The Ideal transformation is often applied at parse time and I wanted to make sure I could stress test the Ideal transformation during IGVN because it performs somewhat trickier graph transformations. Why would I need to make it diagnostic? >> >> My question was why not to do that always after parse, during IGVN? You expand arraycopy node to several memory nodes which increase nodes count and complicate the graph. It may be premature to do that during parsing. On other hand ClearArrayNode::Ideal() is executed during parsing too. > > If we wanted to delay that transformation, wouldn?t we also want a few passes of IGVN to happen before we do the transformation? The thing which can be improved is klass exactness. Which will allow to skip adding dependency. That is what I was thinking. But it may only happen after CCP phase. But I really want to do this optimization before EA which will greatly benefit from it. Also if klass is exact during parsing we may do optimization during parsing too. Vladimir > > Roland. > From roland.westrelin at oracle.com Fri Oct 10 17:47:10 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 10 Oct 2014 19:47:10 +0200 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: <543814CC.2080905@oracle.com> References: <5436E2C3.7060008@oracle.com> <5436FCF6.7080309@oracle.com> <543814CC.2080905@oracle.com> Message-ID: <5C32D21B-9A72-4367-A5F7-3C4FB2326FE0@oracle.com> >> If we wanted to delay that transformation, wouldn?t we also want a few passes of IGVN to happen before we do the transformation? > > The thing which can be improved is klass exactness. Which will allow to skip adding dependency. That is what I was thinking. But it may only happen after CCP phase. But I really want to do this optimization before EA which will greatly benefit from it. Also if klass is exact during parsing we may do optimization during parsing too. Ok. But I?m not sure if you?re suggesting a change or if it?s good as it is? Roland. From vladimir.kozlov at oracle.com Fri Oct 10 19:31:02 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Oct 2014 12:31:02 -0700 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: <5C32D21B-9A72-4367-A5F7-3C4FB2326FE0@oracle.com> References: <5436E2C3.7060008@oracle.com> <5436FCF6.7080309@oracle.com> <543814CC.2080905@oracle.com> <5C32D21B-9A72-4367-A5F7-3C4FB2326FE0@oracle.com> Message-ID: <543833F6.5050002@oracle.com> I was thinking aloud :) Changes are good as it is. Thank you for discussion. Thanks, Vladimir On 10/10/14 10:47 AM, Roland Westrelin wrote: >>> If we wanted to delay that transformation, wouldn?t we also want a few passes of IGVN to happen before we do the transformation? >> >> The thing which can be improved is klass exactness. Which will allow to skip adding dependency. That is what I was thinking. But it may only happen after CCP phase. But I really want to do this optimization before EA which will greatly benefit from it. Also if klass is exact during parsing we may do optimization during parsing too. > > Ok. But I?m not sure if you?re suggesting a change or if it?s good as it is? > > Roland. > From vladimir.kozlov at oracle.com Fri Oct 10 20:19:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Oct 2014 13:19:29 -0700 Subject: [9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation) In-Reply-To: <54379061.5070506@oracle.com> References: <5433C140.9070400@oracle.com> <5433C6C6.20602@oracle.com> <5433EE7A.9060607@oracle.com> <0DBAED7F-65DF-4D15-AFDB-636DF7F70C16@oracle.com> <5436BB16.7010703@oracle.com> <2F9E5CC6-F48F-4250-8D78-5C1AC9BAB82C@oracle.com> <54379061.5070506@oracle.com> Message-ID: <54383F51.3080500@oracle.com> Zoltan, Please, add test. There is -XX:+PrintFlagsFinal which will print all flags after all adjustments so you can verify that thresholds flags are correctly scaled. Check CompileThresholdScaling value corner cases too. Also I would like to see explicit casts to (intx) after multiplication. May be add an other Arguments method which do just multiplication by CompileThresholdScaling and cast to return intx. Thanks, Vladimir On 10/10/14 12:53 AM, Zolt?n Maj? wrote: > Thank you, Igor, for the review. > > Could somebody please provide a second Reviewer's review? I think the > change is too large to be pushed with only one "Review". > > Thank you! > > Best regards, > > > Zoltan > > On 10/09/2014 08:58 PM, Igor Veresov wrote: >> That looks good to me. >> >> igor >> >> On Oct 9, 2014, at 9:43 AM, Zolt?n Maj? wrote: >> >>> Hi Igor, >>> >>> >>> thank you for your feedback! >>> >>> On 10/07/2014 11:17 PM, Igor Veresov wrote: >>>> 1. It would probably be nice not to do multiplications at every >>>> event but rather compute everything once during the startup. Perhaps >>>> it would be better to scale command line options right in >>>> arguments.cpp ? Or setup accessors in Arguments that would compute >>>> and cache the values. If you just scale the options the change would >>>> be smaller though. What do you think? >>> That is a good idea. I changed the code to scale thresholds in >>> arguments.cpp (in Arguments::apply_ergo()). >>> >>>> 2. Why aren?t you scaling Tier{2,3}{Invoke,Backedge}NotifyFreqLog >>>> and Tier23InlineeNotifyFreqLog? Probably can be solved by (1) >>>> automatically. >>> The previous patch adjusts only the transition from Tier 0 to Tier 3 >>> (when methods get first compiled). But now that you've suggested, I >>> extended the patch to scale Tier4* compilation thresholds and >>> Tier{2,3} notification thresholds as well. >>> >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~zmajo/8059604/webrev.02/ >>> >>> I tested the new patch with JPRT and manual testing. >>> >>> Thank you and best regards, >>> >>> >>> Zoltan >>> >>>> igor >>>> >>>> On Oct 7, 2014, at 6:45 AM, Zolt?n Maj? wrote: >>>> >>>>> Hi Albert, >>>>> >>>>> >>>>> thank you for your feedback. >>>>> >>>>> On 10/07/2014 12:56 PM, Albert Noll wrote: >>>>>> How about using a scaling factor instead of using percentage? >>>>> I think that is a good idea because a scaling factor (expressed as >>>>> a double) allows a finer-grained control of compilation thresholds >>>>> than a scaling percentage (expressed as an integer). >>>>> >>>>> Here is the webrev with the scaling factor: >>>>> >>>>> http://cr.openjdk.java.net/~zmajo/8059604/webrev.01/ >>>>> >>>>> The name of the flag is changed to CompileThresholdScaling (from >>>>> CompileThresholdScalingPercentage). >>>>> >>>>>> What happens if a threshold becomes 0 after scaling? >>>>> Then all methods will be interpreted. That seems to be the >>>>> convention (in src/share/vm/runtime/arguments.cpp). >>>>> >>>>> Best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> >>>>>> On 10/07/2014 12:32 PM, Zolt?n Maj? wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> please review the following patch. >>>>>>> >>>>>>> >>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8059604 >>>>>>> >>>>>>> >>>>>>> Problem: With tiered compilation enabled, the value of 6 >>>>>>> different thresholds must be set to control when the JVM compiles >>>>>>> methods for the first time. That is too detailed for the average >>>>>>> customer. >>>>>>> >>>>>>> >>>>>>> Solution: This patch adds a new flag, >>>>>>> CompileThresholdScalingPercentage, to control when methods are >>>>>>> first compiled. The new flag scales thresholds the following way: >>>>>>> >>>>>>> - if CompileThresholdScalingPercentage==100, the default >>>>>>> threshold values are used >>>>>>> - if CompileThresholdScalingPercentage>100, threshold values are >>>>>>> scaled up (e.g., CompileThresholdScalingPercentage=120 scales up >>>>>>> thresholds by a factor of 1.2X) >>>>>>> - if 0 < CompileThresholdScalingPercentage < 100, threshold >>>>>>> values are scaled down accordingly. >>>>>>> >>>>>>> The new flag works both with and without tiered compilation. >>>>>>> Thus, the new flag allows compilation to be controlled the same >>>>>>> way both with and without tiered compilation: >>>>>>> >>>>>>> - with tiered compilation enabled, the value of the flags >>>>>>> Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog, >>>>>>> Tier3InvocationThreshold, Tier3MinInvocationThreshold, >>>>>>> Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled >>>>>>> >>>>>>> - with tiered compilation disabled, the value of CompileThreshold >>>>>>> is scaled >>>>>>> >>>>>>> Currently, tiered and non-tiered compilation treats threshold >>>>>>> values slightly differently: For a threshold value of N and >>>>>>> without tiered compilation enabled, methods are compiled *before* >>>>>>> their Nth execution. With tiered compilation enabled, methods are >>>>>>> compiled *after* the their Nth execution. >>>>>>> >>>>>>> The patch addresses the difference between tiered/non-tiered >>>>>>> compilation: Methods are compiled right before their Nth >>>>>>> execution in both cases (the non-tiered way). If >>>>>>> CompileThresholdScalingPercentage==0, all methods are interpreted >>>>>>> (similarly to the case when CompileThreshold==0). >>>>>>> >>>>>>> This patch is the second (out of three) parts of JDK-8050853 >>>>>>> (adding support for per-compilation >>>>>>> thresholds):https://bugs.openjdk.java.net/browse/JDK-8050853 . >>>>>>> >>>>>>> >>>>>>> Webrev:http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Testing: JPRT, manual testing >>>>>>> >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> > From vladimir.kozlov at oracle.com Fri Oct 10 22:14:44 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Oct 2014 15:14:44 -0700 Subject: [9] RFR (XS) 8059139: It should be possible to explicitly disable usage of TZCNT instr w/ -XX:-UseBMI1Instructions Message-ID: <54385A54.3000008@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8059139 http://cr.openjdk.java.net/~kvn/8059139/webrev/ Before JDK-8055494 it was possible to disable usage of all BMI1-related instructions by passing -XX:-UseBMI1Instructions to JVM, but fix for JDK-8055494 made it impossible to disable usage of TZCNT. Disable TZCNT with -XX:-UseBMI1Instructions flag specified on command line. Testing jtreg,jprt From vladimir.kozlov at oracle.com Fri Oct 10 23:41:06 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Oct 2014 16:41:06 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code Message-ID: <54386E92.3000006@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8054492 http://cr.openjdk.java.net/~kvn/8054492/webrev/ Thanks to Roland for the evaluation of this problem. Class.cast has an explicit null check: public T cast(Object obj) { if (obj != null && !isInstance(obj)) throw new ClassCastException(cannotCastMsg(obj)); return (T) obj; } Compiler generates null check and uncommon trap when it did not see null values in profiled data. In most cases when Class.cast is inlined isInstance() is folded and as result compiled code is looks like: if (obj != null) { return obj; } else { uncommon_trap(); // which triggers deoptimization and Interpreter // will execute the same 'return obj;' code. } The same result you will get with next compiled code. So the null check is noop and will be removed from compiled code (it is the goal of this change): if (obj != null) { } return obj; Even if isInstance() is not folded we don't need to generate uncommon trap for obj == null case: if (obj != null) { if (!isInstance(obj)) { uncommon_trap(); // or throw code } } return obj; One benefit from having uncommon trap is it could be converted to implicit null check by folding it into a following memory instruction (load or store). In Class.cast() we don't have such memory instruction so we don't benefit from uncommon trap. The fix is rise probability of not-taken path to avoid generation of uncommon trap when processing ifnull bytecode in Class.cast method. Tested with JPRT, jtreg Thanks, Vladimir From vladimir.kozlov at oracle.com Sat Oct 11 03:41:32 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Oct 2014 20:41:32 -0700 Subject: [9] RFR(M) 8041984: CompilerThread seems to occupy all CPU in a very rare situation Message-ID: <5438A6EC.8000302@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8041984 http://cr.openjdk.java.net/~kvn/8041984/webrev/ Next method puts C2's EA to its knees: com.graphhopper.coll.GHLongIntBTree$BTreeEntry::put() https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/coll/GHLongIntBTree.java It shows that current EA connection graph build code is very inefficient when a graph has a lot of connections (edges). With inlining the BTreeEntry::put() method has about 100 allocations from which about 80 are arrays allocations. Most of them are object arrays which are generated by Arrays.copyOf(). After number of edges in EA Connection Graph reaches about 50000 it takes more then 1 sec to find all nodes which reference an allocation. Current EA code has bailout by timeout from graph building code. But the timeout (30 sec for product VM) is checked only after all object nodes are processed. So it may take > 2 mins before EA is aborted: Also ConnectionGraph::add_java_object_edges() method does not check the presence of a node when it adds new one to the worklist (in add_to_worklist() method). Which leads to hundreds MB of used by EA memory when BTreeEntry::put() is processed. To address issues new timeout checks were added. New _pidx index field is added to graph's nodes and VectorSet is used to reduce size of worklist in add_java_object_edges() method. Escaping node CreateEx is mapped phantom_obj to reduce number of process objects in connection graph. We do the same for other escaping objects. Tested with graphhopper server application: Thanks, Vladimir From aleksey.shipilev at oracle.com Sat Oct 11 06:38:55 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sat, 11 Oct 2014 10:38:55 +0400 Subject: [9] RFR(M) 8041984: CompilerThread seems to occupy all CPU in a very rare situation In-Reply-To: <5438A6EC.8000302@oracle.com> References: <5438A6EC.8000302@oracle.com> Message-ID: <5438D07F.2060208@oracle.com> I remember chasing the similar issue here: https://bugs.openjdk.java.net/browse/JDK-8057127 ...but never got a chance to pinpoint the actual method that causes EA to explode. I will take a look again once your fix is committed. -Aleksey. On 11.10.2014 07:41, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8041984 > http://cr.openjdk.java.net/~kvn/8041984/webrev/ > > Next method puts C2's EA to its knees: > > com.graphhopper.coll.GHLongIntBTree$BTreeEntry::put() > > https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/coll/GHLongIntBTree.java > > > It shows that current EA connection graph build code is very inefficient > when a graph has a lot of connections (edges). > > With inlining the BTreeEntry::put() method has about 100 allocations > from which about 80 are arrays allocations. Most of them are object > arrays which are generated by Arrays.copyOf(). After number of edges in > EA Connection Graph reaches about 50000 it takes more then 1 sec to find > all nodes which reference an allocation. > > Current EA code has bailout by timeout from graph building code. But the > timeout (30 sec for product VM) is checked only after all object nodes > are processed. So it may take > 2 mins before EA is aborted: > > > > stamp='150.967'/> > > Also ConnectionGraph::add_java_object_edges() method does not check the > presence of a node when it adds new one to the worklist (in > add_to_worklist() method). Which leads to hundreds MB of used by EA > memory when BTreeEntry::put() is processed. > > To address issues new timeout checks were added. > New _pidx index field is added to graph's nodes and VectorSet is used to > reduce size of worklist in add_java_object_edges() method. > > Escaping node CreateEx is mapped phantom_obj to reduce number of process > objects in connection graph. We do the same for other escaping objects. > > Tested with graphhopper server application: > > > > stamp='22.355'/> > > Thanks, > Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From aleksey.shipilev at oracle.com Mon Oct 13 10:39:55 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 13 Oct 2014 12:39:55 +0200 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: References: Message-ID: <543BABFB.30101@oracle.com> On 08.10.2014 14:33, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/6700100/webrev.00/ The rationale in JBS issue looks good. https://bugs.openjdk.java.net/browse/JDK-6700100 Any reason why you chosen 8 as the threshold value? Any benchmarking involved? Do you need one? > Converts ArrayCopy nodes for small instance clones to series of > loads/stores + a little bit of cleanup. > > Small array clones & copies as loads/stores are coming next in > another change. -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Mon Oct 13 13:02:00 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 13 Oct 2014 15:02:00 +0200 Subject: [9] RFR(S): 8060196: CodeHeap for 'non-nmethods' is full Message-ID: <543BCD48.5080508@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8060196 Webrev: http://cr.openjdk.java.net/~thartmann/8060196/webrev.00/ Problem: CodeCache::is_full() returns true if the non-nmethod code heap is full but we can still store non-nmethod code in the non-profiled code heap and therefore should not disable compilation (see comment 'fallback solution' in CodeCache::allocate). Solution: Adapt CodeCache::is_full() to not check the non-nmethod code heap. I also fixed the CodeHeap is full warning to suggest increasing the non-profiled code heap. Thanks, Tobias From albert.noll at oracle.com Mon Oct 13 14:34:16 2014 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 13 Oct 2014 16:34:16 +0200 Subject: [9] RFR(S): 8060196: CodeHeap for 'non-nmethods' is full In-Reply-To: <543BCD48.5080508@oracle.com> References: <543BCD48.5080508@oracle.com> Message-ID: <543BE2E8.50704@oracle.com> Hi Tobias, 8046809 (which is currently under review) removes that check. Does removing the check fix the bug? Best, Albert On 10/13/2014 03:02 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8060196 > Webrev: http://cr.openjdk.java.net/~thartmann/8060196/webrev.00/ > > Problem: > CodeCache::is_full() returns true if the non-nmethod code heap is full > but we can still store non-nmethod code in the non-profiled code heap > and therefore should not disable compilation (see comment 'fallback > solution' in CodeCache::allocate). > > Solution: > Adapt CodeCache::is_full() to not check the non-nmethod code heap. I > also fixed the CodeHeap is full warning to suggest increasing the > non-profiled code heap. > > Thanks, > Tobias From albert.noll at oracle.com Mon Oct 13 14:55:32 2014 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 13 Oct 2014 16:55:32 +0200 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <54381017.6020809@oracle.com> References: <5436465A.3080001@oracle.com> <5437A081.4060608@oracle.com> <5437ED93.6080806@oracle.com> <54381017.6020809@oracle.com> Message-ID: <543BE7E4.6040203@oracle.com> Hi Vladimir, thanks for the feedback. Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8046809/webrev.04/ Best, Albert On 10/10/2014 06:57 PM, Vladimir Kozlov wrote: > On 10/10/14 7:30 AM, Albert Noll wrote: >> Tobias, Vladimir, Dean, Nils, thanks for looking at the patch and for >> your feedback. >> >> @Tobias >> I have adapted your suggestions. >> >> @Vladimir >> I tried to add a condition to >> SafepointSynchronize::is_cleanup_needed() that returns 'true' if the >> code cache has less >> than 10% free space. Unfortunately, that does not fix the bug. A >> safepoint interval of 1000ms seems to be too coarse >> to free space in the code cache fast enough. > > Okay, thank you for trying. > >> >> It seems that the concept of critical memory allocations (allocations >> that must succeed for the VM to be able to >> continue to execute) is broken. For example, we need to compile >> method handle intrinsics (otherwise we get a >> java.lang.VirtualMachineError: out of space in CodeCache for method >> handle intrinsic). However, method handle intrinsic >> are not critical allocations. For this reason, >> test/compiler/startup/SmallCodeCacheStartup.java fails with a 32-bit >> client >> version. We will get a new nightly bug soon... The current patch >> fixes this. >> >> I want to keep the removal of critical allocations in this patch, >> since aggressive sweeping (enabled by the VM >> operation that forces stack scanning) replaces the concept of >> critical allocations in the code cache. I think >> these two changes belong together. If you still want me to, I will do >> a separate change for critical allocation >> removal. > > Okay, I am fine with this removal. > >> >> @Dean >> I removed the corresponding code. It was a fragment that I missed to >> delete. >> >> @Nils >> CodeCacheMinimumFreeSpace did not guarantee that the VM can continue >> to execute. In the failing test >> that is reported in the bug, 500K was not enough to generate all >> adapters. The test can be changed such >> that a CodeCacheMinimumFreeSpace size of 1m, 2m, 3m, etc. is too >> small too. What value should we choose? >> >> Also, as noted above, method handle intrinsic need to be compiled to >> be able to continue execution. >> Method handle intrinsic are currently not critical, so we must make >> them critical allocations. As a consequence, >> we must re-evaluate the default size of CodeCacheMinimumFreeSpace. >> >> The current approach enables very aggressive sweeping, if the code >> cache is 90% full. It is very likely that code >> will be flushed from the code cache in the next 5-10 invocations of >> CodeCache::allocate(). In a sense, the remaining >> 10% can be considered as a 'critical region' that is used as a >> 'buffer' until we free space in the code cache. This bug >> proves that the proposed strategy solves the problem better than >> CodeCacheMinimumFreeSpace. >> >> Maybe we should provide the user with control over this threshold, >> i.e., replace CodeCacheMinimumFreeSpace >> with a different command line flag that allows the user to specify >> the percentage (currently 90%) at which aggressive > > Yes, it should be flag. I think it should be percentage. > > Thanks, > Vladimir > >> sweeping starts. We could also use a fixed-size. I don't think that >> having two thresholds (the threshold where we start >> aggressive sweeping AND CodeCacheMinimumFreeSpace) is necessary. > >> >> What do you think? >> >> >> >> The performance runs show that waking up the sweeper thread for every >> allocation has a negative impact >> on startup time. To fix this, in the current patch, the sweeper >> thread is only woken up, if the code cache is >> more than 10% occupied. I will issue a new performance run and >> compare it against b34 (which includes >> the segmented code cache). >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~anoll/8046809/webrev.03/ >> >> Best, >> Albert >> >> >> On 10/10/2014 11:01 AM, Nils Eliasson wrote: >>> Hi, Albert >>> >>> Overall a very welcome change to move the sweeper into a separate >>> thread. >>> >>> On 2014-10-09 10:24, Albert Noll wrote: >>>> The patch also removes CodeCacheMinimumFreeSpace and 'critical' >>>> code cache allocations. Due to a bug in >>>> heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved >>>> for 'critical' allocations. The following >>>> lines produce an underflow if heap_unallocated_capacity() < >>>> CodeCacheMinimumFreeSpace: >>>> >>>> segments_to_size(number_of_segments) > (heap_unallocated_capacity() >>>> - CodeCacheMinimumFreeSpace) >>>> >>>> Since the critical part in the code cache was never used for its >>>> intended purpose and we did not have problems >>>> due to that, we can remove it. >>> >>> Are you sure? The reasons for the CodeCacheMinimumFreeSpace and >>> critical allocations where problems with code cache >>> fragmentation in long running applications, where small compilations >>> would starve out the adaptors and cause VM >>> shutdown. You won't see this other than in the really long running >>> tests. It might be broken - but then we should open >>> a bug and fix it. (And in the long run we should handle the >>> fragmentation with relocating code.) >>> >>> Regards, >>> //Nils >> From tobias.hartmann at oracle.com Mon Oct 13 14:57:20 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 13 Oct 2014 16:57:20 +0200 Subject: [9] RFR(S): 8060196: CodeHeap for 'non-nmethods' is full In-Reply-To: <543BE2E8.50704@oracle.com> References: <543BCD48.5080508@oracle.com> <543BE2E8.50704@oracle.com> Message-ID: <543BE850.5020303@oracle.com> Hi Albert, On 13.10.2014 16:34, Albert Noll wrote: > Hi Tobias, > > 8046809 (which is currently under review) removes that check. Does removing the > check fix the bug? Yes, but the output (see 'CodeCache::report_codemem_full') is still wrong. Do you think I should only fix the output and wait for your fix to remove the 'is_full' check? Thanks, Tobias > Best, > Albert > > On 10/13/2014 03:02 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8060196 >> Webrev: http://cr.openjdk.java.net/~thartmann/8060196/webrev.00/ >> >> Problem: >> CodeCache::is_full() returns true if the non-nmethod code heap is full but we >> can still store non-nmethod code in the non-profiled code heap and therefore >> should not disable compilation (see comment 'fallback solution' in >> CodeCache::allocate). >> >> Solution: >> Adapt CodeCache::is_full() to not check the non-nmethod code heap. I also >> fixed the CodeHeap is full warning to suggest increasing the non-profiled code >> heap. >> >> Thanks, >> Tobias > From albert.noll at oracle.com Mon Oct 13 15:02:14 2014 From: albert.noll at oracle.com (Albert Noll) Date: Mon, 13 Oct 2014 17:02:14 +0200 Subject: [9] RFR(S): 8060196: CodeHeap for 'non-nmethods' is full In-Reply-To: <543BE850.5020303@oracle.com> References: <543BCD48.5080508@oracle.com> <543BE2E8.50704@oracle.com> <543BE850.5020303@oracle.com> Message-ID: <543BE976.1070303@oracle.com> Hi Tobias, I would wait until 8046809 is reviewed. Doing modifications to a function that is being discussed to remove does not make sense. Best, Albert On 10/13/2014 04:57 PM, Tobias Hartmann wrote: > Hi Albert, > > On 13.10.2014 16:34, Albert Noll wrote: >> Hi Tobias, >> >> 8046809 (which is currently under review) removes that check. Does >> removing the >> check fix the bug? > > Yes, but the output (see 'CodeCache::report_codemem_full') is still > wrong. Do you think I should only fix the output and wait for your fix > to remove the 'is_full' check? > > Thanks, > Tobias > >> Best, >> Albert >> >> On 10/13/2014 03:02 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060196 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8060196/webrev.00/ >>> >>> Problem: >>> CodeCache::is_full() returns true if the non-nmethod code heap is >>> full but we >>> can still store non-nmethod code in the non-profiled code heap and >>> therefore >>> should not disable compilation (see comment 'fallback solution' in >>> CodeCache::allocate). >>> >>> Solution: >>> Adapt CodeCache::is_full() to not check the non-nmethod code heap. I >>> also >>> fixed the CodeHeap is full warning to suggest increasing the >>> non-profiled code >>> heap. >>> >>> Thanks, >>> Tobias >> From vladimir.kozlov at oracle.com Tue Oct 14 02:00:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 13 Oct 2014 19:00:24 -0700 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <543BE7E4.6040203@oracle.com> References: <5436465A.3080001@oracle.com> <5437A081.4060608@oracle.com> <5437ED93.6080806@oracle.com> <54381017.6020809@oracle.com> <543BE7E4.6040203@oracle.com> Message-ID: <543C83B8.5050003@oracle.com> Looks good but you need to wait CCC approval for product flags removal. And you need to add them to obsolete_jvm_flags table in arguments.cpp. Thanks, Vladimir On 10/13/14 7:55 AM, Albert Noll wrote: > Hi Vladimir, > > thanks for the feedback. Here is the updated webrev: > > http://cr.openjdk.java.net/~anoll/8046809/webrev.04/ > > Best, > Albert > > On 10/10/2014 06:57 PM, Vladimir Kozlov wrote: >> On 10/10/14 7:30 AM, Albert Noll wrote: >>> Tobias, Vladimir, Dean, Nils, thanks for looking at the patch and for your feedback. >>> >>> @Tobias >>> I have adapted your suggestions. >>> >>> @Vladimir >>> I tried to add a condition to SafepointSynchronize::is_cleanup_needed() that returns 'true' if the code cache has less >>> than 10% free space. Unfortunately, that does not fix the bug. A safepoint interval of 1000ms seems to be too coarse >>> to free space in the code cache fast enough. >> >> Okay, thank you for trying. >> >>> >>> It seems that the concept of critical memory allocations (allocations that must succeed for the VM to be able to >>> continue to execute) is broken. For example, we need to compile method handle intrinsics (otherwise we get a >>> java.lang.VirtualMachineError: out of space in CodeCache for method handle intrinsic). However, method handle intrinsic >>> are not critical allocations. For this reason, test/compiler/startup/SmallCodeCacheStartup.java fails with a 32-bit >>> client >>> version. We will get a new nightly bug soon... The current patch fixes this. >>> >>> I want to keep the removal of critical allocations in this patch, since aggressive sweeping (enabled by the VM >>> operation that forces stack scanning) replaces the concept of critical allocations in the code cache. I think >>> these two changes belong together. If you still want me to, I will do a separate change for critical allocation >>> removal. >> >> Okay, I am fine with this removal. >> >>> >>> @Dean >>> I removed the corresponding code. It was a fragment that I missed to delete. >>> >>> @Nils >>> CodeCacheMinimumFreeSpace did not guarantee that the VM can continue to execute. In the failing test >>> that is reported in the bug, 500K was not enough to generate all adapters. The test can be changed such >>> that a CodeCacheMinimumFreeSpace size of 1m, 2m, 3m, etc. is too small too. What value should we choose? >>> >>> Also, as noted above, method handle intrinsic need to be compiled to be able to continue execution. >>> Method handle intrinsic are currently not critical, so we must make them critical allocations. As a consequence, >>> we must re-evaluate the default size of CodeCacheMinimumFreeSpace. >>> >>> The current approach enables very aggressive sweeping, if the code cache is 90% full. It is very likely that code >>> will be flushed from the code cache in the next 5-10 invocations of CodeCache::allocate(). In a sense, the remaining >>> 10% can be considered as a 'critical region' that is used as a 'buffer' until we free space in the code cache. This bug >>> proves that the proposed strategy solves the problem better than CodeCacheMinimumFreeSpace. >>> >>> Maybe we should provide the user with control over this threshold, i.e., replace CodeCacheMinimumFreeSpace >>> with a different command line flag that allows the user to specify the percentage (currently 90%) at which aggressive >> >> Yes, it should be flag. I think it should be percentage. >> >> Thanks, >> Vladimir >> >>> sweeping starts. We could also use a fixed-size. I don't think that having two thresholds (the threshold where we start >>> aggressive sweeping AND CodeCacheMinimumFreeSpace) is necessary. >> >>> >>> What do you think? >>> >>> >>> >>> The performance runs show that waking up the sweeper thread for every allocation has a negative impact >>> on startup time. To fix this, in the current patch, the sweeper thread is only woken up, if the code cache is >>> more than 10% occupied. I will issue a new performance run and compare it against b34 (which includes >>> the segmented code cache). >>> >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~anoll/8046809/webrev.03/ >>> >>> Best, >>> Albert >>> >>> >>> On 10/10/2014 11:01 AM, Nils Eliasson wrote: >>>> Hi, Albert >>>> >>>> Overall a very welcome change to move the sweeper into a separate thread. >>>> >>>> On 2014-10-09 10:24, Albert Noll wrote: >>>>> The patch also removes CodeCacheMinimumFreeSpace and 'critical' code cache allocations. Due to a bug in >>>>> heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved for 'critical' allocations. The following >>>>> lines produce an underflow if heap_unallocated_capacity() < CodeCacheMinimumFreeSpace: >>>>> >>>>> segments_to_size(number_of_segments) > (heap_unallocated_capacity() - CodeCacheMinimumFreeSpace) >>>>> >>>>> Since the critical part in the code cache was never used for its intended purpose and we did not have problems >>>>> due to that, we can remove it. >>>> >>>> Are you sure? The reasons for the CodeCacheMinimumFreeSpace and critical allocations where problems with code cache >>>> fragmentation in long running applications, where small compilations would starve out the adaptors and cause VM >>>> shutdown. You won't see this other than in the really long running tests. It might be broken - but then we should open >>>> a bug and fix it. (And in the long run we should handle the fragmentation with relocating code.) >>>> >>>> Regards, >>>> //Nils >>> > From tobias.hartmann at oracle.com Tue Oct 14 07:55:13 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 14 Oct 2014 09:55:13 +0200 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock Message-ID: <543CD6E1.3090305@oracle.com> Hi, please review this small code cleanup that replaces the explicit locking of OsrList_lock by a MutexLockerEx instantiation. Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ Thanks, Tobias From albert.noll at oracle.com Tue Oct 14 08:03:45 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 14 Oct 2014 10:03:45 +0200 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <543C83B8.5050003@oracle.com> References: <5436465A.3080001@oracle.com> <5437A081.4060608@oracle.com> <5437ED93.6080806@oracle.com> <54381017.6020809@oracle.com> <543BE7E4.6040203@oracle.com> <543C83B8.5050003@oracle.com> Message-ID: <543CD8E1.6050303@oracle.com> Hi Vladimir, I filed a CCC request and added the 3 removed flags to the obsolete_jvm_flags table. Here is the updated webrev: http://cr.openjdk.java.net/~anoll/8046809/webrev.05/ Thanks, Albert On 10/14/2014 04:00 AM, Vladimir Kozlov wrote: > Looks good but you need to wait CCC approval for product flags removal. > And you need to add them to obsolete_jvm_flags table in arguments.cpp. > > Thanks, > Vladimir > > On 10/13/14 7:55 AM, Albert Noll wrote: >> Hi Vladimir, >> >> thanks for the feedback. Here is the updated webrev: >> >> http://cr.openjdk.java.net/~anoll/8046809/webrev.04/ >> >> Best, >> Albert >> >> On 10/10/2014 06:57 PM, Vladimir Kozlov wrote: >>> On 10/10/14 7:30 AM, Albert Noll wrote: >>>> Tobias, Vladimir, Dean, Nils, thanks for looking at the patch and >>>> for your feedback. >>>> >>>> @Tobias >>>> I have adapted your suggestions. >>>> >>>> @Vladimir >>>> I tried to add a condition to >>>> SafepointSynchronize::is_cleanup_needed() that returns 'true' if >>>> the code cache has less >>>> than 10% free space. Unfortunately, that does not fix the bug. A >>>> safepoint interval of 1000ms seems to be too coarse >>>> to free space in the code cache fast enough. >>> >>> Okay, thank you for trying. >>> >>>> >>>> It seems that the concept of critical memory allocations >>>> (allocations that must succeed for the VM to be able to >>>> continue to execute) is broken. For example, we need to compile >>>> method handle intrinsics (otherwise we get a >>>> java.lang.VirtualMachineError: out of space in CodeCache for method >>>> handle intrinsic). However, method handle intrinsic >>>> are not critical allocations. For this reason, >>>> test/compiler/startup/SmallCodeCacheStartup.java fails with a 32-bit >>>> client >>>> version. We will get a new nightly bug soon... The current patch >>>> fixes this. >>>> >>>> I want to keep the removal of critical allocations in this patch, >>>> since aggressive sweeping (enabled by the VM >>>> operation that forces stack scanning) replaces the concept of >>>> critical allocations in the code cache. I think >>>> these two changes belong together. If you still want me to, I will >>>> do a separate change for critical allocation >>>> removal. >>> >>> Okay, I am fine with this removal. >>> >>>> >>>> @Dean >>>> I removed the corresponding code. It was a fragment that I missed >>>> to delete. >>>> >>>> @Nils >>>> CodeCacheMinimumFreeSpace did not guarantee that the VM can >>>> continue to execute. In the failing test >>>> that is reported in the bug, 500K was not enough to generate all >>>> adapters. The test can be changed such >>>> that a CodeCacheMinimumFreeSpace size of 1m, 2m, 3m, etc. is too >>>> small too. What value should we choose? >>>> >>>> Also, as noted above, method handle intrinsic need to be compiled >>>> to be able to continue execution. >>>> Method handle intrinsic are currently not critical, so we must make >>>> them critical allocations. As a consequence, >>>> we must re-evaluate the default size of CodeCacheMinimumFreeSpace. >>>> >>>> The current approach enables very aggressive sweeping, if the code >>>> cache is 90% full. It is very likely that code >>>> will be flushed from the code cache in the next 5-10 invocations of >>>> CodeCache::allocate(). In a sense, the remaining >>>> 10% can be considered as a 'critical region' that is used as a >>>> 'buffer' until we free space in the code cache. This bug >>>> proves that the proposed strategy solves the problem better than >>>> CodeCacheMinimumFreeSpace. >>>> >>>> Maybe we should provide the user with control over this threshold, >>>> i.e., replace CodeCacheMinimumFreeSpace >>>> with a different command line flag that allows the user to specify >>>> the percentage (currently 90%) at which aggressive >>> >>> Yes, it should be flag. I think it should be percentage. >>> >>> Thanks, >>> Vladimir >>> >>>> sweeping starts. We could also use a fixed-size. I don't think that >>>> having two thresholds (the threshold where we start >>>> aggressive sweeping AND CodeCacheMinimumFreeSpace) is necessary. >>> >>>> >>>> What do you think? >>>> >>>> >>>> >>>> The performance runs show that waking up the sweeper thread for >>>> every allocation has a negative impact >>>> on startup time. To fix this, in the current patch, the sweeper >>>> thread is only woken up, if the code cache is >>>> more than 10% occupied. I will issue a new performance run and >>>> compare it against b34 (which includes >>>> the segmented code cache). >>>> >>>> Here is the new webrev: >>>> http://cr.openjdk.java.net/~anoll/8046809/webrev.03/ >>>> >>>> Best, >>>> Albert >>>> >>>> >>>> On 10/10/2014 11:01 AM, Nils Eliasson wrote: >>>>> Hi, Albert >>>>> >>>>> Overall a very welcome change to move the sweeper into a separate >>>>> thread. >>>>> >>>>> On 2014-10-09 10:24, Albert Noll wrote: >>>>>> The patch also removes CodeCacheMinimumFreeSpace and 'critical' >>>>>> code cache allocations. Due to a bug in >>>>>> heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved >>>>>> for 'critical' allocations. The following >>>>>> lines produce an underflow if heap_unallocated_capacity() < >>>>>> CodeCacheMinimumFreeSpace: >>>>>> >>>>>> segments_to_size(number_of_segments) > >>>>>> (heap_unallocated_capacity() - CodeCacheMinimumFreeSpace) >>>>>> >>>>>> Since the critical part in the code cache was never used for its >>>>>> intended purpose and we did not have problems >>>>>> due to that, we can remove it. >>>>> >>>>> Are you sure? The reasons for the CodeCacheMinimumFreeSpace and >>>>> critical allocations where problems with code cache >>>>> fragmentation in long running applications, where small >>>>> compilations would starve out the adaptors and cause VM >>>>> shutdown. You won't see this other than in the really long running >>>>> tests. It might be broken - but then we should open >>>>> a bug and fix it. (And in the long run we should handle the >>>>> fragmentation with relocating code.) >>>>> >>>>> Regards, >>>>> //Nils >>>> >> From albert.noll at oracle.com Tue Oct 14 08:09:56 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 14 Oct 2014 10:09:56 +0200 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543CD6E1.3090305@oracle.com> References: <543CD6E1.3090305@oracle.com> Message-ID: <543CDA54.9030508@oracle.com> Hi Tobias, looks good to me (not a reviewer). Best, Albert On 10/14/2014 09:55 AM, Tobias Hartmann wrote: > Hi, > > please review this small code cleanup that replaces the explicit > locking of OsrList_lock by a MutexLockerEx instantiation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 > Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ > > Thanks, > Tobias From tobias.hartmann at oracle.com Tue Oct 14 08:20:14 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 14 Oct 2014 10:20:14 +0200 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543CDA54.9030508@oracle.com> References: <543CD6E1.3090305@oracle.com> <543CDA54.9030508@oracle.com> Message-ID: <543CDCBE.8060503@oracle.com> Thanks, Albert. Best, Tobias On 14.10.2014 10:09, Albert Noll wrote: > Hi Tobias, > > looks good to me (not a reviewer). > > Best, > Albert > > On 10/14/2014 09:55 AM, Tobias Hartmann wrote: >> Hi, >> >> please review this small code cleanup that replaces the explicit locking of >> OsrList_lock by a MutexLockerEx instantiation. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 >> Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ >> >> Thanks, >> Tobias > From david.r.chase at oracle.com Tue Oct 14 12:54:06 2014 From: david.r.chase at oracle.com (David Chase) Date: Tue, 14 Oct 2014 08:54:06 -0400 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543CD6E1.3090305@oracle.com> References: <543CD6E1.3090305@oracle.com> Message-ID: <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> Hello Tobias, Not a Reviewer here, but it looks correct to me. One question ? above I see a NEEDS_CLEANUP notation. Do we know (does someone know?) if it refers to this change? If so, we could remove that :-). David On 2014-10-14, at 3:55 AM, Tobias Hartmann wrote: > Hi, > > please review this small code cleanup that replaces the explicit locking of OsrList_lock by a MutexLockerEx instantiation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 > Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ > > Thanks, > Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Tue Oct 14 14:52:39 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Oct 2014 07:52:39 -0700 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <543CD8E1.6050303@oracle.com> References: <5436465A.3080001@oracle.com> <5437A081.4060608@oracle.com> <5437ED93.6080806@oracle.com> <54381017.6020809@oracle.com> <543BE7E4.6040203@oracle.com> <543C83B8.5050003@oracle.com> <543CD8E1.6050303@oracle.com> Message-ID: <543D38B7.5070508@oracle.com> Good. Thanks, Vladimir On 10/14/14 1:03 AM, Albert Noll wrote: > Hi Vladimir, > > I filed a CCC request and added the 3 removed flags to the > obsolete_jvm_flags table. > > Here is the updated webrev: > http://cr.openjdk.java.net/~anoll/8046809/webrev.05/ > > Thanks, > Albert > > On 10/14/2014 04:00 AM, Vladimir Kozlov wrote: >> Looks good but you need to wait CCC approval for product flags removal. >> And you need to add them to obsolete_jvm_flags table in arguments.cpp. >> >> Thanks, >> Vladimir >> >> On 10/13/14 7:55 AM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks for the feedback. Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~anoll/8046809/webrev.04/ >>> >>> Best, >>> Albert >>> >>> On 10/10/2014 06:57 PM, Vladimir Kozlov wrote: >>>> On 10/10/14 7:30 AM, Albert Noll wrote: >>>>> Tobias, Vladimir, Dean, Nils, thanks for looking at the patch and >>>>> for your feedback. >>>>> >>>>> @Tobias >>>>> I have adapted your suggestions. >>>>> >>>>> @Vladimir >>>>> I tried to add a condition to >>>>> SafepointSynchronize::is_cleanup_needed() that returns 'true' if >>>>> the code cache has less >>>>> than 10% free space. Unfortunately, that does not fix the bug. A >>>>> safepoint interval of 1000ms seems to be too coarse >>>>> to free space in the code cache fast enough. >>>> >>>> Okay, thank you for trying. >>>> >>>>> >>>>> It seems that the concept of critical memory allocations >>>>> (allocations that must succeed for the VM to be able to >>>>> continue to execute) is broken. For example, we need to compile >>>>> method handle intrinsics (otherwise we get a >>>>> java.lang.VirtualMachineError: out of space in CodeCache for method >>>>> handle intrinsic). However, method handle intrinsic >>>>> are not critical allocations. For this reason, >>>>> test/compiler/startup/SmallCodeCacheStartup.java fails with a 32-bit >>>>> client >>>>> version. We will get a new nightly bug soon... The current patch >>>>> fixes this. >>>>> >>>>> I want to keep the removal of critical allocations in this patch, >>>>> since aggressive sweeping (enabled by the VM >>>>> operation that forces stack scanning) replaces the concept of >>>>> critical allocations in the code cache. I think >>>>> these two changes belong together. If you still want me to, I will >>>>> do a separate change for critical allocation >>>>> removal. >>>> >>>> Okay, I am fine with this removal. >>>> >>>>> >>>>> @Dean >>>>> I removed the corresponding code. It was a fragment that I missed >>>>> to delete. >>>>> >>>>> @Nils >>>>> CodeCacheMinimumFreeSpace did not guarantee that the VM can >>>>> continue to execute. In the failing test >>>>> that is reported in the bug, 500K was not enough to generate all >>>>> adapters. The test can be changed such >>>>> that a CodeCacheMinimumFreeSpace size of 1m, 2m, 3m, etc. is too >>>>> small too. What value should we choose? >>>>> >>>>> Also, as noted above, method handle intrinsic need to be compiled >>>>> to be able to continue execution. >>>>> Method handle intrinsic are currently not critical, so we must make >>>>> them critical allocations. As a consequence, >>>>> we must re-evaluate the default size of CodeCacheMinimumFreeSpace. >>>>> >>>>> The current approach enables very aggressive sweeping, if the code >>>>> cache is 90% full. It is very likely that code >>>>> will be flushed from the code cache in the next 5-10 invocations of >>>>> CodeCache::allocate(). In a sense, the remaining >>>>> 10% can be considered as a 'critical region' that is used as a >>>>> 'buffer' until we free space in the code cache. This bug >>>>> proves that the proposed strategy solves the problem better than >>>>> CodeCacheMinimumFreeSpace. >>>>> >>>>> Maybe we should provide the user with control over this threshold, >>>>> i.e., replace CodeCacheMinimumFreeSpace >>>>> with a different command line flag that allows the user to specify >>>>> the percentage (currently 90%) at which aggressive >>>> >>>> Yes, it should be flag. I think it should be percentage. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> sweeping starts. We could also use a fixed-size. I don't think that >>>>> having two thresholds (the threshold where we start >>>>> aggressive sweeping AND CodeCacheMinimumFreeSpace) is necessary. >>>> >>>>> >>>>> What do you think? >>>>> >>>>> >>>>> >>>>> The performance runs show that waking up the sweeper thread for >>>>> every allocation has a negative impact >>>>> on startup time. To fix this, in the current patch, the sweeper >>>>> thread is only woken up, if the code cache is >>>>> more than 10% occupied. I will issue a new performance run and >>>>> compare it against b34 (which includes >>>>> the segmented code cache). >>>>> >>>>> Here is the new webrev: >>>>> http://cr.openjdk.java.net/~anoll/8046809/webrev.03/ >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 10/10/2014 11:01 AM, Nils Eliasson wrote: >>>>>> Hi, Albert >>>>>> >>>>>> Overall a very welcome change to move the sweeper into a separate >>>>>> thread. >>>>>> >>>>>> On 2014-10-09 10:24, Albert Noll wrote: >>>>>>> The patch also removes CodeCacheMinimumFreeSpace and 'critical' >>>>>>> code cache allocations. Due to a bug in >>>>>>> heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved >>>>>>> for 'critical' allocations. The following >>>>>>> lines produce an underflow if heap_unallocated_capacity() < >>>>>>> CodeCacheMinimumFreeSpace: >>>>>>> >>>>>>> segments_to_size(number_of_segments) > >>>>>>> (heap_unallocated_capacity() - CodeCacheMinimumFreeSpace) >>>>>>> >>>>>>> Since the critical part in the code cache was never used for its >>>>>>> intended purpose and we did not have problems >>>>>>> due to that, we can remove it. >>>>>> >>>>>> Are you sure? The reasons for the CodeCacheMinimumFreeSpace and >>>>>> critical allocations where problems with code cache >>>>>> fragmentation in long running applications, where small >>>>>> compilations would starve out the adaptors and cause VM >>>>>> shutdown. You won't see this other than in the really long running >>>>>> tests. It might be broken - but then we should open >>>>>> a bug and fix it. (And in the long run we should handle the >>>>>> fragmentation with relocating code.) >>>>>> >>>>>> Regards, >>>>>> //Nils >>>>> >>> > From vladimir.kozlov at oracle.com Tue Oct 14 14:58:04 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Oct 2014 07:58:04 -0700 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> References: <543CD6E1.3090305@oracle.com> <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> Message-ID: <543D39FC.5020204@oracle.com> Looks good. Should be reviewed by runtime too since changes are in instanceKlass.cpp Thanks, Vlaidmir On 10/14/14 5:54 AM, David Chase wrote: > Hello Tobias, > > Not a Reviewer here, but it looks correct to me. > One question ? above I see a NEEDS_CLEANUP notation. > Do we know (does someone know?) if it refers to this change? > If so, we could remove that :-). > > David > > On 2014-10-14, at 3:55 AM, Tobias Hartmann wrote: > >> Hi, >> >> please review this small code cleanup that replaces the explicit locking of OsrList_lock by a MutexLockerEx instantiation. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 >> Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ >> >> Thanks, >> Tobias > From tobias.hartmann at oracle.com Tue Oct 14 15:05:12 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 14 Oct 2014 17:05:12 +0200 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543D39FC.5020204@oracle.com> References: <543CD6E1.3090305@oracle.com> <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> <543D39FC.5020204@oracle.com> Message-ID: <543D3BA8.60802@oracle.com> Thanks, David and Vladimir. On 14.10.2014 16:58, Vladimir Kozlov wrote: > Looks good. Should be reviewed by runtime too since changes are in > instanceKlass.cpp > > Thanks, > Vlaidmir > > On 10/14/14 5:54 AM, David Chase wrote: >> Hello Tobias, >> >> Not a Reviewer here, but it looks correct to me. >> One question ? above I see a NEEDS_CLEANUP notation. >> Do we know (does someone know?) if it refers to this change? >> If so, we could remove that :-). I don't know if this statement is related to my changes but I assume it refers to the comment '// only one compilation can be active'. Maybe someone from the runtime team knows. Thanks, Tobias >> David >> >> On 2014-10-14, at 3:55 AM, Tobias Hartmann wrote: >> >>> Hi, >>> >>> please review this small code cleanup that replaces the explicit locking of >>> OsrList_lock by a MutexLockerEx instantiation. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ >>> >>> Thanks, >>> Tobias >> From paul.sandoz at oracle.com Tue Oct 14 15:39:31 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 14 Oct 2014 17:39:31 +0200 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <54386E92.3000006@oracle.com> References: <54386E92.3000006@oracle.com> Message-ID: <3976AC9A-9D8F-4520-89A7-37A697DA1B92@oracle.com> Hi Vladimir, Thanks for looking into this. The patch works fine for the simple test case (NullCheckDroppingsTest on the issue) but if i write a test using a MethodHandle to set a field then i still observe generated code for the uncommon trap of obj == null case. See below for test case. When i run it: java -cp target/classes -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -Xbatch -XX:LoopUnrollLimit=0 -XX:+PrintAssembly NullCheckDroppingsMHTest ;; B4: # B6 <- B3 Freq: 0.999997 0x00000001116a4e27: mov %rbx,%r10 0x00000001116a4e2a: add $0x14,%r10 ;*invokevirtual putObject ; - java.lang.invoke.LambdaForm$MH/617901222::putObjectFieldCast at 28 ; - java.lang.invoke.LambdaForm$MH/1072591677::invokeExact_MT at 11 ; - NullCheckDroppingsMHTest::testLoopOne at 5 (line 47) ; - NullCheckDroppingsMHTest::testLoop at 13 (line 29) 0x00000001116a4e2e: mov 0xc(%rbx),%r8d 0x00000001116a4e32: mov $0x193f5c000,%r11 0x00000001116a4e3c: jmp 0x00000001116a4e44 0x00000001116a4e3e: nop 0x00000001116a4e3f: nop ;; B5: # B6 <- B7 top-of-loop Freq: 671086 0x00000001116a4e40: mov 0xc(%rbx),%r8d ;*getfield svalue ; - NullCheckDroppingsMHTest::testLoop at 10 (line 29) ;; B6: # B9 B7 <- B4 B5 Loop: B6-B5 inner Freq: 671087 0x00000001116a4e44: test %r8d,%r8d 0x00000001116a4e47: je 0x00000001116a4e75 ;*ifnull ; - java.lang.Class::cast at 1 (line 3368) ; - java.lang.invoke.DirectMethodHandle$Accessor::checkCast at 5 (line 437) ; - java.lang.invoke.DirectMethodHandle::checkCast at 5 (line 506) ; - java.lang.invoke.LambdaForm$MH/617901222::putObjectFieldCast at 13 ; - java.lang.invoke.LambdaForm$MH/1072591677::invokeExact_MT at 11 ; - NullCheckDroppingsMHTest::testLoopOne at 5 (line 47) ; - NullCheckDroppingsMHTest::testLoop at 13 (line 29) ;; B7: # B5 B8 <- B6 Freq: 671086 0x00000001116a4e49: mov %r8d,(%r10) ;*goto ; - NullCheckDroppingsMHTest::testLoop at 19 (line 28) 0x00000001116a4e4c: mov %r10,%r8 0x00000001116a4e4f: shr $0x9,%r8 0x00000001116a4e53: mov %r12b,(%r11,%r8,1) ;*invokevirtual putObject ; - java.lang.invoke.LambdaForm$MH/617901222::putObjectFieldCast at 28 ; - java.lang.invoke.LambdaForm$MH/1072591677::invokeExact_MT at 11 ; - NullCheckDroppingsMHTest::testLoopOne at 5 (line 47) ; - NullCheckDroppingsMHTest::testLoop at 13 (line 29) 0x00000001116a4e57: inc %ebp ;*iinc ; - NullCheckDroppingsMHTest::testLoop at 16 (line 28) 0x00000001116a4e59: cmp $0xf4240,%ebp 0x00000001116a4e5f: jl 0x00000001116a4e40 ;*if_icmpge ; - NullCheckDroppingsMHTest::testLoop at 5 (line 28) ;; B8: # N132 <- B3 B7 Freq: 0.319999 0x00000001116a4e61: mov $0xffffff5d,%esi 0x00000001116a4e66: mov %rbx,(%rsp) 0x00000001116a4e6a: nop 0x00000001116a4e6b: callq 0x00000001116088e0 ; OopMap{[0]=Oop off=144} ;*if_icmpge ; - NullCheckDroppingsMHTest::testLoop at 5 (line 28) ; {runtime_call} Paul. import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; public class NullCheckDroppingsMHTest { static final MethodHandle SET_SSINK; static { try { SET_SSINK = MethodHandles.lookup().findSetter(NullCheckDroppingsMHTest.class, "ssink", String.class); } catch (Exception e) { throw new Error(e); } } volatile String svalue = "A"; volatile String snull = null; String ssink; public static void main(String[] args) { NullCheckDroppingsMHTest t = new NullCheckDroppingsMHTest(); t.testLoop(); } void testLoop() { // Ensure testLoopOne is compiled and does not // see a null value for (int i = 0; i < 1000000; i++) { testLoopOne(svalue); // Uncomment the following and the call outside // the loop should not result in any deoptimization // testLoopOne(snull); } // Sleep just to create delay in the compilation log try { Thread.currentThread().sleep(1000); } catch (Exception e) {} // This should cause a de-optimisation // if testLoopOne is compiled with a null-check testLoopOne(snull); } void testLoopOne(String s) { try { SET_SSINK.invokeExact(this, s); } catch (Throwable t) { throw new Error(t); } } } On Oct 11, 2014, at 1:41 AM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8054492 > http://cr.openjdk.java.net/~kvn/8054492/webrev/ > > Thanks to Roland for the evaluation of this problem. > > Class.cast has an explicit null check: > > public T cast(Object obj) { > if (obj != null && !isInstance(obj)) > throw new ClassCastException(cannotCastMsg(obj)); > return (T) obj; > } > > Compiler generates null check and uncommon trap when it did not see null values in profiled data. In most cases when Class.cast is inlined isInstance() is folded and as result compiled code is looks like: > > if (obj != null) { > return obj; > } else { > uncommon_trap(); // which triggers deoptimization and Interpreter > // will execute the same 'return obj;' code. > } > > The same result you will get with next compiled code. So the null check is noop and will be removed from compiled code (it is the goal of this change): > > if (obj != null) { > } > return obj; > > Even if isInstance() is not folded we don't need to generate uncommon trap for obj == null case: > > if (obj != null) { > if (!isInstance(obj)) { > uncommon_trap(); // or throw code > } > } > return obj; > > One benefit from having uncommon trap is it could be converted to implicit null check by folding it into a following memory instruction (load or store). In Class.cast() we don't have such memory instruction so we don't benefit from uncommon trap. > > The fix is rise probability of not-taken path to avoid generation of uncommon trap when processing ifnull bytecode in Class.cast method. > > Tested with JPRT, jtreg > > Thanks, > Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From david.r.chase at oracle.com Tue Oct 14 15:45:30 2014 From: david.r.chase at oracle.com (David Chase) Date: Tue, 14 Oct 2014 11:45:30 -0400 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543D3BA8.60802@oracle.com> References: <543CD6E1.3090305@oracle.com> <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> <543D39FC.5020204@oracle.com> <543D3BA8.60802@oracle.com> Message-ID: <0B6745C6-F2CE-44DC-B7F2-A513BD5CBFE4@oracle.com> On 2014-10-14, at 11:05 AM, Tobias Hartmann wrote: >>> One question ? above I see a NEEDS_CLEANUP notation. >>> Do we know (does someone know?) if it refers to this change? >>> If so, we could remove that :-). > > I don't know if this statement is related to my changes but I assume it refers to the comment '// only one compilation can be active'. Maybe someone from the runtime team knows. No doubt it was considered to be too obvious to justify further comment. :-( David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From paul.sandoz at oracle.com Tue Oct 14 16:58:21 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 14 Oct 2014 18:58:21 +0200 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <3976AC9A-9D8F-4520-89A7-37A697DA1B92@oracle.com> References: <54386E92.3000006@oracle.com> <3976AC9A-9D8F-4520-89A7-37A697DA1B92@oracle.com> Message-ID: <1B318630-8544-4FC9-BC7A-9F0BA04EB666@oracle.com> Here is a simpler test case that just uses a MH to Class.cast that exhibits the same behaviour. The commented out use of the BiFunction created from a lambda expressions works fine. This suggests there might be something about the MH invocation that is stopping the optimization from kicking in. Paul. import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.lang.invoke.MethodType; import java.util.function.BiFunction; public class NullCheckDroppingsMHCastTest { static final MethodHandle MH_CAST; static { try { MH_CAST = MethodHandles.lookup().findVirtual(Class.class, "cast", MethodType.methodType(Object.class, Object.class)); } catch (Exception e) { throw new Error(e); } } static final BiFunction fCast = (c, o) -> c.cast(o); volatile String svalue = "A"; volatile String snull = null; String ssink; public static void main(String[] args) { NullCheckDroppingsMHCastTest t = new NullCheckDroppingsMHCastTest(); t.testLoop(); } void testLoop() { // Ensure testLoopOne is compiled and does not // see a null value for (int i = 0; i < 1000000; i++) { testLoopOne(svalue); // Uncomment the following and the call outside // the loop should not result in any deoptimization // testLoopOne(snull); } // Sleep just to create delay in the compilation log try { Thread.currentThread().sleep(1000); } catch (Exception e) { } // This should cause a de-optimisation // if testLoopOne is compiled with a null-check testLoopOne(snull); } void testLoopOne(String s) { try { ssink = (String) (Object) MH_CAST.invokeExact(String.class, (Object) s); // ssink = (String) fCast.apply(String.class, s); } catch (Throwable t) { throw new Error(t); } } } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From david.r.chase at oracle.com Tue Oct 14 17:30:39 2014 From: david.r.chase at oracle.com (David Chase) Date: Tue, 14 Oct 2014 13:30:39 -0400 Subject: [9] RFR(M) 8041984: CompilerThread seems to occupy all CPU in a very rare situation In-Reply-To: <5438A6EC.8000302@oracle.com> References: <5438A6EC.8000302@oracle.com> Message-ID: <415C2022-8ABA-405C-B7C6-258B512C8B04@oracle.com> I?m curious about the granularity of the completion-prediction ? you?re checking every 4 iterations and extrapolating from there. Do we know that the times are that uniform, or would we be better off with larger sample sizes? (How long does a single iteration take, anyway?) And in the sample code, I see the choice of sample size (4) encoded as (next & 3) == 0 // Each 4 iterations calculate how much time it will take double time_per_iter = (stop_time - start_time) * 0.25; why not write this as (say) static const int LOG_SAMPLE_SIZE = 2; static const int SAMPLE_SIZE = (1 << LOG_SAMPLE_SIZE); next % SAMPLE_SIZE == 0 // next could be a uint, couldn?t it? double time_per_iter = (stop_time - start_time) * (1.0/SAMPLE_SIZE); perhaps rewriting 1.0/SAMPLE_SIZE as another static const as necessary to get it properly precalculated; I?m not sure what C++ compilers are doing nowadays. An alternate approach would be to compute the overall rate thus far, checking at (say) iterations 4, 8, 16, 32, etc and computing the average from there, starting at whatever power of two is a decent fraction of the iterations needed to timeout. e.g., don?t reset start_time, just compute elapsed at each sample: if ((next & (ptwo - 1) == 0) { time.stop(); double elapsed = time.seconds() - start_time; double projected = elapsed * (double) java_objects_length / next; Or you can compute a java_objects_length that would surely lead to failure, and always do that (fast, integer) comparison: ... unsigned int length_bound = (int) next * (CG_BUILD_TIME_LIMIT / elapsed) ? if (java_objects_length > length_bound) { ? timeout David On 2014-10-10, at 11:41 PM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8041984 > http://cr.openjdk.java.net/~kvn/8041984/webrev/ > > Next method puts C2's EA to its knees: > > com.graphhopper.coll.GHLongIntBTree$BTreeEntry::put() > > https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/coll/GHLongIntBTree.java > > It shows that current EA connection graph build code is very inefficient when a graph has a lot of connections (edges). > > With inlining the BTreeEntry::put() method has about 100 allocations from which about 80 are arrays allocations. Most of them are object arrays which are generated by Arrays.copyOf(). After number of edges in EA Connection Graph reaches about 50000 it takes more then 1 sec to find all nodes which reference an allocation. > > Current EA code has bailout by timeout from graph building code. But the timeout (30 sec for product VM) is checked only after all object nodes are processed. So it may take > 2 mins before EA is aborted: > > > > > > Also ConnectionGraph::add_java_object_edges() method does not check the presence of a node when it adds new one to the worklist (in add_to_worklist() method). Which leads to hundreds MB of used by EA memory when BTreeEntry::put() is processed. > > To address issues new timeout checks were added. > New _pidx index field is added to graph's nodes and VectorSet is used to reduce size of worklist in add_java_object_edges() method. > > Escaping node CreateEx is mapped phantom_obj to reduce number of process objects in connection graph. We do the same for other escaping objects. > > Tested with graphhopper server application: > > > > > > Thanks, > Vladimir -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From zoltan.majo at oracle.com Tue Oct 14 18:16:22 2014 From: zoltan.majo at oracle.com (=?windows-1252?Q?Zolt=E1n_Maj=F3?=) Date: Tue, 14 Oct 2014 20:16:22 +0200 Subject: [9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation) In-Reply-To: <54383F51.3080500@oracle.com> References: <5433C140.9070400@oracle.com> <5433C6C6.20602@oracle.com> <5433EE7A.9060607@oracle.com> <0DBAED7F-65DF-4D15-AFDB-636DF7F70C16@oracle.com> <5436BB16.7010703@oracle.com> <2F9E5CC6-F48F-4250-8D78-5C1AC9BAB82C@oracle.com> <54379061.5070506@oracle.com> <54383F51.3080500@oracle.com> Message-ID: <543D6876.1020701@oracle.com> Hi Vladimir, thank you for your comments! On 10/10/2014 10:19 PM, Vladimir Kozlov wrote: > Zoltan, > > Please, add test. There is -XX:+PrintFlagsFinal which will print all > flags after all adjustments so you can verify that thresholds flags > are correctly scaled. Check CompileThresholdScaling value corner cases > too. I added compiler/arguments/CheckCompileThresholdScaling.java to check the scaling of flags. > Also I would like to see explicit casts to (intx) after multiplication. > May be add an other Arguments method which do just multiplication by > CompileThresholdScaling and cast to return intx. I added a new function, Arguments::get_scaled_compile_threshold(), that does the scaling and also casts the result of the scaling explicitly. Here is the updated webrev: http://cr.openjdk.java.net/~zmajo/8059604/webrev.03/ All JPRT tests pass. Thank you and best regards, Zoltan > > Thanks, > Vladimir > > On 10/10/14 12:53 AM, Zolt?n Maj? wrote: >> Thank you, Igor, for the review. >> >> Could somebody please provide a second Reviewer's review? I think the >> change is too large to be pushed with only one "Review". >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> On 10/09/2014 08:58 PM, Igor Veresov wrote: >>> That looks good to me. >>> >>> igor >>> >>> On Oct 9, 2014, at 9:43 AM, Zolt?n Maj? wrote: >>> >>>> Hi Igor, >>>> >>>> >>>> thank you for your feedback! >>>> >>>> On 10/07/2014 11:17 PM, Igor Veresov wrote: >>>>> 1. It would probably be nice not to do multiplications at every >>>>> event but rather compute everything once during the startup. Perhaps >>>>> it would be better to scale command line options right in >>>>> arguments.cpp ? Or setup accessors in Arguments that would compute >>>>> and cache the values. If you just scale the options the change would >>>>> be smaller though. What do you think? >>>> That is a good idea. I changed the code to scale thresholds in >>>> arguments.cpp (in Arguments::apply_ergo()). >>>> >>>>> 2. Why aren?t you scaling Tier{2,3}{Invoke,Backedge}NotifyFreqLog >>>>> and Tier23InlineeNotifyFreqLog? Probably can be solved by (1) >>>>> automatically. >>>> The previous patch adjusts only the transition from Tier 0 to Tier 3 >>>> (when methods get first compiled). But now that you've suggested, I >>>> extended the patch to scale Tier4* compilation thresholds and >>>> Tier{2,3} notification thresholds as well. >>>> >>>> Here is the updated webrev: >>>> >>>> http://cr.openjdk.java.net/~zmajo/8059604/webrev.02/ >>>> >>>> I tested the new patch with JPRT and manual testing. >>>> >>>> Thank you and best regards, >>>> >>>> >>>> Zoltan >>>> >>>>> igor >>>>> >>>>> On Oct 7, 2014, at 6:45 AM, Zolt?n Maj? >>>>> wrote: >>>>> >>>>>> Hi Albert, >>>>>> >>>>>> >>>>>> thank you for your feedback. >>>>>> >>>>>> On 10/07/2014 12:56 PM, Albert Noll wrote: >>>>>>> How about using a scaling factor instead of using percentage? >>>>>> I think that is a good idea because a scaling factor (expressed as >>>>>> a double) allows a finer-grained control of compilation thresholds >>>>>> than a scaling percentage (expressed as an integer). >>>>>> >>>>>> Here is the webrev with the scaling factor: >>>>>> >>>>>> http://cr.openjdk.java.net/~zmajo/8059604/webrev.01/ >>>>>> >>>>>> The name of the flag is changed to CompileThresholdScaling (from >>>>>> CompileThresholdScalingPercentage). >>>>>> >>>>>>> What happens if a threshold becomes 0 after scaling? >>>>>> Then all methods will be interpreted. That seems to be the >>>>>> convention (in src/share/vm/runtime/arguments.cpp). >>>>>> >>>>>> Best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> >>>>>>> On 10/07/2014 12:32 PM, Zolt?n Maj? wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> please review the following patch. >>>>>>>> >>>>>>>> >>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8059604 >>>>>>>> >>>>>>>> >>>>>>>> Problem: With tiered compilation enabled, the value of 6 >>>>>>>> different thresholds must be set to control when the JVM compiles >>>>>>>> methods for the first time. That is too detailed for the average >>>>>>>> customer. >>>>>>>> >>>>>>>> >>>>>>>> Solution: This patch adds a new flag, >>>>>>>> CompileThresholdScalingPercentage, to control when methods are >>>>>>>> first compiled. The new flag scales thresholds the following way: >>>>>>>> >>>>>>>> - if CompileThresholdScalingPercentage==100, the default >>>>>>>> threshold values are used >>>>>>>> - if CompileThresholdScalingPercentage>100, threshold values are >>>>>>>> scaled up (e.g., CompileThresholdScalingPercentage=120 scales up >>>>>>>> thresholds by a factor of 1.2X) >>>>>>>> - if 0 < CompileThresholdScalingPercentage < 100, threshold >>>>>>>> values are scaled down accordingly. >>>>>>>> >>>>>>>> The new flag works both with and without tiered compilation. >>>>>>>> Thus, the new flag allows compilation to be controlled the same >>>>>>>> way both with and without tiered compilation: >>>>>>>> >>>>>>>> - with tiered compilation enabled, the value of the flags >>>>>>>> Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog, >>>>>>>> Tier3InvocationThreshold, Tier3MinInvocationThreshold, >>>>>>>> Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled >>>>>>>> >>>>>>>> - with tiered compilation disabled, the value of CompileThreshold >>>>>>>> is scaled >>>>>>>> >>>>>>>> Currently, tiered and non-tiered compilation treats threshold >>>>>>>> values slightly differently: For a threshold value of N and >>>>>>>> without tiered compilation enabled, methods are compiled *before* >>>>>>>> their Nth execution. With tiered compilation enabled, methods are >>>>>>>> compiled *after* the their Nth execution. >>>>>>>> >>>>>>>> The patch addresses the difference between tiered/non-tiered >>>>>>>> compilation: Methods are compiled right before their Nth >>>>>>>> execution in both cases (the non-tiered way). If >>>>>>>> CompileThresholdScalingPercentage==0, all methods are interpreted >>>>>>>> (similarly to the case when CompileThreshold==0). >>>>>>>> >>>>>>>> This patch is the second (out of three) parts of JDK-8050853 >>>>>>>> (adding support for per-compilation >>>>>>>> thresholds):https://bugs.openjdk.java.net/browse/JDK-8050853 . >>>>>>>> >>>>>>>> >>>>>>>> Webrev:http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Testing: JPRT, manual testing >>>>>>>> >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> >>>>>>>> >>>>>>>> Zoltan >>>>>>>> >> From zoltan.majo at oracle.com Tue Oct 14 18:44:35 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 14 Oct 2014 20:44:35 +0200 Subject: [9] RFR(S): 8060215: per-method PrintIdealGraphLevel Message-ID: <543D6F13.5020108@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8060215 Problem: Currently, printing the Ideal Graph can be only enabled for *all* methods compiled by the VM (by setting the PrintIdealGraphLevel flag). The overhead of printing the graph can be too high when a VM is debugged in a resource-constrained environment (e.g., limited network bandwidth, limited disk space, or a slow CPU is available). To reduce the overhed, it can be useful to produce the Ideal Graph only for a subset of all methods compiled. By doing that the size of the output file, the amount of data transferred on the network, and also the overhead of printing the graph is reduced. Solution: - Use CompileCommand=option to set PrintIdealGraphLevel on a per-method level. - PrintIdealGraphLevel sets the level of detail for printing all other methods. - Introduce a new develop flag PrintIdealGraph to control/check if printing the graph is enabled for any method. The old way of checking if PrintIdealGraphLevel > 0 to see if printing is enabled is not good enough, because PrintIdealGraphLevel flag can be 0 while PrintIdealGraphLevel can be set for some method. Webrev: http://cr.openjdk.java.net/~zmajo/8060215/webrev.00/ Testing: JPRT, manual testing. Thank you and best regards, Zoltan From vladimir.kozlov at oracle.com Tue Oct 14 20:15:54 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Oct 2014 13:15:54 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <1B318630-8544-4FC9-BC7A-9F0BA04EB666@oracle.com> References: <54386E92.3000006@oracle.com> <3976AC9A-9D8F-4520-89A7-37A697DA1B92@oracle.com> <1B318630-8544-4FC9-BC7A-9F0BA04EB666@oracle.com> Message-ID: <543D847A.7020407@oracle.com> Thank you, Paul I will look on that. Vladimir On 10/14/14 9:58 AM, Paul Sandoz wrote: > Here is a simpler test case that just uses a MH to Class.cast that exhibits the same behaviour. > > The commented out use of the BiFunction created from a lambda expressions works fine. > > This suggests there might be something about the MH invocation that is stopping the optimization from kicking in. > > Paul. > > import java.lang.invoke.MethodHandle; > import java.lang.invoke.MethodHandles; > import java.lang.invoke.MethodType; > import java.util.function.BiFunction; > > public class NullCheckDroppingsMHCastTest { > > static final MethodHandle MH_CAST; > > static { > try { > MH_CAST = MethodHandles.lookup().findVirtual(Class.class, > "cast", > MethodType.methodType(Object.class, Object.class)); > } > catch (Exception e) { > throw new Error(e); > } > } > > static final BiFunction fCast = (c, o) -> c.cast(o); > > > volatile String svalue = "A"; > volatile String snull = null; > String ssink; > > public static void main(String[] args) { > NullCheckDroppingsMHCastTest t = new NullCheckDroppingsMHCastTest(); > t.testLoop(); > } > > void testLoop() { > // Ensure testLoopOne is compiled and does not > // see a null value > for (int i = 0; i < 1000000; i++) { > testLoopOne(svalue); > // Uncomment the following and the call outside > // the loop should not result in any deoptimization > // testLoopOne(snull); > } > > // Sleep just to create delay in the compilation log > try { > Thread.currentThread().sleep(1000); > } > catch (Exception e) { > } > > // This should cause a de-optimisation > // if testLoopOne is compiled with a null-check > testLoopOne(snull); > } > > void testLoopOne(String s) { > try { > ssink = (String) (Object) MH_CAST.invokeExact(String.class, (Object) s); > // ssink = (String) fCast.apply(String.class, s); > } > catch (Throwable t) { > throw new Error(t); > } > } > } > From vladimir.kozlov at oracle.com Tue Oct 14 20:40:35 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Oct 2014 13:40:35 -0700 Subject: [9] RFR(M) 8041984: CompilerThread seems to occupy all CPU in a very rare situation In-Reply-To: <415C2022-8ABA-405C-B7C6-258B512C8B04@oracle.com> References: <5438A6EC.8000302@oracle.com> <415C2022-8ABA-405C-B7C6-258B512C8B04@oracle.com> Message-ID: <543D8A43.5020405@oracle.com> On 10/14/14 10:30 AM, David Chase wrote: > I?m curious about the granularity of the completion-prediction ? > you?re checking every 4 iterations and extrapolating from there. > Do we know that the times are that uniform, or would we be better off with larger sample sizes? Yes, I observed uniformly slowly growing times for PARTS of iterations and not all iterations. That is why I want to take several samples. For example first iterations where fast but when array allocation objects begin processed time are rapidly growing. If I take very big sample fast iterations affect the result - delay abort. I did implementation similar to your "alternate approach" suggestion and I saw that the abort happened much later than with current my approach. > (How long does a single iteration take, anyway?) As I said one slow iteration may take upto 1 sec. So I want to abort as soon as I see a such case (but allow spikes). Taking larger sample sizes may delay an abort for several seconds. > > And in the sample code, I see the choice of sample size (4) encoded as > (next & 3) == 0 > // Each 4 iterations calculate how much time it will take > double time_per_iter = (stop_time - start_time) * 0.25; > > why not write this as (say) > > static const int LOG_SAMPLE_SIZE = 2; > static const int SAMPLE_SIZE = (1 << LOG_SAMPLE_SIZE); > next % SAMPLE_SIZE == 0 // next could be a uint, couldn?t it? > double time_per_iter = (stop_time - start_time) * (1.0/SAMPLE_SIZE); > > perhaps rewriting 1.0/SAMPLE_SIZE as another static const as necessary > to get it properly precalculated; I?m not sure what C++ compilers are doing nowadays. I am optimizing :) by avoiding % and / operations. But I agree and can add SAMPLE_SIZE constant so code can be more clear. Thanks, Vladimir > > An alternate approach would be to compute the overall rate thus far, checking at > (say) iterations 4, 8, 16, 32, etc and computing the average from there, starting > at whatever power of two is a decent fraction of the iterations needed to timeout. > > e.g., don?t reset start_time, just compute elapsed at each sample: > > if ((next & (ptwo - 1) == 0) { > time.stop(); > double elapsed = time.seconds() - start_time; > double projected = elapsed * (double) java_objects_length / next; > > Or you can compute a java_objects_length that would surely lead to failure, and > always do that (fast, integer) comparison: > ... > unsigned int length_bound = (int) next * (CG_BUILD_TIME_LIMIT / elapsed) > ? > if (java_objects_length > length_bound) { ? timeout > > David > > On 2014-10-10, at 11:41 PM, Vladimir Kozlov wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8041984 >> http://cr.openjdk.java.net/~kvn/8041984/webrev/ >> >> Next method puts C2's EA to its knees: >> >> com.graphhopper.coll.GHLongIntBTree$BTreeEntry::put() >> >> https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/coll/GHLongIntBTree.java >> >> It shows that current EA connection graph build code is very inefficient when a graph has a lot of connections (edges). >> >> With inlining the BTreeEntry::put() method has about 100 allocations from which about 80 are arrays allocations. Most of them are object arrays which are generated by Arrays.copyOf(). After number of edges in EA Connection Graph reaches about 50000 it takes more then 1 sec to find all nodes which reference an allocation. >> >> Current EA code has bailout by timeout from graph building code. But the timeout (30 sec for product VM) is checked only after all object nodes are processed. So it may take > 2 mins before EA is aborted: >> >> >> >> >> >> Also ConnectionGraph::add_java_object_edges() method does not check the presence of a node when it adds new one to the worklist (in add_to_worklist() method). Which leads to hundreds MB of used by EA memory when BTreeEntry::put() is processed. >> >> To address issues new timeout checks were added. >> New _pidx index field is added to graph's nodes and VectorSet is used to reduce size of worklist in add_java_object_edges() method. >> >> Escaping node CreateEx is mapped phantom_obj to reduce number of process objects in connection graph. We do the same for other escaping objects. >> >> Tested with graphhopper server application: >> >> >> >> >> >> Thanks, >> Vladimir > From vladimir.kozlov at oracle.com Tue Oct 14 20:43:31 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Oct 2014 13:43:31 -0700 Subject: [9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation) In-Reply-To: <543D6876.1020701@oracle.com> References: <5433C140.9070400@oracle.com> <5433C6C6.20602@oracle.com> <5433EE7A.9060607@oracle.com> <0DBAED7F-65DF-4D15-AFDB-636DF7F70C16@oracle.com> <5436BB16.7010703@oracle.com> <2F9E5CC6-F48F-4250-8D78-5C1AC9BAB82C@oracle.com> <54379061.5070506@oracle.com> <54383F51.3080500@oracle.com> <543D6876.1020701@oracle.com> Message-ID: <543D8AF3.9050500@oracle.com> This looks good. Thanks, Vladimir On 10/14/14 11:16 AM, Zolt?n Maj? wrote: > Hi Vladimir, > > > thank you for your comments! > > On 10/10/2014 10:19 PM, Vladimir Kozlov wrote: >> Zoltan, >> >> Please, add test. There is -XX:+PrintFlagsFinal which will print all >> flags after all adjustments so you can verify that thresholds flags >> are correctly scaled. Check CompileThresholdScaling value corner cases >> too. > > I added compiler/arguments/CheckCompileThresholdScaling.java to check > the scaling of flags. > >> Also I would like to see explicit casts to (intx) after multiplication. >> May be add an other Arguments method which do just multiplication by >> CompileThresholdScaling and cast to return intx. > > I added a new function, Arguments::get_scaled_compile_threshold(), that > does the scaling and also casts the result of the scaling explicitly. > > Here is the updated webrev: > > http://cr.openjdk.java.net/~zmajo/8059604/webrev.03/ > > All JPRT tests pass. > > Thank you and best regards, > > > Zoltan > >> >> Thanks, >> Vladimir >> >> On 10/10/14 12:53 AM, Zolt?n Maj? wrote: >>> Thank you, Igor, for the review. >>> >>> Could somebody please provide a second Reviewer's review? I think the >>> change is too large to be pushed with only one "Review". >>> >>> Thank you! >>> >>> Best regards, >>> >>> >>> Zoltan >>> >>> On 10/09/2014 08:58 PM, Igor Veresov wrote: >>>> That looks good to me. >>>> >>>> igor >>>> >>>> On Oct 9, 2014, at 9:43 AM, Zolt?n Maj? wrote: >>>> >>>>> Hi Igor, >>>>> >>>>> >>>>> thank you for your feedback! >>>>> >>>>> On 10/07/2014 11:17 PM, Igor Veresov wrote: >>>>>> 1. It would probably be nice not to do multiplications at every >>>>>> event but rather compute everything once during the startup. Perhaps >>>>>> it would be better to scale command line options right in >>>>>> arguments.cpp ? Or setup accessors in Arguments that would compute >>>>>> and cache the values. If you just scale the options the change would >>>>>> be smaller though. What do you think? >>>>> That is a good idea. I changed the code to scale thresholds in >>>>> arguments.cpp (in Arguments::apply_ergo()). >>>>> >>>>>> 2. Why aren?t you scaling Tier{2,3}{Invoke,Backedge}NotifyFreqLog >>>>>> and Tier23InlineeNotifyFreqLog? Probably can be solved by (1) >>>>>> automatically. >>>>> The previous patch adjusts only the transition from Tier 0 to Tier 3 >>>>> (when methods get first compiled). But now that you've suggested, I >>>>> extended the patch to scale Tier4* compilation thresholds and >>>>> Tier{2,3} notification thresholds as well. >>>>> >>>>> Here is the updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~zmajo/8059604/webrev.02/ >>>>> >>>>> I tested the new patch with JPRT and manual testing. >>>>> >>>>> Thank you and best regards, >>>>> >>>>> >>>>> Zoltan >>>>> >>>>>> igor >>>>>> >>>>>> On Oct 7, 2014, at 6:45 AM, Zolt?n Maj? >>>>>> wrote: >>>>>> >>>>>>> Hi Albert, >>>>>>> >>>>>>> >>>>>>> thank you for your feedback. >>>>>>> >>>>>>> On 10/07/2014 12:56 PM, Albert Noll wrote: >>>>>>>> How about using a scaling factor instead of using percentage? >>>>>>> I think that is a good idea because a scaling factor (expressed as >>>>>>> a double) allows a finer-grained control of compilation thresholds >>>>>>> than a scaling percentage (expressed as an integer). >>>>>>> >>>>>>> Here is the webrev with the scaling factor: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~zmajo/8059604/webrev.01/ >>>>>>> >>>>>>> The name of the flag is changed to CompileThresholdScaling (from >>>>>>> CompileThresholdScalingPercentage). >>>>>>> >>>>>>>> What happens if a threshold becomes 0 after scaling? >>>>>>> Then all methods will be interpreted. That seems to be the >>>>>>> convention (in src/share/vm/runtime/arguments.cpp). >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> >>>>>>> Zoltan >>>>>>> >>>>>>>> Best, >>>>>>>> Albert >>>>>>>> >>>>>>>> >>>>>>>> On 10/07/2014 12:32 PM, Zolt?n Maj? wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> please review the following patch. >>>>>>>>> >>>>>>>>> >>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8059604 >>>>>>>>> >>>>>>>>> >>>>>>>>> Problem: With tiered compilation enabled, the value of 6 >>>>>>>>> different thresholds must be set to control when the JVM compiles >>>>>>>>> methods for the first time. That is too detailed for the average >>>>>>>>> customer. >>>>>>>>> >>>>>>>>> >>>>>>>>> Solution: This patch adds a new flag, >>>>>>>>> CompileThresholdScalingPercentage, to control when methods are >>>>>>>>> first compiled. The new flag scales thresholds the following way: >>>>>>>>> >>>>>>>>> - if CompileThresholdScalingPercentage==100, the default >>>>>>>>> threshold values are used >>>>>>>>> - if CompileThresholdScalingPercentage>100, threshold values are >>>>>>>>> scaled up (e.g., CompileThresholdScalingPercentage=120 scales up >>>>>>>>> thresholds by a factor of 1.2X) >>>>>>>>> - if 0 < CompileThresholdScalingPercentage < 100, threshold >>>>>>>>> values are scaled down accordingly. >>>>>>>>> >>>>>>>>> The new flag works both with and without tiered compilation. >>>>>>>>> Thus, the new flag allows compilation to be controlled the same >>>>>>>>> way both with and without tiered compilation: >>>>>>>>> >>>>>>>>> - with tiered compilation enabled, the value of the flags >>>>>>>>> Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog, >>>>>>>>> Tier3InvocationThreshold, Tier3MinInvocationThreshold, >>>>>>>>> Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled >>>>>>>>> >>>>>>>>> - with tiered compilation disabled, the value of CompileThreshold >>>>>>>>> is scaled >>>>>>>>> >>>>>>>>> Currently, tiered and non-tiered compilation treats threshold >>>>>>>>> values slightly differently: For a threshold value of N and >>>>>>>>> without tiered compilation enabled, methods are compiled *before* >>>>>>>>> their Nth execution. With tiered compilation enabled, methods are >>>>>>>>> compiled *after* the their Nth execution. >>>>>>>>> >>>>>>>>> The patch addresses the difference between tiered/non-tiered >>>>>>>>> compilation: Methods are compiled right before their Nth >>>>>>>>> execution in both cases (the non-tiered way). If >>>>>>>>> CompileThresholdScalingPercentage==0, all methods are interpreted >>>>>>>>> (similarly to the case when CompileThreshold==0). >>>>>>>>> >>>>>>>>> This patch is the second (out of three) parts of JDK-8050853 >>>>>>>>> (adding support for per-compilation >>>>>>>>> thresholds):https://bugs.openjdk.java.net/browse/JDK-8050853 . >>>>>>>>> >>>>>>>>> >>>>>>>>> Webrev:http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Testing: JPRT, manual testing >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you and best regards, >>>>>>>>> >>>>>>>>> >>>>>>>>> Zoltan >>>>>>>>> >>> > From dean.long at oracle.com Tue Oct 14 20:52:20 2014 From: dean.long at oracle.com (dean long) Date: Tue, 14 Oct 2014 13:52:20 -0700 Subject: [9] RFR(S): 8060215: per-method PrintIdealGraphLevel In-Reply-To: <543D6F13.5020108@oracle.com> References: <543D6F13.5020108@oracle.com> Message-ID: <543D8D04.1010806@oracle.com> Looks ok to me. dl On 10/14/2014 11:44 AM, Zolt?n Maj? wrote: > Hi, > > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8060215 > > Problem: Currently, printing the Ideal Graph can be only enabled for > *all* methods compiled by the VM (by setting the PrintIdealGraphLevel > flag). The overhead of printing the graph can be too high when a VM is > debugged in a resource-constrained environment (e.g., limited network > bandwidth, limited disk space, or a slow CPU is available). To reduce > the overhed, it can be useful to produce the Ideal Graph only for a > subset of all methods compiled. By doing that the size of the output > file, the amount of data transferred on the network, and also the > overhead of printing the graph is reduced. > > Solution: > > - Use CompileCommand=option to set PrintIdealGraphLevel on a > per-method level. > - PrintIdealGraphLevel sets the level of detail for printing all other > methods. > - Introduce a new develop flag PrintIdealGraph to control/check if > printing the graph is enabled for any method. The old way of checking > if PrintIdealGraphLevel > 0 to see if printing is enabled is not good > enough, because PrintIdealGraphLevel flag can be 0 while > PrintIdealGraphLevel can be set for some method. > > Webrev: http://cr.openjdk.java.net/~zmajo/8060215/webrev.00/ > > Testing: JPRT, manual testing. > > Thank you and best regards, > > > Zoltan > From vladimir.kozlov at oracle.com Tue Oct 14 22:26:44 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Oct 2014 15:26:44 -0700 Subject: [9] RFR(S): 8060215: per-method PrintIdealGraphLevel In-Reply-To: <543D8D04.1010806@oracle.com> References: <543D6F13.5020108@oracle.com> <543D8D04.1010806@oracle.com> Message-ID: <543DA324.5060805@oracle.com> +1 Thanks, Vladimir On 10/14/14 1:52 PM, dean long wrote: > Looks ok to me. > > dl > > On 10/14/2014 11:44 AM, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8060215 >> >> Problem: Currently, printing the Ideal Graph can be only enabled for >> *all* methods compiled by the VM (by setting the PrintIdealGraphLevel >> flag). The overhead of printing the graph can be too high when a VM is >> debugged in a resource-constrained environment (e.g., limited network >> bandwidth, limited disk space, or a slow CPU is available). To reduce >> the overhed, it can be useful to produce the Ideal Graph only for a >> subset of all methods compiled. By doing that the size of the output >> file, the amount of data transferred on the network, and also the >> overhead of printing the graph is reduced. >> >> Solution: >> >> - Use CompileCommand=option to set PrintIdealGraphLevel on a >> per-method level. >> - PrintIdealGraphLevel sets the level of detail for printing all other >> methods. >> - Introduce a new develop flag PrintIdealGraph to control/check if >> printing the graph is enabled for any method. The old way of checking >> if PrintIdealGraphLevel > 0 to see if printing is enabled is not good >> enough, because PrintIdealGraphLevel flag can be 0 while >> PrintIdealGraphLevel can be set for some method. >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8060215/webrev.00/ >> >> Testing: JPRT, manual testing. >> >> Thank you and best regards, >> >> >> Zoltan >> > From vladimir.kozlov at oracle.com Tue Oct 14 23:52:17 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Oct 2014 16:52:17 -0700 Subject: [9] RFR(M) 8041984: CompilerThread seems to occupy all CPU in a very rare situation In-Reply-To: <543D8A43.5020405@oracle.com> References: <5438A6EC.8000302@oracle.com> <415C2022-8ABA-405C-B7C6-258B512C8B04@oracle.com> <543D8A43.5020405@oracle.com> Message-ID: <543DB731.5000301@oracle.com> I updated changes. http://cr.openjdk.java.net/~kvn/8041984/webrev.01/ As David suggested I added SAMPLE_SIZE constant: #define SAMPLE_SIZE 4 if ((next % SAMPLE_SIZE) == 0) { // Each 4 iterations calculate how much time it will take // to complete graph construction. time.stop(); double stop_time = time.seconds(); double time_per_iter = (stop_time - start_time) / (double)SAMPLE_SIZE; double time_until_end = time_per_iter * (double)(java_objects_length - next); if ((start_time + time_until_end) >= EscapeAnalysisTimeout) { I also replaced TIME_LIMIT constant with flag: product(double, EscapeAnalysisTimeout, 20. DEBUG_ONLY(+40.), \ "Abort EA when it reaches time limit (in sec)") \ Thanks, Vladimir On 10/14/14 1:40 PM, Vladimir Kozlov wrote: > On 10/14/14 10:30 AM, David Chase wrote: >> I?m curious about the granularity of the completion-prediction ? >> you?re checking every 4 iterations and extrapolating from there. >> Do we know that the times are that uniform, or would we be better off >> with larger sample sizes? > > Yes, I observed uniformly slowly growing times for PARTS of iterations > and not all iterations. That is why I want to take several samples. > For example first iterations where fast but when array allocation > objects begin processed time are rapidly growing. > If I take very big sample fast iterations affect the result - delay abort. > > I did implementation similar to your "alternate approach" suggestion and > I saw that the abort happened much later than with current my approach. > >> (How long does a single iteration take, anyway?) > > As I said one slow iteration may take upto 1 sec. So I want to abort as > soon as I see a such case (but allow spikes). Taking larger sample sizes > may delay an abort for several seconds. > >> >> And in the sample code, I see the choice of sample size (4) encoded as >> (next & 3) == 0 >> // Each 4 iterations calculate how much time it will take >> double time_per_iter = (stop_time - start_time) * 0.25; >> >> why not write this as (say) >> >> static const int LOG_SAMPLE_SIZE = 2; >> static const int SAMPLE_SIZE = (1 << LOG_SAMPLE_SIZE); >> next % SAMPLE_SIZE == 0 // next could be a uint, couldn?t it? >> double time_per_iter = (stop_time - start_time) * (1.0/SAMPLE_SIZE); >> >> perhaps rewriting 1.0/SAMPLE_SIZE as another static const as necessary >> to get it properly precalculated; I?m not sure what C++ compilers are >> doing nowadays. > > I am optimizing :) by avoiding % and / operations. But I agree and can > add SAMPLE_SIZE constant so code can be more clear. > > Thanks, > Vladimir > >> >> An alternate approach would be to compute the overall rate thus far, >> checking at >> (say) iterations 4, 8, 16, 32, etc and computing the average from >> there, starting >> at whatever power of two is a decent fraction of the iterations needed >> to timeout. >> >> e.g., don?t reset start_time, just compute elapsed at each sample: >> >> if ((next & (ptwo - 1) == 0) { >> time.stop(); >> double elapsed = time.seconds() - start_time; >> double projected = elapsed * (double) java_objects_length / next; >> >> Or you can compute a java_objects_length that would surely lead to >> failure, and >> always do that (fast, integer) comparison: >> ... >> unsigned int length_bound = (int) next * (CG_BUILD_TIME_LIMIT / >> elapsed) >> ? >> if (java_objects_length > length_bound) { ? timeout >> >> David >> >> On 2014-10-10, at 11:41 PM, Vladimir Kozlov >> wrote: >> >>> https://bugs.openjdk.java.net/browse/JDK-8041984 >>> http://cr.openjdk.java.net/~kvn/8041984/webrev/ >>> >>> Next method puts C2's EA to its knees: >>> >>> com.graphhopper.coll.GHLongIntBTree$BTreeEntry::put() >>> >>> https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/coll/GHLongIntBTree.java >>> >>> >>> It shows that current EA connection graph build code is very >>> inefficient when a graph has a lot of connections (edges). >>> >>> With inlining the BTreeEntry::put() method has about 100 allocations >>> from which about 80 are arrays allocations. Most of them are object >>> arrays which are generated by Arrays.copyOf(). After number of edges >>> in EA Connection Graph reaches about 50000 it takes more then 1 sec >>> to find all nodes which reference an allocation. >>> >>> Current EA code has bailout by timeout from graph building code. But >>> the timeout (30 sec for product VM) is checked only after all object >>> nodes are processed. So it may take > 2 mins before EA is aborted: >>> >>> >>> >>> >> stamp='150.967'/> >>> >>> Also ConnectionGraph::add_java_object_edges() method does not check >>> the presence of a node when it adds new one to the worklist (in >>> add_to_worklist() method). Which leads to hundreds MB of used by EA >>> memory when BTreeEntry::put() is processed. >>> >>> To address issues new timeout checks were added. >>> New _pidx index field is added to graph's nodes and VectorSet is used >>> to reduce size of worklist in add_java_object_edges() method. >>> >>> Escaping node CreateEx is mapped phantom_obj to reduce number of >>> process objects in connection graph. We do the same for other >>> escaping objects. >>> >>> Tested with graphhopper server application: >>> >>> >>> >>> >> stamp='22.355'/> >>> >>> Thanks, >>> Vladimir >> From david.holmes at oracle.com Wed Oct 15 00:02:28 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Oct 2014 10:02:28 +1000 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543D39FC.5020204@oracle.com> References: <543CD6E1.3090305@oracle.com> <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> <543D39FC.5020204@oracle.com> Message-ID: <543DB994.8090203@oracle.com> Tobias's change is fine but I get worried when I see: // This is a short non-blocking critical region, so the no safepoint check is ok. as that is only one of the conditions needed to allow locking without safepoint checks! David H. On 15/10/2014 12:58 AM, Vladimir Kozlov wrote: > Looks good. Should be reviewed by runtime too since changes are in > instanceKlass.cpp > > Thanks, > Vlaidmir > > On 10/14/14 5:54 AM, David Chase wrote: >> Hello Tobias, >> >> Not a Reviewer here, but it looks correct to me. >> One question ? above I see a NEEDS_CLEANUP notation. >> Do we know (does someone know?) if it refers to this change? >> If so, we could remove that :-). >> >> David >> >> On 2014-10-14, at 3:55 AM, Tobias Hartmann >> wrote: >> >>> Hi, >>> >>> please review this small code cleanup that replaces the explicit >>> locking of OsrList_lock by a MutexLockerEx instantiation. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ >>> >>> Thanks, >>> Tobias >> From dean.long at oracle.com Wed Oct 15 00:59:22 2014 From: dean.long at oracle.com (Dean Long) Date: Tue, 14 Oct 2014 17:59:22 -0700 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543DB994.8090203@oracle.com> References: <543CD6E1.3090305@oracle.com> <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> <543D39FC.5020204@oracle.com> <543DB994.8090203@oracle.com> Message-ID: <543DC6EA.4070706@oracle.com> BTW, it looks like it does change the semantics slightly. This code is now executed inside the lock: 2881 if (best != NULL && best->comp_level() >= comp_level && match_level == false) { 2882 return best; 2883 } dl On 10/14/2014 5:02 PM, David Holmes wrote: > Tobias's change is fine but I get worried when I see: > > // This is a short non-blocking critical region, so the no safepoint > check is ok. > > as that is only one of the conditions needed to allow locking without > safepoint checks! > > David H. > > On 15/10/2014 12:58 AM, Vladimir Kozlov wrote: >> Looks good. Should be reviewed by runtime too since changes are in >> instanceKlass.cpp >> >> Thanks, >> Vlaidmir >> >> On 10/14/14 5:54 AM, David Chase wrote: >>> Hello Tobias, >>> >>> Not a Reviewer here, but it looks correct to me. >>> One question ? above I see a NEEDS_CLEANUP notation. >>> Do we know (does someone know?) if it refers to this change? >>> If so, we could remove that :-). >>> >>> David >>> >>> On 2014-10-14, at 3:55 AM, Tobias Hartmann >>> wrote: >>> >>>> Hi, >>>> >>>> please review this small code cleanup that replaces the explicit >>>> locking of OsrList_lock by a MutexLockerEx instantiation. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ >>>> >>>> Thanks, >>>> Tobias >>> From tobias.hartmann at oracle.com Wed Oct 15 06:04:09 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Oct 2014 08:04:09 +0200 Subject: [9] RFR(S): 8060215: per-method PrintIdealGraphLevel In-Reply-To: <543D6F13.5020108@oracle.com> References: <543D6F13.5020108@oracle.com> Message-ID: <543E0E59.2050203@oracle.com> Hi Zoltan, this looks good. Just a minor comment (parse.cpp): 2347 if(printer && printer->should_print(_method)) { I prefer having a whitespace after the 'if' because it is more readable. Best, Tobias On 14.10.2014 20:44, Zolt?n Maj? wrote: > Hi, > > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8060215 > > Problem: Currently, printing the Ideal Graph can be only enabled for *all* > methods compiled by the VM (by setting the PrintIdealGraphLevel flag). The > overhead of printing the graph can be too high when a VM is debugged in a > resource-constrained environment (e.g., limited network bandwidth, limited disk > space, or a slow CPU is available). To reduce the overhed, it can be useful to > produce the Ideal Graph only for a subset of all methods compiled. By doing that > the size of the output file, the amount of data transferred on the network, and > also the overhead of printing the graph is reduced. > > Solution: > > - Use CompileCommand=option to set PrintIdealGraphLevel on a per-method level. > - PrintIdealGraphLevel sets the level of detail for printing all other methods. > - Introduce a new develop flag PrintIdealGraph to control/check if printing the > graph is enabled for any method. The old way of checking if PrintIdealGraphLevel > > 0 to see if printing is enabled is not good enough, because > PrintIdealGraphLevel flag can be 0 while PrintIdealGraphLevel can be set for > some method. > > Webrev: http://cr.openjdk.java.net/~zmajo/8060215/webrev.00/ > > Testing: JPRT, manual testing. > > Thank you and best regards, > > > Zoltan > From tobias.hartmann at oracle.com Wed Oct 15 06:09:46 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Oct 2014 08:09:46 +0200 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543D68E6.8080909@oracle.com> References: <543CD6E1.3090305@oracle.com> <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> <543D39FC.5020204@oracle.com> <543D3BA8.60802@oracle.com> <543D68E6.8080909@oracle.com> Message-ID: <543E0FAA.2010904@oracle.com> Thanks, Coleen. I will remove the NEEDS_CLEANUP tag. Best, Tobias On 14.10.2014 20:18, Coleen Phillimore wrote: > > This change looks good to me. I suggest since nobody knows why this is here, > that you remove it: > > // only one compilation can be active > NEEDS_CLEANUP > > It's old (from sccs): > > renes 99/08/30 // only one compilation can be active > kbr 00/02/22 NEEDS_CLEANUP > > > Coleen > > > On 10/14/14, 11:05 AM, Tobias Hartmann wrote: >> Thanks, David and Vladimir. >> >> On 14.10.2014 16:58, Vladimir Kozlov wrote: >>> Looks good. Should be reviewed by runtime too since changes are in >>> instanceKlass.cpp >>> >>> Thanks, >>> Vlaidmir >>> >>> On 10/14/14 5:54 AM, David Chase wrote: >>>> Hello Tobias, >>>> >>>> Not a Reviewer here, but it looks correct to me. >>>> One question ? above I see a NEEDS_CLEANUP notation. >>>> Do we know (does someone know?) if it refers to this change? >>>> If so, we could remove that :-). >> >> I don't know if this statement is related to my changes but I assume it refers >> to the comment '// only one compilation can be active'. Maybe someone from the >> runtime team knows. >> >> Thanks, >> Tobias >> >>>> David >>>> >>>> On 2014-10-14, at 3:55 AM, Tobias Hartmann wrote: >>>> >>>>> Hi, >>>>> >>>>> please review this small code cleanup that replaces the explicit locking of >>>>> OsrList_lock by a MutexLockerEx instantiation. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ >>>>> >>>>> Thanks, >>>>> Tobias >>>> > From tobias.hartmann at oracle.com Wed Oct 15 06:48:30 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Oct 2014 08:48:30 +0200 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543DB994.8090203@oracle.com> References: <543CD6E1.3090305@oracle.com> <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> <543D39FC.5020204@oracle.com> <543DB994.8090203@oracle.com> Message-ID: <543E18BE.6000403@oracle.com> Hi David, On 15.10.2014 02:02, David Holmes wrote: > Tobias's change is fine but I get worried when I see: > > // This is a short non-blocking critical region, so the no safepoint check is ok. > > as that is only one of the conditions needed to allow locking without safepoint > checks! What other conditions have to hold? Do you see a problem here? I think it should be fine as this is very old code that never failed before. Thanks, Tobias > David H. > > On 15/10/2014 12:58 AM, Vladimir Kozlov wrote: >> Looks good. Should be reviewed by runtime too since changes are in >> instanceKlass.cpp >> >> Thanks, >> Vlaidmir >> >> On 10/14/14 5:54 AM, David Chase wrote: >>> Hello Tobias, >>> >>> Not a Reviewer here, but it looks correct to me. >>> One question ? above I see a NEEDS_CLEANUP notation. >>> Do we know (does someone know?) if it refers to this change? >>> If so, we could remove that :-). >>> >>> David >>> >>> On 2014-10-14, at 3:55 AM, Tobias Hartmann >>> wrote: >>> >>>> Hi, >>>> >>>> please review this small code cleanup that replaces the explicit >>>> locking of OsrList_lock by a MutexLockerEx instantiation. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ >>>> >>>> Thanks, >>>> Tobias >>> From tobias.hartmann at oracle.com Wed Oct 15 06:59:52 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Oct 2014 08:59:52 +0200 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543DC6EA.4070706@oracle.com> References: <543CD6E1.3090305@oracle.com> <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> <543D39FC.5020204@oracle.com> <543DB994.8090203@oracle.com> <543DC6EA.4070706@oracle.com> Message-ID: <543E1B68.8030201@oracle.com> Hi Dean, On 15.10.2014 02:59, Dean Long wrote: > BTW, it looks like it does change the semantics slightly. This code is now > executed inside the lock: > > 2881 if (best != NULL && best->comp_level() >= comp_level && match_level == > false) { > 2882 return best; > 2883 } Yes, but that should be fine because the if statement only includes fast and simple integer/pointer comparisons. I think defining an own scope around the loop reduces code readability. What do you think? Best, Tobias > > dl > > On 10/14/2014 5:02 PM, David Holmes wrote: >> Tobias's change is fine but I get worried when I see: >> >> // This is a short non-blocking critical region, so the no safepoint check is ok. >> >> as that is only one of the conditions needed to allow locking without >> safepoint checks! >> >> David H. >> >> On 15/10/2014 12:58 AM, Vladimir Kozlov wrote: >>> Looks good. Should be reviewed by runtime too since changes are in >>> instanceKlass.cpp >>> >>> Thanks, >>> Vlaidmir >>> >>> On 10/14/14 5:54 AM, David Chase wrote: >>>> Hello Tobias, >>>> >>>> Not a Reviewer here, but it looks correct to me. >>>> One question ? above I see a NEEDS_CLEANUP notation. >>>> Do we know (does someone know?) if it refers to this change? >>>> If so, we could remove that :-). >>>> >>>> David >>>> >>>> On 2014-10-14, at 3:55 AM, Tobias Hartmann >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> please review this small code cleanup that replaces the explicit >>>>> locking of OsrList_lock by a MutexLockerEx instantiation. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ >>>>> >>>>> Thanks, >>>>> Tobias >>>> > From dean.long at oracle.com Wed Oct 15 07:05:33 2014 From: dean.long at oracle.com (Dean Long) Date: Wed, 15 Oct 2014 00:05:33 -0700 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543E1B68.8030201@oracle.com> References: <543CD6E1.3090305@oracle.com> <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> <543D39FC.5020204@oracle.com> <543DB994.8090203@oracle.com> <543DC6EA.4070706@oracle.com> <543E1B68.8030201@oracle.com> Message-ID: <543E1CBD.8030405@oracle.com> On 10/14/2014 11:59 PM, Tobias Hartmann wrote: > Hi Dean, > > On 15.10.2014 02:59, Dean Long wrote: >> BTW, it looks like it does change the semantics slightly. This code >> is now >> executed inside the lock: >> >> 2881 if (best != NULL && best->comp_level() >= comp_level && >> match_level == >> false) { >> 2882 return best; >> 2883 } > > Yes, but that should be fine because the if statement only includes > fast and simple integer/pointer comparisons. I think defining an own > scope around the loop reduces code readability. What do you think? > I agree. dl > Best, > Tobias > >> >> dl >> >> On 10/14/2014 5:02 PM, David Holmes wrote: >>> Tobias's change is fine but I get worried when I see: >>> >>> // This is a short non-blocking critical region, so the no safepoint >>> check is ok. >>> >>> as that is only one of the conditions needed to allow locking without >>> safepoint checks! >>> >>> David H. >>> >>> On 15/10/2014 12:58 AM, Vladimir Kozlov wrote: >>>> Looks good. Should be reviewed by runtime too since changes are in >>>> instanceKlass.cpp >>>> >>>> Thanks, >>>> Vlaidmir >>>> >>>> On 10/14/14 5:54 AM, David Chase wrote: >>>>> Hello Tobias, >>>>> >>>>> Not a Reviewer here, but it looks correct to me. >>>>> One question ? above I see a NEEDS_CLEANUP notation. >>>>> Do we know (does someone know?) if it refers to this change? >>>>> If so, we could remove that :-). >>>>> >>>>> David >>>>> >>>>> On 2014-10-14, at 3:55 AM, Tobias Hartmann >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> please review this small code cleanup that replaces the explicit >>>>>> locking of OsrList_lock by a MutexLockerEx instantiation. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>> >> From david.holmes at oracle.com Wed Oct 15 08:02:22 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Oct 2014 18:02:22 +1000 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543E18BE.6000403@oracle.com> References: <543CD6E1.3090305@oracle.com> <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> <543D39FC.5020204@oracle.com> <543DB994.8090203@oracle.com> <543E18BE.6000403@oracle.com> Message-ID: <543E2A0E.8030501@oracle.com> On 15/10/2014 4:48 PM, Tobias Hartmann wrote: > Hi David, > > On 15.10.2014 02:02, David Holmes wrote: >> Tobias's change is fine but I get worried when I see: >> >> // This is a short non-blocking critical region, so the no safepoint >> check is ok. >> >> as that is only one of the conditions needed to allow locking without >> safepoint >> checks! > > What other conditions have to hold? Do you see a problem here? I think > it should be fine as this is very old code that never failed before. If any use of a lock avoids the safepoint check then "all"* uses of the lock must avoid the safepoint check, and it must be impossible to block at a safepoint while the lock is held. *There can be exceptions if the lock is only used by specific threads in specific circumstances. It seems the only uses of this lock are in the code you changed so it appears ok - just wanted to highlight a common misconception about when it is okay to skip the safepoint checks. Though really any such code should have a No_Safepoint_Verifier in the locked region (at least in debug mode). Curiously the uses of the MemberNameTable_lock in the same file all have the No_Safepoint_Verifier but don't elide the safepoint check when locking. Cheers, David > Thanks, > Tobias > >> David H. >> >> On 15/10/2014 12:58 AM, Vladimir Kozlov wrote: >>> Looks good. Should be reviewed by runtime too since changes are in >>> instanceKlass.cpp >>> >>> Thanks, >>> Vlaidmir >>> >>> On 10/14/14 5:54 AM, David Chase wrote: >>>> Hello Tobias, >>>> >>>> Not a Reviewer here, but it looks correct to me. >>>> One question ? above I see a NEEDS_CLEANUP notation. >>>> Do we know (does someone know?) if it refers to this change? >>>> If so, we could remove that :-). >>>> >>>> David >>>> >>>> On 2014-10-14, at 3:55 AM, Tobias Hartmann >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> please review this small code cleanup that replaces the explicit >>>>> locking of OsrList_lock by a MutexLockerEx instantiation. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ >>>>> >>>>> Thanks, >>>>> Tobias >>>> From tobias.hartmann at oracle.com Wed Oct 15 08:09:20 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Oct 2014 10:09:20 +0200 Subject: [9] RFR(S): 8059846: InstanceKlass should use MutexLockerEx to acquire OsrList_lock In-Reply-To: <543E2A0E.8030501@oracle.com> References: <543CD6E1.3090305@oracle.com> <48F7A649-6BBF-46BC-BDB9-1FC56D11C503@oracle.com> <543D39FC.5020204@oracle.com> <543DB994.8090203@oracle.com> <543E18BE.6000403@oracle.com> <543E2A0E.8030501@oracle.com> Message-ID: <543E2BB0.5090000@oracle.com> Hi David, On 15.10.2014 10:02, David Holmes wrote: > On 15/10/2014 4:48 PM, Tobias Hartmann wrote: >> Hi David, >> >> On 15.10.2014 02:02, David Holmes wrote: >>> Tobias's change is fine but I get worried when I see: >>> >>> // This is a short non-blocking critical region, so the no safepoint >>> check is ok. >>> >>> as that is only one of the conditions needed to allow locking without >>> safepoint >>> checks! >> >> What other conditions have to hold? Do you see a problem here? I think >> it should be fine as this is very old code that never failed before. > > If any use of a lock avoids the safepoint check then "all"* uses of the lock > must avoid the safepoint check, and it must be impossible to block at a > safepoint while the lock is held. > > *There can be exceptions if the lock is only used by specific threads in > specific circumstances. > > It seems the only uses of this lock are in the code you changed so it appears ok > - just wanted to highlight a common misconception about when it is okay to skip > the safepoint checks. Though really any such code should have a > No_Safepoint_Verifier in the locked region (at least in debug mode). Curiously > the uses of the MemberNameTable_lock in the same file all have the > No_Safepoint_Verifier but don't elide the safepoint check when locking. Okay, thanks for pointing that out. Best, Tobias > > Cheers, > David > >> Thanks, >> Tobias >> >>> David H. >>> >>> On 15/10/2014 12:58 AM, Vladimir Kozlov wrote: >>>> Looks good. Should be reviewed by runtime too since changes are in >>>> instanceKlass.cpp >>>> >>>> Thanks, >>>> Vlaidmir >>>> >>>> On 10/14/14 5:54 AM, David Chase wrote: >>>>> Hello Tobias, >>>>> >>>>> Not a Reviewer here, but it looks correct to me. >>>>> One question ? above I see a NEEDS_CLEANUP notation. >>>>> Do we know (does someone know?) if it refers to this change? >>>>> If so, we could remove that :-). >>>>> >>>>> David >>>>> >>>>> On 2014-10-14, at 3:55 AM, Tobias Hartmann >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> please review this small code cleanup that replaces the explicit >>>>>> locking of OsrList_lock by a MutexLockerEx instantiation. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8059846 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8059846/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>> From tobias.hartmann at oracle.com Wed Oct 15 08:47:07 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Oct 2014 10:47:07 +0200 Subject: [9] RFR(S): [TESTBUG] Whitebox tests fail with -XX:CompileThreshold=100 Message-ID: <543E348B.6060103@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8060454 Webrev: http://cr.openjdk.java.net/~thartmann/8060454/webrev.00/ Problem: The problem is that with a low CompileThreshold we execute the loop to trigger osr compilation fewer times. While the osr compilation should be triggered there is still a non-osr compilation request in the compile queue and therefore the osr compilation fails (see 'compilation_is_in_queue(method)' check in 'CompileBroker::compile_method_base'). Solution: I moved the call to 'waitAndDeoptimize' from the warmup methods to the osr triggering methods to make sure that no non-osr compilation is in the queue after warmup. Maybe we should think about allowing both osr and non-osr compilations in the compile queue at the same time. Currently, we check this with the access flag 'JVM_ACC_QUEUED'. Unfortunately, it is not possible to simply add a new flag for osr compilations because all bitmasks are taken. Testing: Executed failing tests on JPRT with different VM options (this time including -XX:CompileThreshold). Results are attached to bug. Thanks, Tobias From zoltan.majo at oracle.com Wed Oct 15 08:54:52 2014 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 15 Oct 2014 10:54:52 +0200 Subject: [9] RFR(S): 8060215: per-method PrintIdealGraphLevel In-Reply-To: <543E0E59.2050203@oracle.com> References: <543D6F13.5020108@oracle.com> <543E0E59.2050203@oracle.com> Message-ID: <543E365C.9030706@oracle.com> Thank you Dean, Vladimir, and Tobias for the feedback! On 10/15/2014 08:04 AM, Tobias Hartmann wrote: > Hi Zoltan, > > this looks good. Just a minor comment (parse.cpp): > > 2347 if(printer && printer->should_print(_method)) { > > I prefer having a whitespace after the 'if' because it is more readable. I corrected that. Thank you and best regards, Zoltan > > Best, > Tobias > > On 14.10.2014 20:44, Zolt?n Maj? wrote: >> Hi, >> >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8060215 >> >> Problem: Currently, printing the Ideal Graph can be only enabled for >> *all* >> methods compiled by the VM (by setting the PrintIdealGraphLevel >> flag). The >> overhead of printing the graph can be too high when a VM is debugged >> in a >> resource-constrained environment (e.g., limited network bandwidth, >> limited disk >> space, or a slow CPU is available). To reduce the overhed, it can be >> useful to >> produce the Ideal Graph only for a subset of all methods compiled. By >> doing that >> the size of the output file, the amount of data transferred on the >> network, and >> also the overhead of printing the graph is reduced. >> >> Solution: >> >> - Use CompileCommand=option to set PrintIdealGraphLevel on a >> per-method level. >> - PrintIdealGraphLevel sets the level of detail for printing all >> other methods. >> - Introduce a new develop flag PrintIdealGraph to control/check if >> printing the >> graph is enabled for any method. The old way of checking if >> PrintIdealGraphLevel >> > 0 to see if printing is enabled is not good enough, because >> PrintIdealGraphLevel flag can be 0 while PrintIdealGraphLevel can be >> set for >> some method. >> >> Webrev: http://cr.openjdk.java.net/~zmajo/8060215/webrev.00/ >> >> Testing: JPRT, manual testing. >> >> Thank you and best regards, >> >> >> Zoltan >> From igor.veresov at oracle.com Wed Oct 15 09:18:13 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 15 Oct 2014 02:18:13 -0700 Subject: [9] RFR (XS) 8059139: It should be possible to explicitly disable usage of TZCNT instr w/ -XX:-UseBMI1Instructions In-Reply-To: <54385A54.3000008@oracle.com> References: <54385A54.3000008@oracle.com> Message-ID: Looks good. igor On Oct 10, 2014, at 3:14 PM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8059139 > http://cr.openjdk.java.net/~kvn/8059139/webrev/ > > Before JDK-8055494 it was possible to disable usage of all BMI1-related instructions by passing -XX:-UseBMI1Instructions to JVM, but fix for JDK-8055494 made it impossible to disable usage of TZCNT. > > Disable TZCNT with -XX:-UseBMI1Instructions flag specified on command line. > > Testing jtreg,jprt From vladimir.kozlov at oracle.com Wed Oct 15 09:51:40 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Oct 2014 02:51:40 -0700 Subject: [9] RFR (XS) 8059139: It should be possible to explicitly disable usage of TZCNT instr w/ -XX:-UseBMI1Instructions In-Reply-To: References: <54385A54.3000008@oracle.com> Message-ID: <543E43AC.5080108@oracle.com> Thank you, Igor Vladimir On 10/15/14 2:18 AM, Igor Veresov wrote: > Looks good. > > igor > > On Oct 10, 2014, at 3:14 PM, Vladimir Kozlov wrote: > >> https://bugs.openjdk.java.net/browse/JDK-8059139 >> http://cr.openjdk.java.net/~kvn/8059139/webrev/ >> >> Before JDK-8055494 it was possible to disable usage of all BMI1-related instructions by passing -XX:-UseBMI1Instructions to JVM, but fix for JDK-8055494 made it impossible to disable usage of TZCNT. >> >> Disable TZCNT with -XX:-UseBMI1Instructions flag specified on command line. >> >> Testing jtreg,jprt > From tobias.hartmann at oracle.com Wed Oct 15 11:11:21 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Oct 2014 13:11:21 +0200 Subject: [9] RFR(S): 8060196: CodeHeap for 'non-nmethods' is full In-Reply-To: <543BE976.1070303@oracle.com> References: <543BCD48.5080508@oracle.com> <543BE2E8.50704@oracle.com> <543BE850.5020303@oracle.com> <543BE976.1070303@oracle.com> Message-ID: <543E5659.5080201@oracle.com> Hi Albert, On 13.10.2014 17:02, Albert Noll wrote: > Hi Tobias, > > I would wait until 8046809 is reviewed. Doing modifications to a function that > is being discussed to remove does not make sense. Yes, I agree. I changed the webrev to only fix the output of the "code heap is full" message: http://cr.openjdk.java.net/~thartmann/8060196/webrev.01/ I added a comment to the bug. Thanks, Tobias > Best, > Albert > > On 10/13/2014 04:57 PM, Tobias Hartmann wrote: >> Hi Albert, >> >> On 13.10.2014 16:34, Albert Noll wrote: >>> Hi Tobias, >>> >>> 8046809 (which is currently under review) removes that check. Does removing the >>> check fix the bug? >> >> Yes, but the output (see 'CodeCache::report_codemem_full') is still wrong. Do >> you think I should only fix the output and wait for your fix to remove the >> 'is_full' check? >> >> Thanks, >> Tobias >> >>> Best, >>> Albert >>> >>> On 10/13/2014 03:02 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060196 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060196/webrev.00/ >>>> >>>> Problem: >>>> CodeCache::is_full() returns true if the non-nmethod code heap is full but we >>>> can still store non-nmethod code in the non-profiled code heap and therefore >>>> should not disable compilation (see comment 'fallback solution' in >>>> CodeCache::allocate). >>>> >>>> Solution: >>>> Adapt CodeCache::is_full() to not check the non-nmethod code heap. I also >>>> fixed the CodeHeap is full warning to suggest increasing the non-profiled code >>>> heap. >>>> >>>> Thanks, >>>> Tobias >>> > From zoltan.majo at oracle.com Wed Oct 15 11:41:41 2014 From: zoltan.majo at oracle.com (=?windows-1252?Q?Zolt=E1n_Maj=F3?=) Date: Wed, 15 Oct 2014 13:41:41 +0200 Subject: [9] RFR(S): 8059604: Add CompileThresholdScalingPercentage flag to control when methods are first compiled (with +/-TieredCompilation) In-Reply-To: <543D8AF3.9050500@oracle.com> References: <5433C140.9070400@oracle.com> <5433C6C6.20602@oracle.com> <5433EE7A.9060607@oracle.com> <0DBAED7F-65DF-4D15-AFDB-636DF7F70C16@oracle.com> <5436BB16.7010703@oracle.com> <2F9E5CC6-F48F-4250-8D78-5C1AC9BAB82C@oracle.com> <54379061.5070506@oracle.com> <54383F51.3080500@oracle.com> <543D6876.1020701@oracle.com> <543D8AF3.9050500@oracle.com> Message-ID: <543E5D75.2090006@oracle.com> Thank you, Vladimir, for the feedback! Best regards, Zoltan On 10/14/2014 10:43 PM, Vladimir Kozlov wrote: > This looks good. > > Thanks, > Vladimir > > On 10/14/14 11:16 AM, Zolt?n Maj? wrote: >> Hi Vladimir, >> >> >> thank you for your comments! >> >> On 10/10/2014 10:19 PM, Vladimir Kozlov wrote: >>> Zoltan, >>> >>> Please, add test. There is -XX:+PrintFlagsFinal which will print all >>> flags after all adjustments so you can verify that thresholds flags >>> are correctly scaled. Check CompileThresholdScaling value corner cases >>> too. >> >> I added compiler/arguments/CheckCompileThresholdScaling.java to check >> the scaling of flags. >> >>> Also I would like to see explicit casts to (intx) after multiplication. >>> May be add an other Arguments method which do just multiplication by >>> CompileThresholdScaling and cast to return intx. >> >> I added a new function, Arguments::get_scaled_compile_threshold(), that >> does the scaling and also casts the result of the scaling explicitly. >> >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~zmajo/8059604/webrev.03/ >> >> All JPRT tests pass. >> >> Thank you and best regards, >> >> >> Zoltan >> >>> >>> Thanks, >>> Vladimir >>> >>> On 10/10/14 12:53 AM, Zolt?n Maj? wrote: >>>> Thank you, Igor, for the review. >>>> >>>> Could somebody please provide a second Reviewer's review? I think the >>>> change is too large to be pushed with only one "Review". >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> >>>> >>>> Zoltan >>>> >>>> On 10/09/2014 08:58 PM, Igor Veresov wrote: >>>>> That looks good to me. >>>>> >>>>> igor >>>>> >>>>> On Oct 9, 2014, at 9:43 AM, Zolt?n Maj? >>>>> wrote: >>>>> >>>>>> Hi Igor, >>>>>> >>>>>> >>>>>> thank you for your feedback! >>>>>> >>>>>> On 10/07/2014 11:17 PM, Igor Veresov wrote: >>>>>>> 1. It would probably be nice not to do multiplications at every >>>>>>> event but rather compute everything once during the startup. >>>>>>> Perhaps >>>>>>> it would be better to scale command line options right in >>>>>>> arguments.cpp ? Or setup accessors in Arguments that would compute >>>>>>> and cache the values. If you just scale the options the change >>>>>>> would >>>>>>> be smaller though. What do you think? >>>>>> That is a good idea. I changed the code to scale thresholds in >>>>>> arguments.cpp (in Arguments::apply_ergo()). >>>>>> >>>>>>> 2. Why aren?t you scaling Tier{2,3}{Invoke,Backedge}NotifyFreqLog >>>>>>> and Tier23InlineeNotifyFreqLog? Probably can be solved by (1) >>>>>>> automatically. >>>>>> The previous patch adjusts only the transition from Tier 0 to Tier 3 >>>>>> (when methods get first compiled). But now that you've suggested, I >>>>>> extended the patch to scale Tier4* compilation thresholds and >>>>>> Tier{2,3} notification thresholds as well. >>>>>> >>>>>> Here is the updated webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~zmajo/8059604/webrev.02/ >>>>>> >>>>>> I tested the new patch with JPRT and manual testing. >>>>>> >>>>>> Thank you and best regards, >>>>>> >>>>>> >>>>>> Zoltan >>>>>> >>>>>>> igor >>>>>>> >>>>>>> On Oct 7, 2014, at 6:45 AM, Zolt?n Maj? >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Albert, >>>>>>>> >>>>>>>> >>>>>>>> thank you for your feedback. >>>>>>>> >>>>>>>> On 10/07/2014 12:56 PM, Albert Noll wrote: >>>>>>>>> How about using a scaling factor instead of using percentage? >>>>>>>> I think that is a good idea because a scaling factor (expressed as >>>>>>>> a double) allows a finer-grained control of compilation thresholds >>>>>>>> than a scaling percentage (expressed as an integer). >>>>>>>> >>>>>>>> Here is the webrev with the scaling factor: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~zmajo/8059604/webrev.01/ >>>>>>>> >>>>>>>> The name of the flag is changed to CompileThresholdScaling (from >>>>>>>> CompileThresholdScalingPercentage). >>>>>>>> >>>>>>>>> What happens if a threshold becomes 0 after scaling? >>>>>>>> Then all methods will be interpreted. That seems to be the >>>>>>>> convention (in src/share/vm/runtime/arguments.cpp). >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> >>>>>>>> Zoltan >>>>>>>> >>>>>>>>> Best, >>>>>>>>> Albert >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/07/2014 12:32 PM, Zolt?n Maj? wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> please review the following patch. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Bug:https://bugs.openjdk.java.net/browse/JDK-8059604 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Problem: With tiered compilation enabled, the value of 6 >>>>>>>>>> different thresholds must be set to control when the JVM >>>>>>>>>> compiles >>>>>>>>>> methods for the first time. That is too detailed for the average >>>>>>>>>> customer. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Solution: This patch adds a new flag, >>>>>>>>>> CompileThresholdScalingPercentage, to control when methods are >>>>>>>>>> first compiled. The new flag scales thresholds the following >>>>>>>>>> way: >>>>>>>>>> >>>>>>>>>> - if CompileThresholdScalingPercentage==100, the default >>>>>>>>>> threshold values are used >>>>>>>>>> - if CompileThresholdScalingPercentage>100, threshold values are >>>>>>>>>> scaled up (e.g., CompileThresholdScalingPercentage=120 scales up >>>>>>>>>> thresholds by a factor of 1.2X) >>>>>>>>>> - if 0 < CompileThresholdScalingPercentage < 100, threshold >>>>>>>>>> values are scaled down accordingly. >>>>>>>>>> >>>>>>>>>> The new flag works both with and without tiered compilation. >>>>>>>>>> Thus, the new flag allows compilation to be controlled the same >>>>>>>>>> way both with and without tiered compilation: >>>>>>>>>> >>>>>>>>>> - with tiered compilation enabled, the value of the flags >>>>>>>>>> Tier0InvokeNotifyFreqLog, Tier0BackedgeNotifyFreqLog, >>>>>>>>>> Tier3InvocationThreshold, Tier3MinInvocationThreshold, >>>>>>>>>> Tier3CompileThreshold, and Tier3BackEdgeThreshold is scaled >>>>>>>>>> >>>>>>>>>> - with tiered compilation disabled, the value of >>>>>>>>>> CompileThreshold >>>>>>>>>> is scaled >>>>>>>>>> >>>>>>>>>> Currently, tiered and non-tiered compilation treats threshold >>>>>>>>>> values slightly differently: For a threshold value of N and >>>>>>>>>> without tiered compilation enabled, methods are compiled >>>>>>>>>> *before* >>>>>>>>>> their Nth execution. With tiered compilation enabled, methods >>>>>>>>>> are >>>>>>>>>> compiled *after* the their Nth execution. >>>>>>>>>> >>>>>>>>>> The patch addresses the difference between tiered/non-tiered >>>>>>>>>> compilation: Methods are compiled right before their Nth >>>>>>>>>> execution in both cases (the non-tiered way). If >>>>>>>>>> CompileThresholdScalingPercentage==0, all methods are >>>>>>>>>> interpreted >>>>>>>>>> (similarly to the case when CompileThreshold==0). >>>>>>>>>> >>>>>>>>>> This patch is the second (out of three) parts of JDK-8050853 >>>>>>>>>> (adding support for per-compilation >>>>>>>>>> thresholds):https://bugs.openjdk.java.net/browse/JDK-8050853 . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Webrev:http://cr.openjdk.java.net/~zmajo/8059604/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Testing: JPRT, manual testing >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thank you and best regards, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Zoltan >>>>>>>>>> >>>> >> From tobias.hartmann at oracle.com Wed Oct 15 14:19:57 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 15 Oct 2014 16:19:57 +0200 Subject: [9] RFR(S): 8060479: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java test fails with product build Message-ID: <543E828D.6050205@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8060479 Webrev: http://cr.openjdk.java.net/~thartmann/8060479/webrev.00/ Problem: The test CheckSegmentedCodeCache assumes that VM startup always fails with a ReservedCodeCacheSize of 1700K. This is not true for product builds (see 'min_code_cache_size' in 'CodeCache::initialize_heaps()'). Solution: Check for debug build and adjust minimum code cache size accordingly. Testing: Failing test on JPRT. Thanks, Tobias From david.r.chase at oracle.com Wed Oct 15 17:37:17 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 15 Oct 2014 13:37:17 -0400 Subject: [9] RFR(S): 8060479: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java test fails with product build In-Reply-To: <543E828D.6050205@oracle.com> References: <543E828D.6050205@oracle.com> Message-ID: <86DFDC02-AFA8-4BBE-8557-4C45777A099B@oracle.com> Hello Tobias, I am not a Reviewer, but that looks good to me. I would add a comment to the bug itself making sure that you clarify what is going on. Current text overuses the word ?failure? without making it ?clear? that the ?failure? is a failure to fail; that the test is verifies that the VM will exit with an error when the code cache is too small, but in turns out that a release VM can run in a small enough code cache that the size used by the test is in fact, not too small, and thus no error is seen, and thus the test is judged to have failed. I?m not sure I was any better at explaining it :-(. The intent is to make someone less puzzled when they look at this six months from now. David On 2014-10-15, at 10:19 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8060479 > Webrev: http://cr.openjdk.java.net/~thartmann/8060479/webrev.00/ > > Problem: > The test CheckSegmentedCodeCache assumes that VM startup always fails with a ReservedCodeCacheSize of 1700K. This is not true for product builds (see 'min_code_cache_size' in 'CodeCache::initialize_heaps()'). > > Solution: > Check for debug build and adjust minimum code cache size accordingly. > > Testing: > Failing test on JPRT. > > Thanks, > Tobias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From david.r.chase at oracle.com Wed Oct 15 18:11:05 2014 From: david.r.chase at oracle.com (David Chase) Date: Wed, 15 Oct 2014 14:11:05 -0400 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <543D847A.7020407@oracle.com> References: <54386E92.3000006@oracle.com> <3976AC9A-9D8F-4520-89A7-37A697DA1B92@oracle.com> <1B318630-8544-4FC9-BC7A-9F0BA04EB666@oracle.com> <543D847A.7020407@oracle.com> Message-ID: <7708AD6E-AE45-463C-8351-87374C1CC3B8@oracle.com> The changes look good to me; did you find anything more out about Paul Sandoz?s problem? David On 2014-10-14, at 4:15 PM, Vladimir Kozlov wrote: > Thank you, Paul > > I will look on that. > > Vladimir > > On 10/14/14 9:58 AM, Paul Sandoz wrote: >> Here is a simpler test case that just uses a MH to Class.cast that exhibits the same behaviour. >> >> The commented out use of the BiFunction created from a lambda expressions works fine. >> >> This suggests there might be something about the MH invocation that is stopping the optimization from kicking in. >> >> Paul. >> >> import java.lang.invoke.MethodHandle; >> import java.lang.invoke.MethodHandles; >> import java.lang.invoke.MethodType; >> import java.util.function.BiFunction; >> >> public class NullCheckDroppingsMHCastTest { >> >> static final MethodHandle MH_CAST; >> >> static { >> try { >> MH_CAST = MethodHandles.lookup().findVirtual(Class.class, >> "cast", >> MethodType.methodType(Object.class, Object.class)); >> } >> catch (Exception e) { >> throw new Error(e); >> } >> } >> >> static final BiFunction fCast = (c, o) -> c.cast(o); >> >> >> volatile String svalue = "A"; >> volatile String snull = null; >> String ssink; >> >> public static void main(String[] args) { >> NullCheckDroppingsMHCastTest t = new NullCheckDroppingsMHCastTest(); >> t.testLoop(); >> } >> >> void testLoop() { >> // Ensure testLoopOne is compiled and does not >> // see a null value >> for (int i = 0; i < 1000000; i++) { >> testLoopOne(svalue); >> // Uncomment the following and the call outside >> // the loop should not result in any deoptimization >> // testLoopOne(snull); >> } >> >> // Sleep just to create delay in the compilation log >> try { >> Thread.currentThread().sleep(1000); >> } >> catch (Exception e) { >> } >> >> // This should cause a de-optimisation >> // if testLoopOne is compiled with a null-check >> testLoopOne(snull); >> } >> >> void testLoopOne(String s) { >> try { >> ssink = (String) (Object) MH_CAST.invokeExact(String.class, (Object) s); >> // ssink = (String) fCast.apply(String.class, s); >> } >> catch (Throwable t) { >> throw new Error(t); >> } >> } >> } >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Wed Oct 15 19:39:18 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Oct 2014 12:39:18 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <7708AD6E-AE45-463C-8351-87374C1CC3B8@oracle.com> References: <54386E92.3000006@oracle.com> <3976AC9A-9D8F-4520-89A7-37A697DA1B92@oracle.com> <1B318630-8544-4FC9-BC7A-9F0BA04EB666@oracle.com> <543D847A.7020407@oracle.com> <7708AD6E-AE45-463C-8351-87374C1CC3B8@oracle.com> Message-ID: <543ECD66.20608@oracle.com> Thank you, David I do not have time to investigate new Paul's cases. I will do that most likely next week and I will send new updated webrev. And I will add test. So we can delay review for this until then. Thanks, Vladimir On 10/15/14 11:11 AM, David Chase wrote: > The changes look good to me; > did you find anything more out about Paul Sandoz?s problem? > > David > > > On 2014-10-14, at 4:15 PM, Vladimir Kozlov wrote: > >> Thank you, Paul >> >> I will look on that. >> >> Vladimir >> >> On 10/14/14 9:58 AM, Paul Sandoz wrote: >>> Here is a simpler test case that just uses a MH to Class.cast that exhibits the same behaviour. >>> >>> The commented out use of the BiFunction created from a lambda expressions works fine. >>> >>> This suggests there might be something about the MH invocation that is stopping the optimization from kicking in. >>> >>> Paul. >>> >>> import java.lang.invoke.MethodHandle; >>> import java.lang.invoke.MethodHandles; >>> import java.lang.invoke.MethodType; >>> import java.util.function.BiFunction; >>> >>> public class NullCheckDroppingsMHCastTest { >>> >>> static final MethodHandle MH_CAST; >>> >>> static { >>> try { >>> MH_CAST = MethodHandles.lookup().findVirtual(Class.class, >>> "cast", >>> MethodType.methodType(Object.class, Object.class)); >>> } >>> catch (Exception e) { >>> throw new Error(e); >>> } >>> } >>> >>> static final BiFunction fCast = (c, o) -> c.cast(o); >>> >>> >>> volatile String svalue = "A"; >>> volatile String snull = null; >>> String ssink; >>> >>> public static void main(String[] args) { >>> NullCheckDroppingsMHCastTest t = new NullCheckDroppingsMHCastTest(); >>> t.testLoop(); >>> } >>> >>> void testLoop() { >>> // Ensure testLoopOne is compiled and does not >>> // see a null value >>> for (int i = 0; i < 1000000; i++) { >>> testLoopOne(svalue); >>> // Uncomment the following and the call outside >>> // the loop should not result in any deoptimization >>> // testLoopOne(snull); >>> } >>> >>> // Sleep just to create delay in the compilation log >>> try { >>> Thread.currentThread().sleep(1000); >>> } >>> catch (Exception e) { >>> } >>> >>> // This should cause a de-optimisation >>> // if testLoopOne is compiled with a null-check >>> testLoopOne(snull); >>> } >>> >>> void testLoopOne(String s) { >>> try { >>> ssink = (String) (Object) MH_CAST.invokeExact(String.class, (Object) s); >>> // ssink = (String) fCast.apply(String.class, s); >>> } >>> catch (Throwable t) { >>> throw new Error(t); >>> } >>> } >>> } >>> > From vladimir.kozlov at oracle.com Thu Oct 16 01:26:02 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Oct 2014 18:26:02 -0700 Subject: [9] RFR(S): [TESTBUG] Whitebox tests fail with -XX:CompileThreshold=100 In-Reply-To: <543E348B.6060103@oracle.com> References: <543E348B.6060103@oracle.com> Message-ID: <543F1EAA.1050504@oracle.com> On 10/15/14 1:47 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8060454 > Webrev: http://cr.openjdk.java.net/~thartmann/8060454/webrev.00/ > > Problem: > The problem is that with a low CompileThreshold we execute the loop to trigger osr compilation fewer times. While the > osr compilation should be triggered there is still a non-osr compilation request in the compile queue and therefore the > osr compilation fails (see 'compilation_is_in_queue(method)' check in 'CompileBroker::compile_method_base'). This is strange. OSR (backbranch count) threshold should be reached before invocation count threshold. OSR threshold is calculated as invocation threshold * 1.3 (OnStackReplacePercentage flag). So for 100, OSR threshold should be 130. Do you know why we get normal compilation in queue? Did we deoptimized first OSR compilation? In this case osr test is not correct - it should not trigger deoptimization. Thanks, Vladimir > > Solution: > I moved the call to 'waitAndDeoptimize' from the warmup methods to the osr triggering methods to make sure that no > non-osr compilation is in the queue after warmup. > > Maybe we should think about allowing both osr and non-osr compilations in the compile queue at the same time. Currently, > we check this with the access flag 'JVM_ACC_QUEUED'. Unfortunately, it is not possible to simply add a new flag for osr > compilations because all bitmasks are taken. > > Testing: > Executed failing tests on JPRT with different VM options (this time including -XX:CompileThreshold). Results are > attached to bug. > > Thanks, > Tobias From vladimir.kozlov at oracle.com Thu Oct 16 01:36:04 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 Oct 2014 18:36:04 -0700 Subject: [9] RFR(S): 8060196: CodeHeap for 'non-nmethods' is full In-Reply-To: <543E5659.5080201@oracle.com> References: <543BCD48.5080508@oracle.com> <543BE2E8.50704@oracle.com> <543BE850.5020303@oracle.com> <543BE976.1070303@oracle.com> <543E5659.5080201@oracle.com> Message-ID: <543F2104.6040205@oracle.com> Should you add and use CodeCache::get_code_heap_flag_name(code_blob_type) instead? You have more segments types the these two. May be change bug's Synopsis since you not fixing what it is filed for. Thanks, Vladimir On 10/15/14 4:11 AM, Tobias Hartmann wrote: > Hi Albert, > > On 13.10.2014 17:02, Albert Noll wrote: >> Hi Tobias, >> >> I would wait until 8046809 is reviewed. Doing modifications to a function that >> is being discussed to remove does not make sense. > > Yes, I agree. I changed the webrev to only fix the output of the "code heap is full" message: > > http://cr.openjdk.java.net/~thartmann/8060196/webrev.01/ > > I added a comment to the bug. > > Thanks, > Tobias > > >> Best, >> Albert >> >> On 10/13/2014 04:57 PM, Tobias Hartmann wrote: >>> Hi Albert, >>> >>> On 13.10.2014 16:34, Albert Noll wrote: >>>> Hi Tobias, >>>> >>>> 8046809 (which is currently under review) removes that check. Does removing the >>>> check fix the bug? >>> >>> Yes, but the output (see 'CodeCache::report_codemem_full') is still wrong. Do >>> you think I should only fix the output and wait for your fix to remove the >>> 'is_full' check? >>> >>> Thanks, >>> Tobias >>> >>>> Best, >>>> Albert >>>> >>>> On 10/13/2014 03:02 PM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060196 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060196/webrev.00/ >>>>> >>>>> Problem: >>>>> CodeCache::is_full() returns true if the non-nmethod code heap is full but we >>>>> can still store non-nmethod code in the non-profiled code heap and therefore >>>>> should not disable compilation (see comment 'fallback solution' in >>>>> CodeCache::allocate). >>>>> >>>>> Solution: >>>>> Adapt CodeCache::is_full() to not check the non-nmethod code heap. I also >>>>> fixed the CodeHeap is full warning to suggest increasing the non-profiled code >>>>> heap. >>>>> >>>>> Thanks, >>>>> Tobias >>>> >> From albert.noll at oracle.com Thu Oct 16 08:33:43 2014 From: albert.noll at oracle.com (Albert Noll) Date: Thu, 16 Oct 2014 10:33:43 +0200 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <543CD8E1.6050303@oracle.com> References: <5436465A.3080001@oracle.com> <5437A081.4060608@oracle.com> <5437ED93.6080806@oracle.com> <54381017.6020809@oracle.com> <543BE7E4.6040203@oracle.com> <543C83B8.5050003@oracle.com> <543CD8E1.6050303@oracle.com> Message-ID: <543F82E7.1050706@oracle.com> Can I have a second review? Thanks, Albert On 10/14/2014 10:03 AM, Albert Noll wrote: > Hi Vladimir, > > I filed a CCC request and added the 3 removed flags to the > obsolete_jvm_flags table. > > Here is the updated webrev: > http://cr.openjdk.java.net/~anoll/8046809/webrev.05/ > > Thanks, > Albert > > On 10/14/2014 04:00 AM, Vladimir Kozlov wrote: >> Looks good but you need to wait CCC approval for product flags removal. >> And you need to add them to obsolete_jvm_flags table in arguments.cpp. >> >> Thanks, >> Vladimir >> >> On 10/13/14 7:55 AM, Albert Noll wrote: >>> Hi Vladimir, >>> >>> thanks for the feedback. Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~anoll/8046809/webrev.04/ >>> >>> Best, >>> Albert >>> >>> On 10/10/2014 06:57 PM, Vladimir Kozlov wrote: >>>> On 10/10/14 7:30 AM, Albert Noll wrote: >>>>> Tobias, Vladimir, Dean, Nils, thanks for looking at the patch and >>>>> for your feedback. >>>>> >>>>> @Tobias >>>>> I have adapted your suggestions. >>>>> >>>>> @Vladimir >>>>> I tried to add a condition to >>>>> SafepointSynchronize::is_cleanup_needed() that returns 'true' if >>>>> the code cache has less >>>>> than 10% free space. Unfortunately, that does not fix the bug. A >>>>> safepoint interval of 1000ms seems to be too coarse >>>>> to free space in the code cache fast enough. >>>> >>>> Okay, thank you for trying. >>>> >>>>> >>>>> It seems that the concept of critical memory allocations >>>>> (allocations that must succeed for the VM to be able to >>>>> continue to execute) is broken. For example, we need to compile >>>>> method handle intrinsics (otherwise we get a >>>>> java.lang.VirtualMachineError: out of space in CodeCache for >>>>> method handle intrinsic). However, method handle intrinsic >>>>> are not critical allocations. For this reason, >>>>> test/compiler/startup/SmallCodeCacheStartup.java fails with a 32-bit >>>>> client >>>>> version. We will get a new nightly bug soon... The current patch >>>>> fixes this. >>>>> >>>>> I want to keep the removal of critical allocations in this patch, >>>>> since aggressive sweeping (enabled by the VM >>>>> operation that forces stack scanning) replaces the concept of >>>>> critical allocations in the code cache. I think >>>>> these two changes belong together. If you still want me to, I will >>>>> do a separate change for critical allocation >>>>> removal. >>>> >>>> Okay, I am fine with this removal. >>>> >>>>> >>>>> @Dean >>>>> I removed the corresponding code. It was a fragment that I missed >>>>> to delete. >>>>> >>>>> @Nils >>>>> CodeCacheMinimumFreeSpace did not guarantee that the VM can >>>>> continue to execute. In the failing test >>>>> that is reported in the bug, 500K was not enough to generate all >>>>> adapters. The test can be changed such >>>>> that a CodeCacheMinimumFreeSpace size of 1m, 2m, 3m, etc. is too >>>>> small too. What value should we choose? >>>>> >>>>> Also, as noted above, method handle intrinsic need to be compiled >>>>> to be able to continue execution. >>>>> Method handle intrinsic are currently not critical, so we must >>>>> make them critical allocations. As a consequence, >>>>> we must re-evaluate the default size of CodeCacheMinimumFreeSpace. >>>>> >>>>> The current approach enables very aggressive sweeping, if the code >>>>> cache is 90% full. It is very likely that code >>>>> will be flushed from the code cache in the next 5-10 invocations >>>>> of CodeCache::allocate(). In a sense, the remaining >>>>> 10% can be considered as a 'critical region' that is used as a >>>>> 'buffer' until we free space in the code cache. This bug >>>>> proves that the proposed strategy solves the problem better than >>>>> CodeCacheMinimumFreeSpace. >>>>> >>>>> Maybe we should provide the user with control over this threshold, >>>>> i.e., replace CodeCacheMinimumFreeSpace >>>>> with a different command line flag that allows the user to specify >>>>> the percentage (currently 90%) at which aggressive >>>> >>>> Yes, it should be flag. I think it should be percentage. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> sweeping starts. We could also use a fixed-size. I don't think >>>>> that having two thresholds (the threshold where we start >>>>> aggressive sweeping AND CodeCacheMinimumFreeSpace) is necessary. >>>> >>>>> >>>>> What do you think? >>>>> >>>>> >>>>> >>>>> The performance runs show that waking up the sweeper thread for >>>>> every allocation has a negative impact >>>>> on startup time. To fix this, in the current patch, the sweeper >>>>> thread is only woken up, if the code cache is >>>>> more than 10% occupied. I will issue a new performance run and >>>>> compare it against b34 (which includes >>>>> the segmented code cache). >>>>> >>>>> Here is the new webrev: >>>>> http://cr.openjdk.java.net/~anoll/8046809/webrev.03/ >>>>> >>>>> Best, >>>>> Albert >>>>> >>>>> >>>>> On 10/10/2014 11:01 AM, Nils Eliasson wrote: >>>>>> Hi, Albert >>>>>> >>>>>> Overall a very welcome change to move the sweeper into a separate >>>>>> thread. >>>>>> >>>>>> On 2014-10-09 10:24, Albert Noll wrote: >>>>>>> The patch also removes CodeCacheMinimumFreeSpace and 'critical' >>>>>>> code cache allocations. Due to a bug in >>>>>>> heap.cpp, the CodeCacheMinimumFreeSpace was in fact not reserved >>>>>>> for 'critical' allocations. The following >>>>>>> lines produce an underflow if heap_unallocated_capacity() < >>>>>>> CodeCacheMinimumFreeSpace: >>>>>>> >>>>>>> segments_to_size(number_of_segments) > >>>>>>> (heap_unallocated_capacity() - CodeCacheMinimumFreeSpace) >>>>>>> >>>>>>> Since the critical part in the code cache was never used for its >>>>>>> intended purpose and we did not have problems >>>>>>> due to that, we can remove it. >>>>>> >>>>>> Are you sure? The reasons for the CodeCacheMinimumFreeSpace and >>>>>> critical allocations where problems with code cache >>>>>> fragmentation in long running applications, where small >>>>>> compilations would starve out the adaptors and cause VM >>>>>> shutdown. You won't see this other than in the really long >>>>>> running tests. It might be broken - but then we should open >>>>>> a bug and fix it. (And in the long run we should handle the >>>>>> fragmentation with relocating code.) >>>>>> >>>>>> Regards, >>>>>> //Nils >>>>> >>> > From tobias.hartmann at oracle.com Thu Oct 16 09:01:39 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 Oct 2014 11:01:39 +0200 Subject: [9] RFR(S): [TESTBUG] Whitebox tests fail with -XX:CompileThreshold=100 In-Reply-To: <543F1EAA.1050504@oracle.com> References: <543E348B.6060103@oracle.com> <543F1EAA.1050504@oracle.com> Message-ID: <543F8973.7060307@oracle.com> Hi Vladimir, thanks for the review! On 16.10.2014 03:26, Vladimir Kozlov wrote: > On 10/15/14 1:47 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8060454 >> Webrev: http://cr.openjdk.java.net/~thartmann/8060454/webrev.00/ >> >> Problem: >> The problem is that with a low CompileThreshold we execute the loop to trigger >> osr compilation fewer times. While the >> osr compilation should be triggered there is still a non-osr compilation >> request in the compile queue and therefore the >> osr compilation fails (see 'compilation_is_in_queue(method)' check in >> 'CompileBroker::compile_method_base'). > > This is strange. OSR (backbranch count) threshold should be reached before > invocation count threshold. OSR threshold is calculated as invocation threshold > * 1.3 (OnStackReplacePercentage flag). So for 100, OSR threshold should be 130. > Do you know why we get normal compilation in queue? Did we deoptimized first OSR > compilation? In this case osr test is not correct - it should not trigger > deoptimization. Yes, the OSR threshold is reached and an OSR compilation is triggered. The problem is that the warmup code may trigger a non-OSR compilation. To avoid this we deoptimize non-OSR versions after warmup (see line 557/576). We then invoke 'osrMethod' to enforce OSR compilation and this immediately triggers a non-OSR compilation because the threshold was already reached by the warmup code. While we are in the loop (only a short time with a low CompileThreshold) this compilation is still in the queue and blocks an OSR compilation. After loop exit no OSR version is available and the test fails. I think the simplest solution is to just move the deoptimization code inside the OSR triggering methods (as proposed in the webrev). This way we can make sure that there is no non-OSR version available that prevents or blocks OSR compilations. Thanks, Tobias > > Thanks, > Vladimir > >> >> Solution: >> I moved the call to 'waitAndDeoptimize' from the warmup methods to the osr >> triggering methods to make sure that no >> non-osr compilation is in the queue after warmup. >> >> Maybe we should think about allowing both osr and non-osr compilations in the >> compile queue at the same time. Currently, >> we check this with the access flag 'JVM_ACC_QUEUED'. Unfortunately, it is not >> possible to simply add a new flag for osr >> compilations because all bitmasks are taken. >> >> Testing: >> Executed failing tests on JPRT with different VM options (this time including >> -XX:CompileThreshold). Results are >> attached to bug. >> >> Thanks, >> Tobias From tobias.hartmann at oracle.com Thu Oct 16 09:40:57 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 Oct 2014 11:40:57 +0200 Subject: [9] RFR(S): 8060479: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java test fails with product build In-Reply-To: <86DFDC02-AFA8-4BBE-8557-4C45777A099B@oracle.com> References: <543E828D.6050205@oracle.com> <86DFDC02-AFA8-4BBE-8557-4C45777A099B@oracle.com> Message-ID: <543F92A9.4020705@oracle.com> Hi David, On 15.10.2014 19:37, David Chase wrote: > Hello Tobias, > > I am not a Reviewer, but that looks good to me. > > I would add a comment to the bug itself making sure that you clarify what is going on. > Current text overuses the word ?failure? without making it ?clear? that the ?failure? is a failure to fail; > that the test is verifies that the VM will exit with an error when the code cache is too small, > but in turns out that a release VM can run in a small enough code cache that the size used > by the test is in fact, not too small, and thus no error is seen, and thus the test is judged to have failed. > > I?m not sure I was any better at explaining it :-(. > The intent is to make someone less puzzled when they look at this six months from now. Thanks for the suggestion. I updated the bug description to make it more explicit that this is a test bug. I also added the appropriate labels and a link to a JPRT run with the fixed test. Best, Tobias > > David > > On 2014-10-15, at 10:19 AM, Tobias Hartmann wrote: > >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8060479 >> Webrev: http://cr.openjdk.java.net/~thartmann/8060479/webrev.00/ >> >> Problem: >> The test CheckSegmentedCodeCache assumes that VM startup always fails with a ReservedCodeCacheSize of 1700K. This is not true for product builds (see 'min_code_cache_size' in 'CodeCache::initialize_heaps()'). >> >> Solution: >> Check for debug build and adjust minimum code cache size accordingly. >> >> Testing: >> Failing test on JPRT. >> >> Thanks, >> Tobias > From tobias.hartmann at oracle.com Thu Oct 16 10:47:01 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 16 Oct 2014 12:47:01 +0200 Subject: [9] RFR(S): 8060196: CodeHeap for 'non-nmethods' is full In-Reply-To: <543F2104.6040205@oracle.com> References: <543BCD48.5080508@oracle.com> <543BE2E8.50704@oracle.com> <543BE850.5020303@oracle.com> <543BE976.1070303@oracle.com> <543E5659.5080201@oracle.com> <543F2104.6040205@oracle.com> Message-ID: <543FA225.9050006@oracle.com> Hi Vladimir, thanks for the review. On 16.10.2014 03:36, Vladimir Kozlov wrote: > Should you add and use CodeCache::get_code_heap_flag_name(code_blob_type) instead? > You have more segments types the these two. Yes, I agree. New webrev: http://cr.openjdk.java.net/~thartmann/8060196/webrev.02/ > May be change bug's Synopsis since you not fixing what it is filed for. Done. Thanks, Tobias > Thanks, > Vladimir > > On 10/15/14 4:11 AM, Tobias Hartmann wrote: >> Hi Albert, >> >> On 13.10.2014 17:02, Albert Noll wrote: >>> Hi Tobias, >>> >>> I would wait until 8046809 is reviewed. Doing modifications to a function that >>> is being discussed to remove does not make sense. >> >> Yes, I agree. I changed the webrev to only fix the output of the "code heap is >> full" message: >> >> http://cr.openjdk.java.net/~thartmann/8060196/webrev.01/ >> >> I added a comment to the bug. >> >> Thanks, >> Tobias >> >> >>> Best, >>> Albert >>> >>> On 10/13/2014 04:57 PM, Tobias Hartmann wrote: >>>> Hi Albert, >>>> >>>> On 13.10.2014 16:34, Albert Noll wrote: >>>>> Hi Tobias, >>>>> >>>>> 8046809 (which is currently under review) removes that check. Does removing >>>>> the >>>>> check fix the bug? >>>> >>>> Yes, but the output (see 'CodeCache::report_codemem_full') is still wrong. Do >>>> you think I should only fix the output and wait for your fix to remove the >>>> 'is_full' check? >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> Best, >>>>> Albert >>>>> >>>>> On 10/13/2014 03:02 PM, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> please review the following patch. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060196 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060196/webrev.00/ >>>>>> >>>>>> Problem: >>>>>> CodeCache::is_full() returns true if the non-nmethod code heap is full but we >>>>>> can still store non-nmethod code in the non-profiled code heap and therefore >>>>>> should not disable compilation (see comment 'fallback solution' in >>>>>> CodeCache::allocate). >>>>>> >>>>>> Solution: >>>>>> Adapt CodeCache::is_full() to not check the non-nmethod code heap. I also >>>>>> fixed the CodeHeap is full warning to suggest increasing the non-profiled >>>>>> code >>>>>> heap. >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>> >>> From vladimir.kozlov at oracle.com Thu Oct 16 15:46:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Oct 2014 08:46:27 -0700 Subject: [9] RFR(S): [TESTBUG] Whitebox tests fail with -XX:CompileThreshold=100 In-Reply-To: <543F8973.7060307@oracle.com> References: <543E348B.6060103@oracle.com> <543F1EAA.1050504@oracle.com> <543F8973.7060307@oracle.com> Message-ID: <543FE853.206@oracle.com> Thank you for explaining, Tobias Changes look good. Vladimir On 10/16/14 2:01 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review! > > On 16.10.2014 03:26, Vladimir Kozlov wrote: >> On 10/15/14 1:47 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060454 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8060454/webrev.00/ >>> >>> Problem: >>> The problem is that with a low CompileThreshold we execute the loop to trigger >>> osr compilation fewer times. While the >>> osr compilation should be triggered there is still a non-osr compilation >>> request in the compile queue and therefore the >>> osr compilation fails (see 'compilation_is_in_queue(method)' check in >>> 'CompileBroker::compile_method_base'). >> >> This is strange. OSR (backbranch count) threshold should be reached before >> invocation count threshold. OSR threshold is calculated as invocation threshold >> * 1.3 (OnStackReplacePercentage flag). So for 100, OSR threshold should be 130. >> Do you know why we get normal compilation in queue? Did we deoptimized first OSR >> compilation? In this case osr test is not correct - it should not trigger >> deoptimization. > > Yes, the OSR threshold is reached and an OSR compilation is triggered. > > The problem is that the warmup code may trigger a non-OSR compilation. To avoid this we deoptimize non-OSR versions > after warmup (see line 557/576). > > We then invoke 'osrMethod' to enforce OSR compilation and this immediately triggers a non-OSR compilation because the > threshold was already reached by the warmup code. While we are in the loop (only a short time with a low > CompileThreshold) this compilation is still in the queue and blocks an OSR compilation. After loop exit no OSR version > is available and the test fails. > > I think the simplest solution is to just move the deoptimization code inside the OSR triggering methods (as proposed in > the webrev). This way we can make sure that there is no non-OSR version available that prevents or blocks OSR compilations. > > Thanks, > Tobias > >> >> Thanks, >> Vladimir >> >>> >>> Solution: >>> I moved the call to 'waitAndDeoptimize' from the warmup methods to the osr >>> triggering methods to make sure that no >>> non-osr compilation is in the queue after warmup. >>> >>> Maybe we should think about allowing both osr and non-osr compilations in the >>> compile queue at the same time. Currently, >>> we check this with the access flag 'JVM_ACC_QUEUED'. Unfortunately, it is not >>> possible to simply add a new flag for osr >>> compilations because all bitmasks are taken. >>> >>> Testing: >>> Executed failing tests on JPRT with different VM options (this time including >>> -XX:CompileThreshold). Results are >>> attached to bug. >>> >>> Thanks, >>> Tobias From vladimir.kozlov at oracle.com Thu Oct 16 15:47:54 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 16 Oct 2014 08:47:54 -0700 Subject: [9] RFR(S): 8060196: CodeHeap for 'non-nmethods' is full In-Reply-To: <543FA225.9050006@oracle.com> References: <543BCD48.5080508@oracle.com> <543BE2E8.50704@oracle.com> <543BE850.5020303@oracle.com> <543BE976.1070303@oracle.com> <543E5659.5080201@oracle.com> <543F2104.6040205@oracle.com> <543FA225.9050006@oracle.com> Message-ID: <543FE8AA.4060509@oracle.com> Good. Thanks, Vladimir On 10/16/14 3:47 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > > On 16.10.2014 03:36, Vladimir Kozlov wrote: >> Should you add and use CodeCache::get_code_heap_flag_name(code_blob_type) instead? >> You have more segments types the these two. > > Yes, I agree. New webrev: > > http://cr.openjdk.java.net/~thartmann/8060196/webrev.02/ > >> May be change bug's Synopsis since you not fixing what it is filed for. > > Done. > > Thanks, > Tobias > >> Thanks, >> Vladimir >> >> On 10/15/14 4:11 AM, Tobias Hartmann wrote: >>> Hi Albert, >>> >>> On 13.10.2014 17:02, Albert Noll wrote: >>>> Hi Tobias, >>>> >>>> I would wait until 8046809 is reviewed. Doing modifications to a function that >>>> is being discussed to remove does not make sense. >>> >>> Yes, I agree. I changed the webrev to only fix the output of the "code heap is >>> full" message: >>> >>> http://cr.openjdk.java.net/~thartmann/8060196/webrev.01/ >>> >>> I added a comment to the bug. >>> >>> Thanks, >>> Tobias >>> >>> >>>> Best, >>>> Albert >>>> >>>> On 10/13/2014 04:57 PM, Tobias Hartmann wrote: >>>>> Hi Albert, >>>>> >>>>> On 13.10.2014 16:34, Albert Noll wrote: >>>>>> Hi Tobias, >>>>>> >>>>>> 8046809 (which is currently under review) removes that check. Does removing >>>>>> the >>>>>> check fix the bug? >>>>> >>>>> Yes, but the output (see 'CodeCache::report_codemem_full') is still wrong. Do >>>>> you think I should only fix the output and wait for your fix to remove the >>>>> 'is_full' check? >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>> Best, >>>>>> Albert >>>>>> >>>>>> On 10/13/2014 03:02 PM, Tobias Hartmann wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review the following patch. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060196 >>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060196/webrev.00/ >>>>>>> >>>>>>> Problem: >>>>>>> CodeCache::is_full() returns true if the non-nmethod code heap is full but we >>>>>>> can still store non-nmethod code in the non-profiled code heap and therefore >>>>>>> should not disable compilation (see comment 'fallback solution' in >>>>>>> CodeCache::allocate). >>>>>>> >>>>>>> Solution: >>>>>>> Adapt CodeCache::is_full() to not check the non-nmethod code heap. I also >>>>>>> fixed the CodeHeap is full warning to suggest increasing the non-profiled >>>>>>> code >>>>>>> heap. >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>> >>>> From tobias.hartmann at oracle.com Fri Oct 17 06:52:24 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Oct 2014 08:52:24 +0200 Subject: [9] RFR(S): 8060196: CodeHeap for 'non-nmethods' is full In-Reply-To: <543FE8AA.4060509@oracle.com> References: <543BCD48.5080508@oracle.com> <543BE2E8.50704@oracle.com> <543BE850.5020303@oracle.com> <543BE976.1070303@oracle.com> <543E5659.5080201@oracle.com> <543F2104.6040205@oracle.com> <543FA225.9050006@oracle.com> <543FE8AA.4060509@oracle.com> Message-ID: <5440BCA8.3050709@oracle.com> Thanks, Vladimir. Best, Tobias On 16.10.2014 17:47, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/16/14 3:47 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. >> >> On 16.10.2014 03:36, Vladimir Kozlov wrote: >>> Should you add and use CodeCache::get_code_heap_flag_name(code_blob_type) >>> instead? >>> You have more segments types the these two. >> >> Yes, I agree. New webrev: >> >> http://cr.openjdk.java.net/~thartmann/8060196/webrev.02/ >> >>> May be change bug's Synopsis since you not fixing what it is filed for. >> >> Done. >> >> Thanks, >> Tobias >> >>> Thanks, >>> Vladimir >>> >>> On 10/15/14 4:11 AM, Tobias Hartmann wrote: >>>> Hi Albert, >>>> >>>> On 13.10.2014 17:02, Albert Noll wrote: >>>>> Hi Tobias, >>>>> >>>>> I would wait until 8046809 is reviewed. Doing modifications to a function that >>>>> is being discussed to remove does not make sense. >>>> >>>> Yes, I agree. I changed the webrev to only fix the output of the "code heap is >>>> full" message: >>>> >>>> http://cr.openjdk.java.net/~thartmann/8060196/webrev.01/ >>>> >>>> I added a comment to the bug. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> >>>>> Best, >>>>> Albert >>>>> >>>>> On 10/13/2014 04:57 PM, Tobias Hartmann wrote: >>>>>> Hi Albert, >>>>>> >>>>>> On 13.10.2014 16:34, Albert Noll wrote: >>>>>>> Hi Tobias, >>>>>>> >>>>>>> 8046809 (which is currently under review) removes that check. Does removing >>>>>>> the >>>>>>> check fix the bug? >>>>>> >>>>>> Yes, but the output (see 'CodeCache::report_codemem_full') is still wrong. Do >>>>>> you think I should only fix the output and wait for your fix to remove the >>>>>> 'is_full' check? >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>> Best, >>>>>>> Albert >>>>>>> >>>>>>> On 10/13/2014 03:02 PM, Tobias Hartmann wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review the following patch. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060196 >>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060196/webrev.00/ >>>>>>>> >>>>>>>> Problem: >>>>>>>> CodeCache::is_full() returns true if the non-nmethod code heap is full >>>>>>>> but we >>>>>>>> can still store non-nmethod code in the non-profiled code heap and >>>>>>>> therefore >>>>>>>> should not disable compilation (see comment 'fallback solution' in >>>>>>>> CodeCache::allocate). >>>>>>>> >>>>>>>> Solution: >>>>>>>> Adapt CodeCache::is_full() to not check the non-nmethod code heap. I also >>>>>>>> fixed the CodeHeap is full warning to suggest increasing the non-profiled >>>>>>>> code >>>>>>>> heap. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>> >>>>> From tobias.hartmann at oracle.com Fri Oct 17 06:59:02 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Oct 2014 08:59:02 +0200 Subject: [9] RFR(S): [TESTBUG] Whitebox tests fail with -XX:CompileThreshold=100 In-Reply-To: <543FE853.206@oracle.com> References: <543E348B.6060103@oracle.com> <543F1EAA.1050504@oracle.com> <543F8973.7060307@oracle.com> <543FE853.206@oracle.com> Message-ID: <5440BE36.9080209@oracle.com> Thanks, Vladimir. Best, Tobias On 16.10.2014 17:46, Vladimir Kozlov wrote: > Thank you for explaining, Tobias > > Changes look good. > > Vladimir > > On 10/16/14 2:01 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review! >> >> On 16.10.2014 03:26, Vladimir Kozlov wrote: >>> On 10/15/14 1:47 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060454 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060454/webrev.00/ >>>> >>>> Problem: >>>> The problem is that with a low CompileThreshold we execute the loop to trigger >>>> osr compilation fewer times. While the >>>> osr compilation should be triggered there is still a non-osr compilation >>>> request in the compile queue and therefore the >>>> osr compilation fails (see 'compilation_is_in_queue(method)' check in >>>> 'CompileBroker::compile_method_base'). >>> >>> This is strange. OSR (backbranch count) threshold should be reached before >>> invocation count threshold. OSR threshold is calculated as invocation threshold >>> * 1.3 (OnStackReplacePercentage flag). So for 100, OSR threshold should be 130. >>> Do you know why we get normal compilation in queue? Did we deoptimized first OSR >>> compilation? In this case osr test is not correct - it should not trigger >>> deoptimization. >> >> Yes, the OSR threshold is reached and an OSR compilation is triggered. >> >> The problem is that the warmup code may trigger a non-OSR compilation. To >> avoid this we deoptimize non-OSR versions >> after warmup (see line 557/576). >> >> We then invoke 'osrMethod' to enforce OSR compilation and this immediately >> triggers a non-OSR compilation because the >> threshold was already reached by the warmup code. While we are in the loop >> (only a short time with a low >> CompileThreshold) this compilation is still in the queue and blocks an OSR >> compilation. After loop exit no OSR version >> is available and the test fails. >> >> I think the simplest solution is to just move the deoptimization code inside >> the OSR triggering methods (as proposed in >> the webrev). This way we can make sure that there is no non-OSR version >> available that prevents or blocks OSR compilations. >> >> Thanks, >> Tobias >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Solution: >>>> I moved the call to 'waitAndDeoptimize' from the warmup methods to the osr >>>> triggering methods to make sure that no >>>> non-osr compilation is in the queue after warmup. >>>> >>>> Maybe we should think about allowing both osr and non-osr compilations in the >>>> compile queue at the same time. Currently, >>>> we check this with the access flag 'JVM_ACC_QUEUED'. Unfortunately, it is not >>>> possible to simply add a new flag for osr >>>> compilations because all bitmasks are taken. >>>> >>>> Testing: >>>> Executed failing tests on JPRT with different VM options (this time including >>>> -XX:CompileThreshold). Results are >>>> attached to bug. >>>> >>>> Thanks, >>>> Tobias From tobias.hartmann at oracle.com Fri Oct 17 07:00:21 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Oct 2014 09:00:21 +0200 Subject: [9] RFR(S): 8060479: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java test fails with product build In-Reply-To: <543E828D.6050205@oracle.com> References: <543E828D.6050205@oracle.com> Message-ID: <5440BE85.3070409@oracle.com> Can I get another review for this? Thanks, Tobias On 15.10.2014 16:19, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8060479 > Webrev: http://cr.openjdk.java.net/~thartmann/8060479/webrev.00/ > > Problem: > The test CheckSegmentedCodeCache assumes that VM startup always fails with a > ReservedCodeCacheSize of 1700K. This is not true for product builds (see > 'min_code_cache_size' in 'CodeCache::initialize_heaps()'). > > Solution: > Check for debug build and adjust minimum code cache size accordingly. > > Testing: > Failing test on JPRT. > > Thanks, > Tobias From vladimir.kozlov at oracle.com Fri Oct 17 08:47:36 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Oct 2014 01:47:36 -0700 Subject: [9] RFR(S): 8060479: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java test fails with product build In-Reply-To: <5440BE85.3070409@oracle.com> References: <543E828D.6050205@oracle.com> <5440BE85.3070409@oracle.com> Message-ID: <5440D7A8.7050309@oracle.com> CodeCacheMinimumUseSpace is different for Zero. There is WB API which returns options value getUintxVMFlag() you can use to calculate value minSize. 8046809 changes will change min_code_cache_size value again (removes CodeCacheMinimumFreeSpace). Let Albert know to modify this test again. Thanks, Vladimir On 10/17/14 12:00 AM, Tobias Hartmann wrote: > Can I get another review for this? > > Thanks, > Tobias > > On 15.10.2014 16:19, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8060479 >> Webrev: http://cr.openjdk.java.net/~thartmann/8060479/webrev.00/ >> >> Problem: >> The test CheckSegmentedCodeCache assumes that VM startup always fails with a >> ReservedCodeCacheSize of 1700K. This is not true for product builds (see >> 'min_code_cache_size' in 'CodeCache::initialize_heaps()'). >> >> Solution: >> Check for debug build and adjust minimum code cache size accordingly. >> >> Testing: >> Failing test on JPRT. >> >> Thanks, >> Tobias From tobias.hartmann at oracle.com Fri Oct 17 10:18:01 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 17 Oct 2014 12:18:01 +0200 Subject: [9] RFR(S): 8060479: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java test fails with product build In-Reply-To: <5440D7A8.7050309@oracle.com> References: <543E828D.6050205@oracle.com> <5440BE85.3070409@oracle.com> <5440D7A8.7050309@oracle.com> Message-ID: <5440ECD9.4060900@oracle.com> Hi Vladimir, On 17.10.2014 10:47, Vladimir Kozlov wrote: > CodeCacheMinimumUseSpace is different for Zero. There is WB API which returns > options value getUintxVMFlag() you can use to calculate value minSize. Yes, but the flag is only available in debug builds. See 'Flag::find_flag': 525 // Don't report notproduct and develop flags in product builds. Calling getUintxVMFlag() throws a java.lang.NullPointerException with product builds. One solution would be to only perform this check for debug builds where we are able to compute the size. What do you think? > 8046809 changes will change min_code_cache_size value again (removes > CodeCacheMinimumFreeSpace). Let Albert know to modify this test again. I will do so. Thanks, Tobias > Thanks, > Vladimir > > On 10/17/14 12:00 AM, Tobias Hartmann wrote: >> Can I get another review for this? >> >> Thanks, >> Tobias >> >> On 15.10.2014 16:19, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060479 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8060479/webrev.00/ >>> >>> Problem: >>> The test CheckSegmentedCodeCache assumes that VM startup always fails with a >>> ReservedCodeCacheSize of 1700K. This is not true for product builds (see >>> 'min_code_cache_size' in 'CodeCache::initialize_heaps()'). >>> >>> Solution: >>> Check for debug build and adjust minimum code cache size accordingly. >>> >>> Testing: >>> Failing test on JPRT. >>> >>> Thanks, >>> Tobias From sergei.kovalev at oracle.com Fri Oct 17 12:02:22 2014 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Fri, 17 Oct 2014 16:02:22 +0400 Subject: RFR(S): 8028481: [TESTBUG] compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java should be in needs_nashorn test group Message-ID: <5441054E.1030705@oracle.com> Hi All, Please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8028481 Webrev: http://cr.openjdk.java.net/~vlivanov/kovalev/8028481/webrev.00/ Problem: The test CreatesInterfaceDotEqualsCallInfo.java depends on nashorn extension and compact2 API. The extension is optional for embedded world. Therefore we should have an ability to exclude the test from execution. Also we should exclude it from compact1 execution. Solution: Two new groups are introduced: "needs_nashorn", "not_needs_nashorn". Also test added to a group "needs_compact2". I found that by mistake the test listed twice in a "hotspot_compiler_3" group. One of the copies removed. Testing: Groups content verified locally with jtreg. -- With best regards, Sergei From vladimir.x.ivanov at oracle.com Fri Oct 17 12:53:58 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 17 Oct 2014 16:53:58 +0400 Subject: RFR(S): 8028481: [TESTBUG] compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java should be in needs_nashorn test group In-Reply-To: <5441054E.1030705@oracle.com> References: <5441054E.1030705@oracle.com> Message-ID: <54411166.2070204@oracle.com> Looks good. Best regards, Vladimir Ivanov On 10/17/14, 4:02 PM, Sergei Kovalev wrote: > Hi All, > > Please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8028481 > Webrev: http://cr.openjdk.java.net/~vlivanov/kovalev/8028481/webrev.00/ > > Problem: > The test CreatesInterfaceDotEqualsCallInfo.java depends on nashorn > extension and compact2 API. The extension is optional for embedded > world. Therefore we should have an ability to exclude the test from > execution. Also we should exclude it from compact1 execution. > > Solution: > Two new groups are introduced: "needs_nashorn", "not_needs_nashorn". > Also test added to a group "needs_compact2". > I found that by mistake the test listed twice in a "hotspot_compiler_3" > group. One of the copies removed. > > Testing: > Groups content verified locally with jtreg. > From david.r.chase at oracle.com Fri Oct 17 18:16:43 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 17 Oct 2014 14:16:43 -0400 Subject: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames Message-ID: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8013267 webrevs: http://cr.openjdk.java.net/~drchase/8013267/jdk.03/ http://cr.openjdk.java.net/~drchase/8013267/hotspot.03/ related bug: https://bugs.openjdk.java.net/browse/JDK-8042235 The ?bug? is a cleanup/space-saving RFE that enables fixes for other bugs related to method name tables ? e.g., failure to properly update two method handles referring to the same method after the method is redefined. The patch is months old and needed to be brought up to date. In addition, the patch needed the following changes beyond what was seen in other reviews: 1) on the hotspot side, code to adjust the membername table needed to check that the data for the membername table was actually allocated (one goal of this rfe was to avoid allocating that table) else it would null deref and crash. 2) on the jdk side, fencepost error in the membername table insertion; the first entry could be duplicated ( ?if index > 0? wrong, should be ?if index >= 0?). 3) on the jdk side, several of the constructors for MemberNames needed to be replaced with factories that would consult the MemberNameTable and avoid creating duplicates; again, that was the entire point of this fix. *NOT ALL CONSTRUCTORS WERE MODIFIED LIKE THIS?, and there was one curious piece of code where it seemed that this might not be what was desired, but it was unclear how this would behave in the face of method redefinition. From http://cr.openjdk.java.net/~drchase/8013267/jdk.03/src/java.base/share/classes/java/lang/invoke/MemberName.java.html 1047 private MemberName resolve(byte refKind, MemberName ref, Class lookupClass) { 1048 MemberName m = ref.clone(); // JVM will side-effect the ref 1049 assert(refKind == m.getReferenceKind()); 1050 try { 1051 m = MethodHandleNatives.resolve(m, lookupClass); 1052 m.checkForTypeAlias(); 1053 m.resolution = null; 1054 m.intern(); Note that this performs an ?intern? that ignores what is already found in the table and may not place m in the table if a duplicate name is already there. ????????? testing: jtreg: hotspot/{compiler,runtime,gc} jdk/{vm,jdk,sun/{invoke,misc,reflect} by-hand: verified that the crash example for 8042235 still crash in an unmodified VM and does not crash in a modified VM. Modified and retested https://bugs.openjdk.java.net/secure/attachment/20184/RedefineMethodUsedByMultipleMethodHandles.java Old: // Calling fooMH1.vmtarget crashes the VM System.out.println("fooMH1.invoke = " + fooMH1.invokeExact()); New: // Calling fooMH1.vmtarget crashes the VM System.out.println("fooMH1.invoke = " + fooMH1.invokeExact()); System.out.println("fooMH2.invoke = " + fooMH2.invokeExact()); This turned out to be a reasonable thing to do, since the added line caused a crash till further corrections were made. (See fixes 2 and 3 above). Should RedefineMethodUsedByMultipleMethodHandles.java also be added as a test? Are there other tests that would be good to run ?(and if they are ute tests, the more detailed the instructions for how to run them, the better.) David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Sat Oct 18 00:46:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Oct 2014 17:46:24 -0700 Subject: [9] RFR(S): 8060479: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java test fails with product build In-Reply-To: <5440ECD9.4060900@oracle.com> References: <543E828D.6050205@oracle.com> <5440BE85.3070409@oracle.com> <5440D7A8.7050309@oracle.com> <5440ECD9.4060900@oracle.com> Message-ID: <5441B860.9050800@oracle.com> WB get*Flag interface should be fixed! The constant value of develop flags are available in product VM. You need to call Flag::find_flag() with return_flag = true. WB should not use default CommandLineFlags class methods but define its own or extend CommandLineFlags's methods. Igor I. should comment on this since he is author of "new WB API :: get/setVMFlag" Thanks, Vladimir On 10/17/14 3:18 AM, Tobias Hartmann wrote: > Hi Vladimir, > > On 17.10.2014 10:47, Vladimir Kozlov wrote: >> CodeCacheMinimumUseSpace is different for Zero. There is WB API which returns >> options value getUintxVMFlag() you can use to calculate value minSize. > > Yes, but the flag is only available in debug builds. See 'Flag::find_flag': > > 525 // Don't report notproduct and develop flags in product builds. > > Calling getUintxVMFlag() throws a java.lang.NullPointerException with product > builds. One solution would be to only perform this check for debug builds where > we are able to compute the size. What do you think? > >> 8046809 changes will change min_code_cache_size value again (removes >> CodeCacheMinimumFreeSpace). Let Albert know to modify this test again. > > I will do so. > > Thanks, > Tobias > >> Thanks, >> Vladimir >> >> On 10/17/14 12:00 AM, Tobias Hartmann wrote: >>> Can I get another review for this? >>> >>> Thanks, >>> Tobias >>> >>> On 15.10.2014 16:19, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060479 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060479/webrev.00/ >>>> >>>> Problem: >>>> The test CheckSegmentedCodeCache assumes that VM startup always fails with a >>>> ReservedCodeCacheSize of 1700K. This is not true for product builds (see >>>> 'min_code_cache_size' in 'CodeCache::initialize_heaps()'). >>>> >>>> Solution: >>>> Check for debug build and adjust minimum code cache size accordingly. >>>> >>>> Testing: >>>> Failing test on JPRT. >>>> >>>> Thanks, >>>> Tobias From igor.ignatyev at oracle.com Sun Oct 19 00:08:28 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sun, 19 Oct 2014 04:08:28 +0400 Subject: [9] RFR(S): 8060479: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java test fails with product build In-Reply-To: <5441B860.9050800@oracle.com> References: <543E828D.6050205@oracle.com> <5440BE85.3070409@oracle.com> <5440D7A8.7050309@oracle.com> <5440ECD9.4060900@oracle.com> <5441B860.9050800@oracle.com> Message-ID: <544300FC.5070802@oracle.com> Tobias, this is definitely a bug in get*Flag functions. I think it'd be better to fix it as a separate issue. my suggested fix (w/ changes only for bool): > diff -r 821164b0131a src/share/vm/runtime/globals.cpp > --- a/src/share/vm/runtime/globals.cpp Fri Oct 03 12:11:14 2014 -0700 > +++ b/src/share/vm/runtime/globals.cpp Sun Oct 19 04:05:40 2014 +0400 > @@ -629,8 +629,8 @@ > e.commit(); > } > > -bool CommandLineFlags::boolAt(const char* name, size_t len, bool* value) { > - Flag* result = Flag::find_flag(name, len); > +bool CommandLineFlags::boolAt(const char* name, size_t len, bool* value, bool allow_locked, bool return_flag) { > + Flag* result = Flag::find_flag(name, len, allow_locked, return_flag); > if (result == NULL) return false; > if (!result->is_bool()) return false; > *value = result->get_bool(); > diff -r 821164b0131a src/share/vm/runtime/globals.hpp > --- a/src/share/vm/runtime/globals.hpp Fri Oct 03 12:11:14 2014 -0700 > +++ b/src/share/vm/runtime/globals.hpp Sun Oct 19 04:05:40 2014 +0400 > @@ -377,8 +377,8 @@ > > class CommandLineFlags { > public: > - static bool boolAt(const char* name, size_t len, bool* value); > - static bool boolAt(const char* name, bool* value) { return boolAt(name, strlen(name), value); } > + static bool boolAt(const char* name, size_t len, bool* value, bool allow_locked = false, bool return_flag = false); > + static bool boolAt(const char* name, bool* value, bool allow_locked = false, bool return_flag = false) { return boolAt(name, strlen(name), value, allow_locked, return_flag); } > static bool boolAtPut(const char* name, size_t len, bool* value, Flag::Flags origin); > static bool boolAtPut(const char* name, bool* value, Flag::Flags origin) { return boolAtPut(name, strlen(name), value, origin); } > diff -r 821164b0131a src/share/vm/prims/whitebox.cpp > --- a/src/share/vm/prims/whitebox.cpp Fri Oct 03 12:11:14 2014 -0700 > +++ b/src/share/vm/prims/whitebox.cpp Sun Oct 19 04:06:59 2014 +0400 > @@ -543,7 +543,7 @@ > } > ThreadToNativeFromVM ttnfv(thread); // can't be in VM when we call JNI > const char* flag_name = env->GetStringUTFChars(name, NULL); > - bool result = (*TAt)(flag_name, value); > + bool result = (*TAt)(flag_name, value, true, true); > env->ReleaseStringUTFChars(name, flag_name); > return result; > } Thanks, Igor On 10/18/2014 04:46 AM, Vladimir Kozlov wrote: > WB get*Flag interface should be fixed! The constant value of develop > flags are available in product VM. You need to call Flag::find_flag() > with return_flag = true. WB should not use default CommandLineFlags > class methods but define its own or extend CommandLineFlags's methods. > > Igor I. should comment on this since he is author of "new WB API :: > get/setVMFlag" > > Thanks, > Vladimir > > On 10/17/14 3:18 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> On 17.10.2014 10:47, Vladimir Kozlov wrote: >>> CodeCacheMinimumUseSpace is different for Zero. There is WB API which >>> returns >>> options value getUintxVMFlag() you can use to calculate value minSize. >> >> Yes, but the flag is only available in debug builds. See >> 'Flag::find_flag': >> >> 525 // Don't report notproduct and develop flags in product builds. >> >> Calling getUintxVMFlag() throws a java.lang.NullPointerException with >> product >> builds. One solution would be to only perform this check for debug >> builds where >> we are able to compute the size. What do you think? >> >>> 8046809 changes will change min_code_cache_size value again (removes >>> CodeCacheMinimumFreeSpace). Let Albert know to modify this test again. >> >> I will do so. >> >> Thanks, >> Tobias >> >>> Thanks, >>> Vladimir >>> >>> On 10/17/14 12:00 AM, Tobias Hartmann wrote: >>>> Can I get another review for this? >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 15.10.2014 16:19, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060479 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060479/webrev.00/ >>>>> >>>>> Problem: >>>>> The test CheckSegmentedCodeCache assumes that VM startup always >>>>> fails with a >>>>> ReservedCodeCacheSize of 1700K. This is not true for product builds >>>>> (see >>>>> 'min_code_cache_size' in 'CodeCache::initialize_heaps()'). >>>>> >>>>> Solution: >>>>> Check for debug build and adjust minimum code cache size accordingly. >>>>> >>>>> Testing: >>>>> Failing test on JPRT. >>>>> >>>>> Thanks, >>>>> Tobias From tobias.hartmann at oracle.com Mon Oct 20 12:03:15 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 20 Oct 2014 14:03:15 +0200 Subject: [9] RFR(S): 8060479: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java test fails with product build In-Reply-To: <544300FC.5070802@oracle.com> References: <543E828D.6050205@oracle.com> <5440BE85.3070409@oracle.com> <5440D7A8.7050309@oracle.com> <5440ECD9.4060900@oracle.com> <5441B860.9050800@oracle.com> <544300FC.5070802@oracle.com> Message-ID: <5444FA03.6020007@oracle.com> Thanks Vladimir and Igor, I filed a new bug for this and will take care of it: https://bugs.openjdk.java.net/browse/JDK-8061443 Best, Tobias On 19.10.2014 02:08, Igor Ignatyev wrote: > Tobias, > > this is definitely a bug in get*Flag functions. I think it'd be better to fix it > as a separate issue. > > my suggested fix (w/ changes only for bool): > >> diff -r 821164b0131a src/share/vm/runtime/globals.cpp >> --- a/src/share/vm/runtime/globals.cpp Fri Oct 03 12:11:14 2014 -0700 >> +++ b/src/share/vm/runtime/globals.cpp Sun Oct 19 04:05:40 2014 +0400 >> @@ -629,8 +629,8 @@ >> e.commit(); >> } >> >> -bool CommandLineFlags::boolAt(const char* name, size_t len, bool* value) { >> - Flag* result = Flag::find_flag(name, len); >> +bool CommandLineFlags::boolAt(const char* name, size_t len, bool* value, bool >> allow_locked, bool return_flag) { >> + Flag* result = Flag::find_flag(name, len, allow_locked, return_flag); >> if (result == NULL) return false; >> if (!result->is_bool()) return false; >> *value = result->get_bool(); >> diff -r 821164b0131a src/share/vm/runtime/globals.hpp >> --- a/src/share/vm/runtime/globals.hpp Fri Oct 03 12:11:14 2014 -0700 >> +++ b/src/share/vm/runtime/globals.hpp Sun Oct 19 04:05:40 2014 +0400 >> @@ -377,8 +377,8 @@ >> >> class CommandLineFlags { >> public: >> - static bool boolAt(const char* name, size_t len, bool* value); >> - static bool boolAt(const char* name, bool* value) { return >> boolAt(name, strlen(name), value); } >> + static bool boolAt(const char* name, size_t len, bool* value, bool >> allow_locked = false, bool return_flag = false); >> + static bool boolAt(const char* name, bool* value, bool allow_locked = >> false, bool return_flag = false) { return boolAt(name, strlen(name), >> value, allow_locked, return_flag); } >> static bool boolAtPut(const char* name, size_t len, bool* value, >> Flag::Flags origin); >> static bool boolAtPut(const char* name, bool* value, Flag::Flags origin) >> { return boolAtPut(name, strlen(name), value, origin); } > >> diff -r 821164b0131a src/share/vm/prims/whitebox.cpp >> --- a/src/share/vm/prims/whitebox.cpp Fri Oct 03 12:11:14 2014 -0700 >> +++ b/src/share/vm/prims/whitebox.cpp Sun Oct 19 04:06:59 2014 +0400 >> @@ -543,7 +543,7 @@ >> } >> ThreadToNativeFromVM ttnfv(thread); // can't be in VM when we call JNI >> const char* flag_name = env->GetStringUTFChars(name, NULL); >> - bool result = (*TAt)(flag_name, value); >> + bool result = (*TAt)(flag_name, value, true, true); >> env->ReleaseStringUTFChars(name, flag_name); >> return result; >> } > > Thanks, > Igor > > On 10/18/2014 04:46 AM, Vladimir Kozlov wrote: >> WB get*Flag interface should be fixed! The constant value of develop >> flags are available in product VM. You need to call Flag::find_flag() >> with return_flag = true. WB should not use default CommandLineFlags >> class methods but define its own or extend CommandLineFlags's methods. >> >> Igor I. should comment on this since he is author of "new WB API :: >> get/setVMFlag" >> >> Thanks, >> Vladimir >> >> On 10/17/14 3:18 AM, Tobias Hartmann wrote: >>> Hi Vladimir, >>> >>> On 17.10.2014 10:47, Vladimir Kozlov wrote: >>>> CodeCacheMinimumUseSpace is different for Zero. There is WB API which >>>> returns >>>> options value getUintxVMFlag() you can use to calculate value minSize. >>> >>> Yes, but the flag is only available in debug builds. See >>> 'Flag::find_flag': >>> >>> 525 // Don't report notproduct and develop flags in product builds. >>> >>> Calling getUintxVMFlag() throws a java.lang.NullPointerException with >>> product >>> builds. One solution would be to only perform this check for debug >>> builds where >>> we are able to compute the size. What do you think? >>> >>>> 8046809 changes will change min_code_cache_size value again (removes >>>> CodeCacheMinimumFreeSpace). Let Albert know to modify this test again. >>> >>> I will do so. >>> >>> Thanks, >>> Tobias >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/17/14 12:00 AM, Tobias Hartmann wrote: >>>>> Can I get another review for this? >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> On 15.10.2014 16:19, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> please review the following patch. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060479 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060479/webrev.00/ >>>>>> >>>>>> Problem: >>>>>> The test CheckSegmentedCodeCache assumes that VM startup always >>>>>> fails with a >>>>>> ReservedCodeCacheSize of 1700K. This is not true for product builds >>>>>> (see >>>>>> 'min_code_cache_size' in 'CodeCache::initialize_heaps()'). >>>>>> >>>>>> Solution: >>>>>> Check for debug build and adjust minimum code cache size accordingly. >>>>>> >>>>>> Testing: >>>>>> Failing test on JPRT. >>>>>> >>>>>> Thanks, >>>>>> Tobias From sergei.kovalev at oracle.com Mon Oct 20 15:53:04 2014 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 20 Oct 2014 19:53:04 +0400 Subject: RFR(S): 8028481: [TESTBUG] compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java should be in needs_nashorn test group In-Reply-To: <54411166.2070204@oracle.com> References: <5441054E.1030705@oracle.com> <54411166.2070204@oracle.com> Message-ID: <54452FE0.9010304@oracle.com> Hi all Looking for second reviewer. On 17.10.2014 16:53, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 10/17/14, 4:02 PM, Sergei Kovalev wrote: >> Hi All, >> >> Please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8028481 >> Webrev: http://cr.openjdk.java.net/~vlivanov/kovalev/8028481/webrev.00/ >> >> Problem: >> The test CreatesInterfaceDotEqualsCallInfo.java depends on nashorn >> extension and compact2 API. The extension is optional for embedded >> world. Therefore we should have an ability to exclude the test from >> execution. Also we should exclude it from compact1 execution. >> >> Solution: >> Two new groups are introduced: "needs_nashorn", "not_needs_nashorn". >> Also test added to a group "needs_compact2". >> I found that by mistake the test listed twice in a "hotspot_compiler_3" >> group. One of the copies removed. >> >> Testing: >> Groups content verified locally with jtreg. >> > > -- With best regards, Sergei From vladimir.kozlov at oracle.com Mon Oct 20 17:41:15 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Oct 2014 10:41:15 -0700 Subject: RFR(S): 8028481: [TESTBUG] compiler/jsr292/CreatesInterfaceDotEqualsCallInfo.java should be in needs_nashorn test group In-Reply-To: <54452FE0.9010304@oracle.com> References: <5441054E.1030705@oracle.com> <54411166.2070204@oracle.com> <54452FE0.9010304@oracle.com> Message-ID: <5445493B.7090109@oracle.com> Seems fine. Thanks, Vladimir K On 10/20/14 8:53 AM, Sergei Kovalev wrote: > Hi all > > Looking for second reviewer. > > On 17.10.2014 16:53, Vladimir Ivanov wrote: >> Looks good. >> >> Best regards, >> Vladimir Ivanov >> >> On 10/17/14, 4:02 PM, Sergei Kovalev wrote: >>> Hi All, >>> >>> Please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8028481 >>> Webrev: http://cr.openjdk.java.net/~vlivanov/kovalev/8028481/webrev.00/ >>> >>> Problem: >>> The test CreatesInterfaceDotEqualsCallInfo.java depends on nashorn >>> extension and compact2 API. The extension is optional for embedded >>> world. Therefore we should have an ability to exclude the test from >>> execution. Also we should exclude it from compact1 execution. >>> >>> Solution: >>> Two new groups are introduced: "needs_nashorn", "not_needs_nashorn". >>> Also test added to a group "needs_compact2". >>> I found that by mistake the test listed twice in a "hotspot_compiler_3" >>> group. One of the copies removed. >>> >>> Testing: >>> Groups content verified locally with jtreg. >>> >> >> > From vladimir.kozlov at oracle.com Mon Oct 20 22:59:17 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Oct 2014 15:59:17 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <1B318630-8544-4FC9-BC7A-9F0BA04EB666@oracle.com> References: <54386E92.3000006@oracle.com> <3976AC9A-9D8F-4520-89A7-37A697DA1B92@oracle.com> <1B318630-8544-4FC9-BC7A-9F0BA04EB666@oracle.com> Message-ID: <544593C5.2090709@oracle.com> Paul, There was an other place (speculative types code) which added the NULL check. Add next changes in parse2.cpp to previous patch: @@ -2223,6 +2243,7 @@ a = null(); b = pop(); if (!_gvn.type(b)->speculative_maybe_null() && + (method()->intrinsic_id() != vmIntrinsics::_class_cast) && !too_many_traps(Deoptimization::Reason_speculate_null_check)) { inc_sp(1); Node* null_ctl = top(); Whole patch: http://cr.openjdk.java.net/~kvn/8054492/webrev/ Thanks, Vladimir On 10/14/14 9:58 AM, Paul Sandoz wrote: > Here is a simpler test case that just uses a MH to Class.cast that exhibits the same behaviour. > > The commented out use of the BiFunction created from a lambda expressions works fine. > > This suggests there might be something about the MH invocation that is stopping the optimization from kicking in. > > Paul. > > import java.lang.invoke.MethodHandle; > import java.lang.invoke.MethodHandles; > import java.lang.invoke.MethodType; > import java.util.function.BiFunction; > > public class NullCheckDroppingsMHCastTest { > > static final MethodHandle MH_CAST; > > static { > try { > MH_CAST = MethodHandles.lookup().findVirtual(Class.class, > "cast", > MethodType.methodType(Object.class, Object.class)); > } > catch (Exception e) { > throw new Error(e); > } > } > > static final BiFunction fCast = (c, o) -> c.cast(o); > > > volatile String svalue = "A"; > volatile String snull = null; > String ssink; > > public static void main(String[] args) { > NullCheckDroppingsMHCastTest t = new NullCheckDroppingsMHCastTest(); > t.testLoop(); > } > > void testLoop() { > // Ensure testLoopOne is compiled and does not > // see a null value > for (int i = 0; i < 1000000; i++) { > testLoopOne(svalue); > // Uncomment the following and the call outside > // the loop should not result in any deoptimization > // testLoopOne(snull); > } > > // Sleep just to create delay in the compilation log > try { > Thread.currentThread().sleep(1000); > } > catch (Exception e) { > } > > // This should cause a de-optimisation > // if testLoopOne is compiled with a null-check > testLoopOne(snull); > } > > void testLoopOne(String s) { > try { > ssink = (String) (Object) MH_CAST.invokeExact(String.class, (Object) s); > // ssink = (String) fCast.apply(String.class, s); > } > catch (Throwable t) { > throw new Error(t); > } > } > } > From christian.thalinger at oracle.com Mon Oct 20 23:20:00 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 20 Oct 2014 16:20:00 -0700 Subject: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames In-Reply-To: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> References: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> Message-ID: <51850D67-A386-48CF-A065-F6506B31E8F2@oracle.com> There are a couple problems that haven?t been addressed yet. One of which is the fact that: + public > E internMemberName(E memberName) { in java.lang.Class cannot be public. You have to add some magic token machinery to make it usable from java.lang.invoke.MemberName (John knows more about this). Also: + public > E intern(E memberName) { has some commented code which I used to make sure to not introduce the same performance regression we saw in the original implementation. I can?t find the bug right now but maybe Serguei can give us the link. We have to make sure that Arrays.binarySearch fits all array size cases. > On Oct 17, 2014, at 11:16 AM, David Chase wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8013267 > > webrevs: > http://cr.openjdk.java.net/~drchase/8013267/jdk.03/ > http://cr.openjdk.java.net/~drchase/8013267/hotspot.03/ > > related bug: https://bugs.openjdk.java.net/browse/JDK-8042235 > > The ?bug? is a cleanup/space-saving RFE that enables fixes for other bugs related > to method name tables ? e.g., failure to properly update two method handles > referring to the same method after the method is redefined. The patch is months > old and needed to be brought up to date. Well, it is a real bug. > > In addition, the patch needed the following changes beyond what was seen in > other reviews: > 1) on the hotspot side, code to adjust the membername table needed to check > that the data for the membername table was actually allocated (one goal of this > rfe was to avoid allocating that table) else it would null deref and crash. Yes, that was an oversight. > > 2) on the jdk side, fencepost error in the membername table insertion; the first > entry could be duplicated ( ?if index > 0? wrong, should be ?if index >= 0?). Right, thanks. > > 3) on the jdk side, several of the constructors for MemberNames needed to be > replaced with factories that would consult the MemberNameTable and avoid > creating duplicates; again, that was the entire point of this fix. *NOT ALL > CONSTRUCTORS WERE MODIFIED LIKE THIS?, and there was one curious > piece of code where it seemed that this might not be what was desired, but it > was unclear how this would behave in the face of method redefinition. From > > http://cr.openjdk.java.net/~drchase/8013267/jdk.03/src/java.base/share/classes/java/lang/invoke/MemberName.java.html > > 1047 private MemberName resolve(byte refKind, MemberName ref, Class lookupClass) { > 1048 MemberName m = ref.clone(); // JVM will side-effect the ref > 1049 assert(refKind == m.getReferenceKind()); > 1050 try { > 1051 m = MethodHandleNatives.resolve(m, lookupClass); > 1052 m.checkForTypeAlias(); > 1053 m.resolution = null; > 1054 m.intern(); > > Note that this performs an ?intern? that ignores what is already found in the table > and may not place m in the table if a duplicate name is already there. ????????? I can?t remember if that was intended or more a quick hack to get things working. Looking at it again it seems wrong. > > > testing: > jtreg: > hotspot/{compiler,runtime,gc} > jdk/{vm,jdk,sun/{invoke,misc,reflect} > by-hand: verified that the crash example for 8042235 still crash in an unmodified VM and does not crash in a modified VM. > > Modified and retested > https://bugs.openjdk.java.net/secure/attachment/20184/RedefineMethodUsedByMultipleMethodHandles.java > Old: > // Calling fooMH1.vmtarget crashes the VM > System.out.println("fooMH1.invoke = " + fooMH1.invokeExact()); > > New: > // Calling fooMH1.vmtarget crashes the VM > System.out.println("fooMH1.invoke = " + fooMH1.invokeExact()); > System.out.println("fooMH2.invoke = " + fooMH2.invokeExact()); > > This turned out to be a reasonable thing to do, since the added line caused a crash till further corrections were made. > (See fixes 2 and 3 above). > > Should RedefineMethodUsedByMultipleMethodHandles.java also be added as a test? Yes. > > Are there other tests that would be good to run ?(and if they are ute tests, the more > detailed the instructions for how to run them, the better.) You can run the tests that failed during nightly testing. > > David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Oct 20 23:49:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Oct 2014 16:49:16 -0700 Subject: [9] RFR (XXXS) 8061563: Typo in test/compiler/exceptions/CatchInlineExceptions.java Message-ID: <54459F7C.3050700@oracle.com> Fixed typo in the test added with 8059299 fix. http://cr.openjdk.java.net/~kvn/8061563/webrev/ https://bugs.openjdk.java.net/browse/JDK-8061563 Thanks, Vladimir From serguei.spitsyn at oracle.com Tue Oct 21 00:17:14 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 Oct 2014 17:17:14 -0700 Subject: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames In-Reply-To: <51850D67-A386-48CF-A065-F6506B31E8F2@oracle.com> References: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> <51850D67-A386-48CF-A065-F6506B31E8F2@oracle.com> Message-ID: <5445A60A.9050503@oracle.com> On 10/20/14 4:20 PM, Christian Thalinger wrote: > There are a couple problems that haven?t been addressed yet. One of > which is the fact that: > *+ public > E internMemberName(E memberName) {* > in java.lang.Class cannot be public. You have to add some magic token > machinery to make it usable from java.lang.invoke.MemberName (John > knows more about this). Also: > *+ public > E intern(E memberName) {* > has some commented code which I used to make sure to not introduce the > same performance regression we saw in the original implementation. I > can?t find the bug right now but maybe Serguei can give us the link. > We have to make sure that Arrays.binarySearch fits all array size cases. The bug is: https://jbs.oracle.com/bugs/browse/JDK-8014288 perf regression in nashorn JDK-8008448.js test after 8008511 changes and the fix is: http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8014288-JVMTI-JSR292.1/ The approach was to use the*InstanceKlass::idnum_allocated_count()* and *Method::method_idnum()* for organizing a direct indexing based access to the MNT elementsas in the example below: oop MethodHandles::init_method_MemberName(Handle mname, Method* m, bool do_dispatch, KlassHandle receiver_limit_h) { . . . m->method_holder()->add_member_name(*m->method_idnum()*, mname); return mname(); } Not sure, the above is helpful enough though. :) Thanks, Serguei > >> On Oct 17, 2014, at 11:16 AM, David Chase > > wrote: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8013267 >> >> webrevs: >> http://cr.openjdk.java.net/~drchase/8013267/jdk.03/ >> >> http://cr.openjdk.java.net/~drchase/8013267/hotspot.03/ >> >> related bug: https://bugs.openjdk.java.net/browse/JDK-8042235 >> >> The ?bug? is a cleanup/space-saving RFE that enables fixes for other >> bugs related >> to method name tables ? e.g., failure to properly update two method >> handles >> referring to the same method after the method is redefined. The >> patch is months >> old and needed to be brought up to date. > > Well, it is a real bug. > >> >> In addition, the patch needed the following changes beyond what was >> seen in >> other reviews: >> 1) on the hotspot side, code to adjust the membername table needed to >> check >> that the data for the membername table was actually allocated (one >> goal of this >> rfe was to avoid allocating that table) else it would null deref >> and crash. > > Yes, that was an oversight. > >> >> 2) on the jdk side, fencepost error in the membername table >> insertion; the first >> entry could be duplicated ( ?if index > 0? wrong, should be ?if >> index >= 0?). > > Right, thanks. > >> >> 3) on the jdk side, several of the constructors for MemberNames >> needed to be >> replaced with factories that would consult the MemberNameTable and >> avoid >> creating duplicates; again, that was the entire point of this fix. >> *NOT ALL >> CONSTRUCTORS WERE MODIFIED LIKE THIS?, and there was one curious >> piece of code where it seemed that this might not be what was >> desired, but it >> was unclear how this would behave in the face of method >> redefinition. From >> >> http://cr.openjdk.java.net/~drchase/8013267/jdk.03/src/java.base/share/classes/java/lang/invoke/MemberName.java.html >> >> >> 1047 private MemberName resolve(byte refKind, MemberName ref, >> Class lookupClass) { >> 1048 MemberName m = ref.clone(); // JVM will side-effect >> the ref >> 1049 assert(refKind == m.getReferenceKind()); >> 1050 try { >> 1051 m = MethodHandleNatives.resolve(m, lookupClass); >> 1052 m.checkForTypeAlias(); >> 1053 m.resolution = null; >> 1054 m.intern(); >> >> Note that this performs an ?intern? that ignores what is already >> found in the table >> and may not place m in the table if a duplicate name is already >> there. ????????? > > I can?t remember if that was intended or more a quick hack to get > things working. Looking at it again it seems wrong. > >> >> >> testing: >> jtreg: >> hotspot/{compiler,runtime,gc} >> jdk/{vm,jdk,sun/{invoke,misc,reflect} >> by-hand: verified that the crash example for 8042235 still crash in >> an unmodified VM and does not crash in a modified VM. >> >> Modified and retested >> https://bugs.openjdk.java.net/secure/attachment/20184/RedefineMethodUsedByMultipleMethodHandles.java >> Old: >> // Calling fooMH1.vmtarget crashes the VM >> System.out.println("fooMH1.invoke = " + fooMH1.invokeExact()); >> >> New: >> // Calling fooMH1.vmtarget crashes the VM >> System.out.println("fooMH1.invoke = " + fooMH1.invokeExact()); >> System.out.println("fooMH2.invoke = " + fooMH2.invokeExact()); >> >> This turned out to be a reasonable thing to do, since the added line >> caused a crash till further corrections were made. >> (See fixes 2 and 3 above). >> >> Should RedefineMethodUsedByMultipleMethodHandles.java also be added >> as a test? > > Yes. > >> >> Are there other tests that would be good to run ?(and if they are ute >> tests, the more >> detailed the instructions for how to run them, the better.) > > You can run the tests that failed during nightly testing. > >> >> David >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Tue Oct 21 00:59:20 2014 From: john.r.rose at oracle.com (John Rose) Date: Mon, 20 Oct 2014 17:59:20 -0700 Subject: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames In-Reply-To: <51850D67-A386-48CF-A065-F6506B31E8F2@oracle.com> References: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> <51850D67-A386-48CF-A065-F6506B31E8F2@oracle.com> Message-ID: On Oct 20, 2014, at 4:20 PM, Christian Thalinger wrote: > You have to add some magic token machinery to make it usable from java.lang.invoke.MemberName (John knows more about this). I suggest you extend System.setJavaLangAccess, either directly, or by making it a little brother. You might also consider doing some sort of ad hoc bridge with jli.MethodHandle or jlr.Method, but it could propel you into bootstrapping hell. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Tue Oct 21 08:12:27 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 20 Oct 2014 22:12:27 -1000 Subject: [9] RFR (XXXS) 8061563: Typo in test/compiler/exceptions/CatchInlineExceptions.java In-Reply-To: <54459F7C.3050700@oracle.com> References: <54459F7C.3050700@oracle.com> Message-ID: <82C134F5-81F5-41C0-A86B-2EA46C510975@oracle.com> Looks fine. igor On Oct 20, 2014, at 1:49 PM, Vladimir Kozlov wrote: > Fixed typo in the test added with 8059299 fix. > > http://cr.openjdk.java.net/~kvn/8061563/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8061563 > > Thanks, > Vladimir From roland.westrelin at oracle.com Tue Oct 21 09:36:13 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 21 Oct 2014 11:36:13 +0200 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <54386E92.3000006@oracle.com> References: <54386E92.3000006@oracle.com> Message-ID: <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> > Even if isInstance() is not folded we don't need to generate uncommon trap for obj == null case: > > if (obj != null) { > if (!isInstance(obj)) { > uncommon_trap(); // or throw code > } > } > return obj; > > One benefit from having uncommon trap is it could be converted to implicit null check by folding it into a following memory instruction (load or store). In Class.cast() we don't have such memory instruction so we don't benefit from uncommon trap. Another benefit is that if we compile the isInstance as an exact check for a particular class, we can change the type of obj to that particular class: if (obj.klass != myklass) { uncommon_trap(); } // obj is of type myklass from here on If we don?t compile the null check as an uncommon trap we loose the exact type: if (obj != null) { if (obj.klass != myklass) { uncommon_trap(); } // obj is of type myklass } // we don?t don?t know anything about obj?s type here Wouldn?t it be better to have an intrinsic for Class.cast where we check whether the isInstance goes away entirely and then we don?t compile the null check at all. Otherwise, we compile a null check with an uncommon trap so we can propagate an exact type forward? Roland. From vladimir.kozlov at oracle.com Tue Oct 21 17:05:06 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Oct 2014 10:05:06 -0700 Subject: [9] RFR (XXXS) 8061563: Typo in test/compiler/exceptions/CatchInlineExceptions.java In-Reply-To: <82C134F5-81F5-41C0-A86B-2EA46C510975@oracle.com> References: <54459F7C.3050700@oracle.com> <82C134F5-81F5-41C0-A86B-2EA46C510975@oracle.com> Message-ID: <54469242.5040104@oracle.com> Thank you, Igor Vladimir On 10/21/14 1:12 AM, Igor Veresov wrote: > Looks fine. > > igor > > On Oct 20, 2014, at 1:49 PM, Vladimir Kozlov wrote: > >> Fixed typo in the test added with 8059299 fix. >> >> http://cr.openjdk.java.net/~kvn/8061563/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8061563 >> >> Thanks, >> Vladimir > From tobias.hartmann at oracle.com Tue Oct 21 17:07:07 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 21 Oct 2014 19:07:07 +0200 Subject: [9] RFR(S): 8060479: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java test fails with product build In-Reply-To: <5440ECD9.4060900@oracle.com> References: <543E828D.6050205@oracle.com> <5440BE85.3070409@oracle.com> <5440D7A8.7050309@oracle.com> <5440ECD9.4060900@oracle.com> Message-ID: <544692BB.4040405@oracle.com> Hi Vladimir, I changed the fix as you suggested: http://cr.openjdk.java.net/~thartmann/8060479/webrev.01/ The fix depends on JDK-8061443. Thanks, Tobias On 17.10.2014 12:18, Tobias Hartmann wrote: > Hi Vladimir, > > On 17.10.2014 10:47, Vladimir Kozlov wrote: >> CodeCacheMinimumUseSpace is different for Zero. There is WB API which returns >> options value getUintxVMFlag() you can use to calculate value minSize. > > Yes, but the flag is only available in debug builds. See 'Flag::find_flag': > > 525 // Don't report notproduct and develop flags in product builds. > > Calling getUintxVMFlag() throws a java.lang.NullPointerException with product > builds. One solution would be to only perform this check for debug builds where > we are able to compute the size. What do you think? > >> 8046809 changes will change min_code_cache_size value again (removes >> CodeCacheMinimumFreeSpace). Let Albert know to modify this test again. > > I will do so. > > Thanks, > Tobias > >> Thanks, >> Vladimir >> >> On 10/17/14 12:00 AM, Tobias Hartmann wrote: >>> Can I get another review for this? >>> >>> Thanks, >>> Tobias >>> >>> On 15.10.2014 16:19, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060479 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060479/webrev.00/ >>>> >>>> Problem: >>>> The test CheckSegmentedCodeCache assumes that VM startup always fails with a >>>> ReservedCodeCacheSize of 1700K. This is not true for product builds (see >>>> 'min_code_cache_size' in 'CodeCache::initialize_heaps()'). >>>> >>>> Solution: >>>> Check for debug build and adjust minimum code cache size accordingly. >>>> >>>> Testing: >>>> Failing test on JPRT. >>>> >>>> Thanks, >>>> Tobias From vladimir.kozlov at oracle.com Tue Oct 21 17:27:38 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Oct 2014 10:27:38 -0700 Subject: [9] RFR(S): 8060479: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java test fails with product build In-Reply-To: <544692BB.4040405@oracle.com> References: <543E828D.6050205@oracle.com> <5440BE85.3070409@oracle.com> <5440D7A8.7050309@oracle.com> <5440ECD9.4060900@oracle.com> <544692BB.4040405@oracle.com> Message-ID: <5446978A.7070505@oracle.com> This is good. Vladimir On 10/21/14 10:07 AM, Tobias Hartmann wrote: > Hi Vladimir, > > I changed the fix as you suggested: > http://cr.openjdk.java.net/~thartmann/8060479/webrev.01/ > > The fix depends on JDK-8061443. > > Thanks, > Tobias > > > On 17.10.2014 12:18, Tobias Hartmann wrote: >> Hi Vladimir, >> >> On 17.10.2014 10:47, Vladimir Kozlov wrote: >>> CodeCacheMinimumUseSpace is different for Zero. There is WB API which returns >>> options value getUintxVMFlag() you can use to calculate value minSize. >> >> Yes, but the flag is only available in debug builds. See 'Flag::find_flag': >> >> 525 // Don't report notproduct and develop flags in product builds. >> >> Calling getUintxVMFlag() throws a java.lang.NullPointerException with product >> builds. One solution would be to only perform this check for debug builds where >> we are able to compute the size. What do you think? >> >>> 8046809 changes will change min_code_cache_size value again (removes >>> CodeCacheMinimumFreeSpace). Let Albert know to modify this test again. >> >> I will do so. >> >> Thanks, >> Tobias >> >>> Thanks, >>> Vladimir >>> >>> On 10/17/14 12:00 AM, Tobias Hartmann wrote: >>>> Can I get another review for this? >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 15.10.2014 16:19, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060479 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060479/webrev.00/ >>>>> >>>>> Problem: >>>>> The test CheckSegmentedCodeCache assumes that VM startup always fails with a >>>>> ReservedCodeCacheSize of 1700K. This is not true for product builds (see >>>>> 'min_code_cache_size' in 'CodeCache::initialize_heaps()'). >>>>> >>>>> Solution: >>>>> Check for debug build and adjust minimum code cache size accordingly. >>>>> >>>>> Testing: >>>>> Failing test on JPRT. >>>>> >>>>> Thanks, >>>>> Tobias From tobias.hartmann at oracle.com Tue Oct 21 17:37:23 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 21 Oct 2014 19:37:23 +0200 Subject: [9] RFR(S): 8060479: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java test fails with product build In-Reply-To: <5446978A.7070505@oracle.com> References: <543E828D.6050205@oracle.com> <5440BE85.3070409@oracle.com> <5440D7A8.7050309@oracle.com> <5440ECD9.4060900@oracle.com> <544692BB.4040405@oracle.com> <5446978A.7070505@oracle.com> Message-ID: <544699D3.3000708@oracle.com> Thanks, Vladimir. Best, Tobias On 21.10.2014 19:27, Vladimir Kozlov wrote: > This is good. > > Vladimir > > On 10/21/14 10:07 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> I changed the fix as you suggested: >> http://cr.openjdk.java.net/~thartmann/8060479/webrev.01/ >> >> The fix depends on JDK-8061443. >> >> Thanks, >> Tobias >> >> >> On 17.10.2014 12:18, Tobias Hartmann wrote: >>> Hi Vladimir, >>> >>> On 17.10.2014 10:47, Vladimir Kozlov wrote: >>>> CodeCacheMinimumUseSpace is different for Zero. There is WB API which returns >>>> options value getUintxVMFlag() you can use to calculate value minSize. >>> >>> Yes, but the flag is only available in debug builds. See 'Flag::find_flag': >>> >>> 525 // Don't report notproduct and develop flags in product builds. >>> >>> Calling getUintxVMFlag() throws a java.lang.NullPointerException with product >>> builds. One solution would be to only perform this check for debug builds where >>> we are able to compute the size. What do you think? >>> >>>> 8046809 changes will change min_code_cache_size value again (removes >>>> CodeCacheMinimumFreeSpace). Let Albert know to modify this test again. >>> >>> I will do so. >>> >>> Thanks, >>> Tobias >>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/17/14 12:00 AM, Tobias Hartmann wrote: >>>>> Can I get another review for this? >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> On 15.10.2014 16:19, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> please review the following patch. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060479 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8060479/webrev.00/ >>>>>> >>>>>> Problem: >>>>>> The test CheckSegmentedCodeCache assumes that VM startup always fails with a >>>>>> ReservedCodeCacheSize of 1700K. This is not true for product builds (see >>>>>> 'min_code_cache_size' in 'CodeCache::initialize_heaps()'). >>>>>> >>>>>> Solution: >>>>>> Check for debug build and adjust minimum code cache size accordingly. >>>>>> >>>>>> Testing: >>>>>> Failing test on JPRT. >>>>>> >>>>>> Thanks, >>>>>> Tobias From john.r.rose at oracle.com Tue Oct 21 20:00:33 2014 From: john.r.rose at oracle.com (John Rose) Date: Tue, 21 Oct 2014 13:00:33 -0700 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <543F82E7.1050706@oracle.com> References: <5436465A.3080001@oracle.com> <5437A081.4060608@oracle.com> <5437ED93.6080806@oracle.com> <54381017.6020809@oracle.com> <543BE7E4.6040203@oracle.com> <543C83B8.5050003@oracle.com> <543CD8E1.6050303@oracle.com> <543F82E7.1050706@oracle.com> Message-ID: <89875680-40F2-4645-9FF9-A231F2319915@oracle.com> On Oct 16, 2014, at 1:33 AM, Albert Noll wrote: > Can I have a second review? Reviewed. Question: Can you say why "handle_full_code_cache" doesn't need to be called so much anymore? It seems a non-trivial issue since you were able to delete it from so many places, but not all. I suggest adding a comment to the header of handle_full_code_cache to guide future coders where the calls must be put. A couple of typos: + "Start aggressive sweeping if X[%] of the code cache are free." \ s/are/is/ (percentage of singular is singular as in, 5% of code cache is full, etc.) + init_log_sweeer s/sweeer/sweeper/; IMO should actually be "init_records", "init_log", or "init_sweeper_log". (Sweeering is not done in polite company!) I like the cleanups. Lots of tidying, code deletion, and factoring. You have taken a hard part of the JVM and made it incrementally simpler and nicer to work with. Thanks, ? John From vladimir.kozlov at oracle.com Tue Oct 21 21:22:27 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Oct 2014 14:22:27 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> Message-ID: <5446CE93.9040608@oracle.com> You have valid point. When I changed the test to pass Object to testLoopOne() the NULL check with uncommon trap was folded into implicit NULL: 02c movl R10, [RDX + #8 (8-bit)] # compressed klass ptr 030 NullCheck RDX 030 030 B2: # B4 B3 <- B1 Freq: 0.999999 030 cmpl R10, narrowklass: precise klass java/lang/String: 0x00007fe7ba0367e0:Constant:exact * # compressed klass ptr 037 jne,u B4 P=0.000000 C=-1.000000 037 So my original statement (no load in Class.cast()) was incorrect. With my changes it did not and it has more instructions generated. Also checkcast is placed on exit block - it dominates following code as you said. I will try intrinsic and see how it works. The problem with intrinsic we don't get profiling info from Class.cast() MDO. That is why I tried to avoid it. Thanks, Vladimir On 10/21/14 2:36 AM, Roland Westrelin wrote: >> Even if isInstance() is not folded we don't need to generate uncommon trap for obj == null case: >> >> if (obj != null) { >> if (!isInstance(obj)) { >> uncommon_trap(); // or throw code >> } >> } >> return obj; >> >> One benefit from having uncommon trap is it could be converted to implicit null check by folding it into a following memory instruction (load or store). In Class.cast() we don't have such memory instruction so we don't benefit from uncommon trap. > > Another benefit is that if we compile the isInstance as an exact check for a particular class, we can change the type of obj to that particular class: > > if (obj.klass != myklass) { > uncommon_trap(); > } > > // obj is of type myklass from here on > > If we don?t compile the null check as an uncommon trap we loose the exact type: > > if (obj != null) { > if (obj.klass != myklass) { > uncommon_trap(); > } > > // obj is of type myklass > } > // we don?t don?t know anything about obj?s type here > > Wouldn?t it be better to have an intrinsic for Class.cast where we check whether the isInstance goes away entirely and then we don?t compile the null check at all. Otherwise, we compile a null check with an uncommon trap so we can propagate an exact type forward? > > Roland. > From vladimir.kozlov at oracle.com Tue Oct 21 21:32:29 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Oct 2014 14:32:29 -0700 Subject: [9] RFR(M) 8041984: CompilerThread seems to occupy all CPU in a very rare situation In-Reply-To: <543DB731.5000301@oracle.com> References: <5438A6EC.8000302@oracle.com> <415C2022-8ABA-405C-B7C6-258B512C8B04@oracle.com> <543D8A43.5020405@oracle.com> <543DB731.5000301@oracle.com> Message-ID: <5446D0ED.9040900@oracle.com> Please, I need reviews. Thanks, Vladimir On 10/14/14 4:52 PM, Vladimir Kozlov wrote: > I updated changes. > > http://cr.openjdk.java.net/~kvn/8041984/webrev.01/ > > As David suggested I added SAMPLE_SIZE constant: > > #define SAMPLE_SIZE 4 > if ((next % SAMPLE_SIZE) == 0) { > // Each 4 iterations calculate how much time it will take > // to complete graph construction. > time.stop(); > double stop_time = time.seconds(); > double time_per_iter = (stop_time - start_time) / > (double)SAMPLE_SIZE; > double time_until_end = time_per_iter * > (double)(java_objects_length - next); > if ((start_time + time_until_end) >= EscapeAnalysisTimeout) { > > I also replaced TIME_LIMIT constant with flag: > > product(double, EscapeAnalysisTimeout, 20. DEBUG_ONLY(+40.), \ > "Abort EA when it reaches time limit (in sec)") \ > > Thanks, > Vladimir > > On 10/14/14 1:40 PM, Vladimir Kozlov wrote: >> On 10/14/14 10:30 AM, David Chase wrote: >>> I?m curious about the granularity of the completion-prediction ? >>> you?re checking every 4 iterations and extrapolating from there. >>> Do we know that the times are that uniform, or would we be better off >>> with larger sample sizes? >> >> Yes, I observed uniformly slowly growing times for PARTS of iterations >> and not all iterations. That is why I want to take several samples. >> For example first iterations where fast but when array allocation >> objects begin processed time are rapidly growing. >> If I take very big sample fast iterations affect the result - delay >> abort. >> >> I did implementation similar to your "alternate approach" suggestion and >> I saw that the abort happened much later than with current my approach. >> >>> (How long does a single iteration take, anyway?) >> >> As I said one slow iteration may take upto 1 sec. So I want to abort as >> soon as I see a such case (but allow spikes). Taking larger sample sizes >> may delay an abort for several seconds. >> >>> >>> And in the sample code, I see the choice of sample size (4) encoded as >>> (next & 3) == 0 >>> // Each 4 iterations calculate how much time it will take >>> double time_per_iter = (stop_time - start_time) * 0.25; >>> >>> why not write this as (say) >>> >>> static const int LOG_SAMPLE_SIZE = 2; >>> static const int SAMPLE_SIZE = (1 << LOG_SAMPLE_SIZE); >>> next % SAMPLE_SIZE == 0 // next could be a uint, couldn?t it? >>> double time_per_iter = (stop_time - start_time) * (1.0/SAMPLE_SIZE); >>> >>> perhaps rewriting 1.0/SAMPLE_SIZE as another static const as necessary >>> to get it properly precalculated; I?m not sure what C++ compilers are >>> doing nowadays. >> >> I am optimizing :) by avoiding % and / operations. But I agree and can >> add SAMPLE_SIZE constant so code can be more clear. >> >> Thanks, >> Vladimir >> >>> >>> An alternate approach would be to compute the overall rate thus far, >>> checking at >>> (say) iterations 4, 8, 16, 32, etc and computing the average from >>> there, starting >>> at whatever power of two is a decent fraction of the iterations needed >>> to timeout. >>> >>> e.g., don?t reset start_time, just compute elapsed at each sample: >>> >>> if ((next & (ptwo - 1) == 0) { >>> time.stop(); >>> double elapsed = time.seconds() - start_time; >>> double projected = elapsed * (double) java_objects_length / next; >>> >>> Or you can compute a java_objects_length that would surely lead to >>> failure, and >>> always do that (fast, integer) comparison: >>> ... >>> unsigned int length_bound = (int) next * (CG_BUILD_TIME_LIMIT / >>> elapsed) >>> ? >>> if (java_objects_length > length_bound) { ? timeout >>> >>> David >>> >>> On 2014-10-10, at 11:41 PM, Vladimir Kozlov >>> wrote: >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8041984 >>>> http://cr.openjdk.java.net/~kvn/8041984/webrev/ >>>> >>>> Next method puts C2's EA to its knees: >>>> >>>> com.graphhopper.coll.GHLongIntBTree$BTreeEntry::put() >>>> >>>> https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/coll/GHLongIntBTree.java >>>> >>>> >>>> >>>> It shows that current EA connection graph build code is very >>>> inefficient when a graph has a lot of connections (edges). >>>> >>>> With inlining the BTreeEntry::put() method has about 100 allocations >>>> from which about 80 are arrays allocations. Most of them are object >>>> arrays which are generated by Arrays.copyOf(). After number of edges >>>> in EA Connection Graph reaches about 50000 it takes more then 1 sec >>>> to find all nodes which reference an allocation. >>>> >>>> Current EA code has bailout by timeout from graph building code. But >>>> the timeout (30 sec for product VM) is checked only after all object >>>> nodes are processed. So it may take > 2 mins before EA is aborted: >>>> >>>> >>>> >>>> >>> stamp='150.967'/> >>>> >>>> Also ConnectionGraph::add_java_object_edges() method does not check >>>> the presence of a node when it adds new one to the worklist (in >>>> add_to_worklist() method). Which leads to hundreds MB of used by EA >>>> memory when BTreeEntry::put() is processed. >>>> >>>> To address issues new timeout checks were added. >>>> New _pidx index field is added to graph's nodes and VectorSet is used >>>> to reduce size of worklist in add_java_object_edges() method. >>>> >>>> Escaping node CreateEx is mapped phantom_obj to reduce number of >>>> process objects in connection graph. We do the same for other >>>> escaping objects. >>>> >>>> Tested with graphhopper server application: >>>> >>>> >>>> >>>> >>> stamp='22.355'/> >>>> >>>> Thanks, >>>> Vladimir >>> From vladimir.kozlov at oracle.com Wed Oct 22 00:02:06 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Oct 2014 17:02:06 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <5446CE93.9040608@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> Message-ID: <5446F3FE.7080800@oracle.com> Here is intrinsic implementation: http://cr.openjdk.java.net/~kvn/8054492/webrev.01/ It will only optimize (removes NULL check) if isInstance() can be collapsed during parsing. NULL check will not be removed if types are improved after parsing during igvn or CCP phases. It is targeting only cases when object's class and Class's class are known statically: void testLoopOne(String s) { ssink = String.class.cast(s); ssink = (String) MH_CAST.invokeExact(String.class, s); Paul, is it enough for you? Thanks, Vladimir On 10/21/14 2:22 PM, Vladimir Kozlov wrote: > You have valid point. > > When I changed the test to pass Object to testLoopOne() the NULL check > with uncommon trap was folded into implicit NULL: > > 02c movl R10, [RDX + #8 (8-bit)] # compressed klass ptr > 030 NullCheck RDX > 030 > 030 B2: # B4 B3 <- B1 Freq: 0.999999 > 030 cmpl R10, narrowklass: precise klass java/lang/String: > 0x00007fe7ba0367e0:Constant:exact * # compressed klass ptr > 037 jne,u B4 P=0.000000 C=-1.000000 > 037 > > So my original statement (no load in Class.cast()) was incorrect. > With my changes it did not and it has more instructions generated. > > Also checkcast is placed on exit block - it dominates following code as > you said. > > I will try intrinsic and see how it works. The problem with intrinsic we > don't get profiling info from Class.cast() MDO. That is why I tried to > avoid it. > > Thanks, > Vladimir > > On 10/21/14 2:36 AM, Roland Westrelin wrote: >>> Even if isInstance() is not folded we don't need to generate uncommon >>> trap for obj == null case: >>> >>> if (obj != null) { >>> if (!isInstance(obj)) { >>> uncommon_trap(); // or throw code >>> } >>> } >>> return obj; >>> >>> One benefit from having uncommon trap is it could be converted to >>> implicit null check by folding it into a following memory instruction >>> (load or store). In Class.cast() we don't have such memory >>> instruction so we don't benefit from uncommon trap. >> >> Another benefit is that if we compile the isInstance as an exact check >> for a particular class, we can change the type of obj to that >> particular class: >> >> if (obj.klass != myklass) { >> uncommon_trap(); >> } >> >> // obj is of type myklass from here on >> >> If we don?t compile the null check as an uncommon trap we loose the >> exact type: >> >> if (obj != null) { >> if (obj.klass != myklass) { >> uncommon_trap(); >> } >> >> // obj is of type myklass >> } >> // we don?t don?t know anything about obj?s type here >> >> Wouldn?t it be better to have an intrinsic for Class.cast where we >> check whether the isInstance goes away entirely and then we don?t >> compile the null check at all. Otherwise, we compile a null check with >> an uncommon trap so we can propagate an exact type forward? >> >> Roland. >> From brendan.d.gregg at gmail.com Wed Oct 22 00:10:31 2014 From: brendan.d.gregg at gmail.com (Brendan Gregg) Date: Tue, 21 Oct 2014 17:10:31 -0700 Subject: system profilers and incomplete stacks In-Reply-To: References: <1F3E1054-9947-43AC-9AD1-350E0174C9A1@oracle.com> <539FD60E.10203@oracle.com> Message-ID: G'Day, I checked the JDK 9 early access releases, but didn't see anything for JDK-6276264. I've also since learned that Twitter has an OpenJDK fork with frame pointers disabled, for the same purpose: stack profiling (using Linux perf_events). Might this be worked on for JDK 9? I can help test. thanks, Brendan On Mon, Jun 16, 2014 at 11:52 PM, Brendan Gregg wrote: > G'Day Serguei, > > On Mon, Jun 16, 2014 at 10:45 PM, serguei.spitsyn at oracle.com > wrote: >> >> Hi Brendan, >> >> We are aware of these issues and work with the Solaris team to fix them in >> JDK 9. >> One is the frame pointer is used by the server compiler as a general >> purpose register on intel. >> Another is about the virtual (or inlined) frames. >> >> There are a couple of related bugs: >> https://bugs.openjdk.java.net/browse/JDK-6617153 >> https://bugs.openjdk.java.net/browse/JDK-6276264 >> >> There can be more issues filed on this. > > > Ah, thanks, it's JDK-6276264. > > As Tom Rodriguez said at the time (2005): "The server VM uses the frame > pointer as an allocatable register and there's no way to turn that off." I > was really hoping there was a way to turn that off, like > -fno-omit-frame-pointer. > > This also means DTrace jstack() has never worked fully. For the applications > I tried it on, 50% of stacks were incomplete. Perhaps it wasn't that bad in > 2005. I've been getting more mileage today from Java profilers. > >> Please, note, that the jstack action is not implemented on Linux yet. > > > Linux doesn't have DTrace jstack(), no, but its perf_events does has support > for loading an auxiliary file of symbols, which can created via a Java agent > for that purpose (eg, https://github.com/jrudolph/perf-map-agent). But that > hasn't been working fully for the same reason - incomplete stacks. > > Brendan > >> >> Thanks, >> Serguei >> >> >> >> On 6/16/14 5:14 PM, Brendan Gregg wrote: >> >> Thanks but no, I'm aware of that bug and workarounds (I'm using the >> LD_AUDIT_64=/usr/lib/dtrace/64/libdtrace_forceload.so workaround, which >> isn't mentioned in the bug comments, but probably should be). That bug is >> about missing symbols, but the stacks shown in that bug still go all the way >> to thread_start. My stacks often don't. >> >> For simple programs, the stacks are complete. But something complex (eg, >> vert.x with event loops), and the stacks are often incomplete, one frame >> only. Very much like what I see with -fomit-frame-pointer, although this is >> hotspot, not gcc. Such incomplete stacks are seen using either DTrace or >> perf_events. >> >> It was suggested to me to email the hotspot developers, because this may >> well be a hotspot optimization they are familiar with. It may also be >> something really obvious, like that the JVM breaks native stacks due to >> optimized frames / green threads / etc, and there is absolutely no way >> around it (no way to disable it). If that's true, it may also mean that the >> DTrace jstack() action has always had this issue. I'm still reading the >> source... >> >> Brendan >> >> >> >> On Mon, Jun 16, 2014 at 4:04 AM, Staffan Larsen >> wrote: >>> >>> I think this is the bug you are looking at: >>> https://bugs.openjdk.java.net/browse/JDK-7187999, but I?ll defer to someone >>> else to confirm. >>> >>> /Staffan >>> >>> >>> On 16 jun 2014, at 12:47, Roland Westrelin >>> wrote: >>> >>> Forwarding to serviceability alias where this question belongs I think. >>> >>> Begin forwarded message: >>> >>> From: Brendan Gregg >>> Subject: system profilers and incomplete stacks >>> Date: June 12, 2014 at 7:15:54 PM GMT+2 >>> To: hotspot-compiler-dev at openjdk.java.net >>> >>> G'Day, >>> >>> Is there a way to run hotspot so that a system profiler (eg, DTrace, or >>> Linux perf_events) can measure complete stacks? I often get incomplete, >>> partial stacks, with one or a few frames only. I'm not worried about symbols >>> right now, what I'd like is to walk stacks all the way down to thread start. >>> >>> I've been browsing the hotspot code, but haven't found out how yet. I >>> suspect it's related to Java optimized frames, and has ditched the frame >>> pointer. I was looking for an equivalent -fno-omit-frame-pointer option. >>> >>> Here's an example: >>> >>> # dtrace -n 'profile-99 /execname == "java"/ { @[jstack(100, 8000)] = >>> count(); }' >>> [...] >>> org/mozilla/javascript/ >>> >>> ScriptableObject.createSlot(Ljava/lang/String;II)Lorg/mozilla/javascript/ScriptableObject$Slot;* >>> 0x884acce8200002da >>> 1 >>> >>> sun/nio/ch/SocketChannelImpl.read(Ljava/nio/ByteBuffer;)I* >>> 0xffffffff20007f4b >>> 1 >>> >>> >>> org/mozilla/javascript/ScriptRuntime.newObjectLiteral([Ljava/lang/Object;[Ljava/lang/Object;[ILorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;)Lorg/mozilla/javascript/Scriptable;* >>> 0xa20000041 >>> 1 >>> [...] >>> >>> I see similar incomplete stacks with Linux perf_events. Oracle JDKs from >>> 6 to 8, and OpenJDK. >>> >>> thanks, >>> >>> Brendan >>> -- >>> http://www.brendangregg.com >>> >>> >>> >> >> >> >> -- >> http://www.brendangregg.com >> >> > > > > -- > http://www.brendangregg.com From igor.veresov at oracle.com Wed Oct 22 06:05:13 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 21 Oct 2014 20:05:13 -1000 Subject: [9] RFR(M) 8041984: CompilerThread seems to occupy all CPU in a very rare situation In-Reply-To: <5446D0ED.9040900@oracle.com> References: <5438A6EC.8000302@oracle.com> <415C2022-8ABA-405C-B7C6-258B512C8B04@oracle.com> <543D8A43.5020405@oracle.com> <543DB731.5000301@oracle.com> <5446D0ED.9040900@oracle.com> Message-ID: <4E5D5236-86BB-4235-B7DF-AFE90893FB02@oracle.com> Alright, since nobody is taking on it.. The timeout feature looks good, I suppose a JIT needs to be adaptive to available CPU resources. A couple of small questions: 1. Why is it necessary to add phantom_obj to worklists? 130 ptnodes_worklist.append(phantom_obj); 131 java_objects_worklist.append(phantom_obj); 2. What does pidx_bias do here? 399 inline void add_to_worklist(PointsToNode* pt) { 400 PointsToNode* ptf = pt; 401 uint pidx_bias = 0; 402 if (PointsToNode::is_base_use(pt)) { 403 ptf = PointsToNode::get_use_node(pt)->as_Field(); 404 pidx_bias = _next_pidx; 405 } 406 if (!_in_worklist.test_set(ptf->pidx() + pidx_bias)) { 407 _worklist.append(pt); 408 } 409 } Thanks, igor On Oct 21, 2014, at 11:32 AM, Vladimir Kozlov wrote: > Please, I need reviews. > > Thanks, > Vladimir > > On 10/14/14 4:52 PM, Vladimir Kozlov wrote: >> I updated changes. >> >> http://cr.openjdk.java.net/~kvn/8041984/webrev.01/ >> >> As David suggested I added SAMPLE_SIZE constant: >> >> #define SAMPLE_SIZE 4 >> if ((next % SAMPLE_SIZE) == 0) { >> // Each 4 iterations calculate how much time it will take >> // to complete graph construction. >> time.stop(); >> double stop_time = time.seconds(); >> double time_per_iter = (stop_time - start_time) / >> (double)SAMPLE_SIZE; >> double time_until_end = time_per_iter * >> (double)(java_objects_length - next); >> if ((start_time + time_until_end) >= EscapeAnalysisTimeout) { >> >> I also replaced TIME_LIMIT constant with flag: >> >> product(double, EscapeAnalysisTimeout, 20. DEBUG_ONLY(+40.), \ >> "Abort EA when it reaches time limit (in sec)") \ >> >> Thanks, >> Vladimir >> >> On 10/14/14 1:40 PM, Vladimir Kozlov wrote: >>> On 10/14/14 10:30 AM, David Chase wrote: >>>> I?m curious about the granularity of the completion-prediction ? >>>> you?re checking every 4 iterations and extrapolating from there. >>>> Do we know that the times are that uniform, or would we be better off >>>> with larger sample sizes? >>> >>> Yes, I observed uniformly slowly growing times for PARTS of iterations >>> and not all iterations. That is why I want to take several samples. >>> For example first iterations where fast but when array allocation >>> objects begin processed time are rapidly growing. >>> If I take very big sample fast iterations affect the result - delay >>> abort. >>> >>> I did implementation similar to your "alternate approach" suggestion and >>> I saw that the abort happened much later than with current my approach. >>> >>>> (How long does a single iteration take, anyway?) >>> >>> As I said one slow iteration may take upto 1 sec. So I want to abort as >>> soon as I see a such case (but allow spikes). Taking larger sample sizes >>> may delay an abort for several seconds. >>> >>>> >>>> And in the sample code, I see the choice of sample size (4) encoded as >>>> (next & 3) == 0 >>>> // Each 4 iterations calculate how much time it will take >>>> double time_per_iter = (stop_time - start_time) * 0.25; >>>> >>>> why not write this as (say) >>>> >>>> static const int LOG_SAMPLE_SIZE = 2; >>>> static const int SAMPLE_SIZE = (1 << LOG_SAMPLE_SIZE); >>>> next % SAMPLE_SIZE == 0 // next could be a uint, couldn?t it? >>>> double time_per_iter = (stop_time - start_time) * (1.0/SAMPLE_SIZE); >>>> >>>> perhaps rewriting 1.0/SAMPLE_SIZE as another static const as necessary >>>> to get it properly precalculated; I?m not sure what C++ compilers are >>>> doing nowadays. >>> >>> I am optimizing :) by avoiding % and / operations. But I agree and can >>> add SAMPLE_SIZE constant so code can be more clear. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> An alternate approach would be to compute the overall rate thus far, >>>> checking at >>>> (say) iterations 4, 8, 16, 32, etc and computing the average from >>>> there, starting >>>> at whatever power of two is a decent fraction of the iterations needed >>>> to timeout. >>>> >>>> e.g., don?t reset start_time, just compute elapsed at each sample: >>>> >>>> if ((next & (ptwo - 1) == 0) { >>>> time.stop(); >>>> double elapsed = time.seconds() - start_time; >>>> double projected = elapsed * (double) java_objects_length / next; >>>> >>>> Or you can compute a java_objects_length that would surely lead to >>>> failure, and >>>> always do that (fast, integer) comparison: >>>> ... >>>> unsigned int length_bound = (int) next * (CG_BUILD_TIME_LIMIT / >>>> elapsed) >>>> ? >>>> if (java_objects_length > length_bound) { ? timeout >>>> >>>> David >>>> >>>> On 2014-10-10, at 11:41 PM, Vladimir Kozlov >>>> wrote: >>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8041984 >>>>> http://cr.openjdk.java.net/~kvn/8041984/webrev/ >>>>> >>>>> Next method puts C2's EA to its knees: >>>>> >>>>> com.graphhopper.coll.GHLongIntBTree$BTreeEntry::put() >>>>> >>>>> https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/coll/GHLongIntBTree.java >>>>> >>>>> >>>>> >>>>> It shows that current EA connection graph build code is very >>>>> inefficient when a graph has a lot of connections (edges). >>>>> >>>>> With inlining the BTreeEntry::put() method has about 100 allocations >>>>> from which about 80 are arrays allocations. Most of them are object >>>>> arrays which are generated by Arrays.copyOf(). After number of edges >>>>> in EA Connection Graph reaches about 50000 it takes more then 1 sec >>>>> to find all nodes which reference an allocation. >>>>> >>>>> Current EA code has bailout by timeout from graph building code. But >>>>> the timeout (30 sec for product VM) is checked only after all object >>>>> nodes are processed. So it may take > 2 mins before EA is aborted: >>>>> >>>>> >>>>> >>>>> >>>> stamp='150.967'/> >>>>> >>>>> Also ConnectionGraph::add_java_object_edges() method does not check >>>>> the presence of a node when it adds new one to the worklist (in >>>>> add_to_worklist() method). Which leads to hundreds MB of used by EA >>>>> memory when BTreeEntry::put() is processed. >>>>> >>>>> To address issues new timeout checks were added. >>>>> New _pidx index field is added to graph's nodes and VectorSet is used >>>>> to reduce size of worklist in add_java_object_edges() method. >>>>> >>>>> Escaping node CreateEx is mapped phantom_obj to reduce number of >>>>> process objects in connection graph. We do the same for other >>>>> escaping objects. >>>>> >>>>> Tested with graphhopper server application: >>>>> >>>>> >>>>> >>>>> >>>> stamp='22.355'/> >>>>> >>>>> Thanks, >>>>> Vladimir >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Wed Oct 22 06:43:43 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 22 Oct 2014 08:43:43 +0200 Subject: system profilers and incomplete stacks In-Reply-To: References: <1F3E1054-9947-43AC-9AD1-350E0174C9A1@oracle.com> <539FD60E.10203@oracle.com> Message-ID: <542BB193-847F-413F-AE53-3EED02A6B9BE@oracle.com> On 22 okt 2014, at 02:10, Brendan Gregg wrote: > G'Day, > > I checked the JDK 9 early access releases, but didn't see anything for > JDK-6276264. That bug has been closed as a duplicate of https://bugs.openjdk.java.net/browse/JDK-6617153, which is still open. > I've also since learned that Twitter has an OpenJDK fork > with frame pointers disabled, for the same purpose: stack profiling > (using Linux perf_events). Might this be worked on for JDK 9? I would welcome that change - perhaps Twitter can contribute it? Thanks, /Staffan > I can > help test. thanks, > > Brendan > > On Mon, Jun 16, 2014 at 11:52 PM, Brendan Gregg > wrote: >> G'Day Serguei, >> >> On Mon, Jun 16, 2014 at 10:45 PM, serguei.spitsyn at oracle.com >> wrote: >>> >>> Hi Brendan, >>> >>> We are aware of these issues and work with the Solaris team to fix them in >>> JDK 9. >>> One is the frame pointer is used by the server compiler as a general >>> purpose register on intel. >>> Another is about the virtual (or inlined) frames. >>> >>> There are a couple of related bugs: >>> https://bugs.openjdk.java.net/browse/JDK-6617153 >>> https://bugs.openjdk.java.net/browse/JDK-6276264 >>> >>> There can be more issues filed on this. >> >> >> Ah, thanks, it's JDK-6276264. >> >> As Tom Rodriguez said at the time (2005): "The server VM uses the frame >> pointer as an allocatable register and there's no way to turn that off." I >> was really hoping there was a way to turn that off, like >> -fno-omit-frame-pointer. >> >> This also means DTrace jstack() has never worked fully. For the applications >> I tried it on, 50% of stacks were incomplete. Perhaps it wasn't that bad in >> 2005. I've been getting more mileage today from Java profilers. >> >>> Please, note, that the jstack action is not implemented on Linux yet. >> >> >> Linux doesn't have DTrace jstack(), no, but its perf_events does has support >> for loading an auxiliary file of symbols, which can created via a Java agent >> for that purpose (eg, https://github.com/jrudolph/perf-map-agent). But that >> hasn't been working fully for the same reason - incomplete stacks. >> >> Brendan >> >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 6/16/14 5:14 PM, Brendan Gregg wrote: >>> >>> Thanks but no, I'm aware of that bug and workarounds (I'm using the >>> LD_AUDIT_64=/usr/lib/dtrace/64/libdtrace_forceload.so workaround, which >>> isn't mentioned in the bug comments, but probably should be). That bug is >>> about missing symbols, but the stacks shown in that bug still go all the way >>> to thread_start. My stacks often don't. >>> >>> For simple programs, the stacks are complete. But something complex (eg, >>> vert.x with event loops), and the stacks are often incomplete, one frame >>> only. Very much like what I see with -fomit-frame-pointer, although this is >>> hotspot, not gcc. Such incomplete stacks are seen using either DTrace or >>> perf_events. >>> >>> It was suggested to me to email the hotspot developers, because this may >>> well be a hotspot optimization they are familiar with. It may also be >>> something really obvious, like that the JVM breaks native stacks due to >>> optimized frames / green threads / etc, and there is absolutely no way >>> around it (no way to disable it). If that's true, it may also mean that the >>> DTrace jstack() action has always had this issue. I'm still reading the >>> source... >>> >>> Brendan >>> >>> >>> >>> On Mon, Jun 16, 2014 at 4:04 AM, Staffan Larsen >>> wrote: >>>> >>>> I think this is the bug you are looking at: >>>> https://bugs.openjdk.java.net/browse/JDK-7187999, but I?ll defer to someone >>>> else to confirm. >>>> >>>> /Staffan >>>> >>>> >>>> On 16 jun 2014, at 12:47, Roland Westrelin >>>> wrote: >>>> >>>> Forwarding to serviceability alias where this question belongs I think. >>>> >>>> Begin forwarded message: >>>> >>>> From: Brendan Gregg >>>> Subject: system profilers and incomplete stacks >>>> Date: June 12, 2014 at 7:15:54 PM GMT+2 >>>> To: hotspot-compiler-dev at openjdk.java.net >>>> >>>> G'Day, >>>> >>>> Is there a way to run hotspot so that a system profiler (eg, DTrace, or >>>> Linux perf_events) can measure complete stacks? I often get incomplete, >>>> partial stacks, with one or a few frames only. I'm not worried about symbols >>>> right now, what I'd like is to walk stacks all the way down to thread start. >>>> >>>> I've been browsing the hotspot code, but haven't found out how yet. I >>>> suspect it's related to Java optimized frames, and has ditched the frame >>>> pointer. I was looking for an equivalent -fno-omit-frame-pointer option. >>>> >>>> Here's an example: >>>> >>>> # dtrace -n 'profile-99 /execname == "java"/ { @[jstack(100, 8000)] = >>>> count(); }' >>>> [...] >>>> org/mozilla/javascript/ >>>> >>>> ScriptableObject.createSlot(Ljava/lang/String;II)Lorg/mozilla/javascript/ScriptableObject$Slot;* >>>> 0x884acce8200002da >>>> 1 >>>> >>>> sun/nio/ch/SocketChannelImpl.read(Ljava/nio/ByteBuffer;)I* >>>> 0xffffffff20007f4b >>>> 1 >>>> >>>> >>>> org/mozilla/javascript/ScriptRuntime.newObjectLiteral([Ljava/lang/Object;[Ljava/lang/Object;[ILorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;)Lorg/mozilla/javascript/Scriptable;* >>>> 0xa20000041 >>>> 1 >>>> [...] >>>> >>>> I see similar incomplete stacks with Linux perf_events. Oracle JDKs from >>>> 6 to 8, and OpenJDK. >>>> >>>> thanks, >>>> >>>> Brendan >>>> -- >>>> http://www.brendangregg.com >>>> >>>> >>>> >>> >>> >>> >>> -- >>> http://www.brendangregg.com >>> >>> >> >> >> >> -- >> http://www.brendangregg.com From serguei.spitsyn at oracle.com Wed Oct 22 07:32:48 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Oct 2014 00:32:48 -0700 Subject: system profilers and incomplete stacks In-Reply-To: References: <1F3E1054-9947-43AC-9AD1-350E0174C9A1@oracle.com> <539FD60E.10203@oracle.com> Message-ID: <54475DA0.8090103@oracle.com> Hi Brendan, We are working with the Solaris on prototyping an assisted approach to resolve the issue. In this approach the jhelper.d (the dtrace jstack action provider on VM side) is assisting the DTrace framework to do the stack walking cooperatively. I've assigned the bug JDK-6617153 to myself and will post updates about the progress. Please, let us know if you have any questions. Thanks, Serguei On 10/21/14 5:10 PM, Brendan Gregg wrote: > G'Day, > > I checked the JDK 9 early access releases, but didn't see anything for > JDK-6276264. I've also since learned that Twitter has an OpenJDK fork > with frame pointers disabled, for the same purpose: stack profiling > (using Linux perf_events). Might this be worked on for JDK 9? I can > help test. thanks, > > Brendan > > On Mon, Jun 16, 2014 at 11:52 PM, Brendan Gregg > wrote: >> G'Day Serguei, >> >> On Mon, Jun 16, 2014 at 10:45 PM, serguei.spitsyn at oracle.com >> wrote: >>> Hi Brendan, >>> >>> We are aware of these issues and work with the Solaris team to fix them in >>> JDK 9. >>> One is the frame pointer is used by the server compiler as a general >>> purpose register on intel. >>> Another is about the virtual (or inlined) frames. >>> >>> There are a couple of related bugs: >>> https://bugs.openjdk.java.net/browse/JDK-6617153 >>> https://bugs.openjdk.java.net/browse/JDK-6276264 >>> >>> There can be more issues filed on this. >> >> Ah, thanks, it's JDK-6276264. >> >> As Tom Rodriguez said at the time (2005): "The server VM uses the frame >> pointer as an allocatable register and there's no way to turn that off." I >> was really hoping there was a way to turn that off, like >> -fno-omit-frame-pointer. >> >> This also means DTrace jstack() has never worked fully. For the applications >> I tried it on, 50% of stacks were incomplete. Perhaps it wasn't that bad in >> 2005. I've been getting more mileage today from Java profilers. >> >>> Please, note, that the jstack action is not implemented on Linux yet. >> >> Linux doesn't have DTrace jstack(), no, but its perf_events does has support >> for loading an auxiliary file of symbols, which can created via a Java agent >> for that purpose (eg, https://github.com/jrudolph/perf-map-agent). But that >> hasn't been working fully for the same reason - incomplete stacks. >> >> Brendan >> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 6/16/14 5:14 PM, Brendan Gregg wrote: >>> >>> Thanks but no, I'm aware of that bug and workarounds (I'm using the >>> LD_AUDIT_64=/usr/lib/dtrace/64/libdtrace_forceload.so workaround, which >>> isn't mentioned in the bug comments, but probably should be). That bug is >>> about missing symbols, but the stacks shown in that bug still go all the way >>> to thread_start. My stacks often don't. >>> >>> For simple programs, the stacks are complete. But something complex (eg, >>> vert.x with event loops), and the stacks are often incomplete, one frame >>> only. Very much like what I see with -fomit-frame-pointer, although this is >>> hotspot, not gcc. Such incomplete stacks are seen using either DTrace or >>> perf_events. >>> >>> It was suggested to me to email the hotspot developers, because this may >>> well be a hotspot optimization they are familiar with. It may also be >>> something really obvious, like that the JVM breaks native stacks due to >>> optimized frames / green threads / etc, and there is absolutely no way >>> around it (no way to disable it). If that's true, it may also mean that the >>> DTrace jstack() action has always had this issue. I'm still reading the >>> source... >>> >>> Brendan >>> >>> >>> >>> On Mon, Jun 16, 2014 at 4:04 AM, Staffan Larsen >>> wrote: >>>> I think this is the bug you are looking at: >>>> https://bugs.openjdk.java.net/browse/JDK-7187999, but I?ll defer to someone >>>> else to confirm. >>>> >>>> /Staffan >>>> >>>> >>>> On 16 jun 2014, at 12:47, Roland Westrelin >>>> wrote: >>>> >>>> Forwarding to serviceability alias where this question belongs I think. >>>> >>>> Begin forwarded message: >>>> >>>> From: Brendan Gregg >>>> Subject: system profilers and incomplete stacks >>>> Date: June 12, 2014 at 7:15:54 PM GMT+2 >>>> To: hotspot-compiler-dev at openjdk.java.net >>>> >>>> G'Day, >>>> >>>> Is there a way to run hotspot so that a system profiler (eg, DTrace, or >>>> Linux perf_events) can measure complete stacks? I often get incomplete, >>>> partial stacks, with one or a few frames only. I'm not worried about symbols >>>> right now, what I'd like is to walk stacks all the way down to thread start. >>>> >>>> I've been browsing the hotspot code, but haven't found out how yet. I >>>> suspect it's related to Java optimized frames, and has ditched the frame >>>> pointer. I was looking for an equivalent -fno-omit-frame-pointer option. >>>> >>>> Here's an example: >>>> >>>> # dtrace -n 'profile-99 /execname == "java"/ { @[jstack(100, 8000)] = >>>> count(); }' >>>> [...] >>>> org/mozilla/javascript/ >>>> >>>> ScriptableObject.createSlot(Ljava/lang/String;II)Lorg/mozilla/javascript/ScriptableObject$Slot;* >>>> 0x884acce8200002da >>>> 1 >>>> >>>> sun/nio/ch/SocketChannelImpl.read(Ljava/nio/ByteBuffer;)I* >>>> 0xffffffff20007f4b >>>> 1 >>>> >>>> >>>> org/mozilla/javascript/ScriptRuntime.newObjectLiteral([Ljava/lang/Object;[Ljava/lang/Object;[ILorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;)Lorg/mozilla/javascript/Scriptable;* >>>> 0xa20000041 >>>> 1 >>>> [...] >>>> >>>> I see similar incomplete stacks with Linux perf_events. Oracle JDKs from >>>> 6 to 8, and OpenJDK. >>>> >>>> thanks, >>>> >>>> Brendan >>>> -- >>>> http://www.brendangregg.com >>>> >>>> >>>> >>> >>> >>> -- >>> http://www.brendangregg.com >>> >>> >> >> >> -- >> http://www.brendangregg.com From roland.westrelin at oracle.com Wed Oct 22 08:54:33 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 22 Oct 2014 10:54:33 +0200 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <5446F3FE.7080800@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> Message-ID: <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> > Here is intrinsic implementation: > > http://cr.openjdk.java.net/~kvn/8054492/webrev.01/ That looks good to me. Roland. From paul.sandoz at oracle.com Wed Oct 22 09:29:49 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 22 Oct 2014 11:29:49 +0200 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> Message-ID: <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> On Oct 22, 2014, at 10:54 AM, Roland Westrelin wrote: >> Here is intrinsic implementation: >> >> http://cr.openjdk.java.net/~kvn/8054492/webrev.01/ > > That looks good to me. > Same here. On Oct 22, 2014, at 2:02 AM, Vladimir Kozlov wrote: > Paul, is it enough for you? > Yes, many thanks. I verified in a number of scenarios. With Class.cast intrinsified can we can replace uses of following method in j.l.i.MethodHandleImpl with Class.cast? @ForceInline @SuppressWarnings("unchecked") static T castReference(Class t, U x) { // inlined Class.cast because we can't ForceInline it if (x != null && !t.isInstance(x)) throw newClassCastException(t, x); return (T) x; } Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From albert.noll at oracle.com Wed Oct 22 09:52:25 2014 From: albert.noll at oracle.com (Albert Noll) Date: Wed, 22 Oct 2014 11:52:25 +0200 Subject: [9] RFR(L): 8046809: vm/mlvm/meth/stress/compiler/deoptimize CodeCache is full. In-Reply-To: <89875680-40F2-4645-9FF9-A231F2319915@oracle.com> References: <5436465A.3080001@oracle.com> <5437A081.4060608@oracle.com> <5437ED93.6080806@oracle.com> <54381017.6020809@oracle.com> <543BE7E4.6040203@oracle.com> <543C83B8.5050003@oracle.com> <543CD8E1.6050303@oracle.com> <543F82E7.1050706@oracle.com> <89875680-40F2-4645-9FF9-A231F2319915@oracle.com> Message-ID: <54477E59.4050300@oracle.com> Hi John Thanks for the review. Please see comments inline: On 10/21/2014 10:00 PM, John Rose wrote: > On Oct 16, 2014, at 1:33 AM, Albert Noll wrote: > >> Can I have a second review? > Reviewed. > > Question: Can you say why "handle_full_code_cache" doesn't need to be called so much anymore? > It seems a non-trivial issue since you were able to delete it from so many places, but not all. > I suggest adding a comment to the header of handle_full_code_cache to guide future coders where the calls must be put. handle_full_code_cache() is now only called from within the code cache. Since we consistently handle a full code cache, there is no need to put the same code at every call site. I though about moving handle_full_code_cache to the code cache (and make it private). However, the actions that are taken impact compilation, so overall, I think, having handle_full_code_cache is better kept in CompileBroker. I'll update the comment. > A couple of typos: > > + "Start aggressive sweeping if X[%] of the code cache are free." \ > s/are/is/ (percentage of singular is singular as in, 5% of code cache is full, etc.) > > + init_log_sweeer > s/sweeer/sweeper/; IMO should actually be "init_records", "init_log", or "init_sweeper_log". > (Sweeering is not done in polite company!) Fixed. > I like the cleanups. Lots of tidying, code deletion, and factoring. > You have taken a hard part of the JVM and made it incrementally simpler and nicer to work with. Thanks! Here is the webrev with the updated comments. http://cr.openjdk.java.net/~anoll/8046809/webrev.06/ Best, Albert > Thanks, > ? John From tobias.hartmann at oracle.com Wed Oct 22 14:49:39 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 22 Oct 2014 16:49:39 +0200 Subject: [9] RFR(S): 8061486: [TESTBUG] compiler/whitebox/ tests fail : must be osr_compiled (reappeared in nightlies) Message-ID: <5447C403.1090408@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8061486 Webrev: http://cr.openjdk.java.net/~thartmann/8061486/webrev.00/ Problem: JDK-8060454 added a deoptimization before triggering the OSR compilation to avoid non-OSR compilations blocking OSR compilations. This is not sufficient because non-OSR compilations may also be triggered at backedges while the loop is being executed (if the backedge threshold is not yet reached but the invocation threshold is). Solution: Call warmup code from OSR triggering method, make sure non-OSR compilation is triggered and wait for completion until OSR compilation is triggered. Testing: - Failing test on Windows and Linux - Whitebox tests with different parameters on JPRT Thanks, Tobias [1] See 'AdvancedThresholdPolicy::method_back_branch_event()': // Use loop event as an opportunity to also check if there's been // enough calls. From volker.simonis at gmail.com Wed Oct 22 20:29:39 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Oct 2014 00:29:39 +0400 Subject: system profilers and incomplete stacks In-Reply-To: <54475DA0.8090103@oracle.com> References: <1F3E1054-9947-43AC-9AD1-350E0174C9A1@oracle.com> <539FD60E.10203@oracle.com> <54475DA0.8090103@oracle.com> Message-ID: Hi, I think the main problem here is not only that compiled code uses the frame pointer as a general purpose register, but the fact that even the VM itself currently can not reliably take a stack trace of a thread at any arbitrary PC. An external sampling profiler like perf can interrupt the VM at any place (i.e. while the VM sets up a new frame or while inside an adapter). So while keeping the frame pointer alive will definitely help to improve the situation, I'm not it will help in every situation. Regards, Volker On 10/22/14, serguei.spitsyn at oracle.com wrote: > Hi Brendan, > > We are working with the Solaris on prototyping an assisted approach to > resolve the issue. > In this approach the jhelper.d (the dtrace jstack action provider on VM > side) is assisting > the DTrace framework to do the stack walking cooperatively. > > I've assigned the bug JDK-6617153 to myself and will post updates about > the progress. > Please, let us know if you have any questions. > > Thanks, > Serguei > > > On 10/21/14 5:10 PM, Brendan Gregg wrote: >> G'Day, >> >> I checked the JDK 9 early access releases, but didn't see anything for >> JDK-6276264. I've also since learned that Twitter has an OpenJDK fork >> with frame pointers disabled, for the same purpose: stack profiling >> (using Linux perf_events). Might this be worked on for JDK 9? I can >> help test. thanks, >> >> Brendan >> >> On Mon, Jun 16, 2014 at 11:52 PM, Brendan Gregg >> wrote: >>> G'Day Serguei, >>> >>> On Mon, Jun 16, 2014 at 10:45 PM, serguei.spitsyn at oracle.com >>> wrote: >>>> Hi Brendan, >>>> >>>> We are aware of these issues and work with the Solaris team to fix them >>>> in >>>> JDK 9. >>>> One is the frame pointer is used by the server compiler as a general >>>> purpose register on intel. >>>> Another is about the virtual (or inlined) frames. >>>> >>>> There are a couple of related bugs: >>>> https://bugs.openjdk.java.net/browse/JDK-6617153 >>>> https://bugs.openjdk.java.net/browse/JDK-6276264 >>>> >>>> There can be more issues filed on this. >>> >>> Ah, thanks, it's JDK-6276264. >>> >>> As Tom Rodriguez said at the time (2005): "The server VM uses the frame >>> pointer as an allocatable register and there's no way to turn that off." >>> I >>> was really hoping there was a way to turn that off, like >>> -fno-omit-frame-pointer. >>> >>> This also means DTrace jstack() has never worked fully. For the >>> applications >>> I tried it on, 50% of stacks were incomplete. Perhaps it wasn't that bad >>> in >>> 2005. I've been getting more mileage today from Java profilers. >>> >>>> Please, note, that the jstack action is not implemented on Linux yet. >>> >>> Linux doesn't have DTrace jstack(), no, but its perf_events does has >>> support >>> for loading an auxiliary file of symbols, which can created via a Java >>> agent >>> for that purpose (eg, https://github.com/jrudolph/perf-map-agent). But >>> that >>> hasn't been working fully for the same reason - incomplete stacks. >>> >>> Brendan >>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 6/16/14 5:14 PM, Brendan Gregg wrote: >>>> >>>> Thanks but no, I'm aware of that bug and workarounds (I'm using the >>>> LD_AUDIT_64=/usr/lib/dtrace/64/libdtrace_forceload.so workaround, which >>>> isn't mentioned in the bug comments, but probably should be). That bug >>>> is >>>> about missing symbols, but the stacks shown in that bug still go all the >>>> way >>>> to thread_start. My stacks often don't. >>>> >>>> For simple programs, the stacks are complete. But something complex >>>> (eg, >>>> vert.x with event loops), and the stacks are often incomplete, one >>>> frame >>>> only. Very much like what I see with -fomit-frame-pointer, although this >>>> is >>>> hotspot, not gcc. Such incomplete stacks are seen using either DTrace >>>> or >>>> perf_events. >>>> >>>> It was suggested to me to email the hotspot developers, because this >>>> may >>>> well be a hotspot optimization they are familiar with. It may also be >>>> something really obvious, like that the JVM breaks native stacks due to >>>> optimized frames / green threads / etc, and there is absolutely no way >>>> around it (no way to disable it). If that's true, it may also mean that >>>> the >>>> DTrace jstack() action has always had this issue. I'm still reading the >>>> source... >>>> >>>> Brendan >>>> >>>> >>>> >>>> On Mon, Jun 16, 2014 at 4:04 AM, Staffan Larsen >>>> wrote: >>>>> I think this is the bug you are looking at: >>>>> https://bugs.openjdk.java.net/browse/JDK-7187999, but I?ll defer to >>>>> someone >>>>> else to confirm. >>>>> >>>>> /Staffan >>>>> >>>>> >>>>> On 16 jun 2014, at 12:47, Roland Westrelin >>>>> >>>>> wrote: >>>>> >>>>> Forwarding to serviceability alias where this question belongs I >>>>> think. >>>>> >>>>> Begin forwarded message: >>>>> >>>>> From: Brendan Gregg >>>>> Subject: system profilers and incomplete stacks >>>>> Date: June 12, 2014 at 7:15:54 PM GMT+2 >>>>> To: hotspot-compiler-dev at openjdk.java.net >>>>> >>>>> G'Day, >>>>> >>>>> Is there a way to run hotspot so that a system profiler (eg, DTrace, >>>>> or >>>>> Linux perf_events) can measure complete stacks? I often get >>>>> incomplete, >>>>> partial stacks, with one or a few frames only. I'm not worried about >>>>> symbols >>>>> right now, what I'd like is to walk stacks all the way down to thread >>>>> start. >>>>> >>>>> I've been browsing the hotspot code, but haven't found out how yet. I >>>>> suspect it's related to Java optimized frames, and has ditched the >>>>> frame >>>>> pointer. I was looking for an equivalent -fno-omit-frame-pointer >>>>> option. >>>>> >>>>> Here's an example: >>>>> >>>>> # dtrace -n 'profile-99 /execname == "java"/ { @[jstack(100, 8000)] = >>>>> count(); }' >>>>> [...] >>>>> org/mozilla/javascript/ >>>>> >>>>> ScriptableObject.createSlot(Ljava/lang/String;II)Lorg/mozilla/javascript/ScriptableObject$Slot;* >>>>> 0x884acce8200002da >>>>> 1 >>>>> >>>>> >>>>> sun/nio/ch/SocketChannelImpl.read(Ljava/nio/ByteBuffer;)I* >>>>> 0xffffffff20007f4b >>>>> 1 >>>>> >>>>> >>>>> org/mozilla/javascript/ScriptRuntime.newObjectLiteral([Ljava/lang/Object;[Ljava/lang/Object;[ILorg/mozilla/javascript/Context;Lorg/mozilla/javascript/Scriptable;)Lorg/mozilla/javascript/Scriptable;* >>>>> 0xa20000041 >>>>> 1 >>>>> [...] >>>>> >>>>> I see similar incomplete stacks with Linux perf_events. Oracle JDKs >>>>> from >>>>> 6 to 8, and OpenJDK. >>>>> >>>>> thanks, >>>>> >>>>> Brendan >>>>> -- >>>>> http://www.brendangregg.com >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> http://www.brendangregg.com >>>> >>>> >>> >>> >>> -- >>> http://www.brendangregg.com > > From vladimir.kozlov at oracle.com Wed Oct 22 21:24:05 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Oct 2014 14:24:05 -0700 Subject: [9] RFR(S): 8061486: [TESTBUG] compiler/whitebox/ tests fail : must be osr_compiled (reappeared in nightlies) In-Reply-To: <5447C403.1090408@oracle.com> References: <5447C403.1090408@oracle.com> Message-ID: <54482075.3080906@oracle.com> Looks good. Did you tested both Tiered and non-Tiered compilation? Thanks, Vladimir On 10/22/14 7:49 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061486 > Webrev: http://cr.openjdk.java.net/~thartmann/8061486/webrev.00/ > > Problem: > JDK-8060454 added a deoptimization before triggering the OSR compilation to > avoid non-OSR compilations blocking OSR compilations. > This is not sufficient because non-OSR compilations may also be triggered at > backedges while the loop is being executed (if the backedge threshold is not yet > reached but the invocation threshold is). > > Solution: > Call warmup code from OSR triggering method, make sure non-OSR compilation is > triggered and wait for completion until OSR compilation is triggered. > > Testing: > - Failing test on Windows and Linux > - Whitebox tests with different parameters on JPRT > > Thanks, > Tobias > > > [1] See 'AdvancedThresholdPolicy::method_back_branch_event()': > // Use loop event as an opportunity to also check if there's been > // enough calls. > From igor.veresov at oracle.com Wed Oct 22 22:16:05 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 22 Oct 2014 12:16:05 -1000 Subject: RFR(XS) 8047383: SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions. Message-ID: <62DB71C9-2B4E-40E1-BA38-657558138A6D@oracle.com> The problem manifests itself in various instances are constant table base register corruption. The cause is that when we?re rematerializing constant table loads (which are is_Con()) in PhaseAggressiveCoalesce::insert_copies() we are stretching the lrg of the constant table base. If that lrg is a multidef then I think we're in trouble. The fix is not rematerialize constant table loads here. We, however, will rematerialize those when splitting lrgs in split_Rematerialize(), which requires creation of a spill copy for each multidef input. I?d like to also point out that matcher aggressively clones constants (including constant table loads), which puts them close to the use in the majority of cases. So the proposed change has no measurable performance impact, which I verified with performance runs. Webrev: http://cr.openjdk.java.net/~iveresov/8047383/webrev.00/ Thanks, igor From vladimir.kozlov at oracle.com Wed Oct 22 23:06:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Oct 2014 16:06:11 -0700 Subject: [9] RFR(M) 8041984: CompilerThread seems to occupy all CPU in a very rare situation In-Reply-To: <4E5D5236-86BB-4235-B7DF-AFE90893FB02@oracle.com> References: <5438A6EC.8000302@oracle.com> <415C2022-8ABA-405C-B7C6-258B512C8B04@oracle.com> <543D8A43.5020405@oracle.com> <543DB731.5000301@oracle.com> <5446D0ED.9040900@oracle.com> <4E5D5236-86BB-4235-B7DF-AFE90893FB02@oracle.com> Message-ID: <54483863.7010405@oracle.com> Thank you, Igor On 10/21/14 11:05 PM, Igor Veresov wrote: > Alright, since nobody is taking on it.. The timeout feature looks good, > I suppose a JIT needs to be adaptive to available CPU resources. > > A couple of small questions: > > 1. Why is it necessary to add phantom_obj to worklists? > > * 130 ptnodes_worklist.append(phantom_obj); > 131 java_objects_worklist.append(phantom_obj);* To avoid duplicated entries for phantom_obj on these lists. Even so processed ideal nodes are unique on ideal_nodes list several ideal nodes are mapped to phantom_obj: case Op_CreateEx: { // assume that all exception objects globally escape map_ideal_node(n, phantom_obj); break; as result ptnode_adr(n->_idx) will return phantom_obj several times and it will be added to above lists. I added next comment: // Processed ideal nodes are unique on ideal_nodes list // but several ideal nodes are mapped to the phantom_obj. // To avoid duplicated entries on the following worklists // add the phantom_obj only once to them. ptnodes_worklist.append(phantom_obj); > > 2. What does pidx_bias do here? > > 399 inline void add_to_worklist(PointsToNode* pt) { > 400 PointsToNode* ptf = pt; > 401 uint pidx_bias = 0; > 402 if (PointsToNode::is_base_use(pt)) { > 403 ptf = PointsToNode::get_use_node(pt)->as_Field(); > 404 pidx_bias = _next_pidx; > 405 } > 406 if (!_in_worklist.test_set(ptf->pidx() + pidx_bias)) { > 407 _worklist.append(pt); > 408 } > 409 } It is complicated :( To avoid creating a separate worklist in PointsToNode some edges are encoded specially (low bit set in a pointer): // Mark base edge use to distinguish from stored value edge. bool add_base_use(FieldNode* use) { return _uses.append_if_missing((PointsToNode*)((intptr_t)use + 1)); } It is used in add_java_object_edges(): PointsToNode* use = _worklist.at(l); if (PointsToNode::is_base_use(use)) { // Add reference from jobj to field and from field to jobj (field's base). use = PointsToNode::get_use_node(use)->as_Field(); if (add_base(use->as_Field(), jobj)) { new_edges++; So the _worklist may have the same node's pointers, with the bit set and without. add_to_worklist() want to make sure only one of each type is present on the _worklist. As result VectorSet _in_worklist should have 2 separate entries for each type of pointers. I added new _pidx to PointsToNode because I did not want VectorSet _in_worklist to be big - number of created EA nodes is usually about 10% from number of Ideal nodes. So _next_pidx is the number of all created EA nodes and adding it as bias guarantee the an unique entry in VectorSet. I will add next comment to add_to_worklist(): if (PointsToNode::is_base_use(pt)) { // Create a separate entry in _in_worklist for a marked base edge // because _worklist may have an entry for a normal edge pointing // to the same node. To separate them use _next_pidx as bias. ptf = PointsToNode::get_use_node(pt)->as_Field(); pidx_bias = _next_pidx; I hope I answered your question :) Thanks, Vladimir > > > Thanks, > igor > > > On Oct 21, 2014, at 11:32 AM, Vladimir Kozlov > > wrote: > >> Please, I need reviews. >> >> Thanks, >> Vladimir >> >> On 10/14/14 4:52 PM, Vladimir Kozlov wrote: >>> I updated changes. >>> >>> http://cr.openjdk.java.net/~kvn/8041984/webrev.01/ >>> >>> As David suggested I added SAMPLE_SIZE constant: >>> >>> #define SAMPLE_SIZE 4 >>> if ((next % SAMPLE_SIZE) == 0) { >>> // Each 4 iterations calculate how much time it will take >>> // to complete graph construction. >>> time.stop(); >>> double stop_time = time.seconds(); >>> double time_per_iter = (stop_time - start_time) / >>> (double)SAMPLE_SIZE; >>> double time_until_end = time_per_iter * >>> (double)(java_objects_length - next); >>> if ((start_time + time_until_end) >= EscapeAnalysisTimeout) { >>> >>> I also replaced TIME_LIMIT constant with flag: >>> >>> product(double, EscapeAnalysisTimeout, 20. DEBUG_ONLY(+40.), \ >>> "Abort EA when it reaches time limit (in sec)") \ >>> >>> Thanks, >>> Vladimir >>> >>> On 10/14/14 1:40 PM, Vladimir Kozlov wrote: >>>> On 10/14/14 10:30 AM, David Chase wrote: >>>>> I?m curious about the granularity of the completion-prediction ? >>>>> you?re checking every 4 iterations and extrapolating from there. >>>>> Do we know that the times are that uniform, or would we be better off >>>>> with larger sample sizes? >>>> >>>> Yes, I observed uniformly slowly growing times for PARTS of iterations >>>> and not all iterations. That is why I want to take several samples. >>>> For example first iterations where fast but when array allocation >>>> objects begin processed time are rapidly growing. >>>> If I take very big sample fast iterations affect the result - delay >>>> abort. >>>> >>>> I did implementation similar to your "alternate approach" suggestion and >>>> I saw that the abort happened much later than with current my approach. >>>> >>>>> (How long does a single iteration take, anyway?) >>>> >>>> As I said one slow iteration may take upto 1 sec. So I want to abort as >>>> soon as I see a such case (but allow spikes). Taking larger sample sizes >>>> may delay an abort for several seconds. >>>> >>>>> >>>>> And in the sample code, I see the choice of sample size (4) encoded as >>>>> (next & 3) == 0 >>>>> // Each 4 iterations calculate how much time it will take >>>>> double time_per_iter = (stop_time - start_time) * 0.25; >>>>> >>>>> why not write this as (say) >>>>> >>>>> static const int LOG_SAMPLE_SIZE = 2; >>>>> static const int SAMPLE_SIZE = (1 << LOG_SAMPLE_SIZE); >>>>> next % SAMPLE_SIZE == 0 // next could be a uint, couldn?t it? >>>>> double time_per_iter = (stop_time - start_time) * (1.0/SAMPLE_SIZE); >>>>> >>>>> perhaps rewriting 1.0/SAMPLE_SIZE as another static const as necessary >>>>> to get it properly precalculated; I?m not sure what C++ compilers are >>>>> doing nowadays. >>>> >>>> I am optimizing :) by avoiding % and / operations. But I agree and can >>>> add SAMPLE_SIZE constant so code can be more clear. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> An alternate approach would be to compute the overall rate thus far, >>>>> checking at >>>>> (say) iterations 4, 8, 16, 32, etc and computing the average from >>>>> there, starting >>>>> at whatever power of two is a decent fraction of the iterations needed >>>>> to timeout. >>>>> >>>>> e.g., don?t reset start_time, just compute elapsed at each sample: >>>>> >>>>> if ((next & (ptwo - 1) == 0) { >>>>> time.stop(); >>>>> double elapsed = time.seconds() - start_time; >>>>> double projected = elapsed * (double) java_objects_length / next; >>>>> >>>>> Or you can compute a java_objects_length that would surely lead to >>>>> failure, and >>>>> always do that (fast, integer) comparison: >>>>> ... >>>>> unsigned int length_bound = (int) next * (CG_BUILD_TIME_LIMIT / >>>>> elapsed) >>>>> ? >>>>> if (java_objects_length > length_bound) { ? timeout >>>>> >>>>> David >>>>> >>>>> On 2014-10-10, at 11:41 PM, Vladimir Kozlov >>>>> wrote: >>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8041984 >>>>>> http://cr.openjdk.java.net/~kvn/8041984/webrev/ >>>>>> >>>>>> Next method puts C2's EA to its knees: >>>>>> >>>>>> com.graphhopper.coll.GHLongIntBTree$BTreeEntry::put() >>>>>> >>>>>> https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/coll/GHLongIntBTree.java >>>>>> >>>>>> >>>>>> >>>>>> It shows that current EA connection graph build code is very >>>>>> inefficient when a graph has a lot of connections (edges). >>>>>> >>>>>> With inlining the BTreeEntry::put() method has about 100 allocations >>>>>> from which about 80 are arrays allocations. Most of them are object >>>>>> arrays which are generated by Arrays.copyOf(). After number of edges >>>>>> in EA Connection Graph reaches about 50000 it takes more then 1 sec >>>>>> to find all nodes which reference an allocation. >>>>>> >>>>>> Current EA code has bailout by timeout from graph building code. But >>>>>> the timeout (30 sec for product VM) is checked only after all object >>>>>> nodes are processed. So it may take > 2 mins before EA is aborted: >>>>>> >>>>>> >>>>> stamp='4.417'> >>>>>> >>>>>> >>>>> stamp='150.967'/> >>>>>> >>>>>> Also ConnectionGraph::add_java_object_edges() method does not check >>>>>> the presence of a node when it adds new one to the worklist (in >>>>>> add_to_worklist() method). Which leads to hundreds MB of used by EA >>>>>> memory when BTreeEntry::put() is processed. >>>>>> >>>>>> To address issues new timeout checks were added. >>>>>> New _pidx index field is added to graph's nodes and VectorSet is used >>>>>> to reduce size of worklist in add_java_object_edges() method. >>>>>> >>>>>> Escaping node CreateEx is mapped phantom_obj to reduce number of >>>>>> process objects in connection graph. We do the same for other >>>>>> escaping objects. >>>>>> >>>>>> Tested with graphhopper server application: >>>>>> >>>>>> >>>>> stamp='6.829'> >>>>>> >>>>>> >>>>> stamp='22.355'/> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>> > From vladimir.kozlov at oracle.com Wed Oct 22 23:37:22 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Oct 2014 16:37:22 -0700 Subject: RFR(XS) 8047383: SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions. In-Reply-To: <62DB71C9-2B4E-40E1-BA38-657558138A6D@oracle.com> References: <62DB71C9-2B4E-40E1-BA38-657558138A6D@oracle.com> Message-ID: <54483FB2.4020804@oracle.com> You point fix seems correct. The question is should we do the new check inside MachNode::rematerialize() instead? Or don't rematerialized such nodes at all? MachNode::rematerialize() is called from Node::rematerialize() which is used in a lot of places in RA (PhaseChaitin). We need to make sure all those places are safe for MachConstant nodes. Thanks, Vladimir On 10/22/14 3:16 PM, Igor Veresov wrote: > The problem manifests itself in various instances are constant table base register corruption. The cause is that when we?re rematerializing constant table loads (which are is_Con()) in PhaseAggressiveCoalesce::insert_copies() we are stretching the lrg of the constant table base. If that lrg is a multidef then I think we're in trouble. The fix is not rematerialize constant table loads here. We, however, will rematerialize those when splitting lrgs in split_Rematerialize(), which requires creation of a spill copy for each multidef input. I?d like to also point out that matcher aggressively clones constants (including constant table loads), which puts them close to the use in the majority of cases. So the proposed change has no measurable performance impact, which I verified with performance runs. > > Webrev: http://cr.openjdk.java.net/~iveresov/8047383/webrev.00/ > > Thanks, > igor > From igor.veresov at oracle.com Thu Oct 23 00:04:40 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 22 Oct 2014 14:04:40 -1000 Subject: RFR(XS) 8047383: SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions. In-Reply-To: <54483FB2.4020804@oracle.com> References: <62DB71C9-2B4E-40E1-BA38-657558138A6D@oracle.com> <54483FB2.4020804@oracle.com> Message-ID: <183C8276-43CD-474C-96D6-BBA737814EA8@oracle.com> Thanks for looking at it! rematerialize() has bit of a different meaning, I don't think we should do the check there. What it really means is that the node is a pure function (side effect free). It is used in the matcher (if I'm not mistaken) to clone things, which is easy then since we're still in the SSA form. It is also used in split_Rematerialize(), where we do the cloning correctly (with spilling of inputs). And all other places are safe as far as I can tell. igor > On Oct 22, 2014, at 1:37 PM, Vladimir Kozlov wrote: > > You point fix seems correct. > > The question is should we do the new check inside MachNode::rematerialize() instead? Or don't rematerialized such nodes at all? > > MachNode::rematerialize() is called from Node::rematerialize() which is used in a lot of places in RA (PhaseChaitin). We need to make sure all those places are safe for MachConstant nodes. > > Thanks, > Vladimir > >> On 10/22/14 3:16 PM, Igor Veresov wrote: >> The problem manifests itself in various instances are constant table base register corruption. The cause is that when we?re rematerializing constant table loads (which are is_Con()) in PhaseAggressiveCoalesce::insert_copies() we are stretching the lrg of the constant table base. If that lrg is a multidef then I think we're in trouble. The fix is not rematerialize constant table loads here. We, however, will rematerialize those when splitting lrgs in split_Rematerialize(), which requires creation of a spill copy for each multidef input. I?d like to also point out that matcher aggressively clones constants (including constant table loads), which puts them close to the use in the majority of cases. So the proposed change has no measurable performance impact, which I verified with performance runs. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8047383/webrev.00/ >> >> Thanks, >> igor >> From vladimir.kozlov at oracle.com Thu Oct 23 01:01:49 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Oct 2014 18:01:49 -0700 Subject: RFR(XS) 8047383: SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions. In-Reply-To: <183C8276-43CD-474C-96D6-BBA737814EA8@oracle.com> References: <62DB71C9-2B4E-40E1-BA38-657558138A6D@oracle.com> <54483FB2.4020804@oracle.com> <183C8276-43CD-474C-96D6-BBA737814EA8@oracle.com> Message-ID: <5448537D.3050404@oracle.com> Okay. Then you fix looks correct. Thanks, Vladimir On 10/22/14 5:04 PM, Igor Veresov wrote: > Thanks for looking at it! > > rematerialize() has bit of a different meaning, I don't think we should do the check there. What it really means is that the node is a pure function (side effect free). It is used in the matcher (if I'm not mistaken) to clone things, which is easy then since we're still in the SSA form. It is also used in split_Rematerialize(), where we do the cloning correctly (with spilling of inputs). And all other places are safe as far as I can tell. > > igor > >> On Oct 22, 2014, at 1:37 PM, Vladimir Kozlov wrote: >> >> You point fix seems correct. >> >> The question is should we do the new check inside MachNode::rematerialize() instead? Or don't rematerialized such nodes at all? >> >> MachNode::rematerialize() is called from Node::rematerialize() which is used in a lot of places in RA (PhaseChaitin). We need to make sure all those places are safe for MachConstant nodes. >> >> Thanks, >> Vladimir >> >>> On 10/22/14 3:16 PM, Igor Veresov wrote: >>> The problem manifests itself in various instances are constant table base register corruption. The cause is that when we?re rematerializing constant table loads (which are is_Con()) in PhaseAggressiveCoalesce::insert_copies() we are stretching the lrg of the constant table base. If that lrg is a multidef then I think we're in trouble. The fix is not rematerialize constant table loads here. We, however, will rematerialize those when splitting lrgs in split_Rematerialize(), which requires creation of a spill copy for each multidef input. I?d like to also point out that matcher aggressively clones constants (including constant table loads), which puts them close to the use in the majority of cases. So the proposed change has no measurable performance impact, which I verified with performance runs. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8047383/webrev.00/ >>> >>> Thanks, >>> igor >>> From igor.veresov at oracle.com Thu Oct 23 02:03:42 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 22 Oct 2014 16:03:42 -1000 Subject: RFR(XS) 8047383: SIGBUS in C2 compiled method weblogic.wsee.jaxws.framework.jaxrpc.EnvironmentFactory$SimulatedWsdlDefinitions. In-Reply-To: <5448537D.3050404@oracle.com> References: <62DB71C9-2B4E-40E1-BA38-657558138A6D@oracle.com> <54483FB2.4020804@oracle.com> <183C8276-43CD-474C-96D6-BBA737814EA8@oracle.com> <5448537D.3050404@oracle.com> Message-ID: <9A36E685-0A38-4EE2-90BD-98421118B6CD@oracle.com> Thanks, Vladimir! igor > On Oct 22, 2014, at 3:01 PM, Vladimir Kozlov wrote: > > Okay. Then you fix looks correct. > > Thanks, > Vladimir > >> On 10/22/14 5:04 PM, Igor Veresov wrote: >> Thanks for looking at it! >> >> rematerialize() has bit of a different meaning, I don't think we should do the check there. What it really means is that the node is a pure function (side effect free). It is used in the matcher (if I'm not mistaken) to clone things, which is easy then since we're still in the SSA form. It is also used in split_Rematerialize(), where we do the cloning correctly (with spilling of inputs). And all other places are safe as far as I can tell. >> >> igor >> >>> On Oct 22, 2014, at 1:37 PM, Vladimir Kozlov wrote: >>> >>> You point fix seems correct. >>> >>> The question is should we do the new check inside MachNode::rematerialize() instead? Or don't rematerialized such nodes at all? >>> >>> MachNode::rematerialize() is called from Node::rematerialize() which is used in a lot of places in RA (PhaseChaitin). We need to make sure all those places are safe for MachConstant nodes. >>> >>> Thanks, >>> Vladimir >>> >>>> On 10/22/14 3:16 PM, Igor Veresov wrote: >>>> The problem manifests itself in various instances are constant table base register corruption. The cause is that when we?re rematerializing constant table loads (which are is_Con()) in PhaseAggressiveCoalesce::insert_copies() we are stretching the lrg of the constant table base. If that lrg is a multidef then I think we're in trouble. The fix is not rematerialize constant table loads here. We, however, will rematerialize those when splitting lrgs in split_Rematerialize(), which requires creation of a spill copy for each multidef input. I?d like to also point out that matcher aggressively clones constants (including constant table loads), which puts them close to the use in the majority of cases. So the proposed change has no measurable performance impact, which I verified with performance runs. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8047383/webrev.00/ >>>> >>>> Thanks, >>>> igor >>>> From vladimir.kozlov at oracle.com Thu Oct 23 04:53:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Oct 2014 21:53:56 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> Message-ID: <544889E4.4010308@oracle.com> Thank you, Roland I will need an other update to include next Paul's request (always inline Class.cast() to undo changes in castReference()) and the test. Thanks, Vladimir On 10/22/14 1:54 AM, Roland Westrelin wrote: >> Here is intrinsic implementation: >> >> http://cr.openjdk.java.net/~kvn/8054492/webrev.01/ > > That looks good to me. > > Roland. > From vladimir.kozlov at oracle.com Thu Oct 23 05:09:17 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Oct 2014 22:09:17 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> Message-ID: <54488D7D.5080103@oracle.com> On 10/22/14 2:29 AM, Paul Sandoz wrote: > On Oct 22, 2014, at 10:54 AM, Roland Westrelin wrote: >>> Here is intrinsic implementation: >>> >>> http://cr.openjdk.java.net/~kvn/8054492/webrev.01/ >> >> That looks good to me. >> > Same here. > > On Oct 22, 2014, at 2:02 AM, Vladimir Kozlov wrote: >> Paul, is it enough for you? >> > > Yes, many thanks. I verified in a number of scenarios. > > With Class.cast intrinsified can we can replace uses of following method in j.l.i.MethodHandleImpl with Class.cast? Intrinsic is not enough. That code was added because we do not inline Class.cast() for deep call stacks. C2 has inline depth limit 9. But we can workaround using next changes: --- a/src/share/vm/opto/bytecodeInfo.cpp Fri Aug 22 09:55:49 2014 -0700 +++ b/src/share/vm/opto/bytecodeInfo.cpp Wed Oct 22 22:07:21 2014 -0700 @@ -161,6 +161,7 @@ if ((freq >= InlineFrequencyRatio) || (call_site_count >= InlineFrequencyCount) || is_unboxing_method(callee_method, C) || + (callee_method->intrinsic_id() == vmIntrinsics::_class_cast) || is_init_with_ea(callee_method, caller_method, C)) { max_inline_size = C->freq_inline_size(); @@ -262,6 +263,11 @@ return false; } + if (callee_method->intrinsic_id() == vmIntrinsics::_class_cast) { + // Inline Class.cast() method. + return false; + } + if (callee_method->has_compiled_code() && callee_method->instructions_size() > InlineSmallCode) { set_msg("already compiled into a big method"); Thanks, Vladimir > > @ForceInline > @SuppressWarnings("unchecked") > static T castReference(Class t, U x) { > // inlined Class.cast because we can't ForceInline it > if (x != null && !t.isInstance(x)) > throw newClassCastException(t, x); > return (T) x; > } > > Paul. > From john.r.rose at oracle.com Thu Oct 23 06:01:36 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 22 Oct 2014 23:01:36 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <54488D7D.5080103@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> Message-ID: <5BAF11B0-9423-40D6-8EB8-77FD69C67A72@oracle.com> On Oct 22, 2014, at 10:09 PM, Vladimir Kozlov wrote: > Intrinsic is not enough. Would it be possible to give the new intrinsic wider coverage, to replace the logic in a majority of places it is used? The logic in GraphKit::gen_checkcast is pretty sophisticated, and it's all there for a reason. What would stop us from using it more fully? Some of the sophistication depends on profiling of the cast and aastore instructions, crucially with null, but perhaps we can cover that need with Roland's argument profiling work. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Thu Oct 23 06:13:39 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 22 Oct 2014 20:13:39 -1000 Subject: [9] RFR(M) 8041984: CompilerThread seems to occupy all CPU in a very rare situation In-Reply-To: <54483863.7010405@oracle.com> References: <5438A6EC.8000302@oracle.com> <415C2022-8ABA-405C-B7C6-258B512C8B04@oracle.com> <543D8A43.5020405@oracle.com> <543DB731.5000301@oracle.com> <5446D0ED.9040900@oracle.com> <4E5D5236-86BB-4235-B7DF-AFE90893FB02@oracle.com> <54483863.7010405@oracle.com> Message-ID: Thanks for the explanation! It?s a bit clearer now. :) Reviewed. igor On Oct 22, 2014, at 1:06 PM, Vladimir Kozlov wrote: > Thank you, Igor > > On 10/21/14 11:05 PM, Igor Veresov wrote: >> Alright, since nobody is taking on it.. The timeout feature looks good, >> I suppose a JIT needs to be adaptive to available CPU resources. >> >> A couple of small questions: >> >> 1. Why is it necessary to add phantom_obj to worklists? >> >> * 130 ptnodes_worklist.append(phantom_obj); >> 131 java_objects_worklist.append(phantom_obj);* > > To avoid duplicated entries for phantom_obj on these lists. > > Even so processed ideal nodes are unique on ideal_nodes list several ideal nodes are mapped to phantom_obj: > > case Op_CreateEx: { > // assume that all exception objects globally escape > map_ideal_node(n, phantom_obj); > break; > > as result ptnode_adr(n->_idx) will return phantom_obj several times and it will be added to above lists. > > I added next comment: > > // Processed ideal nodes are unique on ideal_nodes list > // but several ideal nodes are mapped to the phantom_obj. > // To avoid duplicated entries on the following worklists > // add the phantom_obj only once to them. > ptnodes_worklist.append(phantom_obj); > >> >> 2. What does pidx_bias do here? >> >> 399 inline void add_to_worklist(PointsToNode* pt) { >> 400 PointsToNode* ptf = pt; >> 401 uint pidx_bias = 0; >> 402 if (PointsToNode::is_base_use(pt)) { >> 403 ptf = PointsToNode::get_use_node(pt)->as_Field(); >> 404 pidx_bias = _next_pidx; >> 405 } >> 406 if (!_in_worklist.test_set(ptf->pidx() + pidx_bias)) { >> 407 _worklist.append(pt); >> 408 } >> 409 } > > It is complicated :( > > To avoid creating a separate worklist in PointsToNode some edges are encoded specially (low bit set in a pointer): > > // Mark base edge use to distinguish from stored value edge. > bool add_base_use(FieldNode* use) { return _uses.append_if_missing((PointsToNode*)((intptr_t)use + 1)); } > > It is used in add_java_object_edges(): > > PointsToNode* use = _worklist.at(l); > if (PointsToNode::is_base_use(use)) { > // Add reference from jobj to field and from field to jobj (field's base). > use = PointsToNode::get_use_node(use)->as_Field(); > if (add_base(use->as_Field(), jobj)) { > new_edges++; > > So the _worklist may have the same node's pointers, with the bit set and without. add_to_worklist() want to make sure only one of each type is present on the _worklist. As result VectorSet _in_worklist should have 2 separate entries for each type of pointers. > > I added new _pidx to PointsToNode because I did not want VectorSet _in_worklist to be big - number of created EA nodes is usually about 10% from number of Ideal nodes. So _next_pidx is the number of all created EA nodes and adding it as bias guarantee the an unique entry in VectorSet. > > I will add next comment to add_to_worklist(): > > if (PointsToNode::is_base_use(pt)) { > // Create a separate entry in _in_worklist for a marked base edge > // because _worklist may have an entry for a normal edge pointing > // to the same node. To separate them use _next_pidx as bias. > ptf = PointsToNode::get_use_node(pt)->as_Field(); > pidx_bias = _next_pidx; > > > I hope I answered your question :) > > Thanks, > Vladimir > >> >> >> Thanks, >> igor >> >> >> On Oct 21, 2014, at 11:32 AM, Vladimir Kozlov >> > wrote: >> >>> Please, I need reviews. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/14/14 4:52 PM, Vladimir Kozlov wrote: >>>> I updated changes. >>>> >>>> http://cr.openjdk.java.net/~kvn/8041984/webrev.01/ >>>> >>>> As David suggested I added SAMPLE_SIZE constant: >>>> >>>> #define SAMPLE_SIZE 4 >>>> if ((next % SAMPLE_SIZE) == 0) { >>>> // Each 4 iterations calculate how much time it will take >>>> // to complete graph construction. >>>> time.stop(); >>>> double stop_time = time.seconds(); >>>> double time_per_iter = (stop_time - start_time) / >>>> (double)SAMPLE_SIZE; >>>> double time_until_end = time_per_iter * >>>> (double)(java_objects_length - next); >>>> if ((start_time + time_until_end) >= EscapeAnalysisTimeout) { >>>> >>>> I also replaced TIME_LIMIT constant with flag: >>>> >>>> product(double, EscapeAnalysisTimeout, 20. DEBUG_ONLY(+40.), \ >>>> "Abort EA when it reaches time limit (in sec)") \ >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/14/14 1:40 PM, Vladimir Kozlov wrote: >>>>> On 10/14/14 10:30 AM, David Chase wrote: >>>>>> I?m curious about the granularity of the completion-prediction ? >>>>>> you?re checking every 4 iterations and extrapolating from there. >>>>>> Do we know that the times are that uniform, or would we be better off >>>>>> with larger sample sizes? >>>>> >>>>> Yes, I observed uniformly slowly growing times for PARTS of iterations >>>>> and not all iterations. That is why I want to take several samples. >>>>> For example first iterations where fast but when array allocation >>>>> objects begin processed time are rapidly growing. >>>>> If I take very big sample fast iterations affect the result - delay >>>>> abort. >>>>> >>>>> I did implementation similar to your "alternate approach" suggestion and >>>>> I saw that the abort happened much later than with current my approach. >>>>> >>>>>> (How long does a single iteration take, anyway?) >>>>> >>>>> As I said one slow iteration may take upto 1 sec. So I want to abort as >>>>> soon as I see a such case (but allow spikes). Taking larger sample sizes >>>>> may delay an abort for several seconds. >>>>> >>>>>> >>>>>> And in the sample code, I see the choice of sample size (4) encoded as >>>>>> (next & 3) == 0 >>>>>> // Each 4 iterations calculate how much time it will take >>>>>> double time_per_iter = (stop_time - start_time) * 0.25; >>>>>> >>>>>> why not write this as (say) >>>>>> >>>>>> static const int LOG_SAMPLE_SIZE = 2; >>>>>> static const int SAMPLE_SIZE = (1 << LOG_SAMPLE_SIZE); >>>>>> next % SAMPLE_SIZE == 0 // next could be a uint, couldn?t it? >>>>>> double time_per_iter = (stop_time - start_time) * (1.0/SAMPLE_SIZE); >>>>>> >>>>>> perhaps rewriting 1.0/SAMPLE_SIZE as another static const as necessary >>>>>> to get it properly precalculated; I?m not sure what C++ compilers are >>>>>> doing nowadays. >>>>> >>>>> I am optimizing :) by avoiding % and / operations. But I agree and can >>>>> add SAMPLE_SIZE constant so code can be more clear. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> An alternate approach would be to compute the overall rate thus far, >>>>>> checking at >>>>>> (say) iterations 4, 8, 16, 32, etc and computing the average from >>>>>> there, starting >>>>>> at whatever power of two is a decent fraction of the iterations needed >>>>>> to timeout. >>>>>> >>>>>> e.g., don?t reset start_time, just compute elapsed at each sample: >>>>>> >>>>>> if ((next & (ptwo - 1) == 0) { >>>>>> time.stop(); >>>>>> double elapsed = time.seconds() - start_time; >>>>>> double projected = elapsed * (double) java_objects_length / next; >>>>>> >>>>>> Or you can compute a java_objects_length that would surely lead to >>>>>> failure, and >>>>>> always do that (fast, integer) comparison: >>>>>> ... >>>>>> unsigned int length_bound = (int) next * (CG_BUILD_TIME_LIMIT / >>>>>> elapsed) >>>>>> ? >>>>>> if (java_objects_length > length_bound) { ? timeout >>>>>> >>>>>> David >>>>>> >>>>>> On 2014-10-10, at 11:41 PM, Vladimir Kozlov >>>>>> wrote: >>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8041984 >>>>>>> http://cr.openjdk.java.net/~kvn/8041984/webrev/ >>>>>>> >>>>>>> Next method puts C2's EA to its knees: >>>>>>> >>>>>>> com.graphhopper.coll.GHLongIntBTree$BTreeEntry::put() >>>>>>> >>>>>>> https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/coll/GHLongIntBTree.java >>>>>>> >>>>>>> >>>>>>> >>>>>>> It shows that current EA connection graph build code is very >>>>>>> inefficient when a graph has a lot of connections (edges). >>>>>>> >>>>>>> With inlining the BTreeEntry::put() method has about 100 allocations >>>>>>> from which about 80 are arrays allocations. Most of them are object >>>>>>> arrays which are generated by Arrays.copyOf(). After number of edges >>>>>>> in EA Connection Graph reaches about 50000 it takes more then 1 sec >>>>>>> to find all nodes which reference an allocation. >>>>>>> >>>>>>> Current EA code has bailout by timeout from graph building code. But >>>>>>> the timeout (30 sec for product VM) is checked only after all object >>>>>>> nodes are processed. So it may take > 2 mins before EA is aborted: >>>>>>> >>>>>>> >>>>>> stamp='4.417'> >>>>>>> >>>>>>> >>>>>> stamp='150.967'/> >>>>>>> >>>>>>> Also ConnectionGraph::add_java_object_edges() method does not check >>>>>>> the presence of a node when it adds new one to the worklist (in >>>>>>> add_to_worklist() method). Which leads to hundreds MB of used by EA >>>>>>> memory when BTreeEntry::put() is processed. >>>>>>> >>>>>>> To address issues new timeout checks were added. >>>>>>> New _pidx index field is added to graph's nodes and VectorSet is used >>>>>>> to reduce size of worklist in add_java_object_edges() method. >>>>>>> >>>>>>> Escaping node CreateEx is mapped phantom_obj to reduce number of >>>>>>> process objects in connection graph. We do the same for other >>>>>>> escaping objects. >>>>>>> >>>>>>> Tested with graphhopper server application: >>>>>>> >>>>>>> >>>>>> stamp='6.829'> >>>>>>> >>>>>>> >>>>>> stamp='22.355'/> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>> >> From vladimir.kozlov at oracle.com Thu Oct 23 06:17:06 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Oct 2014 23:17:06 -0700 Subject: [9] RFR(M) 8041984: CompilerThread seems to occupy all CPU in a very rare situation In-Reply-To: References: <5438A6EC.8000302@oracle.com> <415C2022-8ABA-405C-B7C6-258B512C8B04@oracle.com> <543D8A43.5020405@oracle.com> <543DB731.5000301@oracle.com> <5446D0ED.9040900@oracle.com> <4E5D5236-86BB-4235-B7DF-AFE90893FB02@oracle.com> <54483863.7010405@oracle.com> Message-ID: <54489D62.5070702@oracle.com> Thank you, Igor Vladimir On 10/22/14 11:13 PM, Igor Veresov wrote: > Thanks for the explanation! It?s a bit clearer now. :) Reviewed. > > igor > > On Oct 22, 2014, at 1:06 PM, Vladimir Kozlov wrote: > >> Thank you, Igor >> >> On 10/21/14 11:05 PM, Igor Veresov wrote: >>> Alright, since nobody is taking on it.. The timeout feature looks good, >>> I suppose a JIT needs to be adaptive to available CPU resources. >>> >>> A couple of small questions: >>> >>> 1. Why is it necessary to add phantom_obj to worklists? >>> >>> * 130 ptnodes_worklist.append(phantom_obj); >>> 131 java_objects_worklist.append(phantom_obj);* >> >> To avoid duplicated entries for phantom_obj on these lists. >> >> Even so processed ideal nodes are unique on ideal_nodes list several ideal nodes are mapped to phantom_obj: >> >> case Op_CreateEx: { >> // assume that all exception objects globally escape >> map_ideal_node(n, phantom_obj); >> break; >> >> as result ptnode_adr(n->_idx) will return phantom_obj several times and it will be added to above lists. >> >> I added next comment: >> >> // Processed ideal nodes are unique on ideal_nodes list >> // but several ideal nodes are mapped to the phantom_obj. >> // To avoid duplicated entries on the following worklists >> // add the phantom_obj only once to them. >> ptnodes_worklist.append(phantom_obj); >> >>> >>> 2. What does pidx_bias do here? >>> >>> 399 inline void add_to_worklist(PointsToNode* pt) { >>> 400 PointsToNode* ptf = pt; >>> 401 uint pidx_bias = 0; >>> 402 if (PointsToNode::is_base_use(pt)) { >>> 403 ptf = PointsToNode::get_use_node(pt)->as_Field(); >>> 404 pidx_bias = _next_pidx; >>> 405 } >>> 406 if (!_in_worklist.test_set(ptf->pidx() + pidx_bias)) { >>> 407 _worklist.append(pt); >>> 408 } >>> 409 } >> >> It is complicated :( >> >> To avoid creating a separate worklist in PointsToNode some edges are encoded specially (low bit set in a pointer): >> >> // Mark base edge use to distinguish from stored value edge. >> bool add_base_use(FieldNode* use) { return _uses.append_if_missing((PointsToNode*)((intptr_t)use + 1)); } >> >> It is used in add_java_object_edges(): >> >> PointsToNode* use = _worklist.at(l); >> if (PointsToNode::is_base_use(use)) { >> // Add reference from jobj to field and from field to jobj (field's base). >> use = PointsToNode::get_use_node(use)->as_Field(); >> if (add_base(use->as_Field(), jobj)) { >> new_edges++; >> >> So the _worklist may have the same node's pointers, with the bit set and without. add_to_worklist() want to make sure only one of each type is present on the _worklist. As result VectorSet _in_worklist should have 2 separate entries for each type of pointers. >> >> I added new _pidx to PointsToNode because I did not want VectorSet _in_worklist to be big - number of created EA nodes is usually about 10% from number of Ideal nodes. So _next_pidx is the number of all created EA nodes and adding it as bias guarantee the an unique entry in VectorSet. >> >> I will add next comment to add_to_worklist(): >> >> if (PointsToNode::is_base_use(pt)) { >> // Create a separate entry in _in_worklist for a marked base edge >> // because _worklist may have an entry for a normal edge pointing >> // to the same node. To separate them use _next_pidx as bias. >> ptf = PointsToNode::get_use_node(pt)->as_Field(); >> pidx_bias = _next_pidx; >> >> >> I hope I answered your question :) >> >> Thanks, >> Vladimir >> >>> >>> >>> Thanks, >>> igor >>> >>> >>> On Oct 21, 2014, at 11:32 AM, Vladimir Kozlov >>> > wrote: >>> >>>> Please, I need reviews. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/14/14 4:52 PM, Vladimir Kozlov wrote: >>>>> I updated changes. >>>>> >>>>> http://cr.openjdk.java.net/~kvn/8041984/webrev.01/ >>>>> >>>>> As David suggested I added SAMPLE_SIZE constant: >>>>> >>>>> #define SAMPLE_SIZE 4 >>>>> if ((next % SAMPLE_SIZE) == 0) { >>>>> // Each 4 iterations calculate how much time it will take >>>>> // to complete graph construction. >>>>> time.stop(); >>>>> double stop_time = time.seconds(); >>>>> double time_per_iter = (stop_time - start_time) / >>>>> (double)SAMPLE_SIZE; >>>>> double time_until_end = time_per_iter * >>>>> (double)(java_objects_length - next); >>>>> if ((start_time + time_until_end) >= EscapeAnalysisTimeout) { >>>>> >>>>> I also replaced TIME_LIMIT constant with flag: >>>>> >>>>> product(double, EscapeAnalysisTimeout, 20. DEBUG_ONLY(+40.), \ >>>>> "Abort EA when it reaches time limit (in sec)") \ >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/14/14 1:40 PM, Vladimir Kozlov wrote: >>>>>> On 10/14/14 10:30 AM, David Chase wrote: >>>>>>> I?m curious about the granularity of the completion-prediction ? >>>>>>> you?re checking every 4 iterations and extrapolating from there. >>>>>>> Do we know that the times are that uniform, or would we be better off >>>>>>> with larger sample sizes? >>>>>> >>>>>> Yes, I observed uniformly slowly growing times for PARTS of iterations >>>>>> and not all iterations. That is why I want to take several samples. >>>>>> For example first iterations where fast but when array allocation >>>>>> objects begin processed time are rapidly growing. >>>>>> If I take very big sample fast iterations affect the result - delay >>>>>> abort. >>>>>> >>>>>> I did implementation similar to your "alternate approach" suggestion and >>>>>> I saw that the abort happened much later than with current my approach. >>>>>> >>>>>>> (How long does a single iteration take, anyway?) >>>>>> >>>>>> As I said one slow iteration may take upto 1 sec. So I want to abort as >>>>>> soon as I see a such case (but allow spikes). Taking larger sample sizes >>>>>> may delay an abort for several seconds. >>>>>> >>>>>>> >>>>>>> And in the sample code, I see the choice of sample size (4) encoded as >>>>>>> (next & 3) == 0 >>>>>>> // Each 4 iterations calculate how much time it will take >>>>>>> double time_per_iter = (stop_time - start_time) * 0.25; >>>>>>> >>>>>>> why not write this as (say) >>>>>>> >>>>>>> static const int LOG_SAMPLE_SIZE = 2; >>>>>>> static const int SAMPLE_SIZE = (1 << LOG_SAMPLE_SIZE); >>>>>>> next % SAMPLE_SIZE == 0 // next could be a uint, couldn?t it? >>>>>>> double time_per_iter = (stop_time - start_time) * (1.0/SAMPLE_SIZE); >>>>>>> >>>>>>> perhaps rewriting 1.0/SAMPLE_SIZE as another static const as necessary >>>>>>> to get it properly precalculated; I?m not sure what C++ compilers are >>>>>>> doing nowadays. >>>>>> >>>>>> I am optimizing :) by avoiding % and / operations. But I agree and can >>>>>> add SAMPLE_SIZE constant so code can be more clear. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>>> >>>>>>> An alternate approach would be to compute the overall rate thus far, >>>>>>> checking at >>>>>>> (say) iterations 4, 8, 16, 32, etc and computing the average from >>>>>>> there, starting >>>>>>> at whatever power of two is a decent fraction of the iterations needed >>>>>>> to timeout. >>>>>>> >>>>>>> e.g., don?t reset start_time, just compute elapsed at each sample: >>>>>>> >>>>>>> if ((next & (ptwo - 1) == 0) { >>>>>>> time.stop(); >>>>>>> double elapsed = time.seconds() - start_time; >>>>>>> double projected = elapsed * (double) java_objects_length / next; >>>>>>> >>>>>>> Or you can compute a java_objects_length that would surely lead to >>>>>>> failure, and >>>>>>> always do that (fast, integer) comparison: >>>>>>> ... >>>>>>> unsigned int length_bound = (int) next * (CG_BUILD_TIME_LIMIT / >>>>>>> elapsed) >>>>>>> ? >>>>>>> if (java_objects_length > length_bound) { ? timeout >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 2014-10-10, at 11:41 PM, Vladimir Kozlov >>>>>>> wrote: >>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8041984 >>>>>>>> http://cr.openjdk.java.net/~kvn/8041984/webrev/ >>>>>>>> >>>>>>>> Next method puts C2's EA to its knees: >>>>>>>> >>>>>>>> com.graphhopper.coll.GHLongIntBTree$BTreeEntry::put() >>>>>>>> >>>>>>>> https://github.com/karussell/graphhopper/blob/master/core/src/main/java/com/graphhopper/coll/GHLongIntBTree.java >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It shows that current EA connection graph build code is very >>>>>>>> inefficient when a graph has a lot of connections (edges). >>>>>>>> >>>>>>>> With inlining the BTreeEntry::put() method has about 100 allocations >>>>>>>> from which about 80 are arrays allocations. Most of them are object >>>>>>>> arrays which are generated by Arrays.copyOf(). After number of edges >>>>>>>> in EA Connection Graph reaches about 50000 it takes more then 1 sec >>>>>>>> to find all nodes which reference an allocation. >>>>>>>> >>>>>>>> Current EA code has bailout by timeout from graph building code. But >>>>>>>> the timeout (30 sec for product VM) is checked only after all object >>>>>>>> nodes are processed. So it may take > 2 mins before EA is aborted: >>>>>>>> >>>>>>>> >>>>>>> stamp='4.417'> >>>>>>>> >>>>>>>> >>>>>>> stamp='150.967'/> >>>>>>>> >>>>>>>> Also ConnectionGraph::add_java_object_edges() method does not check >>>>>>>> the presence of a node when it adds new one to the worklist (in >>>>>>>> add_to_worklist() method). Which leads to hundreds MB of used by EA >>>>>>>> memory when BTreeEntry::put() is processed. >>>>>>>> >>>>>>>> To address issues new timeout checks were added. >>>>>>>> New _pidx index field is added to graph's nodes and VectorSet is used >>>>>>>> to reduce size of worklist in add_java_object_edges() method. >>>>>>>> >>>>>>>> Escaping node CreateEx is mapped phantom_obj to reduce number of >>>>>>>> process objects in connection graph. We do the same for other >>>>>>>> escaping objects. >>>>>>>> >>>>>>>> Tested with graphhopper server application: >>>>>>>> >>>>>>>> >>>>>>> stamp='6.829'> >>>>>>>> >>>>>>>> >>>>>>> stamp='22.355'/> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>> >>> > From vladimir.kozlov at oracle.com Thu Oct 23 06:38:31 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 22 Oct 2014 23:38:31 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <5BAF11B0-9423-40D6-8EB8-77FD69C67A72@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <5BAF11B0-9423-40D6-8EB8-77FD69C67A72@oracle.com> Message-ID: <5448A267.6040502@oracle.com> On 10/22/14 11:01 PM, John Rose wrote: > On Oct 22, 2014, at 10:09 PM, Vladimir Kozlov > wrote: > >> Intrinsic is not enough. It was only part of my statement. I suggested to always inline Class.cast() by changes in bytecodeInfo.cpp. As result Class.cast() could be used in castReference() without manual inlining. > > Would it be possible to give the new intrinsic wider coverage, to replace the logic in a majority of places it is used? I need a translation for this suggestion. The intrinsic will be used in all places where Class.cast() is called. If it does not fold code statically Roland's speculative type code fro arguments will generate type check based on profiling and cast. But it does that only if profiled type is unique. Or you are suggesting a full blown intrinsic which executes Class.cast() code for all cases and not only when klasses are matched statically? > > The logic in GraphKit::gen_checkcast is pretty sophisticated, and it's all there for a reason. What would stop us from > using it more fully? Please, explain. gen_instanceof() does not use gen_checkcast(). Are you talking about last cast code: "return (T) obj;"? Or you are talking about folding whole next expression?: void testLoopOne(String s) { ssink = (String) MH_CAST.invokeExact(String.class, s); Thanks, Vladimir > > Some of the sophistication depends on profiling of the cast and aastore instructions, crucially with null, but perhaps > we can cover that need with Roland's argument profiling work. > > ? John From tobias.hartmann at oracle.com Thu Oct 23 07:25:45 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 23 Oct 2014 09:25:45 +0200 Subject: [9] RFR(S): 8061486: [TESTBUG] compiler/whitebox/ tests fail : must be osr_compiled (reappeared in nightlies) In-Reply-To: <54482075.3080906@oracle.com> References: <5447C403.1090408@oracle.com> <54482075.3080906@oracle.com> Message-ID: <5448AD79.3000306@oracle.com> Hi Vladimir, On 22.10.2014 23:24, Vladimir Kozlov wrote: > Looks good. Did you tested both Tiered and non-Tiered compilation? Yes, I tested with the following flags: -Xcomp -XX:-TieredCompilation, -XX:+TieredCompilation -XX:CompileThreshold=100 Thanks, Tobias > > Thanks, > Vladimir > > On 10/22/14 7:49 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8061486 >> Webrev: http://cr.openjdk.java.net/~thartmann/8061486/webrev.00/ >> >> Problem: >> JDK-8060454 added a deoptimization before triggering the OSR compilation to >> avoid non-OSR compilations blocking OSR compilations. >> This is not sufficient because non-OSR compilations may also be triggered at >> backedges while the loop is being executed (if the backedge threshold is not yet >> reached but the invocation threshold is). >> >> Solution: >> Call warmup code from OSR triggering method, make sure non-OSR compilation is >> triggered and wait for completion until OSR compilation is triggered. >> >> Testing: >> - Failing test on Windows and Linux >> - Whitebox tests with different parameters on JPRT >> >> Thanks, >> Tobias >> >> >> [1] See 'AdvancedThresholdPolicy::method_back_branch_event()': >> // Use loop event as an opportunity to also check if there's been >> // enough calls. >> From paul.sandoz at oracle.com Thu Oct 23 10:45:53 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 23 Oct 2014 12:45:53 +0200 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <54488D7D.5080103@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> Message-ID: <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> Hi Vladimir, Do you consider these two aspects (intrinsic and inline) closely interrelated do as to be considered under the same issue? If not i can log another issue for the inlining. Paul. On Oct 23, 2014, at 7:09 AM, Vladimir Kozlov wrote: > On 10/22/14 2:29 AM, Paul Sandoz wrote: >> On Oct 22, 2014, at 10:54 AM, Roland Westrelin wrote: >>>> Here is intrinsic implementation: >>>> >>>> http://cr.openjdk.java.net/~kvn/8054492/webrev.01/ >>> >>> That looks good to me. >>> >> Same here. >> >> On Oct 22, 2014, at 2:02 AM, Vladimir Kozlov wrote: >>> Paul, is it enough for you? >>> >> >> Yes, many thanks. I verified in a number of scenarios. >> >> With Class.cast intrinsified can we can replace uses of following method in j.l.i.MethodHandleImpl with Class.cast? > > Intrinsic is not enough. That code was added because we do not inline Class.cast() for deep call stacks. C2 has inline depth limit 9. But we can workaround using next changes: > > --- a/src/share/vm/opto/bytecodeInfo.cpp Fri Aug 22 09:55:49 2014 -0700 > +++ b/src/share/vm/opto/bytecodeInfo.cpp Wed Oct 22 22:07:21 2014 -0700 > @@ -161,6 +161,7 @@ > if ((freq >= InlineFrequencyRatio) || > (call_site_count >= InlineFrequencyCount) || > is_unboxing_method(callee_method, C) || > + (callee_method->intrinsic_id() == vmIntrinsics::_class_cast) || > is_init_with_ea(callee_method, caller_method, C)) { > > max_inline_size = C->freq_inline_size(); > @@ -262,6 +263,11 @@ > return false; > } > > + if (callee_method->intrinsic_id() == vmIntrinsics::_class_cast) { > + // Inline Class.cast() method. > + return false; > + } > + > if (callee_method->has_compiled_code() && > callee_method->instructions_size() > InlineSmallCode) { > set_msg("already compiled into a big method"); > > > Thanks, > Vladimir > >> >> @ForceInline >> @SuppressWarnings("unchecked") >> static T castReference(Class t, U x) { >> // inlined Class.cast because we can't ForceInline it >> if (x != null && !t.isInstance(x)) >> throw newClassCastException(t, x); >> return (T) x; >> } >> >> Paul. >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From roland.westrelin at oracle.com Thu Oct 23 11:16:03 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 23 Oct 2014 13:16:03 +0200 Subject: RFR(XS): 8060252: JDK-7173584 compiler changes regress SPECjvm2008 on SPARC Message-ID: <3F56D166-0832-44FE-B488-1CF6C9AE242E@oracle.com> http://cr.openjdk.java.net/~roland/8060252/webrev.00/ The predicates that are added to validate arguments confuse tightly_coupled_allocation() and we miss opportunities to optimize the stub that is called for the copy. Roland. From aleksey.shipilev at oracle.com Thu Oct 23 11:20:47 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 23 Oct 2014 15:20:47 +0400 Subject: RFR(XS): 8060252: JDK-7173584 compiler changes regress SPECjvm2008 on SPARC In-Reply-To: <3F56D166-0832-44FE-B488-1CF6C9AE242E@oracle.com> References: <3F56D166-0832-44FE-B488-1CF6C9AE242E@oracle.com> Message-ID: <5448E48F.30205@oracle.com> On 23.10.2014 15:16, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8060252/webrev.00/ +1 > The predicates that are added to validate arguments confuse > tightly_coupled_allocation() and we miss opportunities to optimize > the stub that is called for the copy. The performance regression appears to be gone with this change, thanks. -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From roland.westrelin at oracle.com Thu Oct 23 11:27:21 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 23 Oct 2014 13:27:21 +0200 Subject: RFR(XS): 8060252: JDK-7173584 compiler changes regress SPECjvm2008 on SPARC In-Reply-To: <3F56D166-0832-44FE-B488-1CF6C9AE242E@oracle.com> References: <3F56D166-0832-44FE-B488-1CF6C9AE242E@oracle.com> Message-ID: > http://cr.openjdk.java.net/~roland/8060252/webrev.00/ I added a comment that I had forgotten and updated the webrev in place. Roland. From roland.westrelin at oracle.com Thu Oct 23 11:50:22 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 23 Oct 2014 13:50:22 +0200 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: <543833F6.5050002@oracle.com> References: <5436E2C3.7060008@oracle.com> <5436FCF6.7080309@oracle.com> <543814CC.2080905@oracle.com> <5C32D21B-9A72-4367-A5F7-3C4FB2326FE0@oracle.com> <543833F6.5050002@oracle.com> Message-ID: <71726E40-F4AF-43A4-A213-1A60F5687AB0@oracle.com> Vladimir, Here is a new webrev that takes your comments into account: http://cr.openjdk.java.net/~roland/6700100/webrev.01/ I moved the ik->has_injected_fields() call last in ArrayCopyNode::get_count() and added a comment. I improved the code in fieldStreams.hpp LibraryCallKit::inline_arraycopy() had what turned out to be the fix for JDK-8060252 (performance regression on sparc). I removed it so it can be pushed as a separate fix. Roland. > On Oct 10, 2014, at 9:31 PM, Vladimir Kozlov wrote: > > I was thinking aloud :) > > Changes are good as it is. Thank you for discussion. > > Thanks, > Vladimir > > On 10/10/14 10:47 AM, Roland Westrelin wrote: >>>> If we wanted to delay that transformation, wouldn?t we also want a few passes of IGVN to happen before we do the transformation? >>> >>> The thing which can be improved is klass exactness. Which will allow to skip adding dependency. That is what I was thinking. But it may only happen after CCP phase. But I really want to do this optimization before EA which will greatly benefit from it. Also if klass is exact during parsing we may do optimization during parsing too. >> >> Ok. But I?m not sure if you?re suggesting a change or if it?s good as it is? >> >> Roland. >> From roland.westrelin at oracle.com Thu Oct 23 11:58:15 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 23 Oct 2014 13:58:15 +0200 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: <543BABFB.30101@oracle.com> References: <543BABFB.30101@oracle.com> Message-ID: <04858420-F85F-41B9-8306-72419AE982D4@oracle.com> > Any reason why you chosen 8 as the threshold value? Any benchmarking > involved? Do you need one? I think Vladimir suggested 8, 2 years ago when I worked on this first. The value stayed. Are you talking about micro benchmarks? There are 2 benefits to this change: - it avoids a call so we could look for a copy size where the benefit of not doing the call becomes small enough - it allows other optimizations. An important one is that escape analysis can find more candidate allocations that we can eliminate. That?s much harder to benchmark I think. There?s a second change coming that will do the same for array copies and that will use the same threshold value. So if we want to tune the threshold value we should wait for that change. Do we need a threshold value? I think we do. We don?t want to grow the IR graph if it doesn?t pay off. Roland. > >> Converts ArrayCopy nodes for small instance clones to series of >> loads/stores + a little bit of cleanup. >> >> Small array clones & copies as loads/stores are coming next in >> another change. > > -Aleksey. > From nils.eliasson at oracle.com Thu Oct 23 14:26:11 2014 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 23 Oct 2014 16:26:11 +0200 Subject: RFR(XS): JDK-8061947 Quarantine serviceability/dcmd/CompilerQueueTest.java Message-ID: <54491003.6090007@oracle.com> Hi, Please review this quarantine of two tests. serviceability/dcmd/compiler/CompilerQueueTest.java com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java Webrev: Hotspot: http://cr.openjdk.java.net/~neliasso/8061947/webrev.01/ JDK: http://cr.openjdk.java.net/~neliasso/8061947/webrev.02/ //Regards, Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Thu Oct 23 14:43:22 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 23 Oct 2014 18:43:22 +0400 Subject: RFR(XS): JDK-8061947 Quarantine serviceability/dcmd/CompilerQueueTest.java In-Reply-To: <54491003.6090007@oracle.com> References: <54491003.6090007@oracle.com> Message-ID: <5449140A.8070809@oracle.com> Hi Nils, 0. @ignore should be placed after @library, otherwise jtreg can't start a test in '-ignore:run' mode 1. we use one @ignore w/ many bugs and don't use JDK prefix. > @ignore 8061199 8061250 Thanks Igor On 10/23/2014 06:26 PM, Nils Eliasson wrote: > Hi, > > Please review this quarantine of two tests. > > serviceability/dcmd/compiler/CompilerQueueTest.java > com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java > > Webrev: > Hotspot: http://cr.openjdk.java.net/~neliasso/8061947/webrev.01/ > JDK: http://cr.openjdk.java.net/~neliasso/8061947/webrev.02/ > > //Regards, > Nils From nils.eliasson at oracle.com Thu Oct 23 14:54:59 2014 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 23 Oct 2014 16:54:59 +0200 Subject: RFR(XS): JDK-8061947 Quarantine serviceability/dcmd/CompilerQueueTest.java In-Reply-To: <5449140A.8070809@oracle.com> References: <54491003.6090007@oracle.com> <5449140A.8070809@oracle.com> Message-ID: <544916C3.7070004@oracle.com> Thanks Igor, Updated hotspot webrev: http://cr.openjdk.java.net/~neliasso/8061947/webrev.03 Other still relevant: JDK: http://cr.openjdk.java.net/~neliasso/8061947/webrev.02 Regards, //Nils On 2014-10-23 16:43, Igor Ignatyev wrote: > Hi Nils, > > 0. @ignore should be placed after @library, otherwise jtreg can't > start a test in '-ignore:run' mode > 1. we use one @ignore w/ many bugs and don't use JDK prefix. >> @ignore 8061199 8061250 > > Thanks > Igor > > On 10/23/2014 06:26 PM, Nils Eliasson wrote: >> Hi, >> >> Please review this quarantine of two tests. >> >> serviceability/dcmd/compiler/CompilerQueueTest.java >> com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java >> >> Webrev: >> Hotspot: http://cr.openjdk.java.net/~neliasso/8061947/webrev.01/ >> JDK: http://cr.openjdk.java.net/~neliasso/8061947/webrev.02/ >> >> //Regards, >> Nils From vladimir.kozlov at oracle.com Thu Oct 23 17:29:50 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Oct 2014 10:29:50 -0700 Subject: RFR(XS): 8060252: JDK-7173584 compiler changes regress SPECjvm2008 on SPARC In-Reply-To: References: <3F56D166-0832-44FE-B488-1CF6C9AE242E@oracle.com> Message-ID: <54493B0E.8040801@oracle.com> Looks good. Thanks, Vladimir On 10/23/14 4:27 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~roland/8060252/webrev.00/ > > I added a comment that I had forgotten and updated the webrev in place. > > Roland. > From vladimir.kozlov at oracle.com Thu Oct 23 17:37:47 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Oct 2014 10:37:47 -0700 Subject: RFR(XS): JDK-8061947 Quarantine serviceability/dcmd/CompilerQueueTest.java In-Reply-To: <544916C3.7070004@oracle.com> References: <54491003.6090007@oracle.com> <5449140A.8070809@oracle.com> <544916C3.7070004@oracle.com> Message-ID: <54493CEB.4090206@oracle.com> The explanation/evaluation is needed. Neither RFR of JBS report have it. Thanks, Vladimir On 10/23/14 7:54 AM, Nils Eliasson wrote: > Thanks Igor, > > Updated hotspot webrev: http://cr.openjdk.java.net/~neliasso/8061947/webrev.03 > Other still relevant: JDK: http://cr.openjdk.java.net/~neliasso/8061947/webrev.02 > > Regards, > //Nils > > On 2014-10-23 16:43, Igor Ignatyev wrote: >> Hi Nils, >> >> 0. @ignore should be placed after @library, otherwise jtreg can't start a test in '-ignore:run' mode >> 1. we use one @ignore w/ many bugs and don't use JDK prefix. >>> @ignore 8061199 8061250 >> >> Thanks >> Igor >> >> On 10/23/2014 06:26 PM, Nils Eliasson wrote: >>> Hi, >>> >>> Please review this quarantine of two tests. >>> >>> serviceability/dcmd/compiler/CompilerQueueTest.java >>> com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java >>> >>> Webrev: >>> Hotspot: http://cr.openjdk.java.net/~neliasso/8061947/webrev.01/ >>> JDK: http://cr.openjdk.java.net/~neliasso/8061947/webrev.02/ >>> >>> //Regards, >>> Nils > From vladimir.kozlov at oracle.com Thu Oct 23 17:41:03 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Oct 2014 10:41:03 -0700 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: <71726E40-F4AF-43A4-A213-1A60F5687AB0@oracle.com> References: <5436E2C3.7060008@oracle.com> <5436FCF6.7080309@oracle.com> <543814CC.2080905@oracle.com> <5C32D21B-9A72-4367-A5F7-3C4FB2326FE0@oracle.com> <543833F6.5050002@oracle.com> <71726E40-F4AF-43A4-A213-1A60F5687AB0@oracle.com> Message-ID: <54493DAF.8040609@oracle.com> This looks good. Thanks, Vladimir On 10/23/14 4:50 AM, Roland Westrelin wrote: > Vladimir, > > Here is a new webrev that takes your comments into account: > > http://cr.openjdk.java.net/~roland/6700100/webrev.01/ > > I moved the ik->has_injected_fields() call last in ArrayCopyNode::get_count() and added a comment. > > I improved the code in fieldStreams.hpp > > LibraryCallKit::inline_arraycopy() had what turned out to be the fix for JDK-8060252 (performance regression on sparc). I removed it so it can be pushed as a separate fix. > > Roland. > > >> On Oct 10, 2014, at 9:31 PM, Vladimir Kozlov wrote: >> >> I was thinking aloud :) >> >> Changes are good as it is. Thank you for discussion. >> >> Thanks, >> Vladimir >> >> On 10/10/14 10:47 AM, Roland Westrelin wrote: >>>>> If we wanted to delay that transformation, wouldn?t we also want a few passes of IGVN to happen before we do the transformation? >>>> >>>> The thing which can be improved is klass exactness. Which will allow to skip adding dependency. That is what I was thinking. But it may only happen after CCP phase. But I really want to do this optimization before EA which will greatly benefit from it. Also if klass is exact during parsing we may do optimization during parsing too. >>> >>> Ok. But I?m not sure if you?re suggesting a change or if it?s good as it is? >>> >>> Roland. >>> > From vladimir.x.ivanov at oracle.com Thu Oct 23 18:08:04 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 23 Oct 2014 22:08:04 +0400 Subject: [9] RFR (XS): 8036748: assert(_base == Int) failed: Not an Int w/ -XX:+TraceIterativeGVN Message-ID: <54494404.7040602@oracle.com> http://cr.openjdk.java.net/~vlivanov/8036748/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8036748 Debug builds sometime crash w/ -XX:+TraceIterativeGVN. The fix is an update to the dumping check in CallStaticJavaNode::extract_uncommon_trap_request() to ensure the bottom_type is an TypeInt. Testing: manual. Best regards, Vladimir Ivanov From vladimir.x.ivanov at oracle.com Thu Oct 23 18:21:26 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 23 Oct 2014 22:21:26 +0400 Subject: [9] RFR (XS): 8058847: C2: EliminateAutoBox regression after 8042786 Message-ID: <54494726.3070600@oracle.com> http://cr.openjdk.java.net/~vlivanov/8058847/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8058847 LoadNode::eliminate_autobox() doesn't care whether the unboxing node represents signed or unsigned load. It means that for LoadUB/LoadUS -> ... -> LoadB/LoadS unboxing/boxing pair, information about unsigned load is lost. It leads to incorrect code generation. The fix is to reify this information in the graph by wrapping the result in AddI (_ mask). Testing: regression test Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Thu Oct 23 18:30:54 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Oct 2014 11:30:54 -0700 Subject: [9] RFR (XS): 8058847: C2: EliminateAutoBox regression after 8042786 In-Reply-To: <54494726.3070600@oracle.com> References: <54494726.3070600@oracle.com> Message-ID: <5449495E.7070507@oracle.com> Looks good. Thank you for fixing this. Vladimir K On 10/23/14 11:21 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8058847/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8058847 > > LoadNode::eliminate_autobox() doesn't care whether the unboxing node represents signed or unsigned load. It means that > for LoadUB/LoadUS -> ... -> LoadB/LoadS unboxing/boxing pair, information about unsigned load is lost. It leads to > incorrect code generation. > > The fix is to reify this information in the graph by wrapping the result in AddI (_ mask). > > Testing: regression test > > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Thu Oct 23 18:38:11 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Oct 2014 11:38:11 -0700 Subject: [9] RFR (XS): 8036748: assert(_base == Int) failed: Not an Int w/ -XX:+TraceIterativeGVN In-Reply-To: <54494404.7040602@oracle.com> References: <54494404.7040602@oracle.com> Message-ID: <54494B13.1090108@oracle.com> It is dead node (not connected to graph): CallStaticJava === 1 1 1 1 1 ( 1 1 1 1 ) [[]] Your changes are fine but we should also skip such node at all. Thanks, Vladimir On 10/23/14 11:08 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8036748/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8036748 > > Debug builds sometime crash w/ -XX:+TraceIterativeGVN. > > The fix is an update to the dumping check in CallStaticJavaNode::extract_uncommon_trap_request() to ensure the > bottom_type is an TypeInt. > > Testing: manual. > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Thu Oct 23 18:46:13 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 23 Oct 2014 22:46:13 +0400 Subject: [9] RFR (XS): 8036748: assert(_base == Int) failed: Not an Int w/ -XX:+TraceIterativeGVN In-Reply-To: <54494B13.1090108@oracle.com> References: <54494404.7040602@oracle.com> <54494B13.1090108@oracle.com> Message-ID: <54494CF5.7030005@oracle.com> On 10/23/14, 10:38 PM, Vladimir Kozlov wrote: > It is dead node (not connected to graph): > > CallStaticJava === 1 1 1 1 1 ( 1 1 1 1 ) [[]] > > Your changes are fine but we should also skip such node at all. Thanks, Vladimir! I filed 8061995 [1] to track the problem. Also, added a regression test (updated the webrev in place): http://cr.openjdk.java.net/~vlivanov/8036748/webrev.00/ Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8061995 From vladimir.kozlov at oracle.com Thu Oct 23 18:58:49 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Oct 2014 11:58:49 -0700 Subject: [9] RFR (XS): 8036748: assert(_base == Int) failed: Not an Int w/ -XX:+TraceIterativeGVN In-Reply-To: <54494CF5.7030005@oracle.com> References: <54494404.7040602@oracle.com> <54494B13.1090108@oracle.com> <54494CF5.7030005@oracle.com> Message-ID: <54494FE9.4050306@oracle.com> Very nice. Thanks, Vladimir K On 10/23/14 11:46 AM, Vladimir Ivanov wrote: > > > On 10/23/14, 10:38 PM, Vladimir Kozlov wrote: >> It is dead node (not connected to graph): >> >> CallStaticJava === 1 1 1 1 1 ( 1 1 1 1 ) [[]] >> >> Your changes are fine but we should also skip such node at all. > Thanks, Vladimir! > > I filed 8061995 [1] to track the problem. > > Also, added a regression test (updated the webrev in place): > http://cr.openjdk.java.net/~vlivanov/8036748/webrev.00/ > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8061995 From nils.eliasson at oracle.com Thu Oct 23 19:24:02 2014 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 23 Oct 2014 21:24:02 +0200 Subject: RFR(XS): JDK-8061947 Quarantine serviceability/dcmd/CompilerQueueTest.java In-Reply-To: <54493CEB.4090206@oracle.com> References: <54491003.6090007@oracle.com> <5449140A.8070809@oracle.com> <544916C3.7070004@oracle.com> <54493CEB.4090206@oracle.com> Message-ID: <544955D2.70409@oracle.com> The change is just a quarantine of the tests, not a fix. //N On 2014-10-23 19:37, Vladimir Kozlov wrote: > The explanation/evaluation is needed. Neither RFR of JBS report have it. > > Thanks, > Vladimir > > On 10/23/14 7:54 AM, Nils Eliasson wrote: >> Thanks Igor, >> >> Updated hotspot webrev: >> http://cr.openjdk.java.net/~neliasso/8061947/webrev.03 >> Other still relevant: JDK: >> http://cr.openjdk.java.net/~neliasso/8061947/webrev.02 >> >> Regards, >> //Nils >> >> On 2014-10-23 16:43, Igor Ignatyev wrote: >>> Hi Nils, >>> >>> 0. @ignore should be placed after @library, otherwise jtreg can't >>> start a test in '-ignore:run' mode >>> 1. we use one @ignore w/ many bugs and don't use JDK prefix. >>>> @ignore 8061199 8061250 >>> >>> Thanks >>> Igor >>> >>> On 10/23/2014 06:26 PM, Nils Eliasson wrote: >>>> Hi, >>>> >>>> Please review this quarantine of two tests. >>>> >>>> serviceability/dcmd/compiler/CompilerQueueTest.java >>>> com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java >>>> >>>> >>>> Webrev: >>>> Hotspot: http://cr.openjdk.java.net/~neliasso/8061947/webrev.01/ >>>> JDK: http://cr.openjdk.java.net/~neliasso/8061947/webrev.02/ >>>> >>>> //Regards, >>>> Nils >> From vladimir.kozlov at oracle.com Thu Oct 23 19:51:38 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Oct 2014 12:51:38 -0700 Subject: RFR(XS): JDK-8061947 Quarantine serviceability/dcmd/CompilerQueueTest.java In-Reply-To: <544955D2.70409@oracle.com> References: <54491003.6090007@oracle.com> <5449140A.8070809@oracle.com> <544916C3.7070004@oracle.com> <54493CEB.4090206@oracle.com> <544955D2.70409@oracle.com> Message-ID: <54495C4A.2020205@oracle.com> I am asking why we can't fix the problem. As I said before we should quarantine tests when the fixing takes too long. But 8061199 does not have even evaluation about what happened or cause the failure. Vladimir On 10/23/14 12:24 PM, Nils Eliasson wrote: > The change is just a quarantine of the tests, not a fix. > > //N > > On 2014-10-23 19:37, Vladimir Kozlov wrote: >> The explanation/evaluation is needed. Neither RFR of JBS report have it. >> >> Thanks, >> Vladimir >> >> On 10/23/14 7:54 AM, Nils Eliasson wrote: >>> Thanks Igor, >>> >>> Updated hotspot webrev: http://cr.openjdk.java.net/~neliasso/8061947/webrev.03 >>> Other still relevant: JDK: http://cr.openjdk.java.net/~neliasso/8061947/webrev.02 >>> >>> Regards, >>> //Nils >>> >>> On 2014-10-23 16:43, Igor Ignatyev wrote: >>>> Hi Nils, >>>> >>>> 0. @ignore should be placed after @library, otherwise jtreg can't start a test in '-ignore:run' mode >>>> 1. we use one @ignore w/ many bugs and don't use JDK prefix. >>>>> @ignore 8061199 8061250 >>>> >>>> Thanks >>>> Igor >>>> >>>> On 10/23/2014 06:26 PM, Nils Eliasson wrote: >>>>> Hi, >>>>> >>>>> Please review this quarantine of two tests. >>>>> >>>>> serviceability/dcmd/compiler/CompilerQueueTest.java >>>>> com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java >>>>> >>>>> Webrev: >>>>> Hotspot: http://cr.openjdk.java.net/~neliasso/8061947/webrev.01/ >>>>> JDK: http://cr.openjdk.java.net/~neliasso/8061947/webrev.02/ >>>>> >>>>> //Regards, >>>>> Nils >>> > From john.r.rose at oracle.com Thu Oct 23 23:00:42 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 23 Oct 2014 16:00:42 -0700 Subject: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames In-Reply-To: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> References: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> Message-ID: On Oct 17, 2014, at 11:16 AM, David Chase wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8013267 > > webrevs: > http://cr.openjdk.java.net/~drchase/8013267/jdk.03/ > http://cr.openjdk.java.net/~drchase/8013267/hotspot.03/ > > related bug: https://bugs.openjdk.java.net/browse/JDK-8042235 This is a big 'un. Now that we can modify hotspot and jdk together more easily, it's more feasible to work on. I'm glad to see you taking this on. A few comments for background: This is a case where more logic should go at the JDK layer, where we can work on it and understand it more readily. The JVM layer should supply only a few things for this: - A mapping from symbolic references to resolved references - A mapping from reflective stuff (jlr.Method) to resolved references - A bulk query from a class to its resolved references The common thread is that only the JVM knows how to inject metadata into the MemberName type. Other logic, such as caching or interning or registration, is best handled by Java code. To complicate things, the JVM also needs to (very infrequently) visit the set of all MemberName's in the world. (Or else we need a turtle under the MN turtle, which we are not doing, thankfully.) That's why there needs to be a coupling where the JVM can "see" the Class.ClassData fields. > 1) on the hotspot side, code to adjust the membername table needed to check > that the data for the membername table was actually allocated (one goal of this > rfe was to avoid allocating that table) else it would null deref and crash. Nice catch. C code doesn't do NPEs very well. > 2) on the jdk side, fencepost error in the membername table insertion; the first > entry could be duplicated ( ?if index > 0? wrong, should be ?if index >= 0?). Good. > 3) on the jdk side, several of the constructors for MemberNames needed to be > replaced with factories that would consult the MemberNameTable and avoid > creating duplicates; again, that was the entire point of this fix. *NOT ALL > CONSTRUCTORS WERE MODIFIED LIKE THIS?, and there was one curious > piece of code where it seemed that this might not be what was desired, but it > was unclear how this would behave in the face of method redefinition. Maybe this was a place where the patch was incomplete. Since the MemberName type is *private* to the java.lang.invoke package, public constructors are tolerable. (Some or all of them could be made non-public or private, if that makes the code easier to reason about.) But among the non-private constructors there is a deep difference between constructors which create an unresolved symbolic reference and constructors which somehow create a MN which is resolved from the start. The former are needed to compose a query to the resolve (and possibly intern) functions. The latter are special cases needed by the user-visible unreflectFoo methods. > From > > http://cr.openjdk.java.net/~drchase/8013267/jdk.03/src/java.base/share/classes/java/lang/invoke/MemberName.java.html > > 1047 private MemberName resolve(byte refKind, MemberName ref, Class lookupClass) { > 1048 MemberName m = ref.clone(); // JVM will side-effect the ref > 1049 assert(refKind == m.getReferenceKind()); > 1050 try { > 1051 m = MethodHandleNatives.resolve(m, lookupClass); > 1052 m.checkForTypeAlias(); > 1053 m.resolution = null; > 1054 m.intern(); > > Note that this performs an ?intern? that ignores what is already found in the table > and may not place m in the table if a duplicate name is already there. ????????? That is: + m.intern(); // FIXME: Here's where we stopped work the last time around. I would try, first: + m = m.intern(); > testing: > jtreg: > hotspot/{compiler,runtime,gc} > jdk/{vm,jdk,sun/{invoke,misc,reflect} > by-hand: verified that the crash example for 8042235 still crash in an unmodified VM and does not crash in a modified VM. > > Modified and retested > https://bugs.openjdk.java.net/secure/attachment/20184/RedefineMethodUsedByMultipleMethodHandles.java > Old: > // Calling fooMH1.vmtarget crashes the VM > System.out.println("fooMH1.invoke = " + fooMH1.invokeExact()); > > New: > // Calling fooMH1.vmtarget crashes the VM > System.out.println("fooMH1.invoke = " + fooMH1.invokeExact()); > System.out.println("fooMH2.invoke = " + fooMH2.invokeExact()); > > This turned out to be a reasonable thing to do, since the added line caused a crash till further corrections were made. > (See fixes 2 and 3 above). > > Should RedefineMethodUsedByMultipleMethodHandles.java also be added as a test? I would say yes, though I'd defer to an SQE or Serguei on that. > Are there other tests that would be good to run ?(and if they are ute tests, the more > detailed the instructions for how to run them, the better.) (Same deference.) ? John From aleksey.shipilev at oracle.com Fri Oct 24 07:28:48 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 24 Oct 2014 11:28:48 +0400 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: <04858420-F85F-41B9-8306-72419AE982D4@oracle.com> References: <543BABFB.30101@oracle.com> <04858420-F85F-41B9-8306-72419AE982D4@oracle.com> Message-ID: <5449FFB0.5030004@oracle.com> On 23.10.2014 15:58, Roland Westrelin wrote: > There?s a second change coming that will do the same for array copies > and that will use the same threshold value. So if we want to tune the > threshold value we should wait for that change. Understood. Ping me back when you need the performance experiments for threshold value. > Do we need a threshold value? I think we do. We don?t want to grow > the IR graph if it doesn?t pay off. Agreed. -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From roland.westrelin at oracle.com Fri Oct 24 09:29:22 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 24 Oct 2014 11:29:22 +0200 Subject: [9] RFR (XS): 8036748: assert(_base == Int) failed: Not an Int w/ -XX:+TraceIterativeGVN In-Reply-To: <54494CF5.7030005@oracle.com> References: <54494404.7040602@oracle.com> <54494B13.1090108@oracle.com> <54494CF5.7030005@oracle.com> Message-ID: <76273EEC-ACB2-414B-B5E1-32CA9D6185F9@oracle.com> > http://cr.openjdk.java.net/~vlivanov/8036748/webrev.00/ Looks ok. Roland. From vladimir.x.ivanov at oracle.com Fri Oct 24 09:33:20 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 24 Oct 2014 13:33:20 +0400 Subject: [9] RFR (XS): 8036748: assert(_base == Int) failed: Not an Int w/ -XX:+TraceIterativeGVN In-Reply-To: <76273EEC-ACB2-414B-B5E1-32CA9D6185F9@oracle.com> References: <54494404.7040602@oracle.com> <54494B13.1090108@oracle.com> <54494CF5.7030005@oracle.com> <76273EEC-ACB2-414B-B5E1-32CA9D6185F9@oracle.com> Message-ID: <544A1CE0.8080109@oracle.com> Vladimir, Roland, thanks for review! Best regards, Vladimir Ivanov On 10/24/14, 1:29 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~vlivanov/8036748/webrev.00/ > > Looks ok. > > Roland. > From roland.westrelin at oracle.com Fri Oct 24 09:39:09 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Fri, 24 Oct 2014 11:39:09 +0200 Subject: [9] RFR (XS): 8058847: C2: EliminateAutoBox regression after 8042786 In-Reply-To: <54494726.3070600@oracle.com> References: <54494726.3070600@oracle.com> Message-ID: > http://cr.openjdk.java.net/~vlivanov/8058847/webrev.00/ Looks good. Roland. From vladimir.x.ivanov at oracle.com Fri Oct 24 09:42:04 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 24 Oct 2014 13:42:04 +0400 Subject: [9] RFR (XS): 8058847: C2: EliminateAutoBox regression after 8042786 In-Reply-To: References: <54494726.3070600@oracle.com> Message-ID: <544A1EEC.7030201@oracle.com> Vladimir, Roland, thanks for review! Best regards, Vladimir Ivanov On 10/24/14, 1:39 PM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~vlivanov/8058847/webrev.00/ > > Looks good. > > Roland. > From tobias.hartmann at oracle.com Fri Oct 24 12:39:22 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 24 Oct 2014 14:39:22 +0200 Subject: [9] RFR(S): 8061817: Whitebox.deoptimizeMethod() does not deoptimize all OSR versions of method Message-ID: <544A487A.5080008@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8061817 Webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.00/ Problem 'WhiteBox.deoptimizeMethod' does not deoptimize all OSR compiled versions of the given method but only one. The problem lies in'WB_DeoptimizeMethod'. The call to 'lookup_osr_nmethod_for' only returns the best fitting OSR nmethod. Incrementing the bci (see line 395) does not help. Solution I changed the implementation to deoptimize all OSR versions and added a regression test that triggers two OSR compilations and checks that both are deoptimized ('DeoptimizeMultipleOSRTest'). Testing New test on JPRT Best, Tobias From tobias.hartmann at oracle.com Fri Oct 24 12:54:42 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 24 Oct 2014 14:54:42 +0200 Subject: [9] RFR(S): 8061983: [TESTBUG] compiler/whitebox/MakeMethodNotCompilableTest.java fails with "must not be in queue" Message-ID: <544A4C12.4060506@oracle.com> Hi, please review the following patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8061983 Webrev: http://cr.openjdk.java.net/~thartmann/8061983/webrev.00/ Problem: In the failing case, the test makes a method not OSR compilable and tries to trigger an OSR compilation. 'checkNotOsrCompiled' then fails because a (non-OSR) compilation is in the compile queue. The test should not assume triggering an OSR compilation of a method may not also trigger a non-OSR compilation. Solution: I added a method checkNotCompiled(boolean isOsr) to either check if the method is OSR compiled or to check if it is non-OSR compiled. The method waits for background compilation and then checks. Testing: Failing testcase with different parameters. Best, Tobias From igor.ignatyev at oracle.com Fri Oct 24 13:06:06 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 24 Oct 2014 17:06:06 +0400 Subject: [9] RFR(S): 8061817: Whitebox.deoptimizeMethod() does not deoptimize all OSR versions of method In-Reply-To: <544A487A.5080008@oracle.com> References: <544A487A.5080008@oracle.com> Message-ID: <544A4EBE.7090103@oracle.com> Hi Tobias, DeoptimizeMultipleOSRTest: 1. could you please make 'method' an instance field? 2. use AssertionError instead of RuntimeException 3. have you tried to run this test w/ Xcomp? Thanks, Igor On 10/24/2014 04:39 PM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061817 > Webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.00/ > > Problem > 'WhiteBox.deoptimizeMethod' does not deoptimize all OSR compiled versions of the > given method but only one. The problem lies in'WB_DeoptimizeMethod'. The call to > 'lookup_osr_nmethod_for' only returns the best fitting OSR nmethod. Incrementing > the bci (see line 395) does not help. > > Solution > I changed the implementation to deoptimize all OSR versions and added a > regression test that triggers two OSR compilations and checks that both are > deoptimized ('DeoptimizeMultipleOSRTest'). > > Testing > New test on JPRT > > Best, > Tobias > From vladimir.kozlov at oracle.com Fri Oct 24 16:25:50 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Oct 2014 09:25:50 -0700 Subject: [9] RFR(S): 8061983: [TESTBUG] compiler/whitebox/MakeMethodNotCompilableTest.java fails with "must not be in queue" In-Reply-To: <544A4C12.4060506@oracle.com> References: <544A4C12.4060506@oracle.com> Message-ID: <544A7D8E.1000408@oracle.com> Looks good. Thanks, Vladimir On 10/24/14 5:54 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061983 > Webrev: http://cr.openjdk.java.net/~thartmann/8061983/webrev.00/ > > Problem: > In the failing case, the test makes a method not OSR compilable and tries to > trigger an OSR compilation. 'checkNotOsrCompiled' then fails because a (non-OSR) > compilation is in the compile queue. The test should not assume triggering an > OSR compilation of a method may not also trigger a non-OSR compilation. > > Solution: > I added a method checkNotCompiled(boolean isOsr) to either check if the method > is OSR compiled or to check if it is non-OSR compiled. The method waits for > background compilation and then checks. > > Testing: > Failing testcase with different parameters. > > Best, > Tobias > From igor.veresov at oracle.com Fri Oct 24 20:48:16 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 24 Oct 2014 10:48:16 -1000 Subject: RFR(S) 8059200: Promoted JDK9 b31 for Solaris-amd64 fails (Error: dl failure on line 744, no picl library) on Solaris 11.1 Message-ID: <367309D4-F682-4DB2-8412-F92D4304F268@oracle.com> People are running into problems with PICL on Solaris. First of all we linked with libpicl on x86 and we shouldn?t because it?s not really require here. Secondly, in some situations (like Solaris zones) PICL is not installed by default. Nevertheless it remains the only reasonable way to determine cache line sizes on SPARC (which we need to properly use BIS instructions), so we?d like to keep using it. The only solution I see is to link manually and display a warning if PICL is not installed. Webrev: http://cr.openjdk.java.net/~iveresov/8059200/webrev.00/ igor From paul.sandoz at oracle.com Fri Oct 24 20:52:33 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 24 Oct 2014 22:52:33 +0200 Subject: MH inlining fails for a package-private and protected calls Message-ID: <71AB5B0F-61AC-443F-9556-662BF29B0941@oracle.com> Hi, I am observing that inlining of a MH invocation to a package private method fails. Below is a simple test that test MHs to a public, package-private and protected methods. Using the tip of JDK 9 with "java -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining MHInlineTest" produces the following: ! @ 10 MHInlineTest::testPublicMH (24 bytes) inline (hot) @ 7 java.lang.invoke.LambdaForm$MH/314265080::invokeExact_MT (17 bytes) force inline by annotation @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by annotation @ 11 java.lang.invoke.MethodHandle::type (5 bytes) accessor @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes) force inline by annotation @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation @ 11 MHInlineTest$B::public_x (6 bytes) inline (hot) ! @ 29 MHInlineTest::testProtectedMH (24 bytes) inline (hot) @ 7 java.lang.invoke.LambdaForm$MH/314265080::invokeExact_MT (17 bytes) force inline by annotation @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by annotation @ 11 java.lang.invoke.MethodHandle::type (5 bytes) accessor @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes) force inline by annotation @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation @ 11 MHInlineTest$A::protected_x (6 bytes) virtual call ! @ 48 MHInlineTest::testPackageMH (24 bytes) inline (hot) @ 7 java.lang.invoke.LambdaForm$MH/314265080::invokeExact_MT (17 bytes) force inline by annotation @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by annotation @ 11 java.lang.invoke.MethodHandle::type (5 bytes) accessor @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes) force inline by annotation @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation @ 11 MHInlineTest$A::package_x (6 bytes) virtual call ! @ 67 MHInlineTest::testPackageFinalMH (24 bytes) inline (hot) @ 7 java.lang.invoke.LambdaForm$MH/314265080::invokeExact_MT (17 bytes) force inline by annotation @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by annotation @ 11 java.lang.invoke.MethodHandle::type (5 bytes) accessor @ 13 java.lang.invoke.LambdaForm$DMH/344560770::invokeSpecial_LL_V (15 bytes) force inline by annotation @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation @ 11 MHInlineTest$A::package_final_x (6 bytes) inline (hot) @ 86 MHInlineTest::testPackage (8 bytes) inline (hot) @ 4 MHInlineTest$B::package_x (6 bytes) inline (hot) Note that: - inlining bails out for the MH to the package-private and and protected method, but does not bail out for an explicit package-protected call. - the same LambdaForms are used for all virtual invocations. Is that the expected behaviour? Paul. public class MHInlineTest { public static class A { volatile String s; public void public_x(String s) { this.s = s; } void protected_x(String s) { this.s = s; } void package_x(String s) { this.s = s; } final void package_final_x(String s) { this.s = s; } } public static final class B extends A { volatile String s; @Override public void public_x(String s) { this.s = s; } @Override void protected_x(String s) { this.s = s; } @Override void package_x(String s) { this.s = s; } } static final MethodHandle A_PUBLIC_X; static final MethodHandle A_PROTECTED_X; static final MethodHandle A_PACKAGE_X; static final MethodHandle A_PACKAGE_FINAL_X; static { try { A_PUBLIC_X = MethodHandles.lookup().findVirtual( A.class, "public_x", MethodType.methodType(void.class, String.class)); A_PROTECTED_X = MethodHandles.lookup().findVirtual( A.class, "protected_x", MethodType.methodType(void.class, String.class)); A_PACKAGE_X = MethodHandles.lookup().findVirtual( A.class, "package_x", MethodType.methodType(void.class, String.class)); A_PACKAGE_FINAL_X = MethodHandles.lookup().findVirtual( A.class, "package_final_x", MethodType.methodType(void.class, String.class)); } catch (Exception e) { throw new Error(e); } } static final A a = new B(); public static void main(String[] args) { for (int i = 0; i < 1000_0000; i++) { testPublicMH("X"); } for (int i = 0; i < 1000_0000; i++) { testProtectedMH("X"); } for (int i = 0; i < 1000_0000; i++) { testPackageMH("X"); } for (int i = 0; i < 1000_0000; i++) { testPackageFinalMH("X"); } for (int i = 0; i < 1000_0000; i++) { testPackage("X"); } System.out.println("END"); } private static void testPublicMH(String x) { try { A_PUBLIC_X.invokeExact(a, x); } catch (Throwable throwable) { throw new Error(throwable); } } private static void testProtectedMH(String x) { try { A_PROTECTED_X.invokeExact(a, x); } catch (Throwable throwable) { throw new Error(throwable); } } private static void testPackageMH(String x) { try { A_PACKAGE_X.invokeExact(a, x); } catch (Throwable throwable) { throw new Error(throwable); } } private static void testPackageFinalMH(String x) { try { A_PACKAGE_FINAL_X.invokeExact(a, x); } catch (Throwable throwable) { throw new Error(throwable); } } private static void testPackage(String x) { a.package_x(x); } } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.kozlov at oracle.com Fri Oct 24 21:35:30 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Oct 2014 14:35:30 -0700 Subject: RFR(S) 8059200: Promoted JDK9 b31 for Solaris-amd64 fails (Error: dl failure on line 744, no picl library) on Solaris 11.1 In-Reply-To: <367309D4-F682-4DB2-8412-F92D4304F268@oracle.com> References: <367309D4-F682-4DB2-8412-F92D4304F268@oracle.com> Message-ID: <544AC622.3050402@oracle.com> Wow! Real dynamic execution! The code is good. I think the warning is fine here - we are already warning about kstat information and nobody complained. But I would rephrase it: "PICL (libpicl.so.1) is missed. The performance will not be optimal.") Thank, Vladimir On 10/24/14 1:48 PM, Igor Veresov wrote: > People are running into problems with PICL on Solaris. First of all we linked with libpicl on x86 and we shouldn?t because it?s not really require here. Secondly, in some situations (like Solaris zones) PICL is not installed by default. Nevertheless it remains the only reasonable way to determine cache line sizes on SPARC (which we need to properly use BIS instructions), so we?d like to keep using it. The only solution I see is to link manually and display a warning if PICL is not installed. > > Webrev: http://cr.openjdk.java.net/~iveresov/8059200/webrev.00/ > > igor > From vladimir.kozlov at oracle.com Fri Oct 24 21:57:39 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Oct 2014 14:57:39 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> Message-ID: <544ACB53.5050700@oracle.com> On 10/23/14 3:45 AM, Paul Sandoz wrote: > Hi Vladimir, > > Do you consider these two aspects (intrinsic and inline) closely interrelated do as to be considered under the same issue? If not i can log another issue for the inlining. I am working on next version of my intrinsic after discussion with John Rose. It will use gen_checkcast() code which we use for checkcast bytecode. It will be more general code and less dependable on inlining. But I still want to do force inlining Call.cast() in more general case when we can still use profiling data. I am concern about changes in castReference() to use Class.cast(). It will need additional performance testing because it was big performance bottleneck for jsr292. And I don't want to cause regression. Thanks, Vladimir > > Paul. > > On Oct 23, 2014, at 7:09 AM, Vladimir Kozlov wrote: > >> On 10/22/14 2:29 AM, Paul Sandoz wrote: >>> On Oct 22, 2014, at 10:54 AM, Roland Westrelin wrote: >>>>> Here is intrinsic implementation: >>>>> >>>>> http://cr.openjdk.java.net/~kvn/8054492/webrev.01/ >>>> >>>> That looks good to me. >>>> >>> Same here. >>> >>> On Oct 22, 2014, at 2:02 AM, Vladimir Kozlov wrote: >>>> Paul, is it enough for you? >>>> >>> >>> Yes, many thanks. I verified in a number of scenarios. >>> >>> With Class.cast intrinsified can we can replace uses of following method in j.l.i.MethodHandleImpl with Class.cast? >> >> Intrinsic is not enough. That code was added because we do not inline Class.cast() for deep call stacks. C2 has inline depth limit 9. But we can workaround using next changes: >> >> --- a/src/share/vm/opto/bytecodeInfo.cpp Fri Aug 22 09:55:49 2014 -0700 >> +++ b/src/share/vm/opto/bytecodeInfo.cpp Wed Oct 22 22:07:21 2014 -0700 >> @@ -161,6 +161,7 @@ >> if ((freq >= InlineFrequencyRatio) || >> (call_site_count >= InlineFrequencyCount) || >> is_unboxing_method(callee_method, C) || >> + (callee_method->intrinsic_id() == vmIntrinsics::_class_cast) || >> is_init_with_ea(callee_method, caller_method, C)) { >> >> max_inline_size = C->freq_inline_size(); >> @@ -262,6 +263,11 @@ >> return false; >> } >> >> + if (callee_method->intrinsic_id() == vmIntrinsics::_class_cast) { >> + // Inline Class.cast() method. >> + return false; >> + } >> + >> if (callee_method->has_compiled_code() && >> callee_method->instructions_size() > InlineSmallCode) { >> set_msg("already compiled into a big method"); >> >> >> Thanks, >> Vladimir >> >>> >>> @ForceInline >>> @SuppressWarnings("unchecked") >>> static T castReference(Class t, U x) { >>> // inlined Class.cast because we can't ForceInline it >>> if (x != null && !t.isInstance(x)) >>> throw newClassCastException(t, x); >>> return (T) x; >>> } >>> >>> Paul. >>> > From vladimir.x.ivanov at oracle.com Fri Oct 24 22:00:36 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 25 Oct 2014 02:00:36 +0400 Subject: MH inlining fails for a package-private and protected calls In-Reply-To: <71AB5B0F-61AC-443F-9556-662BF29B0941@oracle.com> References: <71AB5B0F-61AC-443F-9556-662BF29B0941@oracle.com> Message-ID: <544ACC04.2090606@oracle.com> Paul, Accessibility is not a problem. The reason is profile pollution, since DMH bytecode is shared: * MHInlineTest::testPublicMH @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes) force inline by annotation * MHInlineTest::testProtectedMH (24 bytes) inline (hot) @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes) force inline by annotation * MHInlineTest::testPackageMH (24 bytes) inline (hot) @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes) force inline by annotation If you reorder the tests or mix then, inlining behavior will change. Don't know why LambdaForm is different for testPackageFinalMH case. I'll look into this on Monday. Best regards, Vladimir Ivanov On 10/25/14, 12:52 AM, Paul Sandoz wrote: > Hi, > > I am observing that inlining of a MH invocation to a package private method fails. > > Below is a simple test that test MHs to a public, package-private and protected methods. > > Using the tip of JDK 9 with "java -XX:-TieredCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining MHInlineTest" produces the following: > > ! @ 10 MHInlineTest::testPublicMH (24 bytes) inline (hot) > @ 7 java.lang.invoke.LambdaForm$MH/314265080::invokeExact_MT (17 bytes) force inline by annotation > @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by annotation > @ 11 java.lang.invoke.MethodHandle::type (5 bytes) accessor > @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes) force inline by annotation > @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation > @ 11 MHInlineTest$B::public_x (6 bytes) inline (hot) > > ! @ 29 MHInlineTest::testProtectedMH (24 bytes) inline (hot) > @ 7 java.lang.invoke.LambdaForm$MH/314265080::invokeExact_MT (17 bytes) force inline by annotation > @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by annotation > @ 11 java.lang.invoke.MethodHandle::type (5 bytes) accessor > @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes) force inline by annotation > @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation > @ 11 MHInlineTest$A::protected_x (6 bytes) virtual call > > ! @ 48 MHInlineTest::testPackageMH (24 bytes) inline (hot) > @ 7 java.lang.invoke.LambdaForm$MH/314265080::invokeExact_MT (17 bytes) force inline by annotation > @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by annotation > @ 11 java.lang.invoke.MethodHandle::type (5 bytes) accessor > @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes) force inline by annotation > @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation > @ 11 MHInlineTest$A::package_x (6 bytes) virtual call > > ! @ 67 MHInlineTest::testPackageFinalMH (24 bytes) inline (hot) > @ 7 java.lang.invoke.LambdaForm$MH/314265080::invokeExact_MT (17 bytes) force inline by annotation > @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by annotation > @ 11 java.lang.invoke.MethodHandle::type (5 bytes) accessor > @ 13 java.lang.invoke.LambdaForm$DMH/344560770::invokeSpecial_LL_V (15 bytes) force inline by annotation > @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation > @ 11 MHInlineTest$A::package_final_x (6 bytes) inline (hot) > > @ 86 MHInlineTest::testPackage (8 bytes) inline (hot) > @ 4 MHInlineTest$B::package_x (6 bytes) inline (hot) > > Note that: > > - inlining bails out for the MH to the package-private and and protected method, but does not bail out for an explicit package-protected call. > > - the same LambdaForms are used for all virtual invocations. > > Is that the expected behaviour? > > Paul. > > public class MHInlineTest { > > public static class A { > volatile String s; > > public void public_x(String s) { > this.s = s; > } > > void protected_x(String s) { > this.s = s; > } > > void package_x(String s) { > this.s = s; > } > > final void package_final_x(String s) { > this.s = s; > } > } > > public static final class B extends A { > volatile String s; > > @Override > public void public_x(String s) { > this.s = s; > } > > @Override > void protected_x(String s) { > this.s = s; > } > > @Override > void package_x(String s) { > this.s = s; > } > } > > static final MethodHandle A_PUBLIC_X; > static final MethodHandle A_PROTECTED_X; > static final MethodHandle A_PACKAGE_X; > static final MethodHandle A_PACKAGE_FINAL_X; > > static { > try { > A_PUBLIC_X = MethodHandles.lookup().findVirtual( > A.class, "public_x", MethodType.methodType(void.class, String.class)); > A_PROTECTED_X = MethodHandles.lookup().findVirtual( > A.class, "protected_x", MethodType.methodType(void.class, String.class)); > A_PACKAGE_X = MethodHandles.lookup().findVirtual( > A.class, "package_x", MethodType.methodType(void.class, String.class)); > A_PACKAGE_FINAL_X = MethodHandles.lookup().findVirtual( > A.class, "package_final_x", MethodType.methodType(void.class, String.class)); > } > catch (Exception e) { > throw new Error(e); > } > } > > static final A a = new B(); > > public static void main(String[] args) { > for (int i = 0; i < 1000_0000; i++) { > testPublicMH("X"); > } > for (int i = 0; i < 1000_0000; i++) { > testProtectedMH("X"); > } > for (int i = 0; i < 1000_0000; i++) { > testPackageMH("X"); > } > for (int i = 0; i < 1000_0000; i++) { > testPackageFinalMH("X"); > } > for (int i = 0; i < 1000_0000; i++) { > testPackage("X"); > } > System.out.println("END"); > } > > private static void testPublicMH(String x) { > try { > A_PUBLIC_X.invokeExact(a, x); > } > catch (Throwable throwable) { > throw new Error(throwable); > } > } > > private static void testProtectedMH(String x) { > try { > A_PROTECTED_X.invokeExact(a, x); > } > catch (Throwable throwable) { > throw new Error(throwable); > } > } > > private static void testPackageMH(String x) { > try { > A_PACKAGE_X.invokeExact(a, x); > } > catch (Throwable throwable) { > throw new Error(throwable); > } > } > > private static void testPackageFinalMH(String x) { > try { > A_PACKAGE_FINAL_X.invokeExact(a, x); > } > catch (Throwable throwable) { > throw new Error(throwable); > } > } > > private static void testPackage(String x) { > a.package_x(x); > } > } > From igor.veresov at oracle.com Fri Oct 24 22:09:29 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 24 Oct 2014 12:09:29 -1000 Subject: RFR(S) 8059200: Promoted JDK9 b31 for Solaris-amd64 fails (Error: dl failure on line 744, no picl library) on Solaris 11.1 In-Reply-To: <544AC622.3050402@oracle.com> References: <367309D4-F682-4DB2-8412-F92D4304F268@oracle.com> <544AC622.3050402@oracle.com> Message-ID: <9B1A23E9-7E52-4603-8F32-600FEF6B5033@oracle.com> Vladimir, Thanks for the review! I changed the warning: http://cr.openjdk.java.net/~iveresov/8059200/webrev.01/ igor On Oct 24, 2014, at 11:35 AM, Vladimir Kozlov wrote: > Wow! Real dynamic execution! The code is good. > > I think the warning is fine here - we are already warning about kstat information and nobody complained. But I would rephrase it: > > "PICL (libpicl.so.1) is missed. The performance will not be optimal.") > > Thank, > Vladimir > > On 10/24/14 1:48 PM, Igor Veresov wrote: >> People are running into problems with PICL on Solaris. First of all we linked with libpicl on x86 and we shouldn?t because it?s not really require here. Secondly, in some situations (like Solaris zones) PICL is not installed by default. Nevertheless it remains the only reasonable way to determine cache line sizes on SPARC (which we need to properly use BIS instructions), so we?d like to keep using it. The only solution I see is to link manually and display a warning if PICL is not installed. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8059200/webrev.00/ >> >> igor >> From vladimir.kozlov at oracle.com Fri Oct 24 22:23:26 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Oct 2014 15:23:26 -0700 Subject: MH inlining fails for a package-private and protected calls In-Reply-To: <544ACC04.2090606@oracle.com> References: <71AB5B0F-61AC-443F-9556-662BF29B0941@oracle.com> <544ACC04.2090606@oracle.com> Message-ID: <544AD15E.5040809@oracle.com> Does it have > 2 types in profiling? If it is only 2 we should be able to do bi-morphic inlining. Vladimir K On 10/24/14 3:00 PM, Vladimir Ivanov wrote: > Paul, > > Accessibility is not a problem. The reason is profile pollution, since > DMH bytecode is shared: > * MHInlineTest::testPublicMH > @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 > bytes) force inline by annotation > > * MHInlineTest::testProtectedMH (24 bytes) inline (hot) > @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 > bytes) force inline by annotation > > * MHInlineTest::testPackageMH (24 bytes) inline (hot) > > @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 > bytes) force inline by annotation > > If you reorder the tests or mix then, inlining behavior will change. > > Don't know why LambdaForm is different for testPackageFinalMH case. > > I'll look into this on Monday. > > Best regards, > Vladimir Ivanov > > On 10/25/14, 12:52 AM, Paul Sandoz wrote: >> Hi, >> >> I am observing that inlining of a MH invocation to a package private >> method fails. >> >> Below is a simple test that test MHs to a public, package-private and >> protected methods. >> >> Using the tip of JDK 9 with "java -XX:-TieredCompilation >> -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining MHInlineTest" >> produces the following: >> >> ! @ 10 MHInlineTest::testPublicMH (24 >> bytes) inline (hot) >> @ 7 >> java.lang.invoke.LambdaForm$MH/314265080::invokeExact_MT (17 bytes) >> force inline by annotation >> @ 2 >> java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by >> annotation >> @ 11 >> java.lang.invoke.MethodHandle::type (5 bytes) accessor >> @ 13 >> java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 >> bytes) force inline by annotation >> @ 1 >> java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) >> force inline by annotation >> @ 11 MHInlineTest$B::public_x (6 >> bytes) inline (hot) >> >> ! @ 29 MHInlineTest::testProtectedMH (24 >> bytes) inline (hot) >> @ 7 >> java.lang.invoke.LambdaForm$MH/314265080::invokeExact_MT (17 bytes) >> force inline by annotation >> @ 2 >> java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by >> annotation >> @ 11 >> java.lang.invoke.MethodHandle::type (5 bytes) accessor >> @ 13 >> java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 >> bytes) force inline by annotation >> @ 1 >> java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) >> force inline by annotation >> @ 11 MHInlineTest$A::protected_x >> (6 bytes) virtual call >> >> ! @ 48 MHInlineTest::testPackageMH (24 >> bytes) inline (hot) >> @ 7 >> java.lang.invoke.LambdaForm$MH/314265080::invokeExact_MT (17 bytes) >> force inline by annotation >> @ 2 >> java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by >> annotation >> @ 11 >> java.lang.invoke.MethodHandle::type (5 bytes) accessor >> @ 13 >> java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 >> bytes) force inline by annotation >> @ 1 >> java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) >> force inline by annotation >> @ 11 MHInlineTest$A::package_x (6 >> bytes) virtual call >> >> ! @ 67 MHInlineTest::testPackageFinalMH >> (24 bytes) inline (hot) >> @ 7 >> java.lang.invoke.LambdaForm$MH/314265080::invokeExact_MT (17 bytes) >> force inline by annotation >> @ 2 >> java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by >> annotation >> @ 11 >> java.lang.invoke.MethodHandle::type (5 bytes) accessor >> @ 13 >> java.lang.invoke.LambdaForm$DMH/344560770::invokeSpecial_LL_V (15 >> bytes) force inline by annotation >> @ 1 >> java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) >> force inline by annotation >> @ 11 >> MHInlineTest$A::package_final_x (6 bytes) inline (hot) >> >> @ 86 MHInlineTest::testPackage (8 >> bytes) inline (hot) >> @ 4 MHInlineTest$B::package_x (6 >> bytes) inline (hot) >> >> Note that: >> >> - inlining bails out for the MH to the package-private and and >> protected method, but does not bail out for an explicit >> package-protected call. >> >> - the same LambdaForms are used for all virtual invocations. >> >> Is that the expected behaviour? >> >> Paul. >> >> public class MHInlineTest { >> >> public static class A { >> volatile String s; >> >> public void public_x(String s) { >> this.s = s; >> } >> >> void protected_x(String s) { >> this.s = s; >> } >> >> void package_x(String s) { >> this.s = s; >> } >> >> final void package_final_x(String s) { >> this.s = s; >> } >> } >> >> public static final class B extends A { >> volatile String s; >> >> @Override >> public void public_x(String s) { >> this.s = s; >> } >> >> @Override >> void protected_x(String s) { >> this.s = s; >> } >> >> @Override >> void package_x(String s) { >> this.s = s; >> } >> } >> >> static final MethodHandle A_PUBLIC_X; >> static final MethodHandle A_PROTECTED_X; >> static final MethodHandle A_PACKAGE_X; >> static final MethodHandle A_PACKAGE_FINAL_X; >> >> static { >> try { >> A_PUBLIC_X = MethodHandles.lookup().findVirtual( >> A.class, "public_x", >> MethodType.methodType(void.class, String.class)); >> A_PROTECTED_X = MethodHandles.lookup().findVirtual( >> A.class, "protected_x", >> MethodType.methodType(void.class, String.class)); >> A_PACKAGE_X = MethodHandles.lookup().findVirtual( >> A.class, "package_x", >> MethodType.methodType(void.class, String.class)); >> A_PACKAGE_FINAL_X = MethodHandles.lookup().findVirtual( >> A.class, "package_final_x", >> MethodType.methodType(void.class, String.class)); >> } >> catch (Exception e) { >> throw new Error(e); >> } >> } >> >> static final A a = new B(); >> >> public static void main(String[] args) { >> for (int i = 0; i < 1000_0000; i++) { >> testPublicMH("X"); >> } >> for (int i = 0; i < 1000_0000; i++) { >> testProtectedMH("X"); >> } >> for (int i = 0; i < 1000_0000; i++) { >> testPackageMH("X"); >> } >> for (int i = 0; i < 1000_0000; i++) { >> testPackageFinalMH("X"); >> } >> for (int i = 0; i < 1000_0000; i++) { >> testPackage("X"); >> } >> System.out.println("END"); >> } >> >> private static void testPublicMH(String x) { >> try { >> A_PUBLIC_X.invokeExact(a, x); >> } >> catch (Throwable throwable) { >> throw new Error(throwable); >> } >> } >> >> private static void testProtectedMH(String x) { >> try { >> A_PROTECTED_X.invokeExact(a, x); >> } >> catch (Throwable throwable) { >> throw new Error(throwable); >> } >> } >> >> private static void testPackageMH(String x) { >> try { >> A_PACKAGE_X.invokeExact(a, x); >> } >> catch (Throwable throwable) { >> throw new Error(throwable); >> } >> } >> >> private static void testPackageFinalMH(String x) { >> try { >> A_PACKAGE_FINAL_X.invokeExact(a, x); >> } >> catch (Throwable throwable) { >> throw new Error(throwable); >> } >> } >> >> private static void testPackage(String x) { >> a.package_x(x); >> } >> } >> From vladimir.kozlov at oracle.com Fri Oct 24 22:24:18 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Oct 2014 15:24:18 -0700 Subject: RFR(S) 8059200: Promoted JDK9 b31 for Solaris-amd64 fails (Error: dl failure on line 744, no picl library) on Solaris 11.1 In-Reply-To: <9B1A23E9-7E52-4603-8F32-600FEF6B5033@oracle.com> References: <367309D4-F682-4DB2-8412-F92D4304F268@oracle.com> <544AC622.3050402@oracle.com> <9B1A23E9-7E52-4603-8F32-600FEF6B5033@oracle.com> Message-ID: <544AD192.40002@oracle.com> Good. Thanks, Vladimir On 10/24/14 3:09 PM, Igor Veresov wrote: > Vladimir, > > Thanks for the review! > > I changed the warning: http://cr.openjdk.java.net/~iveresov/8059200/webrev.01/ > > igor > > On Oct 24, 2014, at 11:35 AM, Vladimir Kozlov wrote: > >> Wow! Real dynamic execution! The code is good. >> >> I think the warning is fine here - we are already warning about kstat information and nobody complained. But I would rephrase it: >> >> "PICL (libpicl.so.1) is missed. The performance will not be optimal.") >> >> Thank, >> Vladimir >> >> On 10/24/14 1:48 PM, Igor Veresov wrote: >>> People are running into problems with PICL on Solaris. First of all we linked with libpicl on x86 and we shouldn?t because it?s not really require here. Secondly, in some situations (like Solaris zones) PICL is not installed by default. Nevertheless it remains the only reasonable way to determine cache line sizes on SPARC (which we need to properly use BIS instructions), so we?d like to keep using it. The only solution I see is to link manually and display a warning if PICL is not installed. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8059200/webrev.00/ >>> >>> igor >>> > From tobias.hartmann at oracle.com Mon Oct 27 06:04:52 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Oct 2014 07:04:52 +0100 Subject: [9] RFR(S): 8061983: [TESTBUG] compiler/whitebox/MakeMethodNotCompilableTest.java fails with "must not be in queue" In-Reply-To: <544A7D8E.1000408@oracle.com> References: <544A4C12.4060506@oracle.com> <544A7D8E.1000408@oracle.com> Message-ID: <544DE084.5000308@oracle.com> Thanks, Vladimir. Best, Tobias On 24.10.2014 18:25, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/24/14 5:54 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8061983 >> Webrev: http://cr.openjdk.java.net/~thartmann/8061983/webrev.00/ >> >> Problem: >> In the failing case, the test makes a method not OSR compilable and tries to >> trigger an OSR compilation. 'checkNotOsrCompiled' then fails because a (non-OSR) >> compilation is in the compile queue. The test should not assume triggering an >> OSR compilation of a method may not also trigger a non-OSR compilation. >> >> Solution: >> I added a method checkNotCompiled(boolean isOsr) to either check if the method >> is OSR compiled or to check if it is non-OSR compiled. The method waits for >> background compilation and then checks. >> >> Testing: >> Failing testcase with different parameters. >> >> Best, >> Tobias >> From nils.eliasson at oracle.com Mon Oct 27 14:01:44 2014 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 27 Oct 2014 15:01:44 +0100 Subject: RFR(S): 8061250: serviceability/dcmd/compiler/CompilerQueueTest.java failed Message-ID: <544E5048.6050907@oracle.com> Hi, Please review this change. There was a small difference in logging depending on whether tiered was on or off. This made the parsing in the test fail. This problem was not caught earlier by a few reasons: 1) We don't run the testing with a client VM very often 2) Running server with tiered off don't compile much and the queue is mostly empty 3) When runnning with Xcomp compilation is synchronous so the queue is always empty The change includes a small fix for consistent logging indentation regardless of tiering, and adding a non-tiered test-case. Bug: https://bugs.openjdk.java.net/browse/JDK-8061250 Rev: file:///home/neliasso/repos/jdk9_hs-comp/hotspot/8061250/webrev.02/index.html Thanks, Nils From tobias.hartmann at oracle.com Mon Oct 27 14:45:30 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Oct 2014 15:45:30 +0100 Subject: [9] RFR(S): 8061817: Whitebox.deoptimizeMethod() does not deoptimize all OSR versions of method In-Reply-To: <544A4EBE.7090103@oracle.com> References: <544A487A.5080008@oracle.com> <544A4EBE.7090103@oracle.com> Message-ID: <544E5A8A.1060800@oracle.com> Hi Igor, thanks for the review. On 24.10.2014 15:06, Igor Ignatyev wrote: > Hi Tobias, > > DeoptimizeMultipleOSRTest: > 1. could you please make 'method' an instance field? Done. > 2. use AssertionError instead of RuntimeException Done. > 3. have you tried to run this test w/ Xcomp? Yes, it works fine (OSR compilations are still triggered and deoptimized). However, I found another bug and filed 8062169. New webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.01/ Thanks, Tobias > > Thanks, > Igor > > On 10/24/2014 04:39 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8061817 >> Webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.00/ >> >> Problem >> 'WhiteBox.deoptimizeMethod' does not deoptimize all OSR compiled versions of the >> given method but only one. The problem lies in'WB_DeoptimizeMethod'. The call to >> 'lookup_osr_nmethod_for' only returns the best fitting OSR nmethod. Incrementing >> the bci (see line 395) does not help. >> >> Solution >> I changed the implementation to deoptimize all OSR versions and added a >> regression test that triggers two OSR compilations and checks that both are >> deoptimized ('DeoptimizeMultipleOSRTest'). >> >> Testing >> New test on JPRT >> >> Best, >> Tobias >> From vladimir.kozlov at oracle.com Mon Oct 27 16:40:20 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Oct 2014 09:40:20 -0700 Subject: [9] RFR(S): 8061817: Whitebox.deoptimizeMethod() does not deoptimize all OSR versions of method In-Reply-To: <544E5A8A.1060800@oracle.com> References: <544A487A.5080008@oracle.com> <544A4EBE.7090103@oracle.com> <544E5A8A.1060800@oracle.com> Message-ID: <544E7574.6050005@oracle.com> Hi Tobias, I don't like adding deoptimization checks inside lookup method which have nothing to do with deoptimization. I would suggest to add new method InstanceKlass::mark_osr_nmethods() to mark all related OSRs. We have already InstanceKlass::mark_dependent_nmethods() but it could be not applicable to all our tests if they don't record dependencies during OSR compilation. Regards, Vladimir On 10/27/14 7:45 AM, Tobias Hartmann wrote: > Hi Igor, > > thanks for the review. > > On 24.10.2014 15:06, Igor Ignatyev wrote: >> Hi Tobias, >> >> DeoptimizeMultipleOSRTest: >> 1. could you please make 'method' an instance field? > > Done. > >> 2. use AssertionError instead of RuntimeException > > Done. > >> 3. have you tried to run this test w/ Xcomp? > > Yes, it works fine (OSR compilations are still triggered and deoptimized). > However, I found another bug and filed 8062169. > > New webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.01/ > > Thanks, > Tobias > >> >> Thanks, >> Igor >> >> On 10/24/2014 04:39 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061817 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.00/ >>> >>> Problem >>> 'WhiteBox.deoptimizeMethod' does not deoptimize all OSR compiled versions of the >>> given method but only one. The problem lies in'WB_DeoptimizeMethod'. The call to >>> 'lookup_osr_nmethod_for' only returns the best fitting OSR nmethod. Incrementing >>> the bci (see line 395) does not help. >>> >>> Solution >>> I changed the implementation to deoptimize all OSR versions and added a >>> regression test that triggers two OSR compilations and checks that both are >>> deoptimized ('DeoptimizeMultipleOSRTest'). >>> >>> Testing >>> New test on JPRT >>> >>> Best, >>> Tobias >>> From christian.thalinger at oracle.com Mon Oct 27 16:46:40 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Oct 2014 09:46:40 -0700 Subject: RFR(S): 8061250: serviceability/dcmd/compiler/CompilerQueueTest.java failed In-Reply-To: <544E5048.6050907@oracle.com> References: <544E5048.6050907@oracle.com> Message-ID: <5A97F6BA-BEBE-46BB-A681-23F0C281D3CB@oracle.com> > On Oct 27, 2014, at 7:01 AM, Nils Eliasson wrote: > > Hi, > > Please review this change. > > There was a small difference in logging depending on whether tiered was on or off. This made the parsing in the test fail. This problem was not caught earlier by a few reasons: > > 1) We don't run the testing with a client VM very often > 2) Running server with tiered off don't compile much and the queue is mostly empty > 3) When runnning with Xcomp compilation is synchronous so the queue is always empty > > The change includes a small fix for consistent logging indentation regardless of tiering, and adding a non-tiered test-case. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061250 > Rev: file:///home/neliasso/repos/jdk9_hs-comp/hotspot/8061250/webrev.02/index.html WEB-rev: http://cr.openjdk.java.net/~neliasso/8061250/webrev.02/ ;-) > > Thanks, > Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.thalinger at oracle.com Mon Oct 27 16:48:39 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 27 Oct 2014 09:48:39 -0700 Subject: RFR(S): 8061250: serviceability/dcmd/compiler/CompilerQueueTest.java failed In-Reply-To: <5A97F6BA-BEBE-46BB-A681-23F0C281D3CB@oracle.com> References: <544E5048.6050907@oracle.com> <5A97F6BA-BEBE-46BB-A681-23F0C281D3CB@oracle.com> Message-ID: <0D8243B5-3ACA-4A5A-8E3F-209664CADF10@oracle.com> Looks good except the indent is a bit off: + } else { + st->print(" "); } > On Oct 27, 2014, at 9:46 AM, Christian Thalinger wrote: > >> >> On Oct 27, 2014, at 7:01 AM, Nils Eliasson > wrote: >> >> Hi, >> >> Please review this change. >> >> There was a small difference in logging depending on whether tiered was on or off. This made the parsing in the test fail. This problem was not caught earlier by a few reasons: >> >> 1) We don't run the testing with a client VM very often >> 2) Running server with tiered off don't compile much and the queue is mostly empty >> 3) When runnning with Xcomp compilation is synchronous so the queue is always empty >> >> The change includes a small fix for consistent logging indentation regardless of tiering, and adding a non-tiered test-case. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8061250 >> Rev: file:///home/neliasso/repos/jdk9_hs-comp/hotspot/8061250/webrev.02/index.html > > WEB-rev: http://cr.openjdk.java.net/~neliasso/8061250/webrev.02/ > > ;-) > >> >> Thanks, >> Nils -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Oct 27 17:02:49 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Oct 2014 10:02:49 -0700 Subject: RFR(S): 8061250: serviceability/dcmd/compiler/CompilerQueueTest.java failed In-Reply-To: <544E5048.6050907@oracle.com> References: <544E5048.6050907@oracle.com> Message-ID: <544E7AB9.6090200@oracle.com> Correct webrev link: http://cr.openjdk.java.net/~neliasso/8061250/webrev.02/ Hi Nils, Indention of changed code is incorrect in compileBroker.cpp. Output parser should not relay on particular spacing in output. Is it hard to fix? I am not comfortable that you changing output of non-tiered code just to workaround a problem in a tool. Do you think we should also test only C1 compilation when Tiered is enabled?: -XX:+TieredCompilation -XX:TieredStopAtLevel=1 Thanks, Vladimir On 10/27/14 7:01 AM, Nils Eliasson wrote: > Hi, > > Please review this change. > > There was a small difference in logging depending on whether tiered was > on or off. This made the parsing in the test fail. This problem was not > caught earlier by a few reasons: > > 1) We don't run the testing with a client VM very often > 2) Running server with tiered off don't compile much and the queue is > mostly empty > 3) When runnning with Xcomp compilation is synchronous so the queue is > always empty > > The change includes a small fix for consistent logging indentation > regardless of tiering, and adding a non-tiered test-case. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8061250 > Rev: > file:///home/neliasso/repos/jdk9_hs-comp/hotspot/8061250/webrev.02/index.html > > > Thanks, > Nils From paul.sandoz at oracle.com Mon Oct 27 17:23:30 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 27 Oct 2014 18:23:30 +0100 Subject: MH inlining fails for a package-private and protected calls In-Reply-To: <544ACC04.2090606@oracle.com> References: <71AB5B0F-61AC-443F-9556-662BF29B0941@oracle.com> <544ACC04.2090606@oracle.com> Message-ID: On Oct 25, 2014, at 12:00 AM, Vladimir Ivanov wrote: > Paul, > > Accessibility is not a problem. The reason is profile pollution, since > DMH bytecode is shared: > * MHInlineTest::testPublicMH > @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes) force inline by annotation > > * MHInlineTest::testProtectedMH (24 bytes) inline (hot) > @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes) force inline by annotation > > * MHInlineTest::testPackageMH (24 bytes) inline (hot) > > @ 13 java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes) force inline by annotation > > If you reorder the tests or mix then, inlining behavior will change. > > Don't know why LambdaForm is different for testPackageFinalMH case. > I presume because it is a final method and linkToSpecial can be used instead? Perhaps my example is a little misleading regarding profile pollution. FWIW i could not get any indication from the inlining or method data output that profiling was an issue. See below for a simpler case that just calls a package-private method on a static final instance of A: ! @ 10 MHInlineSimpleTest::testPackageMH (24 bytes) inline (hot) @ 7 java.lang.invoke.LambdaForm$MH/708049632::invokeExact_MT (17 bytes) force inline by annotation @ 2 java.lang.invoke.Invokers::checkExactType (30 bytes) force inline by annotation @ 11 java.lang.invoke.MethodHandle::type (5 bytes) accessor @ 13 java.lang.invoke.LambdaForm$DMH/385242642::invokeVirtual_LL_V (15 bytes) force inline by annotation @ 1 java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes) force inline by annotation @ 11 MHInlineSimpleTest$A::package_x (6 bytes) virtual call @ 4 MHInlineSimpleTest$A::package_x (6 bytes) inline (hot) @ 29 MHInlineSimpleTest::testPackage (8 bytes) inline (hot) @ 4 MHInlineSimpleTest$A::package_x (6 bytes) inline (hot) This appears to indicate there is something more fundamental going on. Is there some information lost when unpacking the underlying method characterized by member name passed to MH.linkToVirtual? AFAICT an access control check fails for the lambda form to access the protected method when attempting to inline the method handle. > I'll look into this on Monday. > Thanks, Paul. import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.lang.invoke.MethodType; public class MHInlineSimpleTest { public static class A { volatile String s; void package_x(String s) { this.s = s; } } static final MethodHandle A_PACKAGE_X; static { try { A_PACKAGE_X = MethodHandles.lookup().in(A.class).findVirtual( A.class, "package_x", MethodType.methodType(void.class, String.class)); } catch (Exception e) { throw new Error(e); } } static final A a = new A(); public static void main(String[] args) { for (int i = 0; i < 1000_0000; i++) { testPackageMH("X"); } for (int i = 0; i < 1000_0000; i++) { testPackage("X"); } System.out.println("END"); } private static void testPackageMH(String x) { try { A_PACKAGE_X.invokeExact(a, x); } catch (Throwable throwable) { throw new Error(throwable); } } private static void testPackage(String x) { a.package_x(x); } } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tobias.hartmann at oracle.com Tue Oct 28 08:54:02 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Oct 2014 09:54:02 +0100 Subject: [9] RFR(S): 8062250: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java fails after CodeCacheMinimumFreeSpace removal Message-ID: <544F59AA.8050604@oracle.com> Hi, please review the following patch that fixes the test 'compiler/codecache/CheckSegmentedCodeCache.java' after JDK-8046809 removed the CodeCacheMinimumFreeSpace VM flag. As Vladimir K. suggested, I also added the test to JPRT. Bug: https://bugs.openjdk.java.net/browse/JDK-8062250 Webrev: http://cr.openjdk.java.net/~thartmann/8062250/webrev.00/ Thanks, Tobias From roland.westrelin at oracle.com Tue Oct 28 09:18:59 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 28 Oct 2014 10:18:59 +0100 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: <71726E40-F4AF-43A4-A213-1A60F5687AB0@oracle.com> References: <5436E2C3.7060008@oracle.com> <5436FCF6.7080309@oracle.com> <543814CC.2080905@oracle.com> <5C32D21B-9A72-4367-A5F7-3C4FB2326FE0@oracle.com> <543833F6.5050002@oracle.com> <71726E40-F4AF-43A4-A213-1A60F5687AB0@oracle.com> Message-ID: <025487DA-04CA-49BB-885C-39446D0C9BF7@oracle.com> Anyone else for this review? Roland. > On Oct 23, 2014, at 1:50 PM, Roland Westrelin wrote: > > Vladimir, > > Here is a new webrev that takes your comments into account: > > http://cr.openjdk.java.net/~roland/6700100/webrev.01/ > > I moved the ik->has_injected_fields() call last in ArrayCopyNode::get_count() and added a comment. > > I improved the code in fieldStreams.hpp > > LibraryCallKit::inline_arraycopy() had what turned out to be the fix for JDK-8060252 (performance regression on sparc). I removed it so it can be pushed as a separate fix. > > Roland. > > >> On Oct 10, 2014, at 9:31 PM, Vladimir Kozlov wrote: >> >> I was thinking aloud :) >> >> Changes are good as it is. Thank you for discussion. >> >> Thanks, >> Vladimir >> >> On 10/10/14 10:47 AM, Roland Westrelin wrote: >>>>> If we wanted to delay that transformation, wouldn?t we also want a few passes of IGVN to happen before we do the transformation? >>>> >>>> The thing which can be improved is klass exactness. Which will allow to skip adding dependency. That is what I was thinking. But it may only happen after CCP phase. But I really want to do this optimization before EA which will greatly benefit from it. Also if klass is exact during parsing we may do optimization during parsing too. >>> >>> Ok. But I?m not sure if you?re suggesting a change or if it?s good as it is? >>> >>> Roland. >>> > From paul.sandoz at oracle.com Tue Oct 28 09:25:40 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 28 Oct 2014 10:25:40 +0100 Subject: MH inlining fails for a package-private and protected calls In-Reply-To: References: <71AB5B0F-61AC-443F-9556-662BF29B0941@oracle.com> <544ACC04.2090606@oracle.com> Message-ID: <5FD6D13B-75B9-4A43-93AA-EB208C5C73C0@oracle.com> On Oct 27, 2014, at 6:23 PM, Paul Sandoz wrote: > AFAICT an access control check fails for the lambda form to access the protected method when attempting to inline the method handle. > FWIW below is a hacky patch that makes the inlining work, the intent being just to highlight the access control area. I don't quite know what the proper fix should be. The Compile::optimize_inlining method attempts to find the mono morphic target, which in turn needs to resolve the method in the context of the calling class via LinkResolver::resolve_virtual_call_or_null, and that fails. If the method is private then Compile::optimize_inlining skips such checks because the method can be statically bound. Paul. diff -r b1c2dd843f24 src/share/vm/interpreter/linkResolver.cpp --- a/src/share/vm/interpreter/linkResolver.cpp Fri Oct 24 12:32:53 2014 +0400 +++ b/src/share/vm/interpreter/linkResolver.cpp Tue Oct 28 10:12:48 2014 +0100 @@ -472,6 +472,33 @@ } // assert(extra_arg_result_or_null != NULL, "must be able to return extra argument"); + { + InstanceKlass* inst = InstanceKlass::cast(ref_klass()); + if (inst->is_anonymous()) { + Klass* host_klass = inst->host_klass(); + if (host_klass == SystemDictionary::LambdaForm_klass()) { + +#ifndef PRODUCT + if (PrintOpto && (Verbose || WizardMode)) { + tty->print_cr("Host class of reference class is LambdaForm"); + tty->print_cr("LinkResolver::check_method_accessability access to method %s.%s%s from class %s, with resolved class %s\n", + sel_klass->external_name(), + sel_method->name()->as_C_string(), + sel_method->signature()->as_C_string(), + ref_klass->external_name(), + resolved_klass->external_name() + ); + } +#endif + + jint new_flags = flags.as_int(); + new_flags = new_flags & (~JVM_ACC_PROTECTED); + new_flags = new_flags | JVM_ACC_PUBLIC; + flags.set_flags(new_flags); + } + } + } + if (!Reflection::verify_field_access(ref_klass(), resolved_klass(), sel_klass(), diff -r b1c2dd843f24 src/share/vm/opto/callGenerator.cpp --- a/src/share/vm/opto/callGenerator.cpp Fri Oct 24 12:32:53 2014 +0400 +++ b/src/share/vm/opto/callGenerator.cpp Tue Oct 28 10:12:48 2014 +0100 @@ -822,6 +822,19 @@ case vmIntrinsics::_linkToSpecial: case vmIntrinsics::_linkToInterface: { + +#ifndef PRODUCT + if (PrintOpto && (Verbose || WizardMode)) { + tty->print_cr("CallGenerator::for_method_handle_inline"); + tty->print(" Caller: "); + caller->print_name(); + tty->cr(); + tty->print(" Callee: "); + callee->print_name(); + tty->cr(); + } +#endif + // Get MemberName argument: Node* member_name = kit.argument(callee->arg_size() - 1); if (member_name->Opcode() == Op_ConP) { -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From albert.noll at oracle.com Tue Oct 28 09:39:33 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 28 Oct 2014 10:39:33 +0100 Subject: [9] RFR(S): 8062250: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java fails after CodeCacheMinimumFreeSpace removal In-Reply-To: <544F59AA.8050604@oracle.com> References: <544F59AA.8050604@oracle.com> Message-ID: <544F6455.8000109@oracle.com> Looks good (not a Reviewer). Thanks for taking are of this. Best, Albert On 10/28/2014 09:54 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that fixes the test > 'compiler/codecache/CheckSegmentedCodeCache.java' after JDK-8046809 removed the > CodeCacheMinimumFreeSpace VM flag. As Vladimir K. suggested, I also added the > test to JPRT. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8062250 > Webrev: http://cr.openjdk.java.net/~thartmann/8062250/webrev.00/ > > Thanks, > Tobias From aleksey.shipilev at oracle.com Tue Oct 28 09:53:40 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 28 Oct 2014 12:53:40 +0300 Subject: RFR(M): 6700100: optimize inline_native_clone() for small objects with exact klass In-Reply-To: <025487DA-04CA-49BB-885C-39446D0C9BF7@oracle.com> References: <5436E2C3.7060008@oracle.com> <5436FCF6.7080309@oracle.com> <543814CC.2080905@oracle.com> <5C32D21B-9A72-4367-A5F7-3C4FB2326FE0@oracle.com> <543833F6.5050002@oracle.com> <71726E40-F4AF-43A4-A213-1A60F5687AB0@oracle.com> <025487DA-04CA-49BB-885C-39446D0C9BF7@oracle.com> Message-ID: <544F67A4.3060801@oracle.com> On 10/28/2014 12:18 PM, Roland Westrelin wrote: > Anyone else for this review? > > Roland. > > >> On Oct 23, 2014, at 1:50 PM, Roland Westrelin wrote: >> >> Vladimir, >> >> Here is a new webrev that takes your comments into account: >> >> http://cr.openjdk.java.net/~roland/6700100/webrev.01/ No red flags from me. A minor pet peeve about the code style in Hotspot, which adds up to accidental code complexity: pro-actively blowing up more methods than required to solve the task at hand. This change provides the example: both compute_injected_fields() and has_injected_fields() do dances around _has_injected_fields value. It would seem more readable to just have has_injected_fields() to lazily compute the value on demand, inlining both compute_injected_fields() and compute_injected_fields_helper(). That would spare two additional methods, and make the code generally more readable, and maintainable. Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From tobias.hartmann at oracle.com Tue Oct 28 11:42:17 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Oct 2014 12:42:17 +0100 Subject: [9] RFR(S): 8062250: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java fails after CodeCacheMinimumFreeSpace removal In-Reply-To: <544F6455.8000109@oracle.com> References: <544F59AA.8050604@oracle.com> <544F6455.8000109@oracle.com> Message-ID: <544F8119.1070207@oracle.com> Thanks, Albert. Best, Tobias On 28.10.2014 10:39, Albert Noll wrote: > Looks good (not a Reviewer). > > Thanks for taking are of this. > > Best, > Albert > > On 10/28/2014 09:54 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch that fixes the test >> 'compiler/codecache/CheckSegmentedCodeCache.java' after JDK-8046809 removed the >> CodeCacheMinimumFreeSpace VM flag. As Vladimir K. suggested, I also added the >> test to JPRT. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8062250 >> Webrev: http://cr.openjdk.java.net/~thartmann/8062250/webrev.00/ >> >> Thanks, >> Tobias > From vladimir.x.ivanov at oracle.com Tue Oct 28 11:45:46 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 Oct 2014 15:45:46 +0400 Subject: MH inlining fails for a package-private and protected calls In-Reply-To: <5FD6D13B-75B9-4A43-93AA-EB208C5C73C0@oracle.com> References: <71AB5B0F-61AC-443F-9556-662BF29B0941@oracle.com> <544ACC04.2090606@oracle.com> <5FD6D13B-75B9-4A43-93AA-EB208C5C73C0@oracle.com> Message-ID: <544F81EA.5030201@oracle.com> Good catch, Paul! Your analysis is correct. I came to the same conclusion: inlining doesn't happen because LambdaForm$DMH can't access MHInlineTest$B::package_x and others. I'm looking for a proper fix right now. Filed JDK-8062280 [1] to track the problem. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8062280 On 10/28/14, 1:25 PM, Paul Sandoz wrote: > On Oct 27, 2014, at 6:23 PM, Paul Sandoz wrote: >> AFAICT an access control check fails for the lambda form to access the protected method when attempting to inline the method handle. >> > > FWIW below is a hacky patch that makes the inlining work, the intent being just to highlight the access control area. > > I don't quite know what the proper fix should be. > > The Compile::optimize_inlining method attempts to find the mono morphic target, which in turn needs to resolve the method in the context of the calling class via LinkResolver::resolve_virtual_call_or_null, and that fails. If the method is private then Compile::optimize_inlining skips such checks because the method can be statically bound. > > Paul. > > diff -r b1c2dd843f24 src/share/vm/interpreter/linkResolver.cpp > --- a/src/share/vm/interpreter/linkResolver.cpp Fri Oct 24 12:32:53 2014 +0400 > +++ b/src/share/vm/interpreter/linkResolver.cpp Tue Oct 28 10:12:48 2014 +0100 > @@ -472,6 +472,33 @@ > } > // assert(extra_arg_result_or_null != NULL, "must be able to return extra argument"); > > + { > + InstanceKlass* inst = InstanceKlass::cast(ref_klass()); > + if (inst->is_anonymous()) { > + Klass* host_klass = inst->host_klass(); > + if (host_klass == SystemDictionary::LambdaForm_klass()) { > + > +#ifndef PRODUCT > + if (PrintOpto && (Verbose || WizardMode)) { > + tty->print_cr("Host class of reference class is LambdaForm"); > + tty->print_cr("LinkResolver::check_method_accessability access to method %s.%s%s from class %s, with resolved class %s\n", > + sel_klass->external_name(), > + sel_method->name()->as_C_string(), > + sel_method->signature()->as_C_string(), > + ref_klass->external_name(), > + resolved_klass->external_name() > + ); > + } > +#endif > + > + jint new_flags = flags.as_int(); > + new_flags = new_flags & (~JVM_ACC_PROTECTED); > + new_flags = new_flags | JVM_ACC_PUBLIC; > + flags.set_flags(new_flags); > + } > + } > + } > + > if (!Reflection::verify_field_access(ref_klass(), > resolved_klass(), > sel_klass(), > diff -r b1c2dd843f24 src/share/vm/opto/callGenerator.cpp > --- a/src/share/vm/opto/callGenerator.cpp Fri Oct 24 12:32:53 2014 +0400 > +++ b/src/share/vm/opto/callGenerator.cpp Tue Oct 28 10:12:48 2014 +0100 > @@ -822,6 +822,19 @@ > case vmIntrinsics::_linkToSpecial: > case vmIntrinsics::_linkToInterface: > { > + > +#ifndef PRODUCT > + if (PrintOpto && (Verbose || WizardMode)) { > + tty->print_cr("CallGenerator::for_method_handle_inline"); > + tty->print(" Caller: "); > + caller->print_name(); > + tty->cr(); > + tty->print(" Callee: "); > + callee->print_name(); > + tty->cr(); > + } > +#endif > + > // Get MemberName argument: > Node* member_name = kit.argument(callee->arg_size() - 1); > if (member_name->Opcode() == Op_ConP) { > From albert.noll at oracle.com Tue Oct 28 14:06:02 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 28 Oct 2014 15:06:02 +0100 Subject: [9] RFR(XXS): 8062284: Sweeper thread should not be visible when calling Thread.getAllStackTraces() Message-ID: <544FA2CA.9020909@oracle.com> Hi, could I get reviews for this small patch? Bug https://bugs.openjdk.java.net/browse/JDK-8062284 Problem JDK-8046809 introduced a new thread that does code cache sweeping. The new thread (similar to a compiler thread) should not be visible when calling Thread.getAllStackTraces() Testing Inspect output of Thread.getAllStackTraces() Webrev http://cr.openjdk.java.net/~anoll/8062284/webrev.00/ Many thanks in advance, Albert -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils.eliasson at oracle.com Tue Oct 28 13:59:16 2014 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 28 Oct 2014 14:59:16 +0100 Subject: RFR(S): 8061250: serviceability/dcmd/compiler/CompilerQueueTest.java failed In-Reply-To: <544E7AB9.6090200@oracle.com> References: <544E5048.6050907@oracle.com> <544E7AB9.6090200@oracle.com> Message-ID: <544FA134.9010003@oracle.com> Hi Vladimir, It is human readable output that differs unnecessarily with tiered or not. This is only a sanity test for that output (otherwise I would have use a structured output). I implemented a workaround in the test instead. Webrev: http://cr.openjdk.java.net/~neliasso/8061250/webrev.04 We don't need to add a test case for C1. The tiered case covers that well. Regards, Nils On 2014-10-27 18:02, Vladimir Kozlov wrote: > Correct webrev link: > > http://cr.openjdk.java.net/~neliasso/8061250/webrev.02/ > > Hi Nils, > > Indention of changed code is incorrect in compileBroker.cpp. > > Output parser should not relay on particular spacing in output. Is it > hard to fix? I am not comfortable that you changing output of > non-tiered code just to workaround a problem in a tool. > > Do you think we should also test only C1 compilation when Tiered is > enabled?: > > -XX:+TieredCompilation -XX:TieredStopAtLevel=1 > > Thanks, > Vladimir > > On 10/27/14 7:01 AM, Nils Eliasson wrote: >> Hi, >> >> Please review this change. >> >> There was a small difference in logging depending on whether tiered was >> on or off. This made the parsing in the test fail. This problem was not >> caught earlier by a few reasons: >> >> 1) We don't run the testing with a client VM very often >> 2) Running server with tiered off don't compile much and the queue is >> mostly empty >> 3) When runnning with Xcomp compilation is synchronous so the queue is >> always empty >> >> The change includes a small fix for consistent logging indentation >> regardless of tiering, and adding a non-tiered test-case. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8061250 >> Rev: >> file:///home/neliasso/repos/jdk9_hs-comp/hotspot/8061250/webrev.02/index.html >> >> >> >> Thanks, >> Nils From aleksey.shipilev at oracle.com Tue Oct 28 14:11:45 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 28 Oct 2014 17:11:45 +0300 Subject: [9] RFR(XXS): 8062284: Sweeper thread should not be visible when calling Thread.getAllStackTraces() In-Reply-To: <544FA2CA.9020909@oracle.com> References: <544FA2CA.9020909@oracle.com> Message-ID: <544FA421.6040506@oracle.com> On 10/28/2014 05:06 PM, Albert Noll wrote: > Webrev > http://cr.openjdk.java.net/~anoll/8062284/webrev.00/ Looks reasonable (not a Reviewer). Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From albert.noll at oracle.com Tue Oct 28 14:15:40 2014 From: albert.noll at oracle.com (Albert Noll) Date: Tue, 28 Oct 2014 15:15:40 +0100 Subject: [9] RFR(XXS): 8062284: Sweeper thread should not be visible when calling Thread.getAllStackTraces() In-Reply-To: <544FA421.6040506@oracle.com> References: <544FA2CA.9020909@oracle.com> <544FA421.6040506@oracle.com> Message-ID: <544FA50C.9010408@oracle.com> Thanks for looking at this, Aleksey. Best, Albert On 10/28/2014 03:11 PM, Aleksey Shipilev wrote: > On 10/28/2014 05:06 PM, Albert Noll wrote: >> Webrev >> http://cr.openjdk.java.net/~anoll/8062284/webrev.00/ > Looks reasonable (not a Reviewer). > > Thanks, > -Aleksey. > > From tobias.hartmann at oracle.com Tue Oct 28 15:04:03 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Oct 2014 16:04:03 +0100 Subject: [9] RFR(S): 8061817: Whitebox.deoptimizeMethod() does not deoptimize all OSR versions of method In-Reply-To: <544E7574.6050005@oracle.com> References: <544A487A.5080008@oracle.com> <544A4EBE.7090103@oracle.com> <544E5A8A.1060800@oracle.com> <544E7574.6050005@oracle.com> Message-ID: <544FB063.1080304@oracle.com> Hi Vladimir, thanks for the review. On 27.10.2014 17:40, Vladimir Kozlov wrote: > Hi Tobias, > > I don't like adding deoptimization checks inside lookup method which have > nothing to do with deoptimization. > I would suggest to add new method InstanceKlass::mark_osr_nmethods() to mark all > related OSRs. I agree. I added a method "InstanceKlass::mark_osr_nmethods()" and refactored "WB_DeoptimizeMethod" accordingly. > We have already InstanceKlass::mark_dependent_nmethods() but it > could be not applicable to all our tests if they don't record dependencies > during OSR compilation. Yes. I also think that using "mark_osr_nmethods()" makes it more explicit. New webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.02 Thanks, Tobias > > Regards, > Vladimir > > On 10/27/14 7:45 AM, Tobias Hartmann wrote: >> Hi Igor, >> >> thanks for the review. >> >> On 24.10.2014 15:06, Igor Ignatyev wrote: >>> Hi Tobias, >>> >>> DeoptimizeMultipleOSRTest: >>> 1. could you please make 'method' an instance field? >> >> Done. >> >>> 2. use AssertionError instead of RuntimeException >> >> Done. >> >>> 3. have you tried to run this test w/ Xcomp? >> >> Yes, it works fine (OSR compilations are still triggered and deoptimized). >> However, I found another bug and filed 8062169. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.01/ >> >> Thanks, >> Tobias >> >>> >>> Thanks, >>> Igor >>> >>> On 10/24/2014 04:39 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061817 >>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.00/ >>>> >>>> Problem >>>> 'WhiteBox.deoptimizeMethod' does not deoptimize all OSR compiled versions of >>>> the >>>> given method but only one. The problem lies in'WB_DeoptimizeMethod'. The >>>> call to >>>> 'lookup_osr_nmethod_for' only returns the best fitting OSR nmethod. >>>> Incrementing >>>> the bci (see line 395) does not help. >>>> >>>> Solution >>>> I changed the implementation to deoptimize all OSR versions and added a >>>> regression test that triggers two OSR compilations and checks that both are >>>> deoptimized ('DeoptimizeMultipleOSRTest'). >>>> >>>> Testing >>>> New test on JPRT >>>> >>>> Best, >>>> Tobias >>>> From vladimir.kozlov at oracle.com Tue Oct 28 15:25:34 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Oct 2014 08:25:34 -0700 Subject: [9] RFR(S): 8062250: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java fails after CodeCacheMinimumFreeSpace removal In-Reply-To: <544F59AA.8050604@oracle.com> References: <544F59AA.8050604@oracle.com> Message-ID: <544FB56E.40909@oracle.com> Good. Thanks, Vladimir On 10/28/14 1:54 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that fixes the test > 'compiler/codecache/CheckSegmentedCodeCache.java' after JDK-8046809 removed the > CodeCacheMinimumFreeSpace VM flag. As Vladimir K. suggested, I also added the > test to JPRT. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8062250 > Webrev: http://cr.openjdk.java.net/~thartmann/8062250/webrev.00/ > > Thanks, > Tobias > From vladimir.kozlov at oracle.com Tue Oct 28 15:38:34 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Oct 2014 08:38:34 -0700 Subject: RFR(S): 8061250: serviceability/dcmd/compiler/CompilerQueueTest.java failed In-Reply-To: <544FA134.9010003@oracle.com> References: <544E5048.6050907@oracle.com> <544E7AB9.6090200@oracle.com> <544FA134.9010003@oracle.com> Message-ID: <544FB87A.5050003@oracle.com> On 10/28/14 6:59 AM, Nils Eliasson wrote: > Hi Vladimir, > > It is human readable output that differs unnecessarily with tiered or not. This is only a sanity test for that output > (otherwise I would have use a structured output). We don't mix tiered and not-tiered outputs so difference is not obvious. And adding 2 empty spaces will change output format slightly. > > I implemented a workaround in the test instead. > > Webrev: http://cr.openjdk.java.net/~neliasso/8061250/webrev.04 Good. > > We don't need to add a test case for C1. The tiered case covers that well. Okay. Thanks, Vladimir > > Regards, > Nils > > On 2014-10-27 18:02, Vladimir Kozlov wrote: >> Correct webrev link: >> >> http://cr.openjdk.java.net/~neliasso/8061250/webrev.02/ >> >> Hi Nils, >> >> Indention of changed code is incorrect in compileBroker.cpp. >> >> Output parser should not relay on particular spacing in output. Is it hard to fix? I am not comfortable that you >> changing output of non-tiered code just to workaround a problem in a tool. >> >> Do you think we should also test only C1 compilation when Tiered is enabled?: >> >> -XX:+TieredCompilation -XX:TieredStopAtLevel=1 >> >> Thanks, >> Vladimir >> >> On 10/27/14 7:01 AM, Nils Eliasson wrote: >>> Hi, >>> >>> Please review this change. >>> >>> There was a small difference in logging depending on whether tiered was >>> on or off. This made the parsing in the test fail. This problem was not >>> caught earlier by a few reasons: >>> >>> 1) We don't run the testing with a client VM very often >>> 2) Running server with tiered off don't compile much and the queue is >>> mostly empty >>> 3) When runnning with Xcomp compilation is synchronous so the queue is >>> always empty >>> >>> The change includes a small fix for consistent logging indentation >>> regardless of tiering, and adding a non-tiered test-case. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061250 >>> Rev: >>> file:///home/neliasso/repos/jdk9_hs-comp/hotspot/8061250/webrev.02/index.html >>> >>> >>> Thanks, >>> Nils > From vladimir.kozlov at oracle.com Tue Oct 28 15:40:23 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Oct 2014 08:40:23 -0700 Subject: [9] RFR(XXS): 8062284: Sweeper thread should not be visible when calling Thread.getAllStackTraces() In-Reply-To: <544FA2CA.9020909@oracle.com> References: <544FA2CA.9020909@oracle.com> Message-ID: <544FB8E7.8040700@oracle.com> Good. Thanks, Vladimir On 10/28/14 7:06 AM, Albert Noll wrote: > Hi, > > could I get reviews for this small patch? > > Bug > https://bugs.openjdk.java.net/browse/JDK-8062284 > > Problem > JDK-8046809 introduced a new thread that does code cache sweeping. The new thread (similar to a compiler thread) should > not be visible when calling Thread.getAllStackTraces() > > Testing > Inspect output of Thread.getAllStackTraces() > > Webrev > http://cr.openjdk.java.net/~anoll/8062284/webrev.00/ > > Many thanks in advance, > Albert > From tobias.hartmann at oracle.com Tue Oct 28 15:41:23 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Oct 2014 16:41:23 +0100 Subject: [9] RFR(S): 8062250: [TESTBUG] compiler/codecache/CheckSegmentedCodeCache.java fails after CodeCacheMinimumFreeSpace removal In-Reply-To: <544FB56E.40909@oracle.com> References: <544F59AA.8050604@oracle.com> <544FB56E.40909@oracle.com> Message-ID: <544FB923.1050106@oracle.com> Thanks, Vladimir. Best, Tobias On 28.10.2014 16:25, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/28/14 1:54 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch that fixes the test >> 'compiler/codecache/CheckSegmentedCodeCache.java' after JDK-8046809 removed the >> CodeCacheMinimumFreeSpace VM flag. As Vladimir K. suggested, I also added the >> test to JPRT. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8062250 >> Webrev: http://cr.openjdk.java.net/~thartmann/8062250/webrev.00/ >> >> Thanks, >> Tobias >> From tobias.hartmann at oracle.com Tue Oct 28 15:45:37 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Oct 2014 16:45:37 +0100 Subject: [9] RFR(XXS): 8062284: Sweeper thread should not be visible when calling Thread.getAllStackTraces() In-Reply-To: <544FB8E7.8040700@oracle.com> References: <544FA2CA.9020909@oracle.com> <544FB8E7.8040700@oracle.com> Message-ID: <544FBA21.8000709@oracle.com> Thanks, Vladimir. Best, Tobias On 28.10.2014 16:40, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/28/14 7:06 AM, Albert Noll wrote: >> Hi, >> >> could I get reviews for this small patch? >> >> Bug >> https://bugs.openjdk.java.net/browse/JDK-8062284 >> >> Problem >> JDK-8046809 introduced a new thread that does code cache sweeping. The new >> thread (similar to a compiler thread) should >> not be visible when calling Thread.getAllStackTraces() >> >> Testing >> Inspect output of Thread.getAllStackTraces() >> >> Webrev >> http://cr.openjdk.java.net/~anoll/8062284/webrev.00/ >> >> Many thanks in advance, >> Albert >> From tobias.hartmann at oracle.com Tue Oct 28 15:46:50 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Oct 2014 16:46:50 +0100 Subject: [9] RFR(XXS): 8062284: Sweeper thread should not be visible when calling Thread.getAllStackTraces() In-Reply-To: <544FBA21.8000709@oracle.com> References: <544FA2CA.9020909@oracle.com> <544FB8E7.8040700@oracle.com> <544FBA21.8000709@oracle.com> Message-ID: <544FBA6A.5050204@oracle.com> Sorry, responded to the wrong email :) On 28.10.2014 16:45, Tobias Hartmann wrote: > Thanks, Vladimir. > > Best, > Tobias > > On 28.10.2014 16:40, Vladimir Kozlov wrote: >> Good. >> >> Thanks, >> Vladimir >> >> On 10/28/14 7:06 AM, Albert Noll wrote: >>> Hi, >>> >>> could I get reviews for this small patch? >>> >>> Bug >>> https://bugs.openjdk.java.net/browse/JDK-8062284 >>> >>> Problem >>> JDK-8046809 introduced a new thread that does code cache sweeping. The new >>> thread (similar to a compiler thread) should >>> not be visible when calling Thread.getAllStackTraces() >>> >>> Testing >>> Inspect output of Thread.getAllStackTraces() >>> >>> Webrev >>> http://cr.openjdk.java.net/~anoll/8062284/webrev.00/ >>> >>> Many thanks in advance, >>> Albert >>> From vladimir.kozlov at oracle.com Tue Oct 28 15:51:48 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Oct 2014 08:51:48 -0700 Subject: [9] RFR(S): 8061817: Whitebox.deoptimizeMethod() does not deoptimize all OSR versions of method In-Reply-To: <544FB063.1080304@oracle.com> References: <544A487A.5080008@oracle.com> <544A4EBE.7090103@oracle.com> <544E5A8A.1060800@oracle.com> <544E7574.6050005@oracle.com> <544FB063.1080304@oracle.com> Message-ID: <544FBB94.1070300@oracle.com> Looks good. Thanks, Vladimir On 10/28/14 8:04 AM, Tobias Hartmann wrote: > Hi Vladimir, > > thanks for the review. > > On 27.10.2014 17:40, Vladimir Kozlov wrote: >> Hi Tobias, >> >> I don't like adding deoptimization checks inside lookup method which have >> nothing to do with deoptimization. >> I would suggest to add new method InstanceKlass::mark_osr_nmethods() to mark all >> related OSRs. > > I agree. I added a method "InstanceKlass::mark_osr_nmethods()" and refactored > "WB_DeoptimizeMethod" accordingly. > >> We have already InstanceKlass::mark_dependent_nmethods() but it >> could be not applicable to all our tests if they don't record dependencies >> during OSR compilation. > > Yes. I also think that using "mark_osr_nmethods()" makes it more explicit. > > New webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.02 > > Thanks, > Tobias > >> >> Regards, >> Vladimir >> >> On 10/27/14 7:45 AM, Tobias Hartmann wrote: >>> Hi Igor, >>> >>> thanks for the review. >>> >>> On 24.10.2014 15:06, Igor Ignatyev wrote: >>>> Hi Tobias, >>>> >>>> DeoptimizeMultipleOSRTest: >>>> 1. could you please make 'method' an instance field? >>> >>> Done. >>> >>>> 2. use AssertionError instead of RuntimeException >>> >>> Done. >>> >>>> 3. have you tried to run this test w/ Xcomp? >>> >>> Yes, it works fine (OSR compilations are still triggered and deoptimized). >>> However, I found another bug and filed 8062169. >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.01/ >>> >>> Thanks, >>> Tobias >>> >>>> >>>> Thanks, >>>> Igor >>>> >>>> On 10/24/2014 04:39 PM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> please review the following patch. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061817 >>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.00/ >>>>> >>>>> Problem >>>>> 'WhiteBox.deoptimizeMethod' does not deoptimize all OSR compiled versions of >>>>> the >>>>> given method but only one. The problem lies in'WB_DeoptimizeMethod'. The >>>>> call to >>>>> 'lookup_osr_nmethod_for' only returns the best fitting OSR nmethod. >>>>> Incrementing >>>>> the bci (see line 395) does not help. >>>>> >>>>> Solution >>>>> I changed the implementation to deoptimize all OSR versions and added a >>>>> regression test that triggers two OSR compilations and checks that both are >>>>> deoptimized ('DeoptimizeMultipleOSRTest'). >>>>> >>>>> Testing >>>>> New test on JPRT >>>>> >>>>> Best, >>>>> Tobias >>>>> From tobias.hartmann at oracle.com Tue Oct 28 16:18:19 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Oct 2014 17:18:19 +0100 Subject: [9] RFR(S): 8061817: Whitebox.deoptimizeMethod() does not deoptimize all OSR versions of method In-Reply-To: <544FBB94.1070300@oracle.com> References: <544A487A.5080008@oracle.com> <544A4EBE.7090103@oracle.com> <544E5A8A.1060800@oracle.com> <544E7574.6050005@oracle.com> <544FB063.1080304@oracle.com> <544FBB94.1070300@oracle.com> Message-ID: <544FC1CB.5060308@oracle.com> Thanks, Vladimir. Best, Tobias On 28.10.2014 16:51, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/28/14 8:04 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> thanks for the review. >> >> On 27.10.2014 17:40, Vladimir Kozlov wrote: >>> Hi Tobias, >>> >>> I don't like adding deoptimization checks inside lookup method which have >>> nothing to do with deoptimization. >>> I would suggest to add new method InstanceKlass::mark_osr_nmethods() to mark all >>> related OSRs. >> >> I agree. I added a method "InstanceKlass::mark_osr_nmethods()" and refactored >> "WB_DeoptimizeMethod" accordingly. >> >>> We have already InstanceKlass::mark_dependent_nmethods() but it >>> could be not applicable to all our tests if they don't record dependencies >>> during OSR compilation. >> >> Yes. I also think that using "mark_osr_nmethods()" makes it more explicit. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.02 >> >> Thanks, >> Tobias >> >>> >>> Regards, >>> Vladimir >>> >>> On 10/27/14 7:45 AM, Tobias Hartmann wrote: >>>> Hi Igor, >>>> >>>> thanks for the review. >>>> >>>> On 24.10.2014 15:06, Igor Ignatyev wrote: >>>>> Hi Tobias, >>>>> >>>>> DeoptimizeMultipleOSRTest: >>>>> 1. could you please make 'method' an instance field? >>>> >>>> Done. >>>> >>>>> 2. use AssertionError instead of RuntimeException >>>> >>>> Done. >>>> >>>>> 3. have you tried to run this test w/ Xcomp? >>>> >>>> Yes, it works fine (OSR compilations are still triggered and deoptimized). >>>> However, I found another bug and filed 8062169. >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.01/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> Thanks, >>>>> Igor >>>>> >>>>> On 10/24/2014 04:39 PM, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> please review the following patch. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061817 >>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8061817/webrev.00/ >>>>>> >>>>>> Problem >>>>>> 'WhiteBox.deoptimizeMethod' does not deoptimize all OSR compiled versions of >>>>>> the >>>>>> given method but only one. The problem lies in'WB_DeoptimizeMethod'. The >>>>>> call to >>>>>> 'lookup_osr_nmethod_for' only returns the best fitting OSR nmethod. >>>>>> Incrementing >>>>>> the bci (see line 395) does not help. >>>>>> >>>>>> Solution >>>>>> I changed the implementation to deoptimize all OSR versions and added a >>>>>> regression test that triggers two OSR compilations and checks that both are >>>>>> deoptimized ('DeoptimizeMultipleOSRTest'). >>>>>> >>>>>> Testing >>>>>> New test on JPRT >>>>>> >>>>>> Best, >>>>>> Tobias >>>>>> From igor.ignatyev at oracle.com Tue Oct 28 18:22:24 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 28 Oct 2014 21:22:24 +0300 Subject: RFR(XS) : 8036913 : make DeoptimizeALot dependent on number of threads Message-ID: <544FDEE0.2040105@oracle.com> http://cr.openjdk.java.net/~iignatyev/8036913/webrev.00/ 8 lines changed: 2 ins; 2 del; 4 mod; Hi all, Please review changes which makes DeoptimizeALot/ZombieALot dependent on number of threads. To achieve that, counter value is divided by number of threads before comparison w/ limit (*Interval). + zombieAllCounter incrementation is moved out of if-else to be aligned w/ deoptimizeAllCounter bug: https://bugs.openjdk.java.net/browse/JDK-8036913 testing: - jprt - gc/gctests/RememberedSet on solaris-sparcv9 w/ -Xcomp -XX:+DeoptimizeALot : w/ the fix it takes 4m, w/o -- 100m // w/o DeoptimizeALot it takes 2m. -- Igor From aleksey.shipilev at oracle.com Tue Oct 28 18:41:33 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 28 Oct 2014 21:41:33 +0300 Subject: RFR(XS) : 8036913 : make DeoptimizeALot dependent on number of threads In-Reply-To: <544FDEE0.2040105@oracle.com> References: <544FDEE0.2040105@oracle.com> Message-ID: <544FE35D.5080003@oracle.com> On 28.10.2014 21:22, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8036913/webrev.00/ > 8 lines changed: 2 ins; 2 del; 4 mod; Looks good. > + zombieAllCounter incrementation is moved out of if-else to be aligned > w/ deoptimizeAllCounter Shouldn't it be in reverse, i.e. deoptimizeAllCounter to be moved in the block? I would think counting the _successful_ deoptimizeAll/zombieAll events is more useful. -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From christian.thalinger at oracle.com Tue Oct 28 19:08:28 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 28 Oct 2014 12:08:28 -0700 Subject: RFR(S): 8061250: serviceability/dcmd/compiler/CompilerQueueTest.java failed In-Reply-To: <544FA134.9010003@oracle.com> References: <544E5048.6050907@oracle.com> <544E7AB9.6090200@oracle.com> <544FA134.9010003@oracle.com> Message-ID: <0A586E0B-4840-47EA-A058-01D067F70F89@oracle.com> Looks good. > On Oct 28, 2014, at 6:59 AM, Nils Eliasson wrote: > > Hi Vladimir, > > It is human readable output that differs unnecessarily with tiered or not. This is only a sanity test for that output (otherwise I would have use a structured output). > > I implemented a workaround in the test instead. > > Webrev: http://cr.openjdk.java.net/~neliasso/8061250/webrev.04 > > We don't need to add a test case for C1. The tiered case covers that well. > > Regards, > Nils > > On 2014-10-27 18:02, Vladimir Kozlov wrote: >> Correct webrev link: >> >> http://cr.openjdk.java.net/~neliasso/8061250/webrev.02/ >> >> Hi Nils, >> >> Indention of changed code is incorrect in compileBroker.cpp. >> >> Output parser should not relay on particular spacing in output. Is it hard to fix? I am not comfortable that you changing output of non-tiered code just to workaround a problem in a tool. >> >> Do you think we should also test only C1 compilation when Tiered is enabled?: >> >> -XX:+TieredCompilation -XX:TieredStopAtLevel=1 >> >> Thanks, >> Vladimir >> >> On 10/27/14 7:01 AM, Nils Eliasson wrote: >>> Hi, >>> >>> Please review this change. >>> >>> There was a small difference in logging depending on whether tiered was >>> on or off. This made the parsing in the test fail. This problem was not >>> caught earlier by a few reasons: >>> >>> 1) We don't run the testing with a client VM very often >>> 2) Running server with tiered off don't compile much and the queue is >>> mostly empty >>> 3) When runnning with Xcomp compilation is synchronous so the queue is >>> always empty >>> >>> The change includes a small fix for consistent logging indentation >>> regardless of tiering, and adding a non-tiered test-case. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8061250 >>> Rev: >>> file:///home/neliasso/repos/jdk9_hs-comp/hotspot/8061250/webrev.02/index.html >>> >>> >>> Thanks, >>> Nils > From sergei.kovalev at oracle.com Wed Oct 29 09:02:22 2014 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 29 Oct 2014 12:02:22 +0300 Subject: RFR(M): 8044186 Introduce a reproducible random generator In-Reply-To: <7DC5F0F7-15A1-4FFD-BCE8-5E857138E25C@oracle.com> References: <54218BFA.7020803@oracle.com> <542285EC.408@oracle.com> <54228A50.6080406@oracle.com> <5422D36E.9060002@oracle.com> <7DC5F0F7-15A1-4FFD-BCE8-5E857138E25C@oracle.com> Message-ID: <5450AD1E.3030407@oracle.com> Hello team. Next round of review: http://cr.openjdk.java.net/~iignatyev/skovalev/8044186/webrev.00/ Main changes: - introduced new test that testing new testlibrary functionality: test/testlibrary_tests/RandomGeneratorTest.java - slightly improved Utility.java in part of SEED variable access. All affected tests passed locally on Linux host. On 24.09.2014 22:36, Igor Veresov wrote: > Looks good. > > igor > > On Sep 24, 2014, at 7:21 AM, Sergei Kovalev wrote: > >> Update: http://cr.openjdk.java.net/~vlivanov/kovalev/8044186/webrev.03/ >> >> Added new testcase test/testlibrary_tests/RandomGeneratorTest.java that verify correctness of work for Utils.getRandomInstance() method. >> >> On 24.09.2014 13:09, Sergei Kovalev wrote: >>> Update: http://cr.openjdk.java.net/~vlivanov/kovalev/8044186/webrev.02/ >>> >>> Added new test. >>> Fixed misprint. >>> >>> On 24.09.2014 12:50, Vladimir Ivanov wrote: >>>> Sergei, >>>> >>>> Please, update recently introduced test/compiler/unsafe/UnsafeRaw.java. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 9/23/14, 7:04 PM, Sergei Kovalev wrote: >>>>> Hello all, >>>>> >>>>> Looking for volunteers for review. >>>>> >>>>> I'm working for CR https://bugs.openjdk.java.net/browse/JDK-8044186 that >>>>> submitted against tests. >>>>> >>>>> There's the several tests which use randomly generated numbers. It's >>>>> needed to introduce a way that provide a common manner to reproduce the >>>>> same random sequence, set seed. >>>>> >>>>> There are two possible way to provide seed value: >>>>> - system property >>>>> - command line arguments. >>>>> >>>>> I chose system property to provide seed value because it could be >>>>> obtained in any part of code without additional effort. In case passing >>>>> seed value as command line argument we have to introduce additional >>>>> logic (and unwanted code) to pass this value in appropriate method. >>>>> >>>>> I introduced factory method getRandomInstance in the file Utility.java >>>>> and make reference to this method in all applicable tests. >>>>> There is other utility class: Verifier.java. It used in several other >>>>> testcases from test/compiler/intrinsics/mathexact/ package. Therefore >>>>> many files contains modifications only for jtreg annotations. >>>>> >>>>> I've tested all related tests locally. All tests passed and seed value >>>>> printed to the logs. >>>>> >>>>> links: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044186 >>>>> webrev: http://cr.openjdk.java.net/~vlivanov/kovalev/8044186/webrev.01/ >>>>> >>>> >> -- >> With best regards, >> Sergei >> > > -- With best regards, Sergei From vladimir.x.ivanov at oracle.com Wed Oct 29 11:57:45 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 29 Oct 2014 15:57:45 +0400 Subject: [9] RFR (XXS): 8062258: compiler/debug/TraceIterativeGVN.java segfaults in trace_PhaseIterGVN Message-ID: <5450D639.2050506@oracle.com> http://cr.openjdk.java.net/~vlivanov/8062258/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8062258 Trivial fix to avoid NULL dereference w/ -XX:+TraceIterativeGVN while querying adr_type() on dead MemNode. Testing: failing test. Best regards, Vladimir Ivanov From igor.ignatyev at oracle.com Wed Oct 29 13:49:01 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 29 Oct 2014 16:49:01 +0300 Subject: RFR(XS) : 8036913 : make DeoptimizeALot dependent on number of threads In-Reply-To: <544FE35D.5080003@oracle.com> References: <544FDEE0.2040105@oracle.com> <544FE35D.5080003@oracle.com> Message-ID: <5450F04D.9030703@oracle.com> Aleksey, zombie/deoptimizeAllCounter are invocation counters of corresponding function and not counters of the actually happened events. so they should be incremented on each invocation of the function. Thanks Igor On 10/28/2014 09:41 PM, Aleksey Shipilev wrote: > On 28.10.2014 21:22, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8036913/webrev.00/ >> 8 lines changed: 2 ins; 2 del; 4 mod; > > Looks good. > >> + zombieAllCounter incrementation is moved out of if-else to be aligned >> w/ deoptimizeAllCounter > > Shouldn't it be in reverse, i.e. deoptimizeAllCounter to be moved in the > block? I would think counting the _successful_ deoptimizeAll/zombieAll > events is more useful. > > -Aleksey. > > From vladimir.kozlov at oracle.com Wed Oct 29 14:48:01 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Oct 2014 07:48:01 -0700 Subject: RFR(XS) : 8036913 : make DeoptimizeALot dependent on number of threads In-Reply-To: <5450F04D.9030703@oracle.com> References: <544FDEE0.2040105@oracle.com> <544FE35D.5080003@oracle.com> <5450F04D.9030703@oracle.com> Message-ID: <5450FE21.40106@oracle.com> Igor, On 10/29/14 6:49 AM, Igor Ignatyev wrote: > Aleksey, > > zombie/deoptimizeAllCounter are invocation counters of corresponding function and not counters of the actually happened > events. so they should be incremented on each invocation of the function. Please, add this explanation as a comment so it would be clear why you divide by number of threads. Changes are fine with that. Thanks, Vladimir > > Thanks > Igor > > On 10/28/2014 09:41 PM, Aleksey Shipilev wrote: >> On 28.10.2014 21:22, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev/8036913/webrev.00/ >>> 8 lines changed: 2 ins; 2 del; 4 mod; >> >> Looks good. >> >>> + zombieAllCounter incrementation is moved out of if-else to be aligned >>> w/ deoptimizeAllCounter >> >> Shouldn't it be in reverse, i.e. deoptimizeAllCounter to be moved in the >> block? I would think counting the _successful_ deoptimizeAll/zombieAll >> events is more useful. >> >> -Aleksey. >> >> From tobias.hartmann at oracle.com Wed Oct 29 14:54:29 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 29 Oct 2014 15:54:29 +0100 Subject: [9] RFR(S): 8062169: Multiple OSR compilations issued for same bci Message-ID: <5450FFA5.3080804@oracle.com> Hi, please review the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8062169 Webrev: http://cr.openjdk.java.net/~thartmann/8062169/webrev.00/ Summary: An existing OSR nmethod blocks OSR for the same method at other BCIs. Problem: The method 'triggerOSR' contains two loops to trigger OSR compilations. The first loop triggers an OSR compilation at BCI 59 and comp level 4. While executing the second loop an OSR compilation at BCI 89 and comp level 3 is triggered [1]. We then check if the event led to a higher level OSR compilation by checking if the 'highest_osr_comp_level()' is greater than the current compilation level (in this case 0 since we are interpreting) and if so perform an OSR [2]. The problem is that 'highest_osr_comp_level()' is independent of the BCI and therefore returns 4 (because of the existing OSR nmethod at BCI 59). The following lookup for an OSR nmethod at BCI 89 fails and no OSR is performed. The interpreter continues executing the method until the backbranch event is triggered again and we start right from the beginning. However, we do not issue a new OSR compilation but fail to perform OSR with the existing OSR nmethod. This repeats until we finally decide to OSR compile at level 4 (see log [3]). With -Xcomp it's even worse because we issue a new compilation every time. This is because a compilation at level 3 is requested but an in-queue update changes it to level 2 (see 'AdvancedThresholdPolicy::select_task'). The next time the compilation is requested we search for existing level 3 compilations, do not find any and therefore issue a new compilation at level 3 that is then changed to 2 again. In this case, we issue approximately 40 OSR compilations but never use them until we finally OSR compile at level 4 (see log [4]). Solution: I changed 'SimpleThresholdPolicy::event' such that it does not use 'highest_osr_comp_level()' for the lookup but the current comp level. Like this, we always perform OSR if there is an OSR nmethod available for the current BCI that has a higher compilation. I also checked the other usages of 'highest_osr_comp_level()' and they seem to be fine. Testing JPRT + DeoptimizeMultipleOSRTest Thanks, Tobias [1] 'SimpleThresholdPolicy::event' invokes 'AdvancedThresholdPolicy::method_back_branch_event' [2] simpleThresholdPolicy.cpp lines 215f [3] Logs (note missing 'OSR entry @ pc' in failed.log showing that no OSR is performed) https://bugs.openjdk.java.net/secure/attachment/23183/failed.log https://bugs.openjdk.java.net/secure/attachment/23185/fixed.log [4] Logs with -Xcomp https://bugs.openjdk.java.net/secure/attachment/23184/failed_Xcomp.log https://bugs.openjdk.java.net/secure/attachment/23186/fixed_Xcomp.log From vladimir.x.ivanov at oracle.com Wed Oct 29 13:57:53 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 29 Oct 2014 17:57:53 +0400 Subject: [9] RFR (S): 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv Message-ID: <5450F261.60400@oracle.com> http://cr.openjdk.java.net/~vlivanov/8060147/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8060147 ciObjectFactory doesn't keep cached Metadata* alive. ciMetadata is different from ciObject - it doesn't store JNI handle, but a raw Metadata* pointer. In order to avoid Metadata* vanishing during compilation, I cache ciObject for it's holder, which should keep corresponding Metadata* alive. Cached objects have the same lifetime as the owning ciObjectFactory (no cache pruning), so Metadata* will be available as long as ciObjectFactory instance is used. Also, cleaned relevant comments and strengthened some asserts (since NULL keys are not allowed). Testing: jprt, stress mode - full Nashorn/Octane with aggressive VM anonymous class unloading (LambdaForm/MethodHandle caching completely turned off). Thanks! Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Wed Oct 29 15:00:57 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Oct 2014 08:00:57 -0700 Subject: [9] RFR (XXS): 8062258: compiler/debug/TraceIterativeGVN.java segfaults in trace_PhaseIterGVN In-Reply-To: <5450D639.2050506@oracle.com> References: <5450D639.2050506@oracle.com> Message-ID: <54510129.8080108@oracle.com> I would suggest to dead node check in trace_PhaseIterGVN() instead of in MemNode::adr_type(). So the fix for your JDK-8061995 should fix this problem too. Thanks, Vladimir On 10/29/14 4:57 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8062258/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8062258 > > Trivial fix to avoid NULL dereference w/ -XX:+TraceIterativeGVN while querying adr_type() on dead MemNode. > > Testing: failing test. > > Best regards, > Vladimir Ivanov From roland.westrelin at oracle.com Wed Oct 29 15:12:07 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 29 Oct 2014 16:12:07 +0100 Subject: [9] RFR (S): 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv In-Reply-To: <5450F261.60400@oracle.com> References: <5450F261.60400@oracle.com> Message-ID: <4B1E9213-DC7E-47CA-A79F-66C8A2873E18@oracle.com> Hi Vladimir, > http://cr.openjdk.java.net/~vlivanov/8060147/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8060147 > > ciObjectFactory doesn't keep cached Metadata* alive. ciMetadata is different from ciObject - it doesn't store JNI handle, but a raw Metadata* pointer. What kind of ciMetadata do you observe being unloaded? For instance, if I remember correctly ciInstanceKlass is kept alive by storing a handle to the loader object of the instance klass. Roland. From bertrand.delsart at oracle.com Wed Oct 29 15:24:40 2014 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 29 Oct 2014 16:24:40 +0100 Subject: [9] RFR (S): 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv In-Reply-To: <5450F261.60400@oracle.com> References: <5450F261.60400@oracle.com> Message-ID: <545106B8.4060305@oracle.com> Hi Vladimir, This seems OK with respect to class unloading but what about class redefinition ? In particular, this may not be sufficient for Method* or MethodData*. Still catching up on runtime issues but I think a redefined method has a smaller lifetime than its holder class. Hence, it seems that keeping the holder klass alive may not be sufficient to ensure a Method* survives as long as you need it for the ciMetadata. Regards, Bertrand. On 29/10/14 14:57, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8060147/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8060147 > > ciObjectFactory doesn't keep cached Metadata* alive. ciMetadata is > different from ciObject - it doesn't store JNI handle, but a raw > Metadata* pointer. > > In order to avoid Metadata* vanishing during compilation, I cache > ciObject for it's holder, which should keep corresponding Metadata* > alive. Cached objects have the same lifetime as the owning > ciObjectFactory (no cache pruning), so Metadata* will be available as > long as ciObjectFactory instance is used. > > Also, cleaned relevant comments and strengthened some asserts (since > NULL keys are not allowed). > > Testing: jprt, stress mode - full Nashorn/Octane with aggressive VM > anonymous class unloading (LambdaForm/MethodHandle caching completely > turned off). > > Thanks! > > Best regards, > Vladimir Ivanov -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38334 Saint Ismier, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From vladimir.x.ivanov at oracle.com Wed Oct 29 15:05:12 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 29 Oct 2014 19:05:12 +0400 Subject: [9] RFR (S): 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv In-Reply-To: <545106B8.4060305@oracle.com> References: <5450F261.60400@oracle.com> <545106B8.4060305@oracle.com> Message-ID: <54510228.4040207@oracle.com> Bertrand, Thanks for the review. There's another mechanism to support class redefinition - MetadataOnStackMark. It iterates over all threads and sets on_stack bit on every Metadata* it encounters. It keeps metadata from clearing. Eventually, it calls ciObjectFactory::metadata_do() for every compiler thread which marks all Metadata* in associated ciObjectFactory::_ci_metadata. Best regards, Vladimir Ivanov On 10/29/14, 7:24 PM, Bertrand Delsart wrote: > Hi Vladimir, > > This seems OK with respect to class unloading but what about class > redefinition ? > > In particular, this may not be sufficient for Method* or MethodData*. > Still catching up on runtime issues but I think a redefined method has a > smaller lifetime than its holder class. Hence, it seems that keeping the > holder klass alive may not be sufficient to ensure a Method* survives as > long as you need it for the ciMetadata. > > Regards, > > Bertrand. > > On 29/10/14 14:57, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8060147/webrev.00 >> https://bugs.openjdk.java.net/browse/JDK-8060147 >> >> ciObjectFactory doesn't keep cached Metadata* alive. ciMetadata is >> different from ciObject - it doesn't store JNI handle, but a raw >> Metadata* pointer. >> >> In order to avoid Metadata* vanishing during compilation, I cache >> ciObject for it's holder, which should keep corresponding Metadata* >> alive. Cached objects have the same lifetime as the owning >> ciObjectFactory (no cache pruning), so Metadata* will be available as >> long as ciObjectFactory instance is used. >> >> Also, cleaned relevant comments and strengthened some asserts (since >> NULL keys are not allowed). >> >> Testing: jprt, stress mode - full Nashorn/Octane with aggressive VM >> anonymous class unloading (LambdaForm/MethodHandle caching completely >> turned off). >> >> Thanks! >> >> Best regards, >> Vladimir Ivanov > > From vladimir.kozlov at oracle.com Wed Oct 29 16:08:44 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Oct 2014 09:08:44 -0700 Subject: [9] RFR(S): 8062169: Multiple OSR compilations issued for same bci In-Reply-To: <5450FFA5.3080804@oracle.com> References: <5450FFA5.3080804@oracle.com> Message-ID: <5451110C.3050604@oracle.com> This looks reasonable to me but Igor is more familiar with this. Thanks, Vladimir On 10/29/14 7:54 AM, Tobias Hartmann wrote: > Hi, > > please review the following fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8062169 > Webrev: http://cr.openjdk.java.net/~thartmann/8062169/webrev.00/ > > Summary: > An existing OSR nmethod blocks OSR for the same method at other BCIs. > > Problem: > The method 'triggerOSR' contains two loops to trigger OSR compilations. The > first loop triggers an OSR compilation at BCI 59 and comp level 4. While > executing the second loop an OSR compilation at BCI 89 and comp level 3 is > triggered [1]. We then check if the event led to a higher level OSR compilation > by checking if the 'highest_osr_comp_level()' is greater than the current > compilation level (in this case 0 since we are interpreting) and if so perform > an OSR [2]. The problem is that 'highest_osr_comp_level()' is independent of the > BCI and therefore returns 4 (because of the existing OSR nmethod at BCI 59). The > following lookup for an OSR nmethod at BCI 89 fails and no OSR is performed. The > interpreter continues executing the method until the backbranch event is > triggered again and we start right from the beginning. However, we do not issue > a new OSR compilation but fail to perform OSR with the existing OSR nmethod. > This repeats until we finally decide to OSR compile at level 4 (see log [3]). > > With -Xcomp it's even worse because we issue a new compilation every time. This > is because a compilation at level 3 is requested but an in-queue update changes > it to level 2 (see 'AdvancedThresholdPolicy::select_task'). The next time the > compilation is requested we search for existing level 3 compilations, do not > find any and therefore issue a new compilation at level 3 that is then changed > to 2 again. In this case, we issue approximately 40 OSR compilations but never > use them until we finally OSR compile at level 4 (see log [4]). > > Solution: > I changed 'SimpleThresholdPolicy::event' such that it does not use > 'highest_osr_comp_level()' for the lookup but the current comp level. Like this, > we always perform OSR if there is an OSR nmethod available for the current BCI > that has a higher compilation. I also checked the other usages of > 'highest_osr_comp_level()' and they seem to be fine. > > Testing > JPRT + DeoptimizeMultipleOSRTest > > Thanks, > Tobias > > > [1] 'SimpleThresholdPolicy::event' invokes > 'AdvancedThresholdPolicy::method_back_branch_event' > [2] simpleThresholdPolicy.cpp lines 215f > [3] Logs (note missing 'OSR entry @ pc' in failed.log showing that no OSR is > performed) > https://bugs.openjdk.java.net/secure/attachment/23183/failed.log > https://bugs.openjdk.java.net/secure/attachment/23185/fixed.log > [4] Logs with -Xcomp > https://bugs.openjdk.java.net/secure/attachment/23184/failed_Xcomp.log > https://bugs.openjdk.java.net/secure/attachment/23186/fixed_Xcomp.log > From mikael.gerdin at oracle.com Wed Oct 29 16:25:03 2014 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 29 Oct 2014 17:25:03 +0100 Subject: [9] RFR (S): 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv In-Reply-To: <5450F261.60400@oracle.com> References: <5450F261.60400@oracle.com> Message-ID: <545114DF.7040005@oracle.com> Hi Vladimir, On 2014-10-29 14:57, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8060147/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8060147 > > ciObjectFactory doesn't keep cached Metadata* alive. ciMetadata is > different from ciObject - it doesn't store JNI handle, but a raw > Metadata* pointer. > > In order to avoid Metadata* vanishing during compilation, I cache > ciObject for it's holder, which should keep corresponding Metadata* > alive. Cached objects have the same lifetime as the owning > ciObjectFactory (no cache pruning), so Metadata* will be available as > long as ciObjectFactory instance is used. > > Also, cleaned relevant comments and strengthened some asserts (since > NULL keys are not allowed). > > Testing: jprt, stress mode - full Nashorn/Octane with aggressive VM > anonymous class unloading (LambdaForm/MethodHandle caching completely > turned off). Have you tried this with G1? I'm asking because G1's concurrent marking algorithm behaves slightly different to the other gcs, and I'm unsure if you need to also need to call G1SATBCardTableModRefBS::enqueue (like ensure_metadata_alive does). When implementing class unloading for G1 we saw some similar crashes and I think I redeemed them by calling ensure_metadata_alive for Metadata retrieved from the MDO's (since MDO's are in fact "weak" Metadata references). Essentially, since we have a compilation executing I thought that the reciever of the methods compiled must all be alive, and if the receivers are alive then they should keep all the holders alive. ciInstanceKlass::ciInstanceKlass creates a JNIHandle to the class_loader() of an InstanceKlass being wrapped in the CI, perhaps that should be changed to klass_holder() to account for anonymous classes? /Mikael > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.kozlov at oracle.com Wed Oct 29 17:49:05 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Oct 2014 10:49:05 -0700 Subject: RFR(M): 8044186 Introduce a reproducible random generator In-Reply-To: <5450AD1E.3030407@oracle.com> References: <54218BFA.7020803@oracle.com> <542285EC.408@oracle.com> <54228A50.6080406@oracle.com> <5422D36E.9060002@oracle.com> <7DC5F0F7-15A1-4FFD-BCE8-5E857138E25C@oracle.com> <5450AD1E.3030407@oracle.com> Message-ID: <54512891.5070705@oracle.com> Hi Sergei, Please create webrev of differences between last webrev.03, which we reviewed, and new webrev.00. Thanks, Vladimir On 10/29/14 2:02 AM, Sergei Kovalev wrote: > Hello team. > > Next round of review: > > http://cr.openjdk.java.net/~iignatyev/skovalev/8044186/webrev.00/ > > Main changes: > - introduced new test that testing new testlibrary functionality: > test/testlibrary_tests/RandomGeneratorTest.java > - slightly improved Utility.java in part of SEED variable access. > > All affected tests passed locally on Linux host. > > On 24.09.2014 22:36, Igor Veresov wrote: >> Looks good. >> >> igor >> >> On Sep 24, 2014, at 7:21 AM, Sergei Kovalev >> wrote: >> >>> Update: http://cr.openjdk.java.net/~vlivanov/kovalev/8044186/webrev.03/ >>> >>> Added new testcase test/testlibrary_tests/RandomGeneratorTest.java >>> that verify correctness of work for Utils.getRandomInstance() method. >>> >>> On 24.09.2014 13:09, Sergei Kovalev wrote: >>>> Update: http://cr.openjdk.java.net/~vlivanov/kovalev/8044186/webrev.02/ >>>> >>>> Added new test. >>>> Fixed misprint. >>>> >>>> On 24.09.2014 12:50, Vladimir Ivanov wrote: >>>>> Sergei, >>>>> >>>>> Please, update recently introduced >>>>> test/compiler/unsafe/UnsafeRaw.java. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> On 9/23/14, 7:04 PM, Sergei Kovalev wrote: >>>>>> Hello all, >>>>>> >>>>>> Looking for volunteers for review. >>>>>> >>>>>> I'm working for CR >>>>>> https://bugs.openjdk.java.net/browse/JDK-8044186 that >>>>>> submitted against tests. >>>>>> >>>>>> There's the several tests which use randomly generated numbers. It's >>>>>> needed to introduce a way that provide a common manner to >>>>>> reproduce the >>>>>> same random sequence, set seed. >>>>>> >>>>>> There are two possible way to provide seed value: >>>>>> - system property >>>>>> - command line arguments. >>>>>> >>>>>> I chose system property to provide seed value because it could be >>>>>> obtained in any part of code without additional effort. In case >>>>>> passing >>>>>> seed value as command line argument we have to introduce additional >>>>>> logic (and unwanted code) to pass this value in appropriate method. >>>>>> >>>>>> I introduced factory method getRandomInstance in the file >>>>>> Utility.java >>>>>> and make reference to this method in all applicable tests. >>>>>> There is other utility class: Verifier.java. It used in several other >>>>>> testcases from test/compiler/intrinsics/mathexact/ package. Therefore >>>>>> many files contains modifications only for jtreg annotations. >>>>>> >>>>>> I've tested all related tests locally. All tests passed and seed >>>>>> value >>>>>> printed to the logs. >>>>>> >>>>>> links: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044186 >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~vlivanov/kovalev/8044186/webrev.01/ >>>>>> >>>>> >>> -- >>> With best regards, >>> Sergei >>> >> >> > From bertrand.delsart at oracle.com Wed Oct 29 17:55:05 2014 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Wed, 29 Oct 2014 18:55:05 +0100 Subject: [9] RFR (S): 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv In-Reply-To: <54510228.4040207@oracle.com> References: <5450F261.60400@oracle.com> <545106B8.4060305@oracle.com> <54510228.4040207@oracle.com> Message-ID: <545129F9.7020104@oracle.com> Got it, I had forgotten that the GC no longer needs to walk the metadata by default and now understand why you need to instead explicitly keep the Java holder alive. Looks good, Bertrand, not a Reviewer. On 29/10/14 16:05, Vladimir Ivanov wrote: > Bertrand, > > Thanks for the review. > > There's another mechanism to support class redefinition - > MetadataOnStackMark. It iterates over all threads and sets on_stack bit > on every Metadata* it encounters. It keeps metadata from clearing. > > Eventually, it calls ciObjectFactory::metadata_do() for every compiler > thread which marks all Metadata* in associated > ciObjectFactory::_ci_metadata. > > Best regards, > Vladimir Ivanov > > On 10/29/14, 7:24 PM, Bertrand Delsart wrote: >> Hi Vladimir, >> >> This seems OK with respect to class unloading but what about class >> redefinition ? >> >> In particular, this may not be sufficient for Method* or MethodData*. >> Still catching up on runtime issues but I think a redefined method has a >> smaller lifetime than its holder class. Hence, it seems that keeping the >> holder klass alive may not be sufficient to ensure a Method* survives as >> long as you need it for the ciMetadata. >> >> Regards, >> >> Bertrand. >> >> On 29/10/14 14:57, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8060147/webrev.00 >>> https://bugs.openjdk.java.net/browse/JDK-8060147 >>> >>> ciObjectFactory doesn't keep cached Metadata* alive. ciMetadata is >>> different from ciObject - it doesn't store JNI handle, but a raw >>> Metadata* pointer. >>> >>> In order to avoid Metadata* vanishing during compilation, I cache >>> ciObject for it's holder, which should keep corresponding Metadata* >>> alive. Cached objects have the same lifetime as the owning >>> ciObjectFactory (no cache pruning), so Metadata* will be available as >>> long as ciObjectFactory instance is used. >>> >>> Also, cleaned relevant comments and strengthened some asserts (since >>> NULL keys are not allowed). >>> >>> Testing: jprt, stress mode - full Nashorn/Octane with aggressive VM >>> anonymous class unloading (LambdaForm/MethodHandle caching completely >>> turned off). >>> >>> Thanks! >>> >>> Best regards, >>> Vladimir Ivanov >> >> -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38334 Saint Ismier, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From vladimir.kozlov at oracle.com Wed Oct 29 20:14:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Oct 2014 13:14:56 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <544ACB53.5050700@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> <544ACB53.5050700@oracle.com> Message-ID: <54514AC0.7000605@oracle.com> I hope it is the final version. http://cr.openjdk.java.net/~kvn/8054492/webrev.02/ Full blown intrinsic is created for Class.cast(). It tries, first, to fold statically the code. If it can't, it calls gen_checkcast() and generate uncommon trap when the exception have to be thrown. Also if we hit uncommon trap too match it will not generate instrinsic with dynamic checks during recompilation, but it still tries to fold it statically. Since the intrinsic can be skipped I marked Class.cast() as force_inline method to make sure it is inlined to propagate checkcast information in compiled code. An additional improvement could be made to type checks in intrinsics if we use speculative types. I filed RFE: https://bugs.openjdk.java.net/browse/JDK-8062477 I added new regression test and added compile_id to WB nmethod information. Tested jtreg hotspot and jtreg j/l/invoke from jdk, CTW, JPRT, performance. Nashorn's Octane-Box2D and Octane-DeltaBlue shows few percents improvement. Thanks, Vladimir On 10/24/14 2:57 PM, Vladimir Kozlov wrote: > On 10/23/14 3:45 AM, Paul Sandoz wrote: >> Hi Vladimir, >> >> Do you consider these two aspects (intrinsic and inline) closely >> interrelated do as to be considered under the same issue? If not i can >> log another issue for the inlining. > > I am working on next version of my intrinsic after discussion with John > Rose. It will use gen_checkcast() code which we use for checkcast > bytecode. It will be more general code and less dependable on inlining. > But I still want to do force inlining Call.cast() in more general case > when we can still use profiling data. > > I am concern about changes in castReference() to use Class.cast(). It > will need additional performance testing because it was big performance > bottleneck for jsr292. And I don't want to cause regression. > > Thanks, > Vladimir > >> >> Paul. >> >> On Oct 23, 2014, at 7:09 AM, Vladimir Kozlov >> wrote: >> >>> On 10/22/14 2:29 AM, Paul Sandoz wrote: >>>> On Oct 22, 2014, at 10:54 AM, Roland Westrelin >>>> wrote: >>>>>> Here is intrinsic implementation: >>>>>> >>>>>> http://cr.openjdk.java.net/~kvn/8054492/webrev.01/ >>>>> >>>>> That looks good to me. >>>>> >>>> Same here. >>>> >>>> On Oct 22, 2014, at 2:02 AM, Vladimir Kozlov >>>> wrote: >>>>> Paul, is it enough for you? >>>>> >>>> >>>> Yes, many thanks. I verified in a number of scenarios. >>>> >>>> With Class.cast intrinsified can we can replace uses of following >>>> method in j.l.i.MethodHandleImpl with Class.cast? >>> >>> Intrinsic is not enough. That code was added because we do not inline >>> Class.cast() for deep call stacks. C2 has inline depth limit 9. But >>> we can workaround using next changes: >>> >>> --- a/src/share/vm/opto/bytecodeInfo.cpp Fri Aug 22 09:55:49 2014 >>> -0700 >>> +++ b/src/share/vm/opto/bytecodeInfo.cpp Wed Oct 22 22:07:21 2014 >>> -0700 >>> @@ -161,6 +161,7 @@ >>> if ((freq >= InlineFrequencyRatio) || >>> (call_site_count >= InlineFrequencyCount) || >>> is_unboxing_method(callee_method, C) || >>> + (callee_method->intrinsic_id() == vmIntrinsics::_class_cast) || >>> is_init_with_ea(callee_method, caller_method, C)) { >>> >>> max_inline_size = C->freq_inline_size(); >>> @@ -262,6 +263,11 @@ >>> return false; >>> } >>> >>> + if (callee_method->intrinsic_id() == vmIntrinsics::_class_cast) { >>> + // Inline Class.cast() method. >>> + return false; >>> + } >>> + >>> if (callee_method->has_compiled_code() && >>> callee_method->instructions_size() > InlineSmallCode) { >>> set_msg("already compiled into a big method"); >>> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> @ForceInline >>>> @SuppressWarnings("unchecked") >>>> static T castReference(Class t, U x) { >>>> // inlined Class.cast because we can't ForceInline it >>>> if (x != null && !t.isInstance(x)) >>>> throw newClassCastException(t, x); >>>> return (T) x; >>>> } >>>> >>>> Paul. >>>> >> From igor.veresov at oracle.com Wed Oct 29 21:37:18 2014 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 29 Oct 2014 11:37:18 -1000 Subject: [9] RFR(S): 8062169: Multiple OSR compilations issued for same bci In-Reply-To: <5451110C.3050604@oracle.com> References: <5450FFA5.3080804@oracle.com> <5451110C.3050604@oracle.com> Message-ID: <1337ED36-D7BA-4402-9DDE-87A80E437B86@oracle.com> Looks good to me. igor On Oct 29, 2014, at 6:08 AM, Vladimir Kozlov wrote: > This looks reasonable to me but Igor is more familiar with this. > > Thanks, > Vladimir > > On 10/29/14 7:54 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8062169 >> Webrev: http://cr.openjdk.java.net/~thartmann/8062169/webrev.00/ >> >> Summary: >> An existing OSR nmethod blocks OSR for the same method at other BCIs. >> >> Problem: >> The method 'triggerOSR' contains two loops to trigger OSR compilations. The >> first loop triggers an OSR compilation at BCI 59 and comp level 4. While >> executing the second loop an OSR compilation at BCI 89 and comp level 3 is >> triggered [1]. We then check if the event led to a higher level OSR compilation >> by checking if the 'highest_osr_comp_level()' is greater than the current >> compilation level (in this case 0 since we are interpreting) and if so perform >> an OSR [2]. The problem is that 'highest_osr_comp_level()' is independent of the >> BCI and therefore returns 4 (because of the existing OSR nmethod at BCI 59). The >> following lookup for an OSR nmethod at BCI 89 fails and no OSR is performed. The >> interpreter continues executing the method until the backbranch event is >> triggered again and we start right from the beginning. However, we do not issue >> a new OSR compilation but fail to perform OSR with the existing OSR nmethod. >> This repeats until we finally decide to OSR compile at level 4 (see log [3]). >> >> With -Xcomp it's even worse because we issue a new compilation every time. This >> is because a compilation at level 3 is requested but an in-queue update changes >> it to level 2 (see 'AdvancedThresholdPolicy::select_task'). The next time the >> compilation is requested we search for existing level 3 compilations, do not >> find any and therefore issue a new compilation at level 3 that is then changed >> to 2 again. In this case, we issue approximately 40 OSR compilations but never >> use them until we finally OSR compile at level 4 (see log [4]). >> >> Solution: >> I changed 'SimpleThresholdPolicy::event' such that it does not use >> 'highest_osr_comp_level()' for the lookup but the current comp level. Like this, >> we always perform OSR if there is an OSR nmethod available for the current BCI >> that has a higher compilation. I also checked the other usages of >> 'highest_osr_comp_level()' and they seem to be fine. >> >> Testing >> JPRT + DeoptimizeMultipleOSRTest >> >> Thanks, >> Tobias >> >> >> [1] 'SimpleThresholdPolicy::event' invokes >> 'AdvancedThresholdPolicy::method_back_branch_event' >> [2] simpleThresholdPolicy.cpp lines 215f >> [3] Logs (note missing 'OSR entry @ pc' in failed.log showing that no OSR is >> performed) >> https://bugs.openjdk.java.net/secure/attachment/23183/failed.log >> https://bugs.openjdk.java.net/secure/attachment/23185/fixed.log >> [4] Logs with -Xcomp >> https://bugs.openjdk.java.net/secure/attachment/23184/failed_Xcomp.log >> https://bugs.openjdk.java.net/secure/attachment/23186/fixed_Xcomp.log >> From john.r.rose at oracle.com Wed Oct 29 21:51:42 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 29 Oct 2014 14:51:42 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <54514AC0.7000605@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> <544ACB53.5050700@oracle.com> <54514AC0.7000605@oracle.com> Message-ID: On Oct 29, 2014, at 1:14 PM, Vladimir Kozlov wrote: > I hope it is the final version. > > http://cr.openjdk.java.net/~kvn/8054492/webrev.02/ > > Full blown intrinsic is created for Class.cast(). It tries, first, to fold statically the code. If it can't, it calls gen_checkcast() and generate uncommon trap when the exception have to be thrown. Also if we hit uncommon trap too match it will not generate instrinsic with dynamic checks during recompilation, but it still tries to fold it statically. > > Since the intrinsic can be skipped I marked Class.cast() as force_inline method to make sure it is inlined to propagate checkcast information in compiled code. Good. Suggest a comment like: set_intrinsic_id(id); + if (id == vmIntrinsics::_class_cast) { ++ // even if the intrinsic is rejected, we want to inline this simple method + set_force_inline(true); + } return; Nit: should be "_Class_cast" not "_class_cast" (cf. _Short_valueOf etc.). + // Don't use intrinsic, have to throw ClassCastException. Suggest additional comment: ++ // If the reference is null, the non-intrinsic bytecode will optimize appropriately. A similar point probably applies to the !is_loaded case which you handle next. Suggest just bailing out of the intrinsic for that case, same as SSC_always_false. That might simplify the code. Good test, although I have a sneaking suspicion that nobody is testing corner cases like: int.class.cast(null); // OK int.class.cast(42); // CCE int != Integer I suggest doing a little informal coverage analysis to make sure your new code branches get exercised. It looks good; count me a reviewer. > An additional improvement could be made to type checks in intrinsics if we use speculative types. I filed RFE: > https://bugs.openjdk.java.net/browse/JDK-8062477 Thanks for filing that. > > I added new regression test and added compile_id to WB nmethod information. > > Tested jtreg hotspot and jtreg j/l/invoke from jdk, CTW, JPRT, performance. > > Nashorn's Octane-Box2D and Octane-DeltaBlue shows few percents improvement. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Thu Oct 30 00:02:57 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 30 Oct 2014 03:02:57 +0300 Subject: RFR(XS) : 8036913 : make DeoptimizeALot dependent on number of threads In-Reply-To: <5450FE21.40106@oracle.com> References: <544FDEE0.2040105@oracle.com> <544FE35D.5080003@oracle.com> <5450F04D.9030703@oracle.com> <5450FE21.40106@oracle.com> Message-ID: <54518031.2060102@oracle.com> Vladimir/Aleksey, thanks for review. the updated webrev w/ the comment: http://cr.openjdk.java.net/~iignatyev/8036913/webrev.01/ 11 lines changed: 3 ins; 3 del; 5 mod; Igor On 10/29/2014 05:48 PM, Vladimir Kozlov wrote: > Igor, > > On 10/29/14 6:49 AM, Igor Ignatyev wrote: >> Aleksey, >> >> zombie/deoptimizeAllCounter are invocation counters of corresponding >> function and not counters of the actually happened >> events. so they should be incremented on each invocation of the function. > > Please, add this explanation as a comment so it would be clear why you > divide by number of threads. > Changes are fine with that. > > Thanks, > Vladimir > >> >> Thanks >> Igor >> >> On 10/28/2014 09:41 PM, Aleksey Shipilev wrote: >>> On 28.10.2014 21:22, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev/8036913/webrev.00/ >>>> 8 lines changed: 2 ins; 2 del; 4 mod; >>> >>> Looks good. >>> >>>> + zombieAllCounter incrementation is moved out of if-else to be aligned >>>> w/ deoptimizeAllCounter >>> >>> Shouldn't it be in reverse, i.e. deoptimizeAllCounter to be moved in the >>> block? I would think counting the _successful_ deoptimizeAll/zombieAll >>> events is more useful. >>> >>> -Aleksey. >>> >>> From vladimir.kozlov at oracle.com Thu Oct 30 00:29:48 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Oct 2014 17:29:48 -0700 Subject: RFR(XS) : 8036913 : make DeoptimizeALot dependent on number of threads In-Reply-To: <54518031.2060102@oracle.com> References: <544FDEE0.2040105@oracle.com> <544FE35D.5080003@oracle.com> <5450F04D.9030703@oracle.com> <5450FE21.40106@oracle.com> <54518031.2060102@oracle.com> Message-ID: <5451867C.2080202@oracle.com> I thought about something like next comment in places where you add division: void InterfaceSupport::zombieAll() { // This method is called by all threads when a thread make // transition to VM state (for example, runtime calls). // Divide number of calls by number of threads to avoid // dependence of ZombieAll events on number of threads. int value = zombieAllCounter / Threads::number_of_threads(); Thanks, Vladimir On 10/29/14 5:02 PM, Igor Ignatyev wrote: > Vladimir/Aleksey, > > thanks for review. > > the updated webrev w/ the comment: > http://cr.openjdk.java.net/~iignatyev/8036913/webrev.01/ > 11 lines changed: 3 ins; 3 del; 5 mod; > > Igor > > On 10/29/2014 05:48 PM, Vladimir Kozlov wrote: >> Igor, >> >> On 10/29/14 6:49 AM, Igor Ignatyev wrote: >>> Aleksey, >>> >>> zombie/deoptimizeAllCounter are invocation counters of corresponding >>> function and not counters of the actually happened >>> events. so they should be incremented on each invocation of the >>> function. >> >> Please, add this explanation as a comment so it would be clear why you >> divide by number of threads. >> Changes are fine with that. >> >> Thanks, >> Vladimir >> >>> >>> Thanks >>> Igor >>> >>> On 10/28/2014 09:41 PM, Aleksey Shipilev wrote: >>>> On 28.10.2014 21:22, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev/8036913/webrev.00/ >>>>> 8 lines changed: 2 ins; 2 del; 4 mod; >>>> >>>> Looks good. >>>> >>>>> + zombieAllCounter incrementation is moved out of if-else to be >>>>> aligned >>>>> w/ deoptimizeAllCounter >>>> >>>> Shouldn't it be in reverse, i.e. deoptimizeAllCounter to be moved in >>>> the >>>> block? I would think counting the _successful_ deoptimizeAll/zombieAll >>>> events is more useful. >>>> >>>> -Aleksey. >>>> >>>> From igor.ignatyev at oracle.com Thu Oct 30 03:01:09 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 30 Oct 2014 06:01:09 +0300 Subject: RFR(S) : 8043125 : compiler/types/correctness/CorrectnessTest.java: assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type Message-ID: <5451A9F5.2060207@oracle.com> http://cr.openjdk.java.net/~iignatyev/8043125/webrev.00/ 12 lines changed: 0 ins; 10 del; 2 mod; Hi all, Please review patch: Problem: WB_ClearMethodState triggers VM_WhiteBoxCleanMethodData which cleans all profile entries. Though WhiteBoxCleanMethodData requires a safepoint, this clean may happen during SpeculativeTrapData translation (in ciMethodData::load_extra_data) and entries being translated are then removed. Fix: instead of using VM operation, ClearMethodState holds the lock on methodData:extra_data_lock(). // ciMethodData::load_extra_data() holds the same lock. jbs: https://jbs.oracle.com/bugs/browse/JDK-8043125 testing: - jprt - compiler/types/correctness/CorrectnessTest.java a hundred times -- Igor From vladimir.kozlov at oracle.com Thu Oct 30 03:47:30 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Oct 2014 20:47:30 -0700 Subject: RFR(S) : 8043125 : compiler/types/correctness/CorrectnessTest.java: assert(layout->tag() == DataLayout::speculative_trap_data_tag) failed: wrong type In-Reply-To: <5451A9F5.2060207@oracle.com> References: <5451A9F5.2060207@oracle.com> Message-ID: <5451B4D2.4010202@oracle.com> Looks good. Thanks, Vlaidmir On 10/29/14 8:01 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8043125/webrev.00/ > 12 lines changed: 0 ins; 10 del; 2 mod; > > Hi all, > > Please review patch: > > Problem: > WB_ClearMethodState triggers VM_WhiteBoxCleanMethodData which cleans all > profile entries. Though WhiteBoxCleanMethodData requires a safepoint, > this clean may happen during SpeculativeTrapData translation (in > ciMethodData::load_extra_data) and entries being translated are then > removed. > > Fix: > instead of using VM operation, ClearMethodState holds the lock on > methodData:extra_data_lock(). > // ciMethodData::load_extra_data() holds the same lock. > > jbs: https://jbs.oracle.com/bugs/browse/JDK-8043125 > testing: > - jprt > - compiler/types/correctness/CorrectnessTest.java a hundred times From vladimir.kozlov at oracle.com Thu Oct 30 03:54:56 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Oct 2014 20:54:56 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> <544ACB53.5050700@oracle.com> <54514AC0.7000605@oracle.com> Message-ID: <5451B690.9040309@oracle.com> Thank you, John Updated webrev: http://cr.openjdk.java.net/~kvn/8054492/webrev.03/ On 10/29/14 2:51 PM, John Rose wrote: > On Oct 29, 2014, at 1:14 PM, Vladimir Kozlov > wrote: > >> I hope it is the final version. >> >> http://cr.openjdk.java.net/~kvn/8054492/webrev.02/ >> >> Full blown intrinsic is created for Class.cast(). It tries, first, to >> fold statically the code. If it can't, it calls gen_checkcast() and >> generate uncommon trap when the exception have to be thrown. Also if >> we hit uncommon trap too match it will not generate instrinsic with >> dynamic checks during recompilation, but it still tries to fold it >> statically. >> >> Since the intrinsic can be skipped I marked Class.cast() as >> force_inline method to make sure it is inlined to propagate checkcast >> information in compiled code. > > Good. Suggest a comment like: > set_intrinsic_id(id); > + if (id == vmIntrinsics::_class_cast) { > ++ // even if the intrinsic is rejected, we want to inline this > simple method > + set_force_inline(true); > + } > return; Comment is added. > > Nit: should be "_Class_cast" not "_class_cast" (cf. _Short_valueOf etc.). Renamed. > > + // Don't use intrinsic, have to throw ClassCastException. > Suggest additional comment: > ++ // If the reference is null, the non-intrinsic bytecode will > optimize appropriately. Added. > > A similar point probably applies to the !is_loaded case which you handle > next. > Suggest just bailing out of the intrinsic for that case, same > as SSC_always_false. > That might simplify the code. Agree. > > Good test, although I have a sneaking suspicion that nobody is testing > corner cases like: > int.class.cast(null); // OK > int.class.cast(42); // CCE int != Integer > I suggest doing a little informal coverage analysis to make sure your > new code branches get exercised. I added new test methods. Thanks, Vladimir > > It looks good; count me a reviewer. > >> An additional improvement could be made to type checks in intrinsics >> if we use speculative types. I filed RFE: >> https://bugs.openjdk.java.net/browse/JDK-8062477 > > Thanks for filing that. >> >> I added new regression test and added compile_id to WB nmethod >> information. >> >> Tested jtreg hotspot and jtreg j/l/invoke from jdk, CTW, JPRT, >> performance. >> >> Nashorn's Octane-Box2D and Octane-DeltaBlue shows few percents >> improvement. >> > From john.r.rose at oracle.com Thu Oct 30 06:08:27 2014 From: john.r.rose at oracle.com (John Rose) Date: Wed, 29 Oct 2014 23:08:27 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <5451B690.9040309@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> <544ACB53.5050700@oracle.com> <54514AC0.7000605@oracle.com> <5451B690.9040309@oracle.com> Message-ID: <268DE38F-F78A-413F-90F1-F6F6DC053889@oracle.com> On Oct 29, 2014, at 8:54 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8054492/webrev.03/ That's it, except a couple more comments on testing: I would prefer a cast against int.class (more useful than int[].class). It should get a CCE like int[], but exercise a different path through the optimizer. So: -187 asink = int[].class.cast(s); +187.1 asink = int.class.cast(s); +187.2 throw new AssertionError("not reached"); 188 } catch (ClassCastException t) { 189 // Ignore ClassCastException: Cannot cast java.lang.String to [I The assertion error can go in spots where an exception is expected, just to make sure the JIT doesn't allow the cast by accident. Thanks! ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Oct 30 08:05:08 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Oct 2014 01:05:08 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <268DE38F-F78A-413F-90F1-F6F6DC053889@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> <544ACB53.5050700@oracle.com> <54514AC0.7000605@oracle.com> <5451B690.9040309@oracle.com> <268DE38F-F78A-413F-90F1-F6F6DC053889@oracle.com> Message-ID: <5451F134.1030900@oracle.com> Thank you, John! I added AssertionError as you suggested. And I added new tests for int.class.cast and null.cast. http://cr.openjdk.java.net/~kvn/8054492/webrev.04/ Thanks, Vladimir On 10/29/14 11:08 PM, John Rose wrote: > On Oct 29, 2014, at 8:54 PM, Vladimir Kozlov > wrote: > >> http://cr.openjdk.java.net/~kvn/8054492/webrev.03/ > > That's it, except a couple more comments on testing: > > I would prefer a cast against int.class (more useful than int[].class). It should get a CCE like int[], but exercise a > different path through the optimizer. So: > > -187 asink = int[].class.cast(s); > +187.1 asink = int.class.cast(s); > +187.2 throw new AssertionError("not reached"); > 188 } catch (ClassCastException t) { > 189 // Ignore ClassCastException: Cannot cast java.lang.String to [I > > The assertion error can go in spots where an exception is expected, just to make sure the JIT doesn't allow the cast by > accident. > > Thanks! > ? John From tobias.hartmann at oracle.com Thu Oct 30 08:19:37 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 30 Oct 2014 09:19:37 +0100 Subject: [9] RFR(S): 8062169: Multiple OSR compilations issued for same bci In-Reply-To: <1337ED36-D7BA-4402-9DDE-87A80E437B86@oracle.com> References: <5450FFA5.3080804@oracle.com> <5451110C.3050604@oracle.com> <1337ED36-D7BA-4402-9DDE-87A80E437B86@oracle.com> Message-ID: <5451F499.9010409@oracle.com> Vladimir, Igor, thanks for the reviews. Best, Tobias On 29.10.2014 22:37, Igor Veresov wrote: > Looks good to me. > > igor > > On Oct 29, 2014, at 6:08 AM, Vladimir Kozlov wrote: > >> This looks reasonable to me but Igor is more familiar with this. >> >> Thanks, >> Vladimir >> >> On 10/29/14 7:54 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8062169 >>> Webrev: http://cr.openjdk.java.net/~thartmann/8062169/webrev.00/ >>> >>> Summary: >>> An existing OSR nmethod blocks OSR for the same method at other BCIs. >>> >>> Problem: >>> The method 'triggerOSR' contains two loops to trigger OSR compilations. The >>> first loop triggers an OSR compilation at BCI 59 and comp level 4. While >>> executing the second loop an OSR compilation at BCI 89 and comp level 3 is >>> triggered [1]. We then check if the event led to a higher level OSR compilation >>> by checking if the 'highest_osr_comp_level()' is greater than the current >>> compilation level (in this case 0 since we are interpreting) and if so perform >>> an OSR [2]. The problem is that 'highest_osr_comp_level()' is independent of the >>> BCI and therefore returns 4 (because of the existing OSR nmethod at BCI 59). The >>> following lookup for an OSR nmethod at BCI 89 fails and no OSR is performed. The >>> interpreter continues executing the method until the backbranch event is >>> triggered again and we start right from the beginning. However, we do not issue >>> a new OSR compilation but fail to perform OSR with the existing OSR nmethod. >>> This repeats until we finally decide to OSR compile at level 4 (see log [3]). >>> >>> With -Xcomp it's even worse because we issue a new compilation every time. This >>> is because a compilation at level 3 is requested but an in-queue update changes >>> it to level 2 (see 'AdvancedThresholdPolicy::select_task'). The next time the >>> compilation is requested we search for existing level 3 compilations, do not >>> find any and therefore issue a new compilation at level 3 that is then changed >>> to 2 again. In this case, we issue approximately 40 OSR compilations but never >>> use them until we finally OSR compile at level 4 (see log [4]). >>> >>> Solution: >>> I changed 'SimpleThresholdPolicy::event' such that it does not use >>> 'highest_osr_comp_level()' for the lookup but the current comp level. Like this, >>> we always perform OSR if there is an OSR nmethod available for the current BCI >>> that has a higher compilation. I also checked the other usages of >>> 'highest_osr_comp_level()' and they seem to be fine. >>> >>> Testing >>> JPRT + DeoptimizeMultipleOSRTest >>> >>> Thanks, >>> Tobias >>> >>> >>> [1] 'SimpleThresholdPolicy::event' invokes >>> 'AdvancedThresholdPolicy::method_back_branch_event' >>> [2] simpleThresholdPolicy.cpp lines 215f >>> [3] Logs (note missing 'OSR entry @ pc' in failed.log showing that no OSR is >>> performed) >>> https://bugs.openjdk.java.net/secure/attachment/23183/failed.log >>> https://bugs.openjdk.java.net/secure/attachment/23185/fixed.log >>> [4] Logs with -Xcomp >>> https://bugs.openjdk.java.net/secure/attachment/23184/failed_Xcomp.log >>> https://bugs.openjdk.java.net/secure/attachment/23186/fixed_Xcomp.log >>> > From vladimir.x.ivanov at oracle.com Thu Oct 30 10:14:56 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 30 Oct 2014 14:14:56 +0400 Subject: [9] RFR (S): 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv In-Reply-To: <4B1E9213-DC7E-47CA-A79F-66C8A2873E18@oracle.com> References: <5450F261.60400@oracle.com> <4B1E9213-DC7E-47CA-A79F-66C8A2873E18@oracle.com> Message-ID: <54520FA0.3000208@oracle.com> Roland, Thanks for the feedback. >> http://cr.openjdk.java.net/~vlivanov/8060147/webrev.00 >> https://bugs.openjdk.java.net/browse/JDK-8060147 >> >> ciObjectFactory doesn't keep cached Metadata* alive. ciMetadata is different from ciObject - it doesn't store JNI handle, but a raw Metadata* pointer. > > What kind of ciMetadata do you observe being unloaded? I saw that ciMethod for a method from VM anonymous class went away. But that's what my stress test does - unloads VM anonymous classes a lot. > For instance, if I remember correctly ciInstanceKlass is kept alive by storing a handle to the loader object of the instance klass. Thanks for the pointer! I missed that. It should work for ciInstanceKlass & ciMethod with regular classes. VM anonymous classes have loader == NULL, so class holder (java_mirror()) should be used instead. Also, I don't see how ciMethodData keeps relevant MethodData from unloading. Regarding the fix, I can add special cases for VM anonymous classes & MethodData or keep it as is (more explicit). What do people think? Best regards, Vladimir Ivanov From sergei.kovalev at oracle.com Thu Oct 30 11:57:06 2014 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Thu, 30 Oct 2014 14:57:06 +0300 Subject: RFR(M): 8044186 Introduce a reproducible random generator In-Reply-To: <54512891.5070705@oracle.com> References: <54218BFA.7020803@oracle.com> <542285EC.408@oracle.com> <54228A50.6080406@oracle.com> <5422D36E.9060002@oracle.com> <7DC5F0F7-15A1-4FFD-BCE8-5E857138E25C@oracle.com> <5450AD1E.3030407@oracle.com> <54512891.5070705@oracle.com> Message-ID: <54522792.5010106@oracle.com> Hi Vladimir, Would you like to see webrev or diff would be enough? Just in case diff is ok, I'm attaching it. If you'd like published webrev, please let me know. On 29.10.2014 20:49, Vladimir Kozlov wrote: > Hi Sergei, > > Please create webrev of differences between last webrev.03, which we > reviewed, and new webrev.00. > > Thanks, > Vladimir > > On 10/29/14 2:02 AM, Sergei Kovalev wrote: >> Hello team. >> >> Next round of review: >> >> http://cr.openjdk.java.net/~iignatyev/skovalev/8044186/webrev.00/ >> >> Main changes: >> - introduced new test that testing new testlibrary functionality: >> test/testlibrary_tests/RandomGeneratorTest.java >> - slightly improved Utility.java in part of SEED variable access. >> >> All affected tests passed locally on Linux host. >> >> On 24.09.2014 22:36, Igor Veresov wrote: >>> Looks good. >>> >>> igor >>> >>> On Sep 24, 2014, at 7:21 AM, Sergei Kovalev >>> wrote: >>> >>>> Update: >>>> http://cr.openjdk.java.net/~vlivanov/kovalev/8044186/webrev.03/ >>>> >>>> Added new testcase test/testlibrary_tests/RandomGeneratorTest.java >>>> that verify correctness of work for Utils.getRandomInstance() method. >>>> >>>> On 24.09.2014 13:09, Sergei Kovalev wrote: >>>>> Update: >>>>> http://cr.openjdk.java.net/~vlivanov/kovalev/8044186/webrev.02/ >>>>> >>>>> Added new test. >>>>> Fixed misprint. >>>>> >>>>> On 24.09.2014 12:50, Vladimir Ivanov wrote: >>>>>> Sergei, >>>>>> >>>>>> Please, update recently introduced >>>>>> test/compiler/unsafe/UnsafeRaw.java. >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>>>> >>>>>> On 9/23/14, 7:04 PM, Sergei Kovalev wrote: >>>>>>> Hello all, >>>>>>> >>>>>>> Looking for volunteers for review. >>>>>>> >>>>>>> I'm working for CR >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8044186 that >>>>>>> submitted against tests. >>>>>>> >>>>>>> There's the several tests which use randomly generated numbers. >>>>>>> It's >>>>>>> needed to introduce a way that provide a common manner to >>>>>>> reproduce the >>>>>>> same random sequence, set seed. >>>>>>> >>>>>>> There are two possible way to provide seed value: >>>>>>> - system property >>>>>>> - command line arguments. >>>>>>> >>>>>>> I chose system property to provide seed value because it could be >>>>>>> obtained in any part of code without additional effort. In case >>>>>>> passing >>>>>>> seed value as command line argument we have to introduce additional >>>>>>> logic (and unwanted code) to pass this value in appropriate method. >>>>>>> >>>>>>> I introduced factory method getRandomInstance in the file >>>>>>> Utility.java >>>>>>> and make reference to this method in all applicable tests. >>>>>>> There is other utility class: Verifier.java. It used in several >>>>>>> other >>>>>>> testcases from test/compiler/intrinsics/mathexact/ package. >>>>>>> Therefore >>>>>>> many files contains modifications only for jtreg annotations. >>>>>>> >>>>>>> I've tested all related tests locally. All tests passed and seed >>>>>>> value >>>>>>> printed to the logs. >>>>>>> >>>>>>> links: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044186 >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~vlivanov/kovalev/8044186/webrev.01/ >>>>>>> >>>>>> >>>> -- >>>> With best regards, >>>> Sergei >>>> >>> >>> >> > > -- With best regards, Sergei -------------- next part -------------- diff -r 63d7b4f9285b test/compiler/8005956/PolynomialRoot.java --- a/test/compiler/8005956/PolynomialRoot.java Thu Oct 30 14:54:58 2014 +0400 +++ b/test/compiler/8005956/PolynomialRoot.java Thu Oct 30 15:54:47 2014 +0400 @@ -60,7 +60,7 @@ public static int root4(final double [] p,final double [] re_root,final double [] im_root) { - if(PRINT_DEBUG) System.err.println("=====================root4:p="+Arrays.toString(p)); + if (PRINT_DEBUG) { System.err.println("=====================root4:p=" + Arrays.toString(p)); } final double vs=p[4]; if(PRINT_DEBUG) System.err.println("p[4]="+p[4]); if(!(Math.abs(vs)>EPS)) @@ -370,7 +370,7 @@ - static void setRandomP(final double [] p,final int n,Random r) + static void setRandomP(final double [] p, final int n, Random r) { if(r.nextDouble()<0.1) { diff -r 63d7b4f9285b test/testlibrary/com/oracle/java/testlibrary/Utils.java --- a/test/testlibrary/com/oracle/java/testlibrary/Utils.java Thu Oct 30 14:54:58 2014 +0400 +++ b/test/testlibrary/com/oracle/java/testlibrary/Utils.java Thu Oct 30 15:54:47 2014 +0400 @@ -64,7 +64,7 @@ private static Unsafe unsafe = null; /** - * The constant defines property name for seed value. + * Defines property name for seed value. */ public static final String SEED_PROPERTY_NAME = "com.oracle.java.testlibrary.random.seed"; @@ -73,7 +73,11 @@ * "com.oracle.java.testlibrary.random.seed" property value. */ private static volatile Random RANDOM_GENERATOR; - public static final long SEED; + + /** + * Contains the seed value used for {@link java.util.Random} creation. + */ + public static final long SEED = Long.getLong(SEED_PROPERTY_NAME, new Random().nextLong()); /** * Returns the value of 'test.timeout.factor' system property * converted to {@code double}. @@ -82,7 +86,6 @@ static { String toFactor = System.getProperty("test.timeout.factor", "1.0"); TIMEOUT_FACTOR = Double.parseDouble(toFactor); - SEED = Long.valueOf(System.getProperty(SEED_PROPERTY_NAME, "" + new Random().nextLong())); } private Utils() { @@ -346,10 +349,10 @@ } /** - * The method returns {@link java.util.Random} generator with particular seed. - * Seed could be provided via system property com.oracle.java.testlibrary.random.seed. - * In case no seed provided, method will generate random seed. - * The value of used seed printed to logs. + * Returns {@link java.util.Random} generator initialized with particular seed. + * The seed could be provided via system property {@link Utils#SEED_PROPERTY_NAME} + * In case no seed is provided, the method uses a random number. + * The used seed printed to stdout. * @return {@link java.util.Random} generator with particular seed. */ public static Random getRandomInstance() { diff -r 63d7b4f9285b test/testlibrary_tests/RandomGeneratorTest.java --- a/test/testlibrary_tests/RandomGeneratorTest.java Thu Oct 30 14:54:58 2014 +0400 +++ b/test/testlibrary_tests/RandomGeneratorTest.java Thu Oct 30 15:54:47 2014 +0400 @@ -25,9 +25,9 @@ * @test * @summary Verify correctnes of the random generator from Utility.java * @library /testlibrary - * @run main RandomGeneratorTest same - * @run main RandomGeneratorTest noseed - * @run main RandomGeneratorTest different + * @run driver RandomGeneratorTest SAME_SEED + * @run driver RandomGeneratorTest NO_SEED + * @run driver RandomGeneratorTest DIFFERENT_SEED */ import com.oracle.java.testlibrary.ProcessTools; @@ -37,100 +37,119 @@ import java.util.Random; /** - * The test verify correctness of work Utils.getRandonInstance(). - * Test work in three modes: sqme seed provided, no seed provided and - * different seed provided. In first case test expect that all random numbers + * The test verifies correctness of work {@link com.oracle.java.testlibrary.Utils#getRandomInstance()}. + * Test works in three modes: same seed provided, no seed provided and + * different seed provided. In the first case the test expects that all random numbers * will be repeated in all next iterations. For other two modes test expects that - * no one randomly generated long value will repeated in next iterations. - * @author skovalev + * randomly generated numbers differ from original. */ public class RandomGeneratorTest { - private static final String SAME_SEED = "same"; - private static final String NO_SEED = "noseed"; - private static final String DIFFERENT_SEED = "different"; private static final String SEED_VM_OPTION = "-D" + Utils.SEED_PROPERTY_NAME + "="; public static void main( String[] args) throws Throwable { - String mode = NO_SEED; - if (args.length > 0) { - mode = args[0]; + if (args.length == 0) { + throw new Error("TESTBUG: No test mode provided."); } - System.out.printf("<-------- Run test in %s mode ---------------->\n", mode); - SeedOption seedOpt = new SeedOption(mode); + SeedOption seedOpt = SeedOption.valueOf(args[0]); List jvmArgs = new ArrayList(); String optStr = seedOpt.getSeedOption(); - int seedOptsIdx = -1; if (optStr != null) { jvmArgs.add(optStr); - seedOptsIdx = jvmArgs.size() - 1; } jvmArgs.add(RandomRunner.class.getName()); String[] cmdLineArgs = jvmArgs.toArray(new String[jvmArgs.size()]); String etalon = ProcessTools.executeTestJvm(cmdLineArgs).getOutput().trim(); - for (int idx = 0; idx < 10; idx++) { - if (SAME_SEED.equals(mode)) { - ProcessTools.executeTestJvm(cmdLineArgs).shouldMatch(etalon); - } else { - if (DIFFERENT_SEED.equals(mode)) { - jvmArgs.set(seedOptsIdx, seedOpt.getSeedOption()); - cmdLineArgs = jvmArgs.toArray(new String[jvmArgs.size()]); - } - String iterStr = ProcessTools.executeTestJvm(cmdLineArgs).getOutput(); - for (String number : etalon.split("\n")[2].split(" ")) { //first two lines of output contains Utils class output - //therefore we are interested in 3rd line only. - if (iterStr.contains(number)) { - throw new RuntimeException("Number:" + number + " repeated in next iterration."); - } - } + seedOpt.verify(etalon, cmdLineArgs); + } + + /** + * The utility enum helps to generate an appropriate string that should be passed + * to the command line depends on the testing mode. It is also responsible for the result + * validation. + */ + private enum SeedOption { + SAME_SEED { + @Override + public String getSeedOption() { + return SEED_VM_OPTION + Utils.SEED; } + + @Override + protected boolean isOutputExpected(String orig, String output) { + return output.equals(orig); + } + }, + DIFFERENT_SEED { + @Override + public String getSeedOption() { + return SEED_VM_OPTION + Utils.getRandomInstance().nextLong(); + } + + @Override + public void verify(String orig, String[] cmdLine) { + cmdLine[0] = getSeedOption(); + super.verify(orig, cmdLine); + } + }, + NO_SEED { + @Override + public String getSeedOption() { + return null; + } + }; + + /** + * Generates a string to be added as a command line argument. + * It contains "-D" prefix, system property name, '=' sign + * and seed value. + * @return command line argument + */ + public abstract String getSeedOption(); + + protected boolean isOutputExpected(String orig, String output) { + return !output.equals(orig); + } + + /** + * Verifies that the original output meets expectations + * depending on the test mode. It compares the output of second execution + * to original one. + * @param orig original output + * @param cmdLine command line arguments + * @throws Throwable - Throws an exception in case test failure. + */ + public void verify(String orig, String[] cmdLine) { + String lastLineOrig = getLastLine(orig); + String lastLine; + try { + lastLine = getLastLine(ProcessTools.executeTestJvm(cmdLine).getOutput().trim()); + } catch (Throwable t) { + throw new Error("TESTBUG: Unexpedted exception during jvm execution.", t); + } + if (!isOutputExpected(lastLineOrig, lastLine)) { + throw new AssertionError("Unexpected random number sequence for mode: " + this.name()); + } + } + + private static String getLastLine(String output) { + return output.substring(output.lastIndexOf(Utils.NEW_LINE)).trim(); } } /** - * The utility class helps to generate appropriate string that should be passed - * to the command line depends on testing mode. - */ - public static class SeedOption { - private final String mode; - private final long seed = Utils.SEED; - public SeedOption (String value) { - this.mode = value; - } - - /** - * The methods generates a string to be added as an - * command line argument. It contains -D prefix, - * system property name, '=' sight and seed value. - * @return Command line argument - */ - public String getSeedOption() { - switch (mode) { - case SAME_SEED: - return SEED_VM_OPTION + seed; - case DIFFERENT_SEED: - return SEED_VM_OPTION + Utils.getRandomInstance().nextLong(); - default: - throw new IllegalArgumentException("Unsapported test mode: " + mode); - case NO_SEED: - } - return null; - } - } - - /** - * The helper class that gets {@link java.util.Random} class - * from {@link Utils#getRandomInstance()}, generate several random numbers - * and prints it into stdout. + * The helper class generates several random numbers + * and prints them out. */ public static class RandomRunner { - private static int COUNT = 10; + private static final int COUNT = 10; public static void main(String[] args) { StringBuilder sb = new StringBuilder(); Random rng = Utils.getRandomInstance(); - for (int idx = 0; idx < COUNT; idx++) { + for (int i = 0; i < COUNT; i++) { sb.append(rng.nextLong()).append(' '); } System.out.println(sb.toString()); } } -} \ No newline at end of file +} + From vladimir.x.ivanov at oracle.com Thu Oct 30 11:32:55 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 30 Oct 2014 15:32:55 +0400 Subject: [9] RFR (S): 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv In-Reply-To: <54522805.5040701@oracle.com> References: <5450F261.60400@oracle.com> <545114DF.7040005@oracle.com> <54511744.4060904@oracle.com> <5451F43A.1010108@oracle.com> <5452128C.4090408@oracle.com> <54522805.5040701@oracle.com> Message-ID: <545221E7.8040404@oracle.com> Mikael, >> As I wrote to Roland, it seems keeping klass_holder for every >> ciInstanceKlass for VM anonymous classes should solve the problem I >> encountered. It doesn't cover ciMethodData though. > > Ok, I think using klass_holder should be fine for normal classes as > well, since klass_holder returns the class loader oop in that case. I don't think switching from NULL to java_mirror() for VM anonymous classes will work. Some parts of the VM assume it is an instance ClassLoader, not a Class. I thought more about a special case for VM anonymous class - like the first version of the fix I proposed, but applied only to VM anon classes. > Does it need to cover ciMethodData? Since MethodData is allocated in the > ClassLoader's (or VM anon class) metaspace it should have the same > liveness as the Method, and the InstanceKlass and all the other metadata. > > Or does a compilation reference MethodData objects for other methods, > for example when inlining? In that case you need to be sure that we > create a ciInstanceKlass for the method holder of the inlined method. What I see right now is each ciMethodData has owning ciMethod - it is lazily allocated on first request. It should already keep it from deallocation. Not sure whether we need to play safe here and proactively do additional steps to ensure it is kept alive. Best regards, Vladimir Ivanov > /Mikael > >> >> I can narrow the logic to that cases only. What are your thoughts? >> >> Best regards, >> Vladimir Ivanov >> >> On 10/30/14, 12:18 PM, Mikael Gerdin wrote: >>> >>> On 2014-10-29 17:35, Coleen Phillimore wrote: >>>> >>>> On 10/29/14, 12:25 PM, Mikael Gerdin wrote: >>>>> Hi Vladimir, >>>>> >>>>> On 2014-10-29 14:57, Vladimir Ivanov wrote: >>>>>> http://cr.openjdk.java.net/~vlivanov/8060147/webrev.00 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8060147 >>>>>> >>>>>> ciObjectFactory doesn't keep cached Metadata* alive. ciMetadata is >>>>>> different from ciObject - it doesn't store JNI handle, but a raw >>>>>> Metadata* pointer. >>>>>> >>>>>> In order to avoid Metadata* vanishing during compilation, I cache >>>>>> ciObject for it's holder, which should keep corresponding Metadata* >>>>>> alive. Cached objects have the same lifetime as the owning >>>>>> ciObjectFactory (no cache pruning), so Metadata* will be available as >>>>>> long as ciObjectFactory instance is used. >>>>>> >>>>>> Also, cleaned relevant comments and strengthened some asserts (since >>>>>> NULL keys are not allowed). >>>>>> >>>>>> Testing: jprt, stress mode - full Nashorn/Octane with aggressive VM >>>>>> anonymous class unloading (LambdaForm/MethodHandle caching completely >>>>>> turned off). >>>>> >>>>> Have you tried this with G1? >>>>> >>>>> I'm asking because G1's concurrent marking algorithm behaves slightly >>>>> different to the other gcs, and I'm unsure if you need to also need to >>>>> call G1SATBCardTableModRefBS::enqueue (like ensure_metadata_alive >>>>> does). >>>> >>>> ensure_metadata_alive doesn't handle MethodData. Should it? >>> >>> I don't think so. >>> Currently ensure_metadata_alive is needed because metadata pointers >>> embedded in MDOs are converted from "weak" to "strong" references when a >>> MDO is imported into a compilation and its metadata pointers are wrapped >>> in ci objects. >>> >>> At that point the metadata may in fact be otherwise dead, and G1's SATB >>> marking algorithm will correctly determine these to be not alive. This >>> is similar to other read barrier's we've inserted in different places >>> where weak pointers are promoted to strong when running with G1, see >>> java.lang.ref.Reference#get, StringTable, etc. >>> >>>>> >>>>> When implementing class unloading for G1 we saw some similar crashes >>>>> and I think I redeemed them by calling ensure_metadata_alive for >>>>> Metadata retrieved from the MDO's (since MDO's are in fact "weak" >>>>> Metadata references). >>>>> >>>>> Essentially, since we have a compilation executing I thought that the >>>>> reciever of the methods compiled must all be alive, and if the >>>>> receivers are alive then they should keep all the holders alive. >>>>> >>>>> ciInstanceKlass::ciInstanceKlass creates a JNIHandle to the >>>>> class_loader() of an InstanceKlass being wrapped in the CI, perhaps >>>>> that should be changed to klass_holder() to account for anonymous >>>>> classes? >>>> >>>> This is probably unnecessary now with Vladimir's change and why it >>>> didn't crash sooner. >>> >>> Indeed. I sort of see what Vladimir is suggesting as a sledgehammer >>> approach, picking up the holder for every referenced metadata and >>> "interning" it into the ciObjectFactory. >>> >>> What I'm interested to see is if changing to klass_holder() in the >>> ciInstanceKlass is sufficient to solve the current issue because I want >>> to know exactly in what way the compiler needs to access metadata and >>> why it needs otherwise dead metadata. >>> >>> In the end it may be wise to implement Vladimir's suggested change to be >>> sure that we don't crash because we missed something. It depends on if >>> we want to be exact in keeping track of which objects we actually need >>> or if we wrap all the ones we can think of in handles and hope for the >>> best. >>> >>> /Mikael >>> >>>> >>>> Coleen >>>>> >>>>> /Mikael >>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Best regards, >>>>>> Vladimir Ivanov >>>> From paul.sandoz at oracle.com Thu Oct 30 12:54:30 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 30 Oct 2014 13:54:30 +0100 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <54514AC0.7000605@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> <544ACB53.5050700@oracle.com> <54514AC0.7000605@oracle.com> Message-ID: <74FFB34E-3230-477F-B256-1E7122A44D94@oracle.com> On Oct 29, 2014, at 9:14 PM, Vladimir Kozlov wrote: > I hope it is the final version. > > http://cr.openjdk.java.net/~kvn/8054492/webrev.02/ > > Full blown intrinsic is created for Class.cast(). It tries, first, to fold statically the code. If it can't, it calls gen_checkcast() and generate uncommon trap when the exception have to be thrown. Also if we hit uncommon trap too match it will not generate instrinsic with dynamic checks during recompilation, but it still tries to fold it statically. > > Since the intrinsic can be skipped I marked Class.cast() as force_inline method to make sure it is inlined to propagate checkcast information in compiled code. > Created https://bugs.openjdk.java.net/browse/JDK-8062543 to track the replacement of MethodHandleImpl.castReference with Class.cast. > An additional improvement could be made to type checks in intrinsics if we use speculative types. I filed RFE: > https://bugs.openjdk.java.net/browse/JDK-8062477 > > I added new regression test and added compile_id to WB nmethod information. > > Tested jtreg hotspot and jtreg j/l/invoke from jdk, CTW, JPRT, performance. > I also verified it worked. > Nashorn's Octane-Box2D and Octane-DeltaBlue shows few percents improvement. > Yay! Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From roland.westrelin at oracle.com Thu Oct 30 13:04:39 2014 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Thu, 30 Oct 2014 14:04:39 +0100 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <5451F134.1030900@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> <544ACB53.5050700@oracle.com> <54514AC0.7000605@oracle.com> <5451B690.9040309@oracle.com> <268DE38F-F78A-413F-90F1-F6F6DC053889@oracle.com> <5451F134.1030900@oracle.com> Message-ID: <1A9DB3F9-676B-4483-A251-5094960D1216@oracle.com> > http://cr.openjdk.java.net/~kvn/8054492/webrev.04/ That looks good to me. Roland. From evgeniya.stepanova at oracle.com Thu Oct 30 14:05:57 2014 From: evgeniya.stepanova at oracle.com (Evgeniya Stepanova) Date: Thu, 30 Oct 2014 18:05:57 +0400 Subject: RFR: 8062537: [TESTBUG] Conflicting GC combinations in hotspot tests Message-ID: <545245C5.4050504@oracle.com> Hi, Please review changes for 8062537, the OpenJDK/hotspot part of the JDK-8019361 bug: https://bugs.openjdk.java.net/browse/JDK-8062537 fix: http://cr.openjdk.java.net/~eistepan/8062537/webrev.00/ Problem: Some tests explicitly set GC and fail when jtreg set another GC. Solution: Such tests marked with the jtreg tag "requires" to skip test if there is a conflict Tested locally with different GC flags (-XX:+UseG1GC, -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and without any GC flag). Tests are being excluded as expected. No tests failed because of the conflict. Thanks, Evgeniya Stepanova // -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Oct 29 15:31:24 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 29 Oct 2014 08:31:24 -0700 Subject: [9] RFR (S): 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv In-Reply-To: <5450F261.60400@oracle.com> References: <5450F261.60400@oracle.com> Message-ID: <5451084C.2050000@oracle.com> The suggested fix seems correct. Klass* holder; - initialize to NULL. // since cached elements are never removed during ciObjectFactory lifetime. Please, clarify in the comment that ciObjectFactory is created per compilation and lives only during it. Thanks, Vladimir On 10/29/14 6:57 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8060147/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8060147 > > ciObjectFactory doesn't keep cached Metadata* alive. ciMetadata is different from ciObject - it doesn't store JNI > handle, but a raw Metadata* pointer. > > In order to avoid Metadata* vanishing during compilation, I cache ciObject for it's holder, which should keep > corresponding Metadata* alive. Cached objects have the same lifetime as the owning ciObjectFactory (no cache pruning), > so Metadata* will be available as long as ciObjectFactory instance is used. > > Also, cleaned relevant comments and strengthened some asserts (since NULL keys are not allowed). > > Testing: jprt, stress mode - full Nashorn/Octane with aggressive VM anonymous class unloading (LambdaForm/MethodHandle > caching completely turned off). > > Thanks! > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Thu Oct 30 14:55:56 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 30 Oct 2014 18:55:56 +0400 Subject: [9] RFR (S): 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv In-Reply-To: References: <5450F261.60400@oracle.com> <545114DF.7040005@oracle.com> <54511744.4060904@oracle.com> <5451F43A.1010108@oracle.com> <5452128C.4090408@oracle.com> <54522805.5040701@oracle.com> <1421AC31-CBEA-4AED-A657-3C43B258A6DB@oracle.com> <54522357.4070705@oracle.com> <5452425D.7040405@oracle.com> Message-ID: <5452517C.4050104@oracle.com> >> As a solution, _holder can be passed into ciMethod::ciMethod as a parameter. It should fix the problem. > > The first change you suggested (http://cr.openjdk.java.net/~vlivanov/8060147/webrev.00) would fix the ciMethod::ciMethod problem, right? The code would be more robust that way and other similar issues could be avoided. Yes, initial version fixes ciMethod::ciMethod problem. It's also more robust and easier to reason about. The downside is that for every ciMetadata instantiation we do more work. I have an alternative version: http://cr.openjdk.java.net/~vlivanov/8060147/webrev.anon.00/ Initial version (updated): http://cr.openjdk.java.net/~vlivanov/8060147/webrev.01/ I like initial version more, but I don't have strong opinion here. Best regards, Vladimir Ivanov From vladimir.kozlov at oracle.com Thu Oct 30 16:11:52 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Oct 2014 09:11:52 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <74FFB34E-3230-477F-B256-1E7122A44D94@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> <544ACB53.5050700@oracle.com> <54514AC0.7000605@oracle.com> <74FFB34E-3230-477F-B256-1E7122A44D94@oracle.com> Message-ID: <54526348.3080704@oracle.com> Thank you, Paul Vladimir On 10/30/14 5:54 AM, Paul Sandoz wrote: > > On Oct 29, 2014, at 9:14 PM, Vladimir Kozlov wrote: > >> I hope it is the final version. >> >> http://cr.openjdk.java.net/~kvn/8054492/webrev.02/ >> >> Full blown intrinsic is created for Class.cast(). It tries, first, to fold statically the code. If it can't, it calls gen_checkcast() and generate uncommon trap when the exception have to be thrown. Also if we hit uncommon trap too match it will not generate instrinsic with dynamic checks during recompilation, but it still tries to fold it statically. >> >> Since the intrinsic can be skipped I marked Class.cast() as force_inline method to make sure it is inlined to propagate checkcast information in compiled code. >> > > Created > > https://bugs.openjdk.java.net/browse/JDK-8062543 > > to track the replacement of MethodHandleImpl.castReference with Class.cast. > > >> An additional improvement could be made to type checks in intrinsics if we use speculative types. I filed RFE: >> https://bugs.openjdk.java.net/browse/JDK-8062477 >> >> I added new regression test and added compile_id to WB nmethod information. >> >> Tested jtreg hotspot and jtreg j/l/invoke from jdk, CTW, JPRT, performance. >> > > I also verified it worked. > > >> Nashorn's Octane-Box2D and Octane-DeltaBlue shows few percents improvement. >> > > Yay! > > Paul. > From vladimir.kozlov at oracle.com Thu Oct 30 16:12:14 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Oct 2014 09:12:14 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <1A9DB3F9-676B-4483-A251-5094960D1216@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> <544ACB53.5050700@oracle.com> <54514AC0.7000605@oracle.com> <5451B690.9040309@oracle.com> <268DE38F-F78A-413F-90F1-F6F6DC053889@oracle.com> <5451F134.1030900@oracle.com> <1A9DB3F9-676B-4483-A251-5094960D1216@oracle.com> Message-ID: <5452635E.9080906@oracle.com> Thank you, Roland Vlaidmir On 10/30/14 6:04 AM, Roland Westrelin wrote: >> http://cr.openjdk.java.net/~kvn/8054492/webrev.04/ > > That looks good to me. > > Roland. > From vladimir.kozlov at oracle.com Thu Oct 30 16:28:19 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Oct 2014 09:28:19 -0700 Subject: RFR: 8062537: [TESTBUG] Conflicting GC combinations in hotspot tests In-Reply-To: <545245C5.4050504@oracle.com> References: <545245C5.4050504@oracle.com> Message-ID: <54526723.5090602@oracle.com> Change in compiler test is good. Thanks, Vladimir On 10/30/14 7:05 AM, Evgeniya Stepanova wrote: > Hi, > > Please review changes for 8062537, the OpenJDK/hotspot part of the JDK-8019361 > > > bug: https://bugs.openjdk.java.net/browse/JDK-8062537 > fix: http://cr.openjdk.java.net/~eistepan/8062537/webrev.00/ > > Problem: Some tests explicitly set GC and fail when jtreg set another GC. > Solution: Such tests marked with the jtreg tag "requires" to skip test if there is a conflict > > Tested locally with different GC flags (-XX:+UseG1GC, -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and > without any GC flag). Tests are being excluded as expected. No tests failed because of the conflict. > > Thanks, > Evgeniya Stepanova > > // From igor.ignatyev at oracle.com Thu Oct 30 16:50:45 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 30 Oct 2014 19:50:45 +0300 Subject: RFR(XS) : 8036913 : make DeoptimizeALot dependent on number of threads In-Reply-To: <5451867C.2080202@oracle.com> References: <544FDEE0.2040105@oracle.com> <544FE35D.5080003@oracle.com> <5450F04D.9030703@oracle.com> <5450FE21.40106@oracle.com> <54518031.2060102@oracle.com> <5451867C.2080202@oracle.com> Message-ID: <54526C65.9090903@oracle.com> On 10/30/2014 03:29 AM, Vladimir Kozlov wrote: > I thought about something like next comment in places where you add > division: yeah I also thought to add smth like that, but your "add this explanation as a comment" confused me. > > void InterfaceSupport::zombieAll() { > // This method is called by all threads when a thread make > // transition to VM state (for example, runtime calls). > // Divide number of calls by number of threads to avoid > // dependence of ZombieAll events on number of threads. > int value = zombieAllCounter / Threads::number_of_threads(); added almost this comment http://cr.openjdk.java.net/~iignatyev/8036913/webrev.02/ > > Thanks, > Vladimir > > On 10/29/14 5:02 PM, Igor Ignatyev wrote: >> Vladimir/Aleksey, >> >> thanks for review. >> >> the updated webrev w/ the comment: >> http://cr.openjdk.java.net/~iignatyev/8036913/webrev.01/ >> 11 lines changed: 3 ins; 3 del; 5 mod; >> >> Igor >> >> On 10/29/2014 05:48 PM, Vladimir Kozlov wrote: >>> Igor, >>> >>> On 10/29/14 6:49 AM, Igor Ignatyev wrote: >>>> Aleksey, >>>> >>>> zombie/deoptimizeAllCounter are invocation counters of corresponding >>>> function and not counters of the actually happened >>>> events. so they should be incremented on each invocation of the >>>> function. >>> >>> Please, add this explanation as a comment so it would be clear why you >>> divide by number of threads. >>> Changes are fine with that. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> Thanks >>>> Igor >>>> >>>> On 10/28/2014 09:41 PM, Aleksey Shipilev wrote: >>>>> On 28.10.2014 21:22, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev/8036913/webrev.00/ >>>>>> 8 lines changed: 2 ins; 2 del; 4 mod; >>>>> >>>>> Looks good. >>>>> >>>>>> + zombieAllCounter incrementation is moved out of if-else to be >>>>>> aligned >>>>>> w/ deoptimizeAllCounter >>>>> >>>>> Shouldn't it be in reverse, i.e. deoptimizeAllCounter to be moved in >>>>> the >>>>> block? I would think counting the _successful_ deoptimizeAll/zombieAll >>>>> events is more useful. >>>>> >>>>> -Aleksey. >>>>> >>>>> From vladimir.kozlov at oracle.com Thu Oct 30 17:01:53 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Oct 2014 10:01:53 -0700 Subject: RFR(XS) : 8036913 : make DeoptimizeALot dependent on number of threads In-Reply-To: <54526C65.9090903@oracle.com> References: <544FDEE0.2040105@oracle.com> <544FE35D.5080003@oracle.com> <5450F04D.9030703@oracle.com> <5450FE21.40106@oracle.com> <54518031.2060102@oracle.com> <5451867C.2080202@oracle.com> <54526C65.9090903@oracle.com> Message-ID: <54526F01.30209@oracle.com> Looks good. Thanks, Vladimir On 10/30/14 9:50 AM, Igor Ignatyev wrote: > On 10/30/2014 03:29 AM, Vladimir Kozlov wrote: >> I thought about something like next comment in places where you add >> division: > yeah I also thought to add smth like that, but your "add this explanation as a comment" confused me. > >> >> void InterfaceSupport::zombieAll() { >> // This method is called by all threads when a thread make >> // transition to VM state (for example, runtime calls). >> // Divide number of calls by number of threads to avoid >> // dependence of ZombieAll events on number of threads. >> int value = zombieAllCounter / Threads::number_of_threads(); > added almost this comment > > http://cr.openjdk.java.net/~iignatyev/8036913/webrev.02/ >> >> Thanks, >> Vladimir >> >> On 10/29/14 5:02 PM, Igor Ignatyev wrote: >>> Vladimir/Aleksey, >>> >>> thanks for review. >>> >>> the updated webrev w/ the comment: >>> http://cr.openjdk.java.net/~iignatyev/8036913/webrev.01/ >>> 11 lines changed: 3 ins; 3 del; 5 mod; >>> >>> Igor >>> >>> On 10/29/2014 05:48 PM, Vladimir Kozlov wrote: >>>> Igor, >>>> >>>> On 10/29/14 6:49 AM, Igor Ignatyev wrote: >>>>> Aleksey, >>>>> >>>>> zombie/deoptimizeAllCounter are invocation counters of corresponding >>>>> function and not counters of the actually happened >>>>> events. so they should be incremented on each invocation of the >>>>> function. >>>> >>>> Please, add this explanation as a comment so it would be clear why you >>>> divide by number of threads. >>>> Changes are fine with that. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> Thanks >>>>> Igor >>>>> >>>>> On 10/28/2014 09:41 PM, Aleksey Shipilev wrote: >>>>>> On 28.10.2014 21:22, Igor Ignatyev wrote: >>>>>>> http://cr.openjdk.java.net/~iignatyev/8036913/webrev.00/ >>>>>>> 8 lines changed: 2 ins; 2 del; 4 mod; >>>>>> >>>>>> Looks good. >>>>>> >>>>>>> + zombieAllCounter incrementation is moved out of if-else to be >>>>>>> aligned >>>>>>> w/ deoptimizeAllCounter >>>>>> >>>>>> Shouldn't it be in reverse, i.e. deoptimizeAllCounter to be moved in >>>>>> the >>>>>> block? I would think counting the _successful_ deoptimizeAll/zombieAll >>>>>> events is more useful. >>>>>> >>>>>> -Aleksey. >>>>>> >>>>>> From john.r.rose at oracle.com Thu Oct 30 17:28:14 2014 From: john.r.rose at oracle.com (John Rose) Date: Thu, 30 Oct 2014 10:28:14 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <5451F134.1030900@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> <544ACB53.5050700@oracle.com> <54514AC0.7000605@oracle.com> <5451B690.9040309@oracle.com> <268DE38F-F78A-413F-90F1-F6F6DC053889@oracle.com> <5451F134.1030900@oracle.com> Message-ID: <1834BFCE-1887-468F-8D69-3C71FAE27DD6@oracle.com> On Oct 30, 2014, at 1:05 AM, Vladimir Kozlov wrote: > I added AssertionError as you suggested. > And I added new tests for int.class.cast and null.cast. > > http://cr.openjdk.java.net/~kvn/8054492/webrev.04/ Thanks! I'm very happy with the code and the tests. And especially the Nashorn improvement. ? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Oct 30 17:36:47 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Oct 2014 10:36:47 -0700 Subject: [9] RFR [XS] 8054492: Casting can result in redundant null checks in generated code In-Reply-To: <1834BFCE-1887-468F-8D69-3C71FAE27DD6@oracle.com> References: <54386E92.3000006@oracle.com> <4E292A01-0F55-45E2-B517-064C7B7F5384@oracle.com> <5446CE93.9040608@oracle.com> <5446F3FE.7080800@oracle.com> <59103AE9-4EDE-45F3-9D1C-8AA1761F78D9@oracle.com> <07396664-63F2-4AA6-B198-0A6DE6C09DEB@oracle.com> <54488D7D.5080103@oracle.com> <16B81B3E-C1E8-4E80-AC29-3440313BF458@oracle.com> <544ACB53.5050700@oracle.com> <54514AC0.7000605@oracle.com> <5451B690.9040309@oracle.com> <268DE38F-F78A-413F-90F1-F6F6DC053889@oracle.com> <5451F134.1030900@oracle.com> <1834BFCE-1887-468F-8D69-3C71FAE27DD6@oracle.com> Message-ID: <5452772F.1060606@oracle.com> Thank you very much, John. Especially for our discussions. Vladimir On 10/30/14 10:28 AM, John Rose wrote: > On Oct 30, 2014, at 1:05 AM, Vladimir Kozlov > wrote: > >> I added AssertionError as you suggested. >> And I added new tests for int.class.cast and null.cast. >> >> http://cr.openjdk.java.net/~kvn/8054492/webrev.04/ > > Thanks! I'm very happy with the code and the tests. And especially the > Nashorn improvement. > > ? John From vladimir.kozlov at oracle.com Thu Oct 30 18:06:22 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Oct 2014 11:06:22 -0700 Subject: [9] RFR (S): 8060147: SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv In-Reply-To: <5452517C.4050104@oracle.com> References: <5450F261.60400@oracle.com> <545114DF.7040005@oracle.com> <54511744.4060904@oracle.com> <5451F43A.1010108@oracle.com> <5452128C.4090408@oracle.com> <54522805.5040701@oracle.com> <1421AC31-CBEA-4AED-A657-3C43B258A6DB@oracle.com> <54522357.4070705@oracle.com> <5452425D.7040405@oracle.com> <5452517C.4050104@oracle.com> Message-ID: <54527E1E.1070507@oracle.com> I would go with webrev.01 (updated initial version). Regards, Vladimir On 10/30/14 7:55 AM, Vladimir Ivanov wrote: >>> As a solution, _holder can be passed into ciMethod::ciMethod as a >>> parameter. It should fix the problem. >> >> The first change you suggested >> (http://cr.openjdk.java.net/~vlivanov/8060147/webrev.00) would fix the >> ciMethod::ciMethod problem, right? The code would be more robust that >> way and other similar issues could be avoided. > Yes, initial version fixes ciMethod::ciMethod problem. It's also more > robust and easier to reason about. > > The downside is that for every ciMetadata instantiation we do more work. > > I have an alternative version: > http://cr.openjdk.java.net/~vlivanov/8060147/webrev.anon.00/ > > Initial version (updated): > http://cr.openjdk.java.net/~vlivanov/8060147/webrev.01/ > > I like initial version more, but I don't have strong opinion here. > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Thu Oct 30 17:26:40 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 30 Oct 2014 21:26:40 +0400 Subject: [9] RFR (XXS): 8062258: compiler/debug/TraceIterativeGVN.java segfaults in trace_PhaseIterGVN In-Reply-To: <54510129.8080108@oracle.com> References: <5450D639.2050506@oracle.com> <54510129.8080108@oracle.com> Message-ID: <545274D0.3050702@oracle.com> Vladimir, do you suggest to simply skip printing info about dead nodes w/ -XX:+TraceIterativeGVN? Best regards, Vladimir Ivanov On 10/29/14, 7:00 PM, Vladimir Kozlov wrote: > I would suggest to dead node check in trace_PhaseIterGVN() instead of > in MemNode::adr_type(). > So the fix for your JDK-8061995 should fix this problem too. > > Thanks, > Vladimir > > On 10/29/14 4:57 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8062258/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8062258 >> >> Trivial fix to avoid NULL dereference w/ -XX:+TraceIterativeGVN while >> querying adr_type() on dead MemNode. >> >> Testing: failing test. >> >> Best regards, >> Vladimir Ivanov From vladimir.kozlov at oracle.com Thu Oct 30 19:25:04 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Oct 2014 12:25:04 -0700 Subject: [9] RFR (XXS): 8062258: compiler/debug/TraceIterativeGVN.java segfaults in trace_PhaseIterGVN In-Reply-To: <545274D0.3050702@oracle.com> References: <5450D639.2050506@oracle.com> <54510129.8080108@oracle.com> <545274D0.3050702@oracle.com> Message-ID: <54529090.1030200@oracle.com> Hmm, next code in PhaseIterGVN::optimize() worries me. We dump dead nodes before removing them from graph: DEBUG_ONLY(trace_PhaseIterGVN_verbose(n, num_processed++);) if (n->outcnt() != 0) { NOT_PRODUCT(const Type* oldtype = type_or_null(n)); // Do the transformation Node* nn = transform_old(n); NOT_PRODUCT(trace_PhaseIterGVN(n, nn, oldtype);) } else if (!n->is_top()) { remove_dead_node(n); } I am changing my suggestion: fix Node::dump() which calls adr_type() without check. It should not call MemNode::dump_adr_type() because MemNode::dump_spec(), which is called before, already does that and it has NULL check! If you want, you can add " Memory:" output in MemNode::dump_spec() to be similar to Node::dump() output. Thanks, Vladimir On 10/30/14 10:26 AM, Vladimir Ivanov wrote: > Vladimir, do you suggest to simply skip printing info about dead nodes > w/ -XX:+TraceIterativeGVN? > > Best regards, > Vladimir Ivanov > > On 10/29/14, 7:00 PM, Vladimir Kozlov wrote: >> I would suggest to dead node check in trace_PhaseIterGVN() instead of >> in MemNode::adr_type(). >> So the fix for your JDK-8061995 should fix this problem too. >> >> Thanks, >> Vladimir >> >> On 10/29/14 4:57 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8062258/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8062258 >>> >>> Trivial fix to avoid NULL dereference w/ -XX:+TraceIterativeGVN while >>> querying adr_type() on dead MemNode. >>> >>> Testing: failing test. >>> >>> Best regards, >>> Vladimir Ivanov From vladimir.kozlov at oracle.com Thu Oct 30 19:49:33 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Oct 2014 12:49:33 -0700 Subject: RFR(M): 8044186 Introduce a reproducible random generator In-Reply-To: <54522792.5010106@oracle.com> References: <54218BFA.7020803@oracle.com> <542285EC.408@oracle.com> <54228A50.6080406@oracle.com> <5422D36E.9060002@oracle.com> <7DC5F0F7-15A1-4FFD-BCE8-5E857138E25C@oracle.com> <5450AD1E.3030407@oracle.com> <54512891.5070705@oracle.com> <54522792.5010106@oracle.com> Message-ID: <5452964D.301@oracle.com> What is the difference between 'run main' and 'run driver'? I never saw 'driver' before: - * @run main RandomGeneratorTest same - * @run main RandomGeneratorTest noseed - * @run main RandomGeneratorTest different + * @run driver RandomGeneratorTest SAME_SEED + * @run driver RandomGeneratorTest NO_SEED + * @run driver RandomGeneratorTest DIFFERENT_SEED Will it prevent running 6 different process (3 + 3 forked)? I am concern for test's execution run on, say, SPARC with big memory and a lot of threads. Yes, code looks good and relatively compact but consider test's execution time too. Thanks, Vladimir On 10/30/14 4:57 AM, Sergei Kovalev wrote: > Hi Vladimir, > > Would you like to see webrev or diff would be enough? Just in case diff > is ok, I'm attaching it. If you'd like published webrev, please let me > know. > > On 29.10.2014 20:49, Vladimir Kozlov wrote: >> Hi Sergei, >> >> Please create webrev of differences between last webrev.03, which we >> reviewed, and new webrev.00. >> >> Thanks, >> Vladimir >> >> On 10/29/14 2:02 AM, Sergei Kovalev wrote: >>> Hello team. >>> >>> Next round of review: >>> >>> http://cr.openjdk.java.net/~iignatyev/skovalev/8044186/webrev.00/ >>> >>> Main changes: >>> - introduced new test that testing new testlibrary functionality: >>> test/testlibrary_tests/RandomGeneratorTest.java >>> - slightly improved Utility.java in part of SEED variable access. >>> >>> All affected tests passed locally on Linux host. >>> >>> On 24.09.2014 22:36, Igor Veresov wrote: >>>> Looks good. >>>> >>>> igor >>>> >>>> On Sep 24, 2014, at 7:21 AM, Sergei Kovalev >>>> wrote: >>>> >>>>> Update: >>>>> http://cr.openjdk.java.net/~vlivanov/kovalev/8044186/webrev.03/ >>>>> >>>>> Added new testcase test/testlibrary_tests/RandomGeneratorTest.java >>>>> that verify correctness of work for Utils.getRandomInstance() method. >>>>> >>>>> On 24.09.2014 13:09, Sergei Kovalev wrote: >>>>>> Update: >>>>>> http://cr.openjdk.java.net/~vlivanov/kovalev/8044186/webrev.02/ >>>>>> >>>>>> Added new test. >>>>>> Fixed misprint. >>>>>> >>>>>> On 24.09.2014 12:50, Vladimir Ivanov wrote: >>>>>>> Sergei, >>>>>>> >>>>>>> Please, update recently introduced >>>>>>> test/compiler/unsafe/UnsafeRaw.java. >>>>>>> >>>>>>> Best regards, >>>>>>> Vladimir Ivanov >>>>>>> >>>>>>> On 9/23/14, 7:04 PM, Sergei Kovalev wrote: >>>>>>>> Hello all, >>>>>>>> >>>>>>>> Looking for volunteers for review. >>>>>>>> >>>>>>>> I'm working for CR >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8044186 that >>>>>>>> submitted against tests. >>>>>>>> >>>>>>>> There's the several tests which use randomly generated numbers. >>>>>>>> It's >>>>>>>> needed to introduce a way that provide a common manner to >>>>>>>> reproduce the >>>>>>>> same random sequence, set seed. >>>>>>>> >>>>>>>> There are two possible way to provide seed value: >>>>>>>> - system property >>>>>>>> - command line arguments. >>>>>>>> >>>>>>>> I chose system property to provide seed value because it could be >>>>>>>> obtained in any part of code without additional effort. In case >>>>>>>> passing >>>>>>>> seed value as command line argument we have to introduce additional >>>>>>>> logic (and unwanted code) to pass this value in appropriate method. >>>>>>>> >>>>>>>> I introduced factory method getRandomInstance in the file >>>>>>>> Utility.java >>>>>>>> and make reference to this method in all applicable tests. >>>>>>>> There is other utility class: Verifier.java. It used in several >>>>>>>> other >>>>>>>> testcases from test/compiler/intrinsics/mathexact/ package. >>>>>>>> Therefore >>>>>>>> many files contains modifications only for jtreg annotations. >>>>>>>> >>>>>>>> I've tested all related tests locally. All tests passed and seed >>>>>>>> value >>>>>>>> printed to the logs. >>>>>>>> >>>>>>>> links: >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8044186 >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~vlivanov/kovalev/8044186/webrev.01/ >>>>>>>> >>>>>>> >>>>> -- >>>>> With best regards, >>>>> Sergei >>>>> >>>> >>>> >>> >> >> > From bengt.rutisson at oracle.com Thu Oct 30 21:09:11 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Thu, 30 Oct 2014 22:09:11 +0100 Subject: RFR: 8062537: [TESTBUG] Conflicting GC combinations in hotspot tests In-Reply-To: <545245C5.4050504@oracle.com> References: <545245C5.4050504@oracle.com> Message-ID: <5452A8F7.8080709@oracle.com> Hi Evgeniya, On 10/30/14 3:05 PM, Evgeniya Stepanova wrote: > Hi, > > Please review changes for 8062537, the OpenJDK/hotspot part of the > JDK-8019361 > > bug: https://bugs.openjdk.java.net/browse/JDK-8062537 > fix: http://cr.openjdk.java.net/~eistepan/8062537/webrev.00/ > > Problem: Some tests explicitly set GC and fail when jtreg set another GC. > Solution: Such tests marked with the jtreg tag "requires" to skip test > if there is a conflict Thanks for fixing this! It is really great that we finally start sorting this out. First a general comment. The @requires tag has been developed without much cooperation with the GC team. We did have a lot of feedback when it was first presented a year ago, but it does not seem like this feedback was incorporated into the @requires that was eventually built. I think this change that gets proposed now is a big step forward and I won't object to it. But I am pretty convinced that we will soon run in to the limitations of the current @requires implementation and we will have to redo this work. Some of the points I don't really like about the @requires tag are: - the "vm.gc" abstraction is more limiting than helping. It would have been better to just "require" any command line flag. - the requirement should be per @run tag. Right now we have to do what you did in this change and use vm.gc=null even when some tests could actually have been run when a GC was specified. - there are many tests that require more than just a specific GC. Often there are other flags that can't be changed either for the test to work properly. Maybe this is not the right place to discuss the current implementation of the @requires tag. I just want to say that I'm not too happy about how the @requires tag turned out. But assuming we have to use it the way it is now I guess the proposed changeset looks good. > Tested locally with different GC flags (-XX:+UseG1GC, > -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and > without any GC flag). Tests are being excluded as expected. No tests > failed because of the conflict. Have you tested with -Xconcgc too? It's an alias for -XX:+UseConcMarkSweepGC. I think some of the test, like test/gc/startup_warnings/TestDefNewCMS.java, will fail if you run with -XX:+UseParNewGC. Others, like test/gc/startup_warnings/TestParNewCMS.java, will fail if you run with -XX:-UseParNewGC. Could you test these two cases too? Similarly it looks to me like there are tests that will fail if you run them with -XX:-UseParallelOldGC or -XX:+UseParallelOldGC. Just a heads up. These two tests will soon be removed. I'm about to push a changeset that removes them: test/gc/startup_warnings/TestCMSIncrementalMode.java test/gc/startup_warnings/TestCMSNoIncrementalMode.java Is there some way of making sure that all tests are run at one time or another. With this change there is a risk that some tests are never run and always skipped. Will we somehow be tracking what gets skipped and make sure that all tests are at least run once with the correct GC so that it is not skipped all the time? Thanks, Bengt > > Thanks, > Evgeniya Stepanova > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.r.chase at oracle.com Thu Oct 30 21:17:50 2014 From: david.r.chase at oracle.com (David Chase) Date: Thu, 30 Oct 2014 17:17:50 -0400 Subject: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames In-Reply-To: References: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> Message-ID: <0BDCD5DD-CBFB-4A3D-9BAD-7F9912E9237C@oracle.com> New webrevs: http://cr.openjdk.java.net/~drchase/8013267/hotspot.04/ http://cr.openjdk.java.net/~drchase/8013267/jdk.04/ Changes since last RFR: 1) hotspot, the method-renamer has been modified to iterate all the way to the end, because (a) a method can be repeated with different attributes (invokespecial vs invokevirtual) (b) because of rare-but-possible races between Java and Jvm, an entry may temporarily appear twice. 2) jdk: Class.internMemberName was made non-public, exposed through JavaLangAccess Class.classRedefinedCount was made package-visible, exposed through JavaLangAccess. ClassData.intern was modified to be race-safe with class redefinition. The code ?borrowed? from ArrayList was mostly removed, and the call to parallelSort was removed; instead, the array is ?expanded? by duplicating the last element, increasing the size, and sliding elements up by one to open a hole for insertion of the new element. This ensures that existing MemberNames are never accidentally hidden, and that the jvm side never sees nulls. The intern code in ClassData and MemberName had a redefined_count ?transaction token? added so that races between redefinition and membername interning could be detected and the intern retried after a new resolution. A ?transaction? object was added for use by the MemberName-allocating factory methods because the race-detection code was fiddly and ugly, and appeared in several places. The clone+changeReferenceKind+intern idiom was replaced with a method cloneAndChangeReferenceKindAndIntern that included the race detection (slightly less ugly in the case that a membername merely has its reference kind changed). MemberName.compareTo was ?enhanced? to try much harder to return a sensible answer ? where it would previously, in theory never, return a bogus answer, it now, in theory never, works harder to return a correct answer. It now also compares hashCodes correctly (they are integers, possibly negative, subtraction is NOT how you obtain a -/0/+ comparison result). Still to do ? convert RedefineMethodUsedByMultipleMethodHandles into a jtreg test. Passes RedefineMethodUsedByMultipleMethodHandles, passes the failing tests in ute. Passes jtreg of hotspot/{compiler, runtime, gc} and jdk/vm and jdk/sun/{misc,reflect,invoke} Possible concerns: 0) The code that guards against concurrent redefinition has some stores that should not be reordered by the (hotspot) compiler. They take the form: A : store B : volatile store C : store Am I okay? Or do I need to do more than just a volatile store in the middle? (A and C are stores to array elements, so I can?t trivially make them volatile.) Yes, there is a big wordy comment where this happens. 1) the comparison function is completely, bizarrely ad hoc, and essentially impossible to reproduce on the jvm side. That?s not a problem right now, but... 2) Class redefinition is potentially quadratic in the number of methods in a class, if all the methods of that class are unreflected into MethodHandles. Do we think this is a problem? 3) MemberName insertion is expected O(N) where N is the number of MemberNames already interned (unless they are inserted in sorted order, where the sort order is defined by the bizarro-comparison). However, MemberName lookup is O(log N). 4) I need to look into the possible performance regression that Chris and Serguei were talking about. I?m not sure that the old fix will work here at all. Do we need a cleverer data structure? One Java-side option is to create a custom within-array hashtable that would make lookup and insertion O(1) (the JVM should be modified to tolerate nulls, in the array, which is clearly possible). If a hashcode were defined that was easily accessed or understood by the JVM, that would permit faster method redefinition, too. David For reference, here is the class introduced to avoid repetition of the redefinition-detection ugliness: static class InternTransaction { Class tx_class; int txn_token; InternTransaction(Class tx_class) { this.tx_class = tx_class; this.txn_token = internTxnToken(tx_class); } /** * If member_name is not resolved, returns member_name; if is resolved, * attempts to intern member_name (once) while checking for races. * * @param member_name * @return member_name if not resolved, null if racing, otherwise * value of interned member_name. */ MemberName tryIntern(MemberName member_name) { if (member_name.isResolved()) { if (member_name.getClass() != tx_class) { Class prev_tx_class = tx_class; int prev_txn_token = txn_token; tx_class = member_name.getClass(); txn_token = internTxnToken(tx_class); // Zero is a special case. if (txn_token != 0 || prev_txn_token != internTxnToken(prev_tx_class)) { // Resolved class is different and at least one // redef of it occurred, therefore repeat with // proper class for race consistency checking. return null; } } return member_name.intern(txn_token); } else { return member_name; } } } And the code that tap-dances around races with Class redefinition: private > E add(Class klass, int index, E e, int redefined_count) { int oldCapacity = size; Comparable[] element_data = elementData; if (oldCapacity + 1 > element_data.length ) { // Replacing array with a copy is safe; elements are identical. grow(oldCapacity + 1); element_data = elementData; } /* * Careful dance to insert an element. * * Wish to ensure that we do not hide an element of * the array; must also ensure that visible-to-jvm * portion of array never contains nulls; also ensure * that array remains sorted. * * Note that taking a safepoint is also a barrier. */ if (oldCapacity > 0) { element_data[oldCapacity] = element_data[oldCapacity - 1]; // all array elements are non-null and sorted, increase size. // if store to element_data above floats below // store to size on the next line, that will be // inconsistent to the VM if a safepoint occurs here. size += 1; for (int i = oldCapacity; i > index; i--) { // pre: element_data[i] is duplicated at [i+1] element_data[i] = element_data[i - 1]; // post: element_data[i-1] is duplicated at [i] } // element_data[index] is duplicated at [index+1] element_data[index] = (Comparable) e; } else { element_data[index] = (Comparable) e; // Don't want store to element_data[index] above // to float past store to size below, otherwise // VM might see inconsistent state. size += 1; } if (redefined_count == klass.classRedefinedCount()) { return e; } /* The race was lost, must undo insertion and retry the intern * with a new resolution. */ for (int i = index; i < oldCapacity; i++) { element_data[i] = element_data[i+1]; } size -= 1; return null; } On 2014-10-23, at 7:00 PM, John Rose wrote: > On Oct 17, 2014, at 11:16 AM, David Chase wrote: > >> bug: https://bugs.openjdk.java.net/browse/JDK-8013267 >> >> webrevs: >> http://cr.openjdk.java.net/~drchase/8013267/jdk.03/ >> http://cr.openjdk.java.net/~drchase/8013267/hotspot.03/ >> >> related bug: https://bugs.openjdk.java.net/browse/JDK-8042235 > > This is a big 'un. Now that we can modify hotspot and jdk together more easily, it's more feasible to work on. I'm glad to see you taking this on. > > A few comments for background: > > This is a case where more logic should go at the JDK layer, where we can work on it and understand it more readily. > > The JVM layer should supply only a few things for this: > - A mapping from symbolic references to resolved references > - A mapping from reflective stuff (jlr.Method) to resolved references > - A bulk query from a class to its resolved references > > The common thread is that only the JVM knows how to inject metadata into the MemberName type. Other logic, such as caching or interning or registration, is best handled by Java code. > > To complicate things, the JVM also needs to (very infrequently) visit the set of all MemberName's in the world. (Or else we need a turtle under the MN turtle, which we are not doing, thankfully.) That's why there needs to be a coupling where the JVM can "see" the Class.ClassData fields. > >> 1) on the hotspot side, code to adjust the membername table needed to check >> that the data for the membername table was actually allocated (one goal of this >> rfe was to avoid allocating that table) else it would null deref and crash. > > Nice catch. C code doesn't do NPEs very well. > >> 2) on the jdk side, fencepost error in the membername table insertion; the first >> entry could be duplicated ( ?if index > 0? wrong, should be ?if index >= 0?). > > Good. > >> 3) on the jdk side, several of the constructors for MemberNames needed to be >> replaced with factories that would consult the MemberNameTable and avoid >> creating duplicates; again, that was the entire point of this fix. *NOT ALL >> CONSTRUCTORS WERE MODIFIED LIKE THIS?, and there was one curious >> piece of code where it seemed that this might not be what was desired, but it >> was unclear how this would behave in the face of method redefinition. > > Maybe this was a place where the patch was incomplete. > > Since the MemberName type is *private* to the java.lang.invoke package, public constructors are tolerable. (Some or all of them could be made non-public or private, if that makes the code easier to reason about.) > > But among the non-private constructors there is a deep difference between constructors which create an unresolved symbolic reference and constructors which somehow create a MN which is resolved from the start. The former are needed to compose a query to the resolve (and possibly intern) functions. The latter are special cases needed by the user-visible unreflectFoo methods. > >> From >> >> http://cr.openjdk.java.net/~drchase/8013267/jdk.03/src/java.base/share/classes/java/lang/invoke/MemberName.java.html >> >> 1047 private MemberName resolve(byte refKind, MemberName ref, Class lookupClass) { >> 1048 MemberName m = ref.clone(); // JVM will side-effect the ref >> 1049 assert(refKind == m.getReferenceKind()); >> 1050 try { >> 1051 m = MethodHandleNatives.resolve(m, lookupClass); >> 1052 m.checkForTypeAlias(); >> 1053 m.resolution = null; >> 1054 m.intern(); >> >> Note that this performs an ?intern? that ignores what is already found in the table >> and may not place m in the table if a duplicate name is already there. ????????? > > That is: > + m.intern(); // FIXME: Here's where we stopped work the last time around. > > I would try, first: > + m = m.intern(); > >> testing: >> jtreg: >> hotspot/{compiler,runtime,gc} >> jdk/{vm,jdk,sun/{invoke,misc,reflect} >> by-hand: verified that the crash example for 8042235 still crash in an unmodified VM and does not crash in a modified VM. >> >> Modified and retested >> https://bugs.openjdk.java.net/secure/attachment/20184/RedefineMethodUsedByMultipleMethodHandles.java >> Old: >> // Calling fooMH1.vmtarget crashes the VM >> System.out.println("fooMH1.invoke = " + fooMH1.invokeExact()); >> >> New: >> // Calling fooMH1.vmtarget crashes the VM >> System.out.println("fooMH1.invoke = " + fooMH1.invokeExact()); >> System.out.println("fooMH2.invoke = " + fooMH2.invokeExact()); >> >> This turned out to be a reasonable thing to do, since the added line caused a crash till further corrections were made. >> (See fixes 2 and 3 above). >> >> Should RedefineMethodUsedByMultipleMethodHandles.java also be added as a test? > > I would say yes, though I'd defer to an SQE or Serguei on that. > >> Are there other tests that would be good to run ?(and if they are ute tests, the more >> detailed the instructions for how to run them, the better.) > > (Same deference.) > > ? John -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vladimir.x.ivanov at oracle.com Thu Oct 30 20:48:29 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 31 Oct 2014 00:48:29 +0400 Subject: [9] RFR (XXS): 8062258: compiler/debug/TraceIterativeGVN.java segfaults in trace_PhaseIterGVN In-Reply-To: <54529090.1030200@oracle.com> References: <5450D639.2050506@oracle.com> <54510129.8080108@oracle.com> <545274D0.3050702@oracle.com> <54529090.1030200@oracle.com> Message-ID: <5452A41D.1060107@oracle.com> Vladimir, nice observation! http://cr.openjdk.java.net/~vlivanov/8062258/webrev.01/ Best regards, Vladimir Ivanov On 10/30/14, 11:25 PM, Vladimir Kozlov wrote: > Hmm, next code in PhaseIterGVN::optimize() worries me. We dump dead > nodes before removing them from graph: > > DEBUG_ONLY(trace_PhaseIterGVN_verbose(n, num_processed++);) > if (n->outcnt() != 0) { > NOT_PRODUCT(const Type* oldtype = type_or_null(n)); > // Do the transformation > Node* nn = transform_old(n); > NOT_PRODUCT(trace_PhaseIterGVN(n, nn, oldtype);) > } else if (!n->is_top()) { > remove_dead_node(n); > } > > I am changing my suggestion: fix Node::dump() which calls adr_type() > without check. It should not call MemNode::dump_adr_type() because > MemNode::dump_spec(), which is called before, already does that and it > has NULL check! If you want, you can add " Memory:" output in > MemNode::dump_spec() to be similar to Node::dump() output. > > Thanks, > Vladimir > > On 10/30/14 10:26 AM, Vladimir Ivanov wrote: >> Vladimir, do you suggest to simply skip printing info about dead nodes >> w/ -XX:+TraceIterativeGVN? >> >> Best regards, >> Vladimir Ivanov >> >> On 10/29/14, 7:00 PM, Vladimir Kozlov wrote: >>> I would suggest to dead node check in trace_PhaseIterGVN() instead of >>> in MemNode::adr_type(). >>> So the fix for your JDK-8061995 should fix this problem too. >>> >>> Thanks, >>> Vladimir >>> >>> On 10/29/14 4:57 AM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8062258/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8062258 >>>> >>>> Trivial fix to avoid NULL dereference w/ -XX:+TraceIterativeGVN while >>>> querying adr_type() on dead MemNode. >>>> >>>> Testing: failing test. >>>> >>>> Best regards, >>>> Vladimir Ivanov From vladimir.kozlov at oracle.com Thu Oct 30 22:28:16 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Oct 2014 15:28:16 -0700 Subject: [9] RFR (XXS): 8062258: compiler/debug/TraceIterativeGVN.java segfaults in trace_PhaseIterGVN In-Reply-To: <5452A41D.1060107@oracle.com> References: <5450D639.2050506@oracle.com> <54510129.8080108@oracle.com> <545274D0.3050702@oracle.com> <54529090.1030200@oracle.com> <5452A41D.1060107@oracle.com> Message-ID: <5452BB80.9030509@oracle.com> Unfortunately not only MemNode has Type::MEMORY type. PhiNode, SCMemProjNode and others. It looks like you need to fix all places. Change in memnode.cpp is fine but in node.cpp you need: } else if (t == Type::MEMORY && (!is_Mem() || is_LoadStore())) { st->print(" Memory:"); MemNode::dump_adr_type(this, adr_type(), st); Make sure that other Type::MEMORY nodes don't crash in adr_type(). Don't do check under NOT_PRODUCT as in your first fix - just return NULL in all cases. Thanks, Vladimir On 10/30/14 1:48 PM, Vladimir Ivanov wrote: > Vladimir, nice observation! > > http://cr.openjdk.java.net/~vlivanov/8062258/webrev.01/ > > Best regards, > Vladimir Ivanov > > On 10/30/14, 11:25 PM, Vladimir Kozlov wrote: >> Hmm, next code in PhaseIterGVN::optimize() worries me. We dump dead >> nodes before removing them from graph: >> >> DEBUG_ONLY(trace_PhaseIterGVN_verbose(n, num_processed++);) >> if (n->outcnt() != 0) { >> NOT_PRODUCT(const Type* oldtype = type_or_null(n)); >> // Do the transformation >> Node* nn = transform_old(n); >> NOT_PRODUCT(trace_PhaseIterGVN(n, nn, oldtype);) >> } else if (!n->is_top()) { >> remove_dead_node(n); >> } >> >> I am changing my suggestion: fix Node::dump() which calls adr_type() >> without check. It should not call MemNode::dump_adr_type() because >> MemNode::dump_spec(), which is called before, already does that and it >> has NULL check! If you want, you can add " Memory:" output in >> MemNode::dump_spec() to be similar to Node::dump() output. >> >> Thanks, >> Vladimir >> >> On 10/30/14 10:26 AM, Vladimir Ivanov wrote: >>> Vladimir, do you suggest to simply skip printing info about dead nodes >>> w/ -XX:+TraceIterativeGVN? >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 10/29/14, 7:00 PM, Vladimir Kozlov wrote: >>>> I would suggest to dead node check in trace_PhaseIterGVN() instead of >>>> in MemNode::adr_type(). >>>> So the fix for your JDK-8061995 should fix this problem too. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 10/29/14 4:57 AM, Vladimir Ivanov wrote: >>>>> http://cr.openjdk.java.net/~vlivanov/8062258/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8062258 >>>>> >>>>> Trivial fix to avoid NULL dereference w/ -XX:+TraceIterativeGVN while >>>>> querying adr_type() on dead MemNode. >>>>> >>>>> Testing: failing test. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov From dmitry.fazunenko at oracle.com Fri Oct 31 12:56:01 2014 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 31 Oct 2014 16:56:01 +0400 Subject: RFR: 8062537: [TESTBUG] Conflicting GC combinations in hotspot tests In-Reply-To: <5452A8F7.8080709@oracle.com> References: <545245C5.4050504@oracle.com> <5452A8F7.8080709@oracle.com> Message-ID: <545386E1.2050402@oracle.com> Hi Bengt, Thanks a lot for your detailed feedback, we appreciate it very much! See comments inline. On 31.10.2014 1:09, Bengt Rutisson wrote: > > Hi Evgeniya, > > On 10/30/14 3:05 PM, Evgeniya Stepanova wrote: >> Hi, >> >> Please review changes for 8062537, the OpenJDK/hotspot part of the >> JDK-8019361 >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8062537 >> fix: http://cr.openjdk.java.net/~eistepan/8062537/webrev.00/ >> >> Problem: Some tests explicitly set GC and fail when jtreg set another GC. >> Solution: Such tests marked with the jtreg tag "requires" to skip >> test if there is a conflict > > Thanks for fixing this! It is really great that we finally start > sorting this out. > > First a general comment. The @requires tag has been developed without > much cooperation with the GC team. We did have a lot of feedback when > it was first presented a year ago, but it does not seem like this > feedback was incorporated into the @requires that was eventually built. We tried to implement as much developer's wishes as possible. But not everything is possible, sorry for that. > > I think this change that gets proposed now is a big step forward and I > won't object to it. But I am pretty convinced that we will soon run in > to the limitations of the current @requires implementation and we will > have to redo this work. > > Some of the points I don't really like about the @requires tag are: > > - the "vm.gc" abstraction is more limiting than helping. It would have > been better to just "require" any command line flag. "vm.gc" is an alias to a very popular flag. It's also possible to use: vm.opt.UseG1GC == true instead. The table with all vars available in jtreg: http://jre.us.oracle.com/java/re/jtreg/4.1/promoted/latest/binaries/jtreg/doc/jtreg/tag-spec.html#requires_names > - the requirement should be per @run tag. Right now we have to do what > you did in this change and use vm.gc=null even when some tests could > actually have been run when a GC was specified. it would be great, but it will unlikely happen in jtreg, as well as test case support. > - there are many tests that require more than just a specific GC. > Often there are other flags that can't be changed either for the test > to work properly. yes. conflicting GC is just the most popular problem caused by conflicting options. If we address this issue and we are satisfied with solution, we could move further. > > Maybe this is not the right place to discuss the current > implementation of the @requires tag. I just want to say that I'm not > too happy about how the @requires tag turned out. But assuming we have > to use it the way it is now I guess the proposed changeset looks good. yes, this thread is about change made by Evgeniya, not about jtreg :) And thanks for reviewing it! > >> Tested locally with different GC flags (-XX:+UseG1GC, >> -XX:+UseParallelGC, -XX:+UseSerialGC, -XX:+UseConcMarkSweep and >> without any GC flag). Tests are being excluded as expected. No tests >> failed because of the conflict. > Have you tested with -Xconcgc too? It's an alias for > -XX:+UseConcMarkSweepGC. '-Xconcgc' is not supported yet. (bug in jtreg, I will submit) > > I think some of the test, like > test/gc/startup_warnings/TestDefNewCMS.java, will fail if you run with > -XX:+UseParNewGC. Others, like > test/gc/startup_warnings/TestParNewCMS.java, will fail if you run with > -XX:-UseParNewGC. Could you test these two cases too? These two tests ignore vm flags. Add @requires here is not necessary, but it will allow not execute the tests when not needed. So, if we run HS tests with 4 GC, we don't need to run these tests 4 times, 1 should be enough. > > Similarly it looks to me like there are tests that will fail if you > run them with -XX:-UseParallelOldGC or -XX:+UseParallelOldGC. > > Just a heads up. These two tests will soon be removed. I'm about to > push a changeset that removes them: > > test/gc/startup_warnings/TestCMSIncrementalMode.java > test/gc/startup_warnings/TestCMSNoIncrementalMode.java okay, thank for letting us know. > > Is there some way of making sure that all tests are run at one time or > another. With this change there is a risk that some tests are never > run and always skipped. Will we somehow be tracking what gets skipped > and make sure that all tests are at least run once with the correct GC > so that it is not skipped all the time? This is a very good question! jtreg now doesn't report skipped tests, hopefully it will do soon, after getting fix of: https://bugs.openjdk.java.net/browse/CODETOOLS-7900934 And yes, tracking tests which are not run is important thing. @requires - is not the only to exclude test from execution. Other examples: /* *@ignore *@test */ ... /*@bug 4445555 *@test */ ... Such tests will never be run, because jtreg treats as test only files with @test on the first place... So, making sure that tests do not disappear is important SQE task, we know about that, we're thinking on solution (may be very actively). But this subject for another discussion, not within RFR :) Thanks, Dima > > Thanks, > Bengt > >> >> Thanks, >> Evgeniya Stepanova >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duboscq at ssw.jku.at Fri Oct 31 15:17:35 2014 From: duboscq at ssw.jku.at (Gilles Duboscq) Date: Fri, 31 Oct 2014 16:17:35 +0100 Subject: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames In-Reply-To: <0BDCD5DD-CBFB-4A3D-9BAD-7F9912E9237C@oracle.com> References: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> <0BDCD5DD-CBFB-4A3D-9BAD-7F9912E9237C@oracle.com> Message-ID: On Thu, Oct 30, 2014 at 10:17 PM, David Chase wrote: > New webrevs: > http://cr.openjdk.java.net/~drchase/8013267/hotspot.04/ > http://cr.openjdk.java.net/~drchase/8013267/jdk.04/ > > Changes since last RFR: > > 1) hotspot, the method-renamer has been modified to iterate all the way to the end, > because > (a) a method can be repeated with different attributes (invokespecial vs invokevirtual) > (b) because of rare-but-possible races between Java and Jvm, an entry may temporarily appear twice. > > 2) jdk: > Class.internMemberName was made non-public, exposed through JavaLangAccess > > Class.classRedefinedCount was made package-visible, exposed through JavaLangAccess. > > ClassData.intern was modified to be race-safe with class redefinition. The code ?borrowed? > from ArrayList was mostly removed, and the call to parallelSort was removed; instead, the > array is ?expanded? by duplicating the last element, increasing the size, and sliding elements > up by one to open a hole for insertion of the new element. This ensures that existing > MemberNames are never accidentally hidden, and that the jvm side never sees nulls. > > The intern code in ClassData and MemberName had a redefined_count ?transaction token? > added so that races between redefinition and membername interning could be detected > and the intern retried after a new resolution. > > A ?transaction? object was added for use by the MemberName-allocating factory methods > because the race-detection code was fiddly and ugly, and appeared in several places. > > The clone+changeReferenceKind+intern idiom was replaced with a method > cloneAndChangeReferenceKindAndIntern that included the race detection (slightly > less ugly in the case that a membername merely has its reference kind changed). > > MemberName.compareTo was ?enhanced? to try much harder to return a sensible > answer ? where it would previously, in theory never, return a bogus answer, it > now, in theory never, works harder to return a correct answer. It now also compares > hashCodes correctly (they are integers, possibly negative, subtraction is NOT how > you obtain a -/0/+ comparison result). > > Still to do ? convert RedefineMethodUsedByMultipleMethodHandles into a jtreg test. > > Passes RedefineMethodUsedByMultipleMethodHandles, passes the failing tests in ute. > Passes jtreg of hotspot/{compiler, runtime, gc} and jdk/vm and jdk/sun/{misc,reflect,invoke} > > Possible concerns: > > 0) The code that guards against concurrent redefinition has some stores that should not > be reordered by the (hotspot) compiler. They take the form: > A : store > B : volatile store > C : store > Am I okay? Or do I need to do more than just a volatile store in the middle? (A and C are > stores to array elements, so I can?t trivially make them volatile.) Yes, there is a big wordy > comment where this happens. I think B and C can be reordered, i.e., A, C, B is a valid execution order and the VM will not emit any barrier to ensure that B is observed before C. > > 1) the comparison function is completely, bizarrely ad hoc, and essentially impossible > to reproduce on the jvm side. That?s not a problem right now, but... > > 2) Class redefinition is potentially quadratic in the number of methods in a class, if all the > methods of that class are unreflected into MethodHandles. Do we think this is a problem? > > 3) MemberName insertion is expected O(N) where N is the number of MemberNames already > interned (unless they are inserted in sorted order, where the sort order is defined by the > bizarro-comparison). > > However, MemberName lookup is O(log N). > > 4) I need to look into the possible performance regression that Chris and Serguei were talking about. > I?m not sure that the old fix will work here at all. > > Do we need a cleverer data structure? One Java-side option is to create a custom within-array > hashtable that would make lookup and insertion O(1) (the JVM should be modified to tolerate nulls, > in the array, which is clearly possible). If a hashcode were defined that was easily accessed or > understood by the JVM, that would permit faster method redefinition, too. > > David > > For reference, here is the class introduced to avoid repetition of the redefinition-detection ugliness: > > static class InternTransaction { > Class tx_class; > int txn_token; > > InternTransaction(Class tx_class) { > this.tx_class = tx_class; > this.txn_token = internTxnToken(tx_class); > } > > /** > * If member_name is not resolved, returns member_name; if is resolved, > * attempts to intern member_name (once) while checking for races. > * > * @param member_name > * @return member_name if not resolved, null if racing, otherwise > * value of interned member_name. > */ > MemberName tryIntern(MemberName member_name) { > if (member_name.isResolved()) { > if (member_name.getClass() != tx_class) { > Class prev_tx_class = tx_class; > int prev_txn_token = txn_token; > tx_class = member_name.getClass(); > txn_token = internTxnToken(tx_class); > // Zero is a special case. > if (txn_token != 0 || > prev_txn_token != internTxnToken(prev_tx_class)) { > // Resolved class is different and at least one > // redef of it occurred, therefore repeat with > // proper class for race consistency checking. > return null; > } > } > return member_name.intern(txn_token); > } else { > return member_name; > } > } > } > > And the code that tap-dances around races with Class redefinition: > > private > E add(Class klass, int index, E e, int redefined_count) { > int oldCapacity = size; > Comparable[] element_data = elementData; > if (oldCapacity + 1 > element_data.length ) { > // Replacing array with a copy is safe; elements are identical. > grow(oldCapacity + 1); > element_data = elementData; > } > /* > * Careful dance to insert an element. > * > * Wish to ensure that we do not hide an element of > * the array; must also ensure that visible-to-jvm > * portion of array never contains nulls; also ensure > * that array remains sorted. > * > * Note that taking a safepoint is also a barrier. > */ > if (oldCapacity > 0) { > element_data[oldCapacity] = element_data[oldCapacity - 1]; > // all array elements are non-null and sorted, increase size. > // if store to element_data above floats below > // store to size on the next line, that will be > // inconsistent to the VM if a safepoint occurs here. > size += 1; > for (int i = oldCapacity; i > index; i--) { > // pre: element_data[i] is duplicated at [i+1] > element_data[i] = element_data[i - 1]; > // post: element_data[i-1] is duplicated at [i] > } > // element_data[index] is duplicated at [index+1] > element_data[index] = (Comparable) e; > } else { > element_data[index] = (Comparable) e; > // Don't want store to element_data[index] above > // to float past store to size below, otherwise > // VM might see inconsistent state. > size += 1; > } > if (redefined_count == klass.classRedefinedCount()) { > return e; > } > /* The race was lost, must undo insertion and retry the intern > * with a new resolution. > */ > for (int i = index; i < oldCapacity; i++) { > element_data[i] = element_data[i+1]; > } > size -= 1; > return null; > } > > > On 2014-10-23, at 7:00 PM, John Rose wrote: > >> On Oct 17, 2014, at 11:16 AM, David Chase wrote: >> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8013267 >>> >>> webrevs: >>> http://cr.openjdk.java.net/~drchase/8013267/jdk.03/ >>> http://cr.openjdk.java.net/~drchase/8013267/hotspot.03/ >>> >>> related bug: https://bugs.openjdk.java.net/browse/JDK-8042235 >> >> This is a big 'un. Now that we can modify hotspot and jdk together more easily, it's more feasible to work on. I'm glad to see you taking this on. >> >> A few comments for background: >> >> This is a case where more logic should go at the JDK layer, where we can work on it and understand it more readily. >> >> The JVM layer should supply only a few things for this: >> - A mapping from symbolic references to resolved references >> - A mapping from reflective stuff (jlr.Method) to resolved references >> - A bulk query from a class to its resolved references >> >> The common thread is that only the JVM knows how to inject metadata into the MemberName type. Other logic, such as caching or interning or registration, is best handled by Java code. >> >> To complicate things, the JVM also needs to (very infrequently) visit the set of all MemberName's in the world. (Or else we need a turtle under the MN turtle, which we are not doing, thankfully.) That's why there needs to be a coupling where the JVM can "see" the Class.ClassData fields. >> >>> 1) on the hotspot side, code to adjust the membername table needed to check >>> that the data for the membername table was actually allocated (one goal of this >>> rfe was to avoid allocating that table) else it would null deref and crash. >> >> Nice catch. C code doesn't do NPEs very well. >> >>> 2) on the jdk side, fencepost error in the membername table insertion; the first >>> entry could be duplicated ( ?if index > 0? wrong, should be ?if index >= 0?). >> >> Good. >> >>> 3) on the jdk side, several of the constructors for MemberNames needed to be >>> replaced with factories that would consult the MemberNameTable and avoid >>> creating duplicates; again, that was the entire point of this fix. *NOT ALL >>> CONSTRUCTORS WERE MODIFIED LIKE THIS?, and there was one curious >>> piece of code where it seemed that this might not be what was desired, but it >>> was unclear how this would behave in the face of method redefinition. >> >> Maybe this was a place where the patch was incomplete. >> >> Since the MemberName type is *private* to the java.lang.invoke package, public constructors are tolerable. (Some or all of them could be made non-public or private, if that makes the code easier to reason about.) >> >> But among the non-private constructors there is a deep difference between constructors which create an unresolved symbolic reference and constructors which somehow create a MN which is resolved from the start. The former are needed to compose a query to the resolve (and possibly intern) functions. The latter are special cases needed by the user-visible unreflectFoo methods. >> >>> From >>> >>> http://cr.openjdk.java.net/~drchase/8013267/jdk.03/src/java.base/share/classes/java/lang/invoke/MemberName.java.html >>> >>> 1047 private MemberName resolve(byte refKind, MemberName ref, Class lookupClass) { >>> 1048 MemberName m = ref.clone(); // JVM will side-effect the ref >>> 1049 assert(refKind == m.getReferenceKind()); >>> 1050 try { >>> 1051 m = MethodHandleNatives.resolve(m, lookupClass); >>> 1052 m.checkForTypeAlias(); >>> 1053 m.resolution = null; >>> 1054 m.intern(); >>> >>> Note that this performs an ?intern? that ignores what is already found in the table >>> and may not place m in the table if a duplicate name is already there. ????????? >> >> That is: >> + m.intern(); // FIXME: Here's where we stopped work the last time around. >> >> I would try, first: >> + m = m.intern(); >> >>> testing: >>> jtreg: >>> hotspot/{compiler,runtime,gc} >>> jdk/{vm,jdk,sun/{invoke,misc,reflect} >>> by-hand: verified that the crash example for 8042235 still crash in an unmodified VM and does not crash in a modified VM. >>> >>> Modified and retested >>> https://bugs.openjdk.java.net/secure/attachment/20184/RedefineMethodUsedByMultipleMethodHandles.java >>> Old: >>> // Calling fooMH1.vmtarget crashes the VM >>> System.out.println("fooMH1.invoke = " + fooMH1.invokeExact()); >>> >>> New: >>> // Calling fooMH1.vmtarget crashes the VM >>> System.out.println("fooMH1.invoke = " + fooMH1.invokeExact()); >>> System.out.println("fooMH2.invoke = " + fooMH2.invokeExact()); >>> >>> This turned out to be a reasonable thing to do, since the added line caused a crash till further corrections were made. >>> (See fixes 2 and 3 above). >>> >>> Should RedefineMethodUsedByMultipleMethodHandles.java also be added as a test? >> >> I would say yes, though I'd defer to an SQE or Serguei on that. >> >>> Are there other tests that would be good to run ?(and if they are ute tests, the more >>> detailed the instructions for how to run them, the better.) >> >> (Same deference.) >> >> ? John > - Gilles From aleksey.shipilev at oracle.com Fri Oct 31 17:09:04 2014 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 31 Oct 2014 20:09:04 +0300 Subject: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames In-Reply-To: <0BDCD5DD-CBFB-4A3D-9BAD-7F9912E9237C@oracle.com> References: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> <0BDCD5DD-CBFB-4A3D-9BAD-7F9912E9237C@oracle.com> Message-ID: <5453C230.8010709@oracle.com> On 31.10.2014 00:17, David Chase wrote: > 0) The code that guards against concurrent redefinition has some stores that should not > be reordered by the (hotspot) compiler. They take the form: > A : store > B : volatile store > C : store > Am I okay? Or do I need to do more than just a volatile store in the middle? (A and C are > stores to array elements, so I can?t trivially make them volatile.) Yes, there is a big wordy > comment where this happens. JMM-wise, that sequence of stores is "reorderable" into ACB and CAB. Even if compiler does not reorder, weakly ordered architectures might do that for you under cover. Since you are already on mostly-VM side of things, you are better off doing the explicit Unsafe.*fence-s? However, I fail to match your example to your code. Where's A, B, C? I can guess: A: "element_data[oldCap] = element_data[oldCap-1]" B: "size++" // note: this is BOTH volatile read and volatile store C: "element_data[i] = element_data[i-1]" ??? Thanks, -Aleksey. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From david.r.chase at oracle.com Fri Oct 31 18:11:23 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 31 Oct 2014 14:11:23 -0400 Subject: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames In-Reply-To: <5453C230.8010709@oracle.com> References: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> <0BDCD5DD-CBFB-4A3D-9BAD-7F9912E9237C@oracle.com> <5453C230.8010709@oracle.com> Message-ID: <9747A3A3-B7F4-407A-8E00-1E647D9DC2D1@oracle.com> On 2014-10-31, at 1:09 PM, Aleksey Shipilev wrote: > On 31.10.2014 00:17, David Chase wrote: >> 0) The code that guards against concurrent redefinition has some stores that should not >> be reordered by the (hotspot) compiler. They take the form: >> A : store >> B : volatile store >> C : store >> Am I okay? Or do I need to do more than just a volatile store in the middle? (A and C are >> stores to array elements, so I can?t trivially make them volatile.) Yes, there is a big wordy >> comment where this happens. > > JMM-wise, that sequence of stores is "reorderable" into ACB and CAB. > Even if compiler does not reorder, weakly ordered architectures might do > that for you under cover. Since you are already on mostly-VM side of > things, you are better off doing the explicit Unsafe.*fence-s? > > However, I fail to match your example to your code. Where's A, B, C? > > I can guess: > A: "element_data[oldCap] = element_data[oldCap-1]" > B: "size++" // note: this is BOTH volatile read and volatile store > C: "element_data[i] = element_data[i-1]" ??? That is the correct values of A/B/C ? I missed the volatile read. Does the combined volatile read and volatile write get me what I need, or do I still need to drop a barrier in there? I?m not worried about architectural reordering, because the concurrent event is a global safepoint ? officially I have no guarantee that the compiler won?t put that somewhere inconvenient for me which is why I have to code carefully and worry about what the compiler might do, but I do assume that if the safepoint occurs, all writes that nominally precede it will in fact complete before jvm code is entered. (Note that this is a vanishingly rare but still possible event ? it requires intern of a previously non-interned MemberName racing with class redefinition.) I found a lurking bug and updated the webrevs ? I was mistaken about this version having passed the ute tests (but now, for real, it does). I also added converted Christian?s test code into a jtreg test (which passes): http://cr.openjdk.java.net/~drchase/8013267/hotspot.05/ http://cr.openjdk.java.net/~drchase/8013267/jdk.05/ I am not excited about adding a level of indirection and converting all this to jmethodid ? are there other opinions here? I?ve attempted to confine and document the race-sensitive ugliness. David -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From vitalyd at gmail.com Fri Oct 31 21:45:38 2014 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 31 Oct 2014 17:45:38 -0400 Subject: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames In-Reply-To: <9747A3A3-B7F4-407A-8E00-1E647D9DC2D1@oracle.com> References: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> <0BDCD5DD-CBFB-4A3D-9BAD-7F9912E9237C@oracle.com> <5453C230.8010709@oracle.com> <9747A3A3-B7F4-407A-8E00-1E647D9DC2D1@oracle.com> Message-ID: The volatile load prevents subsequent loads and stores from reordering with it, but that doesn't stop C from moving before the B store. So breaking B into the load (call it BL) and store (BS) you can still get this ordering: A, BL, C, BS Sent from my phone On Oct 31, 2014 2:11 PM, "David Chase" wrote: > > On 2014-10-31, at 1:09 PM, Aleksey Shipilev > wrote: > > On 31.10.2014 00:17, David Chase wrote: > >> 0) The code that guards against concurrent redefinition has some stores > that should not > >> be reordered by the (hotspot) compiler. They take the form: > >> A : store > >> B : volatile store > >> C : store > >> Am I okay? Or do I need to do more than just a volatile store in the > middle? (A and C are > >> stores to array elements, so I can?t trivially make them volatile.) > Yes, there is a big wordy > >> comment where this happens. > > > > JMM-wise, that sequence of stores is "reorderable" into ACB and CAB. > > Even if compiler does not reorder, weakly ordered architectures might do > > that for you under cover. Since you are already on mostly-VM side of > > things, you are better off doing the explicit Unsafe.*fence-s? > > > > However, I fail to match your example to your code. Where's A, B, C? > > > > I can guess: > > A: "element_data[oldCap] = element_data[oldCap-1]" > > B: "size++" // note: this is BOTH volatile read and volatile store > > C: "element_data[i] = element_data[i-1]" ??? > > That is the correct values of A/B/C ? I missed the volatile read. > Does the combined volatile read and volatile write get me what I need, > or do I still need to drop a barrier in there? > > I?m not worried about architectural reordering, because the concurrent > event > is a global safepoint ? officially I have no guarantee that the compiler > won?t > put that somewhere inconvenient for me which is why I have to code > carefully > and worry about what the compiler might do, but I do assume that if the > safepoint > occurs, all writes that nominally precede it will in fact complete before > jvm code > is entered. (Note that this is a vanishingly rare but still possible > event ? it > requires intern of a previously non-interned MemberName racing with class > redefinition.) > > I found a lurking bug and updated the webrevs ? I was mistaken > about this version having passed the ute tests (but now, for real, it > does). > > I also added converted Christian?s test code into a jtreg test (which > passes): > > http://cr.openjdk.java.net/~drchase/8013267/hotspot.05/ > http://cr.openjdk.java.net/~drchase/8013267/jdk.05/ > > I am not excited about adding a level of indirection and converting all > this > to jmethodid ? are there other opinions here? I?ve attempted to confine > and document the race-sensitive ugliness. > > David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.r.chase at oracle.com Fri Oct 31 22:59:05 2014 From: david.r.chase at oracle.com (David Chase) Date: Fri, 31 Oct 2014 18:59:05 -0400 Subject: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames In-Reply-To: <545406BC.20005@gmail.com> References: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> <0BDCD5DD-CBFB-4A3D-9BAD-7F9912E9237C@oracle.com> <5453C230.8010709@oracle.com> <9747A3A3-B7F4-407A-8E00-1E647D9DC2D1@oracle.com> <545406BC.20005@gmail.com> Message-ID: Thanks very much, I shall attend to these irregularities. David On 2014-10-31, at 6:01 PM, Peter Levart wrote: > > On 10/31/2014 07:11 PM, David Chase wrote: >> I found a lurking bug and updated the webrevs ? I was mistaken >> about this version having passed the ute tests (but now, for real, it does). >> >> I also added converted Christian?s test code into a jtreg test (which passes): >> >> >> http://cr.openjdk.java.net/~drchase/8013267/hotspot.05/ >> http://cr.openjdk.java.net/~drchase/8013267/jdk.05/ > > Hi David, > > I'll just comment on the JDK side of things. > > In Class.ClassData.intern(), ther is a part that synchronizes on the elementData (volatile field holding array of Comparable(s)): > > 2500 synchronized (elementData) { > 2501 final int index = Arrays.binarySearch(elementData, 0, size, memberName); > 2502 if (index >= 0) { > 2503 return (E) elementData[index]; > 2504 } > 2505 // Not found, add carefully. > 2506 return add(klass, ~index, memberName, redefined_count); > 2507 } > > Inside this synchronized block, add() method is called, which can call grow() method: > > 2522 if (oldCapacity + 1 > element_data.length ) { > 2523 // Replacing array with a copy is safe; elements are identical. > 2524 grow(oldCapacity + 1); > 2525 element_data = elementData; > 2526 } > > grow() method creates a copy of elementData array and replaces it on this volatile field (line 2584): > > 2577 private void grow(int minCapacity) { > 2578 // overflow-conscious code > 2579 int oldCapacity = elementData.length; > 2580 int newCapacity = oldCapacity + (oldCapacity >> 1); > 2581 if (newCapacity - minCapacity < 0) > 2582 newCapacity = minCapacity; > 2583 // minCapacity is usually close to size, so this is a win: > 2584 elementData = Arrays.copyOf(elementData, newCapacity); > 2585 } > > A concurrent call to intern() can therefore synchronize on a different monitor, so two threads will be inserting the element into the same array at the same time, Auch! > > > > Also, lazy construction of ClassData instance: > > 2593 private ClassData classData() { > 2594 if (this.classData != null) { > 2595 return this.classData; > 2596 } > 2597 synchronized (this) { > 2598 if (this.classData == null) { > 2599 this.classData = new ClassData<>(); > 2600 } > 2601 } > 2602 return this.classData; > 2603 } > > Synchronizes on the j.l.Class instance, which can interfere with user synchronization (think synchronized static methods). This dangerous. > > Theres an inner class Class.Atomic which is a home for Unsafe machinery in j.l.Class. You can add a casClassData method to it and use it to atomically install the ClassData instance without synchronized blocks. > > > > Regards, Peter > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From peter.levart at gmail.com Fri Oct 31 22:01:32 2014 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 31 Oct 2014 23:01:32 +0100 Subject: [9] RFR(L) 8013267 : move MemberNameTable from native code to Java heap, use to intern MemberNames In-Reply-To: <9747A3A3-B7F4-407A-8E00-1E647D9DC2D1@oracle.com> References: <594FE416-D445-426E-B7A9-C75F012ADE16@oracle.com> <0BDCD5DD-CBFB-4A3D-9BAD-7F9912E9237C@oracle.com> <5453C230.8010709@oracle.com> <9747A3A3-B7F4-407A-8E00-1E647D9DC2D1@oracle.com> Message-ID: <545406BC.20005@gmail.com> On 10/31/2014 07:11 PM, David Chase wrote: > I found a lurking bug and updated the webrevs ? I was mistaken > about this version having passed the ute tests (but now, for real, it does). > > I also added converted Christian?s test code into a jtreg test (which passes): > > http://cr.openjdk.java.net/~drchase/8013267/hotspot.05/ > http://cr.openjdk.java.net/~drchase/8013267/jdk.05/ Hi David, I'll just comment on the JDK side of things. In Class.ClassData.intern(), ther is a part that synchronizes on the elementData (volatile field holding array of Comparable(s)): 2500 synchronized (elementData) { 2501 final int index = Arrays.binarySearch(elementData, 0, size, memberName); 2502 if (index >= 0) { 2503 return (E) elementData[index]; 2504 } 2505 // Not found, add carefully. 2506 return add(klass, ~index, memberName, redefined_count); 2507 } Inside this synchronized block, add() method is called, which can call grow() method: 2522 if (oldCapacity + 1 > element_data.length ) { 2523 // Replacing array with a copy is safe; elements are identical. 2524 grow(oldCapacity + 1); 2525 element_data = elementData; 2526 } grow() method creates a copy of elementData array and replaces it on this volatile field (line 2584): 2577 private void grow(int minCapacity) { 2578 // overflow-conscious code 2579 int oldCapacity = elementData.length; 2580 int newCapacity = oldCapacity + (oldCapacity >> 1); 2581 if (newCapacity - minCapacity < 0) 2582 newCapacity = minCapacity; 2583 // minCapacity is usually close to size, so this is a win: 2584 elementData = Arrays.copyOf(elementData, newCapacity); 2585 } A concurrent call to intern() can therefore synchronize on a different monitor, so two threads will be inserting the element into the same array at the same time, Auch! Also, lazy construction of ClassData instance: 2593 private ClassData classData() { 2594 if (this.classData != null) { 2595 return this.classData; 2596 } 2597 synchronized (this) { 2598 if (this.classData == null) { 2599 this.classData = new ClassData<>(); 2600 } 2601 } 2602 return this.classData; 2603 } Synchronizes on the j.l.Class instance, which can interfere with user synchronization (think synchronized static methods). This dangerous. Theres an inner class Class.Atomic which is a home for Unsafe machinery in j.l.Class. You can add a casClassData method to it and use it to atomically install the ClassData instance without synchronized blocks. Regards, Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: